Forem: code plato

Do We Still Need to Practice Programming in the AI Era?

code plato — Mon, 25 May 2026 22:25:24 +0000

"Vibe Coding" is having a moment. So — do we still need to practice programming?

My answer is yes.

I've written before about using AI to distill reading material and quickly grasp the structure of an article. But a few fundamental realities won't change just because AI showed up.

The rate at which the human brain absorbs knowledge hasn't changed. No matter how fast AI technology advances, your personal learning speed doesn't automatically accelerate with it. There are no real shortcuts to learning.
AI was trained on both good code and bad code. Bad code isn't always incorrect code — it can simply be code that smells, is hard to maintain, or has a chaotic architecture. If you can't spot the problem yourself, AI often won't spot it either.

Example 1

Experienced developers and beginners literally see different things when they look at the same code.

Imagine you're working in React and you come across this:

const phone = {
  name: 'iPhone',
  price: {
    payInFull: 1000,
    monthlyFin: 99
  }
};

Your product manager asks you to add a "snapshot page" — a page that displays the product's current state frozen at a point in time, so that even if the product data changes later, the snapshot stays the same.

AI quickly generates this:

const phone = {
  name: 'iPhone',
  price: {
    payInFull: 1000,
    monthlyFin: 99
  }
};

<Snapshot {...phone} />

You see {...phone} and think: "Got it — that's an object copy."

A short while later, customer support files a bug: after the price is updated in the parent component, the price on the snapshot page updates too.

You're baffled. This shouldn't be happening.

After digging in, you realize:

<Snapshot {...phone} />

is not the same as:

const snapshot = {...phone}

The former is just React's props spread syntax sugar.

So you update the code:

const snapshot = {...phone};
<Snapshot {...snapshot} />

Still broken.

Eventually you find the fix:

const snapshot = structuredClone(phone);

Someone who has been burned by this before — or who genuinely studied JavaScript's object reference model — would have spotted the problem immediately. Someone who hasn't would go down the same rabbit hole.

Example 2

Have you ever felt completely fluent while watching a tutorial, only to draw a total blank the moment you sit down to write the code yourself?

I was working through a Data Science course recently. The material wasn't particularly complex for a software engineer:

top1 = Table.read_table(path_data + 'top_movies_2017.csv')

But when I sat down to do the assignment — which asked me to load top_movies_2017.csv — my mind went completely empty.

I tried things like:

read_csv
import_csv

…and various other guesses.

Strangely, I had seen Table.read_table multiple times in the course material.

What I realized: the human brain doesn't learn purely through reading. Learning is a multi-sensory process — it involves sound, touch, the frustration of hitting a wall, the cycle of trying and failing. Those experiences are part of the memory itself.

Knowing something intellectually is not the same as having actually learned it.

Summary

AI can help you extract an outline, surface key points, and let you skip over sections that aren't relevant to you. In that sense it's a useful map.

But be clear-eyed about what a map is and isn't.

If your underlying ability to absorb knowledge hasn't actually gotten faster, don't be fooled by the optimistic claim that "anyone can code in the AI era."

"Anyone can generate code" is not the same as "anyone can build a maintainable commercial product."

AI can help you go faster.

But it cannot replace the process of genuinely understanding systems, code, and engineering complexity. That part still takes you.

what-is-context-governance

code plato — Tue, 19 May 2026 20:58:30 +0000

Context Governance is a part of Context Engineering. In my opinion, it's the most interesting part.

That might sound abstract at first — I felt the same way. But once you look at how a few mainstream AI agents handle their context governance, the concept becomes immediately intuitive.

In this post, I'll compare four agents' approaches to context governance, walking from simple to complex, from basic to advanced.

Codex

First up is OpenAI's Codex. Ironically, despite OpenAI being the first company to build a large language model, their agent product is the newest of the bunch.

And fittingly, its context governance is also the simplest. Inside the .codex/ directory, there's a file called AGENTS.md. Here's a minimal example:

# Repository Guidelines

## Project Structure
- `src/` — application code
- `tests/` — test code

## Common Commands
- Run tests: `npm test`
- Run linter: `npm run lint`

## Coding Conventions
- Prefer TypeScript
- Avoid default exports
- Use async/await instead of raw Promises

Before starting any work, Codex reads this file. You maintain it manually, adding rules over time.

Beyond this file, there's a folder: ~/.codex/memories/ — as the name suggests, it's the "memory." Codex writes to it automatically.

The rough structure looks like this:

Type	Contents
summaries	Session summaries
durable	Long-term stable memories
recent	Recent context
evidence	Source evidence

As you can see, Codex's context governance is quite lightweight. At its core, it's just:

One rules file
One auto-managed memory directory

That's it.

Claude Code

Claude Code takes a different approach.

The officially supported mechanisms are similar to Codex:

CLAUDE.md
~/.claude/projects/<project>/memory/

Just these two. The names speak for themselves. But the Claude Code community has expanded this significantly over time, evolving into something like:

Name	Type	Purpose	Manual / Auto
`CLAUDE.md`	File	Project rules, agent behavior	Manual
`MEMORY.md`	File	Long-term memory, preferences, lessons	Semi-auto
`NOTES.md`	File	Scratch notes, working scratchpad	Manual
`DECISIONS.md`	File	Key architecture / tech decision history	Manual
`ARCHITECTURE.md`	File	System structure, module relationships, data flow	Manual
`LEARNINGS.md`	File	Lessons learned, pitfall records	Semi-auto
`TASKS.md`	File	Current task list, TODOs	Manual
`SESSION.md`	File	Current session work log	Semi-auto
`docs/`	Folder	Long-form context documents	Manual
`memory/`	Folder	Categorized memory storage	Semi-auto
`prompts/`	Folder	Prompt templates, workflow prompts	Manual
`.cursorrules`	File	Cursor-compatible rules	Manual

This is far more complex than Codex. But notice: a large number of these files require manual upkeep. And the whole structure looks a lot like the project wiki we'd write for a traditional software project.

That's actually the key insight: for an agent to work well, it should browse the project wiki first — just like we would. People are now turning wiki documents into context Markdown files. With that framing, it all makes sense. Claude Code, grounded in these context documents, increasingly works like a real developer.

Open Claw

Open Claw is positioned differently from Claude Code — it leans more toward a life assistant than a coding tool. The community-extended Claude Code context system requires managing too many files. Unlike Claude Code's typical developer audience, Open Claw's users are more general. Many users never directly edit Open Claw's context files — some don't even know they need to.

Yet Open Claw's context design is actually more "agent-native" than the community Claude Code setup. The latter still carries a strong human project-management mindset. But for an agent, you don't necessarily need that many separate documents.

Open Claw's context governance centers on "persona" and "character." It organizes context into these files:

Core Instruction Layer (static, manually maintained)

SOUL.md — Personality, values, boundaries. Answers "who are you." Defines tone, character, hard constraints.
AGENTS.md — Operational procedures and rules. Answers "what you do and how." The largest and most important file; holds complex workflows and step-by-step instructions.
USER.md — User profile. Your name, timezone, preferences, work background. The personalization layer.
IDENTITY.md — Structured identity record (name, role, goals, tone). For consistently re-applying a known persona. (Personally, I find this slightly redundant.)
TOOLS.md — Tool documentation. Doesn't control permissions (that's config's job) — it tells the agent how to use the tools it already has.

Automation Layer

HEARTBEAT.md — Scheduled tasks, effectively a natural-language cron. E.g., "check every 30 minutes," "generate weekly report every Monday at 8am."
BOOTSTRAP.md — First-run initialization script. Automatically deletes itself after setup.
BOOT.md — Hook that runs on every startup.

Memory Layer

MEMORY.md — Long-term memory. Persistent facts, preferences, decision summaries — effective across weeks and months.
memory/YYYY-MM-DD.md — Daily notes. Today's and yesterday's notes load automatically; older entries are retrieved via memory_search.
DREAMS.md — Diary of the dreaming system, logging the "promotion" of short-term memories to long-term. An experimental feature.

Open Claw is already significantly more sophisticated than the previous two systems. When you use it, you can noticeably feel that it's "smarter."

Hermes Agent

Now for the main event. If you don't understand context governance, Hermes Agent might seem similar to Open Claw. But notice: Open Claw still has many files that need manual maintenance.

Even I — after using Open Claw for a while — only recently realized those files need human upkeep. The result: many of the context structures Open Claw designed were never actually put to use.

Hermes Agent's context governance differs from both Open Claw and Claude Code. Its core design philosophy is:

"Self-evolution" — the agent writes its own memories and skills.

The entire system lives under ~/.hermes/.

Identity Layer (static)

SOUL.md — The first slot in the system prompt. Defines personality, tone, values, behavioral boundaries. This is global, loaded from HERMES_HOME. You can still manually edit this file.

Project Context Layer (priority-ordered, only the first match loads)

.hermes.md
AGENTS.md
CLAUDE.md
.cursorrules

First match wins. This means Hermes is natively compatible with both Claude Code and Cursor project config files.

Memory Layer (three tiers, agent-maintained)

MEMORY.md — Long-term memory. Stores environment info, project conventions, tool usage experience.
USER.md — User profile. Stores your name, communication preferences, skill level. Note: this time USER.md is automatically maintained by the agent.
state.db — A SQLite database with FTS5 full-text indexing, storing all conversation history. The agent doesn't load everything by default — it retrieves on demand via session_search.

Memory has entered the database era. Only a database can truly support long-horizon context retrieval.

Skill Layer (Hermes' most distinctive feature)

skills/ directory — Each skill is its own folder containing a SKILL.md (with YAML frontmatter) and optional templates and scripts.

The key difference: skills are not written by humans. After completing a non-trivial task, the agent creates skills on its own via the skill_manage tool. Similarly, memory no longer relies primarily on human maintenance — the agent edits MEMORY.md and USER.md itself between conversations. And skills are loaded on demand: unused skills never enter the context.

This is already approaching true "automated context governance."

Scheduling Layer

cron jobs — Scheduled tasks, similar to Open Claw's HEARTBEAT.md.

At this point, context governance isn't just more complex — it's starting to run itself.

Summary

Whether an AI can actually get work done, and how well it does, is no longer just a question of which model you use. In many cases, better context governance improves agent productivity more than upgrading to a stronger model.

The Electronic Brain

This raises an interesting question: context is effectively the agent's "electronic brain." The longer you use an agent, the more that accumulated context becomes uniquely it. As long as the context survives, even if you swap out the "shell," your assistant is still your assistant. If an agent crashes and needs to be reinstalled, or you want to migrate to a different platform, moving the context along should theoretically keep your assistant alive.

This opens a new question: how do you safely migrate context?

The problem today is that file names, structures, and formats vary wildly across platforms. Context migration is a mess. I believe a more unified, standardized context protocol will emerge. And "context governance" will gradually become one of the core capabilities of any AI agent worth using.

How to Read Technical Docs in the AI Era: Distilled Reading

code plato — Sat, 16 May 2026 23:15:14 +0000

The Unfinished Docs Problem

We're often told to read more technical documentation. But the reality I've encountered is: some docs are so long that reading them for too long leads to:

Drowsiness and declining efficiency
Getting interrupted by something else midway
Getting pulled into another article by an interesting reference — and that article is just as long. I've done the math: reading all of them is simply not feasible; the time cost is too high.

The result? My browser perpetually has dozens of half-read technical article tabs open, and I can't bring myself to close them. Sometimes I save them to bookmarks. But that doesn't solve the root problem — it just makes the bookmarks folder grow and grow. The bookmarks folder becomes one enormous todo list.

The Reading Bottleneck

This pile of accumulated technical docs weighs on me. It makes me feel guilty, like a form of technical debt in my mind. I keep telling myself I'm not trying hard enough — that's why I haven't finished reading them.

But today I realized: finishing all those technical docs is simply impossible. Because:

Their length means reading them will inevitably consume far more time than I can reasonably afford.
Docs spawn more docs. This process never stops.

Just as technical systems have bottlenecks, I call this the reading bottleneck. It's a problem that requires a logical-level solution, not just brute-force effort.

The essence of the bottleneck is that both time and attention are finite resources. Time, as a unit, is too abstract — it doesn't capture the variability in how fast we actually read. So I prefer to use attention as the unit of measure. Think of human attention as a kind of token: your Attention Token, or AT. Strong focus generates an A.T. Field (LOL). Once it's depleted, sleep is the only way to recharge.

This reading bottleneck is fundamentally:

Total time to read all docs > Your available attention

Distilled Reading

Everything Can Be Distilled

Here's something I realized: even though I've only skimmed most of those technical docs, I've still been doing solid technical work. Some docs were even obsolete before I got around to reading them. Most of the information in those docs doesn't need to be memorized — I just need to know it exists, like a dictionary I can look things up in.

This even applies to docs that are already summaries or digests. They can be distilled further. A distilled piece of text can be distilled again — down to a single sentence, if needed. The distillation process loses information, but that loss is acceptable and expected.

LLM-Assisted Distillation

In the age of AI-assisted programming, a developer's most valuable resource is attention.

When my attention starts to fade, I can use an LLM to summarize the rest of an article. After the LLM reads and condenses it, I review the outline first, then ask follow-up questions on the parts I care about.

Taking it further: why not have the LLM produce a short outline from the very beginning? I read the outline, then decide: do I continue reading, or do I move on? If I continue, I can choose between reading every line carefully or zooming in on the sections that matter most to me.

Don't Wander Off

When you come across an interesting concept while reading, resist the urge to Google it. Here's what that behavior chain looks like:

Search keyword → See search results page → Click a result → Read that page

Google's search result format per entry:

LOGO: Site name
One-line page description (not necessarily the title)
2-3 lines of short preview

You burn attention scanning each result. Then you open a new, visually busy page and burn more attention locating the thing you actually wanted. Other elements on that page may also consume your attention.

So: when you encounter an interesting concept, don't immediately Google it.

Ask the AI directly — let it find what you're looking for
Ask it to include links as supporting evidence
You can click the links to verify. If a link is broken, tell the AI to check the links itself before responding, filtering out dead ones

This is what I call Distilled Reading.

Verification

We need a way to verify this method — otherwise it can't be falsified, and anything that can't be falsified is pseudoscience. If this is just me talking nonsense, that should be provable. If the method doesn't work, it's wasting your time.

Verification dimensions:

The number of open technical doc tabs in your browser should decrease
The number of unread articles in your bookmarks should decrease, or be archived
At the end of the day, you should feel that you actually accomplished your planned reading — and that the guilt has eased (admittedly subjective, and a bit pseudoscientific, but that's fine)

Use these same criteria to evaluate whether this method works for you — and decide whether to trust me and change your reading habits, or conclude that this is all bullshit. Either way, you've taken an important step: you've personally tested how AI can change how you live. That's valuable, regardless of the outcome.

How to Interview Candidates in the AI Era

code plato — Fri, 15 May 2026 03:46:47 +0000

Background

In the age of AI, how do we hire the right people? You don't want to end up with someone who's great at LeetCode but has never touched Claude Code and has zero interest in learning AI-assisted programming.

But compared to LeetCode or traditional software knowledge, AI is still very young. So how do we gauge whether a candidate can stay productive at the company over the next few years?

A Note on Terminology

"AI" is a broad term that works fine for general audiences. But as professionals, we should be precise.

AI covers many subfields — deep learning, supervised learning, large language models, and more. This article focuses specifically on interview questions within the LLM space, so for simplicity I'll use "AI" to mean LLM throughout.

This article also doesn't cover hiring for LLM training roles — that's outside my expertise, and frankly it's a more mature field with established interview practices. The focus here is on LLM application engineering.

Core Framework

We evaluate candidates across 4 dimensions:

Learning velocity: We're hiring engineers who code with AI. Whether they're building AI features or just using Claude Code day-to-day, they need to have a genuine hunger for staying current.

In the LLM application space, there's no university course that can keep up. What you learned at the start of the year may already be obsolete by December. Self-directed learning is the only way.

The best AI engineers are like dogs chasing a ball — they're always running toward the technology, not waiting to be pushed by it.

So our questions don't just test LLM knowledge; they also probe whether the candidate has that chasing instinct.

Conceptual understanding:

How well does the candidate understand LLMs at a systems level?
Hands-on experience:

Have they actually used AI coding tools in practice?
Domain knowledge:

Knowledge of specific frameworks (e.g., LangGraph). This dimension is more relevant for candidates in AI integration roles.

Sample Questions

The following are example questions along with my own answers.

These aren't "correct" answers — treat them as a reference point. And just like LLMs have a training cutoff, my answers here have a cutoff of June 2026.

Learning Velocity

What are the major phases in the evolution of LLM application development? Hint: the first phase is prompt engineering.

Answer: Prompt engineering → context engineering → Harness Engineering
What is Harness Engineering?

Harness Engineering is the practice of building the external execution framework around AI agents — including tools, memory, retrieval, validation, workflow, and feedback loops — to improve agent accuracy and controllability.

Put simply: modern agent architecture = model + harness.

Name a few recent LLM applications you're aware of.

Examples: OpenClaw, Hermes Agent, Happy Codex, etc. (as of May 2026)
Name a few recent LLM models.

Examples: Opus, GPT-5.5, etc. (as of May 2026)
How do you keep up with developments in LLM technology?

Following news sites, specific media outlets, building personal LLM projects and learning as you go, etc.

Conceptual Understanding

What's the difference between prompt engineering and context engineering? Prompt engineering is about how to write a better prompt. Context engineering is about how to dynamically construct the entire runtime context for an AI agent.

Modern agent performance depends primarily on whether the agent has the right context and tools — not just on how elegant the prompt is.

How do you interpret the phrase "RAG is dead"? There are two levels to this:

With the rise of context engineering, the focus has shifted from "better RAG" to "better context management" as the primary lever for improving agent effectiveness.
More precisely: it's not RAG that's dead — it's Naive RAG. The early approach of chunk → embed → similarity search is what's been superseded.

What context engineering methodologies are you familiar with?

Context compression, structured note-taking, sub-agent architectures.
What's the relationship between context engineering and Harness Engineering?

Harness Engineering focuses on the overall execution framework and runtime system for AI agents. Context engineering focuses on how to dynamically organize and deliver the right context to the agent.

Context engineering can be seen as one of the core components of Harness Engineering.

What is Progressive Disclosure? Progressive Disclosure is a design principle where a system doesn't surface all information at once, but instead reveals relevant content incrementally as needed — reducing complexity and minimizing context noise.

Hands-on Experience

The following questions don't have right or wrong answers — except the last one.

Walk me through a real scenario where you used Claude Code to write production code.
What's the dumbest thing you've seen an AI write?
What do you do when the AI keeps failing to fix a bug?
Have you compared multiple AI coding tools? Which do you prefer and why?
As a developer, how should we think about writing code in the AI era?

I have some thoughts on that last question, but I'll save them for a separate piece: The AI-Era Engineer Should Steer, Not Type.

Domain Knowledge

For this section, tailor the questions to whatever frameworks are relevant to the role — LangGraph, for example, if that's part of the stack.

I'll leave the specifics to you.

Web4.0 Is Coming

code plato — Fri, 08 May 2026 06:29:42 +0000

AI isn't just a tool upgrade — it's a new computing platform revolution.

Part 1: The Cracks Are Already Showing

I've been job hunting recently, and I noticed something interesting: genuine "LLM integration developer" roles are still surprisingly rare. What's more interesting is that even when companies do post them, most require:

AI Agent experience
LLM project experience
RAG experience
AI Workflow experience

Here's the problem: LLM development has only exploded in the past few years. How many engineers actually have complete AI development experience? Many engineers only started transitioning into LLM development a few months ago.

If you keep the bar this rigid and can't hire anyone, those people will get picked up by other companies. In another year or two, you might not be able to hire them at all, even if you want to.

(So if I'm job hunting right now — you could hire me today. Just don't make me do LeetCode.)

But the really interesting part isn't the hiring market. It's that most companies, even now, have no idea how to make money with AI. The people who are actually using LLMs to build things are indie developers, small teams, hackers, and solo founders. They don't even know if it will be profitable — but they're running experiments anyway, because "this thing is just too cool."

That hacker intuition is hard to explain with traditional business logic. Most great tech revolutions didn't start with a clear business model. They started because a group of people thought something was fascinating.

That's how the internet started. Personal computers. Smartphones. And now AI.

The real danger is that many large companies are still sitting comfortably in their existing lanes, asking:

Can AI make money?
How do we calculate AI ROI?
Will AI disrupt our current business?

But the question they should actually be asking is:

"Will our company still exist in ten years?"

Because history has already answered this. Kodak didn't die because its technology was weak. Nokia didn't die because its engineers weren't good enough. They died because when a new computing platform arrived, they were still living in the old era.

And right now, the cracks are already showing.

The way I see it, a Niagara Falls is being held back by a thin mud wall — and that wall has started to crack.

Today, 90% of internet companies are already standing at the edge of a cliff. They just haven't realized it yet. Don't believe me? Let's run a social experiment starting now:

Build an AI Skill for Jira
Build an AI Skill for productivity tools
Build AI-native versions of various Web2.0 apps

Watch what happens.

Part 2: The Web4.0 Architecture

"Web3.0" is a term that's been talked to death. Why? Because it never produced a computing paradigm genuinely capable of restructuring Web2.0.

But AI is different.

I'm calling this wave Web4.0, because AI is starting to deeply penetrate software itself. It's no longer just a search bar, a chatbot, or an assistant tool — it's gradually becoming part of the operating logic of software.

I'd even argue this will be the fourth industrial revolution, because for the first time, machines are beginning to participate in producing software themselves.

1. The Software Interface

The software interface of Web4.0 will look very different from today's — but not completely unfamiliar.

Future software will most likely split into: software on the left, AI on the right.

The left side will still be traditional GUI:

Task lists
Tables
Charts
Dashboards
Status bars

Humans still need to see state, so GUI isn't going away.

But the right side will become an AI operation layer. Users won't primarily interact through buttons anymore — they'll accomplish most tasks through natural language, conversation, and intent.

For example:

"Move this issue to next week and notify the relevant team members."

AI will:

Update the issue
Change the status
Send notifications
Adjust the timeline

The left-side GUI's role shifts to: showing the current state of the system. Users can even watch AI operate within the system and step in manually when needed.

Software will shift from:

"Humans operate software"

to:

"AI operates software. Humans supervise AI."

2. System Architecture

The core shift in Web4.0 is that every frontend will eventually connect to an AI engine.

Whether it's:

App
Web
Desktop
Skill
Agent

Everything will plug into:

SLM + RAG

Many people assume the future will be dominated by ever-larger models, but I don't think so. LLMs are too expensive, enterprise-sensitive data can't leave the building, and no serious company wants its core technology dependent on someone else's API. A truly mature company will never build its core business permanently on external infrastructure.

So Web4.0 will inevitably move toward:

Each company's own SLM (Small Language Model) + proprietary RAG.

LLMs will be more like early exploration tools, general reasoning engines, and product validation platforms. Mature products will eventually own their own:

AI Engine
Memory
Knowledge Base
Workflow System

The competitive moat for companies will gradually shift away from:

Frontend pages
CRUD systems
Database design

And toward:

RAG architecture
Workflow orchestration
Enterprise knowledge organization
Agent collaboration systems

3. The Product Lifecycle

The lifecycle of Web4.0 products will also change.

In the early stage, most teams will go straight to:

OpenAI
Claude
Gemini

Combined with:

MCP
RAG
Workflow

To ship fast — because the cost of experimentation is low, and the product can "come alive" from day one.

This is completely different from before. Products used to require massive amounts of custom logic before they were usable. Now AI already ships with enormous general-purpose capability.

But at the mature stage, companies will gradually migrate to:

SLM + proprietary RAG

The reasons are practical:

Reduce costs
Control data
Reduce API dependency
Ensure stability
Establish technical sovereignty

So the typical Web4.0 product evolution path will likely look like:

LLM API
    ↓
RAG
    ↓
Workflow
    ↓
SLM
    ↓
Enterprise AI Engine

4. Customer Support

Customer service may be one of the first industries to be fully restructured.

But this time, it's real AI support — not the "fake AI that makes everyone want to throw their phone" from before.

Old AI customer service:

Couldn't follow context
Couldn't hold a continuous conversation
Couldn't read emotions
Only matched keywords

So users always ended up demanding a human.

Web4.0 AI support is different. It will genuinely understand:

Context
Conversation history
User sentiment
User behavior

It can even detect:

"This user is getting frustrated."

And proactively say:

"Let me connect you with a human agent."

Most companies' support operations will become fully AI-manageable. The scenarios that still require humans will shrink to:

High-stakes decisions
Emotional de-escalation
Edge case handling

Another industry, restructured.

5. Version Iteration

This is a more radical idea, but I think it's cool — and the kind of thing that could go viral.

It's this:

"What goes into the next version is decided by user vote."

AI will:

Analyze user behavior
Summarize user needs
Auto-generate candidate features
Let users vote

And eventually, AI will auto-implement some of those features too.

The old software development flow:

Product Manager
    ↓
Requirements
    ↓
Engineering

In the Web4.0 era, it may gradually become:

Users
    ↓
AI Analysis
    ↓
AI Implementation
    ↓
User Feedback

Software will enter:

"The era of high-velocity self-evolution."

Part 3: Web4.0 Is Not an Upgrade — It's a Replacement

Many companies still think of AI as a plugin, a feature, a chat window, a productivity tool.

But what AI is actually changing is the entire software architecture.

Web4.0 is not "Web2.0 + AI." It's a new computing platform — just like:

PCs replaced mainframes
Smartphones replaced parts of the PC
Cloud computing restructured enterprise systems

AI will redefine:

Software
Workflows
Organizational structures
Development models
User interaction
Enterprise architecture

Most companies think they're just waiting for AI to mature.

But actually:

AI is waiting to replace them.

We may be standing at the single biggest technological inflection point since the invention of the computer. And many companies are already at the edge of the cliff — they just haven't looked down yet.

LLM-Based AI Agent Architecture: A New Kind of Personal Computer on Your Device

code plato — Fri, 08 May 2026 06:27:59 +0000

For a long time, we've thought of AI as a "chatbot."

But if you step back and look from a systems architecture perspective, you'll find that a truly mature AI agent looks more like a new kind of personal computer — one that lives on your device.

It has:

A compute core
Memory
A file system
A software system
Input/output devices
Long-term storage

The difference is:

Its core isn't a traditional CPU. It's an LLM.

Part 1: The LLM Engine — A "CPU" Without Memory

The LLM itself has no long-term memory.

It's more like an inference engine:

Receives input
Reads context
Performs reasoning
Produces output
Then "forgets"

It cannot natively remember things that happened in the past.

Therefore:

The LLM itself is more like a CPU than a complete agent.

It only handles computation.

What makes AI "seem like it knows you" is the context provided externally.

Part 2: Context — The AI Agent's Memory

If the LLM is the CPU,

then Context is the AI's memory.

And this memory should be split into two layers.

1. Global Context

This layer belongs to the entire agent.

It records:

User preferences
Long-term goals
Habitual behaviors
Persona settings
Persistent rules
Historical knowledge

For example:

"User prefers Markdown"
"User is learning AI Agents"
"User habitually writes in Chinese"

This information shapes agent behavior over time.

2. Session Context

This layer belongs only to the current conversation.

For example:

The current topic under discussion
The current article structure
The most recent rounds of dialogue
Temporary reasoning results

It's more like temporary memory during program execution.

The Context Window Is Essentially a "Memory Limit"

An LLM's Context Window isn't unlimited.

This means:

History can't accumulate indefinitely
Information gets more expensive as the window fills
Past the limit, content must be compressed

Therefore:

An agent must manage memory like an operating system:

Compress history
Summarize
Clear low-priority information
Transfer long-term data
Dynamically load needed data

Therefore:

The Context Window is essentially the AI's memory capacity.

Part 3: Markdown Files — The Agent's Hard Drive

Long-term data shouldn't stay in the context window.

Otherwise:

Costs keep rising
Inference slows down
The context balloons rapidly

Therefore:

Long-term memory should live in a file system.

And one very natural form is Markdown files.

For example:

Notes
Project materials
Journals
World-building
User profiles
Writing material
Long-term knowledge bases

All of these can be stored as Markdown.

This means:

Traditional Computer	AI Agent
Hard Drive	Markdown File System

Markdown has one enormous advantage:

It can be read by AI and directly by humans alike.

Therefore:

Humans can edit it
AI can process it
Git can version-control it
Files can sync
It persists even without AI

This creates something like:

"A shared knowledge space between humans and AI."

Part 4: Skills — Software Installed on AI

Future AI agents won't only have "knowledge."

They'll also have "skills."

For example:

Writing Skill
Programming Skill
Video Editing Skill
Data Analysis Skill
Project Management Skill

These Skills might be composed of:

Prompts
Workflows
Python code
MCP configurations
Tool invocation rules

They are like:

Software installed on the AI.

Therefore:

Traditional Computer	AI Agent
Software / App	Skill

Skills can be:

Installed
Uninstalled
Updated
Shared
Combined

In the future there may even be:

Skill Stores
Skill Marketplaces
Open-source Skill communities

Part 5: Input/Output — More Than Just Text

One of the biggest misconceptions about traditional chatbots is that people think AI only communicates through text.

In reality, future AI agents will have a complete multimodal I/O system.

Input

AI can read:

Text
Voice
Images
Video
Camera feeds
Files
Screen content
Device state

Output

AI can generate:

Text
Voice
Images
Video
Automated actions
Control commands

Therefore:

An AI agent is fundamentally a new interaction layer.

The Complete System: A "Von Neumann-style" AI Computer

When you put the whole architecture together:

Traditional Computer	AI Agent
CPU	LLM Engine
Memory	Context
Hard Drive	Markdown File System
Software	Skill
Input Device	Multimodal Input
Output Device	Multimodal Output

You'll find:

It increasingly resembles a real computer.

Except:

This computer isn't built around a GUI.

It's built around:

"Language comprehension and reasoning."

The Operating System: A Personal AI OS

In the future, every person's device may host a persistent AI Agent.

One that:

Understands you
Remembers you
Helps you work
Manages your knowledge
Schedules your Skills
Operates your devices
Grows alongside you over time

At that point:

What we use might no longer just be:

Windows
macOS
Android

But rather:

A new kind of personal AI operating system, with LLM at its core.

And the chat box we use today

may only be the earliest prototype of this new era.

References

Park, Joon Sung et al.

MemGPT: Towards LLMs as Operating Systems

arXiv:2310.08560

https://arxiv.org/abs/2310.08560
Wang, Lei et al.

LLM as OS, Agents as Apps: Envisioning AIOS, Agents and the AIOS-Agent Ecosystem

arXiv:2312.03815

https://arxiv.org/abs/2312.03815

How AI Cured My Writing Procrastination

code plato — Fri, 08 May 2026 06:21:19 +0000

A Procrastinator's Excuse

I haven't written a blog post in years.

Not because I had nothing to say — I just couldn't bring myself to do it. Writing used to take me at least a week per article: brainstorming, drafting, revising over and over, then hunting for images, drawing flowcharts in draw.io, dragging and dropping for half an hour just to get a box on screen. The whole process was slow and exhausting, and I gradually built up a real resistance to it. Every time I opened my editor, the first thought that crossed my mind wasn't "what should I write?" — it was "forget it, maybe another day."

And another day turned into several years.

It was only recently that I realized what had stopped me was never a lack of things to write about. It was that writing itself had become too heavy.

Now AI has taken away a large part of that weight.

The Pain Points

Turning ideas into coherent prose is hard: I just need to articulate my thoughts, even roughly, and AI can organize them into flowing paragraphs. I control the direction and the perspective; it polishes the language. This division of labor suits me much better.

Finding images is time-consuming, and they're often the wrong format or size: Now I describe what I want and AI generates it — style, composition, everything — in seconds.

Drawing flowcharts is slow: I describe the logic to AI and it generates the diagram directly. I just check if it's right and adjust if needed.

My Setup

I've built myself a small writing pipeline, centered around two AI roles.

The first is the writer. I throw my ideas, thoughts, and core points at it, and it turns those fragments into a complete first draft.

Once the draft is ready, I edit it myself. This step is crucial — don't underestimate your readers. The best articles are as short as possible, and most people these days (myself included) don't have the patience for a long read. Later is never.

After editing, I hand it to the second AI role — the editor. It reviews the article and does another round of polishing. Honestly, I'm not sure yet whether I need the editor role. I'll try it this way and see.

I'm not sure how many more articles I'll write after this. But at least today, I opened my editor — and finished this one.

[Enterprise Git Workflow Best Practice] Use a Sub-Project Branch When Developing Large Features

code plato — Sat, 22 Mar 2025 20:15:47 +0000

In a large project team, when developing major features, we may assign a few people to form a sub-project team. From the perspective of the overall project, this temporary group is working on a single, independent feature as a whole. However, within the temporary project, each member has their own sub-feature development tasks.

In this case, individual developers should not commit their code directly to the main development branch, such as develop . Instead, a sub-project branch should be created. Each team member commits their code to the sub-project branch first, and at a designated point in time, the sub-project branch is merged into the main development branch.

Terminology Definitions

feature branch: A Git branch created when developing a new feature. Normally, only one person commits to this branch. You can also think of it as a personal branch. It is often named feature/<feature-name> or feature-<feature-name>

sub-project branch: When developing a large feature, a sub-project team consisting of several developers is formed. In this case, a larger development branch can be created for this sub-project. This branch can span multiple sprints. The sub-project developers first commit their changes to the project branch, and at a certain point in time, the project branch is merged into the main branch. The project branch can be named feature/<sub-project-name>-<creation-date>.

Mistakes We Made with Sub-Project Branch

Before writing on this topic, I assumed the use of sub-project branch was self-evident. However, after our team encountered several issues while using sub-project branches, we considered abandoning them. This led to even more problems, making me truly understand the importance of sub-project branch. As expected, the most profound realizations often come through mistakes.

Below are the reasons we abandoned project branches. However, these reasons actually stemmed from incorrect usage rather than inherent flaws in project branches. Therefore, I will list the problems we encountered, along with the real causes.

Project branches made the code messy: We had different versions of components across different project branches.
- Real Cause: Excessive development branches led to code management chaos, especially when many branches remained unsynchronized for long periods, making the overall code structure complex.
Frequent conflicts during merges: Every time we merged a project branch, we encountered numerous conflicts that were difficult to resolve. Sometimes, new bugs were introduced while resolving conflicts, such as accidentally deleting correct code.
- Real Cause: Long periods without synchronization caused excessive conflicts during merging, increasing the effort required to resolve them. The correct approach is to synchronize from the develop branch to the sub-project branch regularly.

In reality, these issues were not intrinsic to project branches themselves.

Necessity of Sub-Project Branch

Below are the key reasons for using project branches and best practices for managing them properly.

Check for conflicts before merging: Fix the conflicts on the PR before merging.

Evaluate the testing process: Notify the testing team before merging and ensure they have enough time to conduct tests.

Significantly reduce the difficulty of reverts: If a branch contains only a single change, it minimizes coupling issues with other functionalities.

Run automated tests on the project branch: Write sanity tests specifically for the branch to ensure feature reliability before merging.

The develop branch is used more widely than you think: The develop branch is not just for some engineers—others, including different engineering teams, may also rely on it.

Even testers and product managers might use the develop branch.

Conclusion
Using project branches can maximize release stability, improve code traceability, enhance testing efficiency, and facilitate better team collaboration.

Best Practices for Using Sub-Project Branch

Daily synchronization: Keep merging the develop branch changes to Sub-project branch to avoid excessive conflicts.
Keep sub-project branches short-lived: Sub-project branches should not exist for too long (no more than 3 sprints).
Squash merges: Use squash & merge when merging code to make all commits in 1 commit. Cause from the perspective of the develop branch, this feature should have only one or a few commits.

Keep it clean: Delete the sub-project branch after merging to prevent unnecessary future commits.

The Bicycle-shed effect

code plato — Wed, 05 Mar 2025 19:50:05 +0000

The Definition

The Law of triviality as known as the bicycle-shed effect. Quote from wiki page:

The law of triviality is C. Northcote Parkinson's 1957 argument that people within an organization commonly give disproportionate weight to trivial issues.[1] Parkinson provides the example of a fictional committee whose job was to approve the plans for a nuclear power plant spending the majority of its time on discussions about relatively minor but easy-to-grasp issues, such as what materials to use for the staff bicycle shed, while neglecting the proposed design of the plant itself, which is far more important and a far more difficult and complex task.

The law has been applied to software development and other activities.[2] The terms bicycle-shed effect, bike-shed effect, and bike-shedding were coined based on Parkinson's example; it was popularized in the Berkeley Software Distribution community by the Danish software developer Poul-Henning Kamp in 1999[3] and, due to that, has since become popular within the field of software development generally.

What do we use it?

Here are some examples:

☎️ Don’t get too hung up on details during a meeting. For example, don’t argue over the details of the prompts that should be displayed for this feature. Don’t even waste time on technical details. Meeting time is for everyone, not just a few people.
🖱️ When searching for information on the Internet, don't be distracted by interesting little bits of knowledge, or even Google them. Try to be patient with your curiosity.
📦 When developing a feature or product, don’t waste too much time polishing it before the first release. Fine-tune it after the release.
🗄️ When using the four-quadrant work method, try not to waste time on urgent but unimportant tasks. Once you have solved a problem, move on to the next one and do not extend the time for that problem.

[Copilot Extreme Practice Journal] DAY 1: Using Copilot to Generate Unit Tests Without Writing a Single Line of Code

code plato — Tue, 04 Mar 2025 05:13:52 +0000

This series is called "Extreme Practice" because I don't know if this is the best practice. I am currently trying to push ChatGPT to the extreme, meaning almost all actual coding and writing tasks are delegated to ChatGPT to see how much efficiency can be improved—or decreased.

Terminology Introduction

`Copilot`

Copilot is a chatbot developed by Microsoft that utilizes ChatGPT. You can consider it a wrapper around ChatGPT. It allows you to switch between different models, including Gemini, Claude, and ChatGPT.

`GitHub Copilot`

GitHub Copilot is an AI coding assistant that integrates Copilot into GitHub.

`GitHub Copilot VSCode Plugin`

GitHub has developed a Copilot plugin for GitHub. This plugin enables programmers to use Copilot within the IDE by connecting it to GitHub Copilot. It currently supports VSCode and IntelliJ.

Task Requirements

Generating unit tests for UI components is always a painful task. Testing pure logic functions is straightforward—you just pass in parameters and verify the output. However, testing components requires setting up many variables needed for component loading and passing them to the component in different ways.

Today is the first day of practice. I attempted to use Copilot to generate a unit test for the Vue component BenefitsAccordion. The requirements are as follows:

⏳ Must be completed within 30 minutes.
✅ The generated unit test must pass.
🏆 The unit test must follow good coding practices.
🙅‍♂️ I should not write any code; the task should be completed through conversation only.

Execution Process

I will use ✅ and ❌ and 🤔 to show how it is doing.

If it work as my expect. I will give it a ✅
If it doesn't work as expect. I will give it a ❌
If I don't know whether it works well or not, I will give it a 🤔

Step 1: Initial Generation of Test Cases ✅

I opened the Copilot Edits panel:

I selected the file and told it:

/tests generate unit test for this file

It generated a test file, but it did not recognize that my codebase is a monorepo (Monorepo vs Multi-repo vs Monolith). The generated test file should be placed in the corresponding sub-repository.

Step 2: Moving the Test Case ❌

I instructed it to move the unit test to apps/<sub-repo>/tests/unit. So I said:

@workspace app/xxx has its own tests folder. Move the unit test you just generated to that folder instead of tests/unit.

It agreed and moved the file, but placed it in the root directory /tests/unit, which is incorrect.

Step 3: Moving the Test Case Again ✅

Since test cases should be placed according to the structure of the System Under Test (SUT), I said:

Don't put it in the root of apps/ms/tests/unit. Place it according to the source code file structure.

This time, it got it right:

Move the unit test file for the BenefitsAccordion.vue component to the apps/ms/tests/unit/components/xxx/xxx folder to match the source code file structure.
But there were many errors

Step 4: Attempting to Fix the Test Case ❌

I asked it to fix the errors in the unit test file:

Fix the errors in the unit test file BenefitsAccordion.spec.ts.

It responded:

Fix the errors in the unit test file for the BenefitsAccordion.vue component.

However, the errors remained unchanged.

Step 5: Directly Telling It How to Fix the Errors ✅

The errors were basic—missing imports for Vitest functions like describe and beforeEach. I explicitly pointed this out:

The errors in BenefitsAccordion are because you didn't import describe, beforeEach, etc., from Vitest.

This time, it understood:

Fix the errors by importing describe, beforeEach, it, and expect from Vitest.

Step 6: Specifying Which Methods to Test ✅

It generated some unhelpful test cases, such as it should render ..., which I consider meaningless. So, I told it explicitly:

/tests in BenefitsAccordion.spec.ts, only generate unit tests for methods xxx, xxx, xxx, xxx, xxx, xxx. Remove other tests.

It responded correctly:

Generate unit tests only for the methods xxx, xxx, xxx, xxx, xxx, and xxx. Remove other unit tests.

Step 7: Categorizing Test Methods ✅

A good practice is to group test cases using describe(). I instructed:

Use describe to categorize unit tests by the methods being tested.

It got me

Organize the unit tests using describe blocks.

Step 8: Testing More Logical Paths ✅

It only tested one path per method, but each method had at least two logical paths. I told it:

You only test one path. Test more paths. For example, for xxx, test when xxx is true.

It got me

Add more test cases to cover different paths of the methods being tested.

Step 9: Manually Specifying a Missing Path 🤔

One test path was still missing, so I explicitly pointed it out:

For planId, you didn’t test when planId is null.

It responded:

Add a test case for planId when planId is null.

Step 10: Running the Test Cases ❌

I asked it to run the tests, but it said:

❌ Sorry, I can't assist with that.

I ran them manually and found one failed test:

Step 11: Fixing the Test Case ❌

I asked it to fix the failing test:

The unit test "returns empty string when planId is null" failed, correct it.

It responded:

✅ Correct the unit test "returns empty string when planId is null".

However, the error persisted.

Step 12: Attempting to Fix the Test Again ❌

After multiple attempts, it still couldn't fix the test. I had to fix it manually, which violated my goal of not touching the code. Additionally, fixing one test caused five others to fail.

Step 13: Ensuring Test Isolation ❌

To prevent tests from affecting each other, I instructed:

Ensure each test runs with a clean component instance.

It responded:

Ensure each test runs with a new component instance.

However, it did not work, and the errors remained.

Conclusion

The experiment ultimately failed. The tests did not pass, and the situation worsened. I even had to intervene manually. In the end, I deleted the test file. Tomorrow, I will attempt a different approach.

Use watch as the last resort

code plato — Sat, 01 Mar 2025 04:28:13 +0000

We should avoid using watch in Vue. I'm not saying it's bad; we should just treat watch (and watchEffect) as a last resort. watch is a very reliable tool. It is the simplest and laziest way to achieve a function. It can almost guarantee 100% triggering, thus covering your needs. But the problem is that sometimes it covers too much. watch has the following disadvantages:

Disadvantages

1. Implicit Dependency

watch creates an implicit dependency.

An implicit dependency is a hidden relationship between components in a system where one component relies on another without being explicitly stated.

An explicit dependency occurs when component A directly calls component D, making the relationship clear and easy to trace.

Implicit dependency means that component A eventually calls component D in an unobvious way, creating a connection between them.

Although explicit dependencies seem easier to maintain, a system full of them would lack flexibility. For example, vue-router is an implicit dependency, and implicit dependencies are essential for building frameworks. However, using them in business code increases maintenance difficulty.

Here is a great article that explains the disadvantages of implicit dependencies:

Side Effects in Code: Why They Matter and How to Avoid Them

Although this article does not explicitly mention implicit dependencies, side effects are essentially how watch operates in Vue.

Side effects create implicit dependencies between components, increasing the chance of bugs. For instance, in our discussion, I noted: "If a method assumes that a specific member variable will be updated beforehand, you’ve built a trap for the next developer — or even for yourself six months later."

2. Difficult to Trace the Source of Changes

When an error occurs, it is difficult to determine which piece of code initially triggered the change. If you are debugging in a local environment, it's easy to check the stack trace. But if you are troubleshooting on QA, CM, or PROD and are unaware of a watch, debugging can become a nightmare.

A real-world example: while working on one of the page of our project, we encountered a defect that seemed to originate from the data initialization. However, we didn't realize that the data were initialized twice—once via a watch. If both initializations worked correctly, the duplicate execution would go unnoticed. But when bugs inevitably appear, identifying the source of the error becomes critical in measuring code quality.

3. Creates Tight Coupling, Making Refactoring Difficult

Using watch can tightly couple different parts of the code. Initially, we knew that code A triggered code B through watch. Over time, additional code was introduced—code C also triggered code B through watch. Then, a third engineer, seeing the existing pattern, added code D, further expanding the web of dependencies. This results in increased coupling, making the code harder to maintain.

This article discusses the dangers of tight coupling:

Code Coupling: Reducing Dependency in Your Code

You’ve no doubt encountered this effect: you make a change in one corner of the system and it breaks code in a far, far distant corner. You might not even spot such a defect, particularly if you don’t do extensive regression testing with each release. That, of course, means your unfortunate customer will likely be the one who spots the defect.

A watch is like a spider web—it captures any logic that falls into its scope. If you watch a global variable, such as savedSession, its impact could extend across the entire project.

A project with excessive watch usage resembles the image above.

4. May Cause Infinite Loops

If watch A triggers watch B, and watch B triggers watch A, you create an infinite loop.

A real example: while developing QuotesPage.vue, I was a big fan of watch and added five or six of them on a single page. This led to an infinite loop when the page attempted a "relaxation" operation. At the time, there was no good way to suspend a watcher. See this answer from Evan You, the creator of Vue.js:

The only way to suspend a watch is to include a conditional check. I had to add some variables like watcherEnabled disable the watch when necessary. After I stopped using watch, I was able to say goodbye to this ugly workaround.

5. Hard to Read and Understand

When reviewing the logic behind a watch, you often need to navigate between multiple files or distant parts of the same file.

You might need to jump across different areas of the project to understand the full logic flow.

Better Solutions

There are better alternatives to watch. Consider the following before using a watcher:

Directly call the method if they are in the same component.
Use computed properties if you only need to display something.
Use custom events to trigger methods in a parent component.
Use lifecycle hooks like app:rendered, page:start, definePageMeta in Nuxt, or onMounted in Vue.

When to Use `watch`

Despite its drawbacks, watch is still useful in some cases:

When you need to update something, but custom events cannot achieve the desired behavior.

By using watch cautiously and considering alternatives first, you can write more maintainable and predictable Vue applications.

How to write elegant code 1: Keep the chain of event calls short

code plato — Sat, 21 Dec 2024 18:21:12 +0000

The chain of event calls

There are some scenarios we keep throw up the event to the parent component. Then it handle the event in the component far way from the component which raise the event

This has the following disadvantages

Switching between different component source code increase the difficulty of developing
We coupling deeply these components. The architecture is fragile. If there is a component updated might break the event chain

If we calculate the distance of event calls chain in this way:

when the event is handled in the same component which fire it, the distance is 0
if the event if handled in the parent component we plus 1 to the distance. For example, the event is handled by the parent component, the distance is 1

In the example above, the distance is 3

The code is hard to read if the distance is larger than 1. If it’s 3, you will need to switch 4 files to read the event call chain completely.

How to fix it

Put the even handler beside the event listener

Questions

Q: Will this cause a lot of duplicate code? A: No. we can extract common code to composable or component to reuse the same code.
Q: Will this create a lot of duplicate components like modals? A: No, make sure the component only be created when it's needed. For example if you are using Vue.js use v-if instead of v-show for modal component to make sure it won’t be rendered when no needed. Also, use private variable instead of global variable to control if the modal is shown to make sure the toggle method will only trigger 1 modal to be open or close.