DEV Community: code plato

Code Review in the AI Era: From Review to Audit

code plato — Sat, 04 Jul 2026 21:34:10 +0000

The PR Review Paradox

Programmers may be the most disoriented group of people in this era, and the most disorienting thing a programmer does every day is reviewing PRs.

Agents write code too fast and produce too many lines. Humans can't keep up, so most reviews end with a mechanical click on "Approve."
Agents rarely make low-level mistakes anymore, so reading their code feels like a waste of time.

So some people came up with the idea of having one agent review another agent's PR. It doesn't work well. You'll often find that the agent misses the real structural problems, while the issues it does flag are trivial nitpicks — some of them aren't even problems at all.

Others have built skills to help agents review code better. But think about it the other way around: if we put those rules directly into the project's ABS (Agent Behavior Specification) files and let the agent write compliant code from the start, wouldn't that solve the problem at its root?

Where the Problem Lies

PR code review was extremely valuable in the era of hand-written code, because humans make mistakes all the time. Another programmer reading your code could:

Catch bugs in your code
Get familiar with the project by reading your code
Spot code smells
Point out places where your code violates project conventions

But with agents:

Given how well agents write code today, you almost never find low-level mistakes
An agent doesn't need to read a particular PR to get familiar with the project
Agents are bad at spotting code smells in each other's work
If you set things up properly, the agent loads the project conventions before writing — so compliance issues simply don't arise

I often say that agent-written code has no small problems, only big ones.

I've also observed two trends:

Projects are shifting from multi-person maintenance to one person per project. That makes reviewing other people's code hard, because you don't have the cross-project context a meaningful review requires.
Agent-written PRs keep getting bigger. Past a certain size, reviewing a PR becomes mission impossible.

A New Kind of Review

So I believe the way we review code needs a revolutionary change in the AI era. Specifically, the following changes.

A New Point in Time

One benefit of the old PR review was that people don't share the same information or think the same way, so one person could catch problems another person missed. In agent coding, this asymmetry barely exists — reviewing someone else's PR doesn't buy you much anymore.

That doesn't mean review is unnecessary. It means we should review the code before it gets committed. The timing has changed. We should call a halt before the agent's spaghetti code gets pushed to the repo, preventing piles of useless code from landing on the server and wasting other engineers' attention.

You might say this is obvious — of course you look at the code after the agent finishes. Actually, no. You'll find that agents sometimes announce they've finished the code and have already committed and pushed it for you. You need to explicitly stop the agent from auto-committing and auto-pushing. This can be enforced with a commit lock and hooks.

My own setup is a convention where the agent, after finishing the code, generates a temporary commit lock file called a CR (commit request), and the agent's hooks check for the CR file. If the lock file exists, the commit is rejected. The CR file can only be removed by me manually, or through an agreed-upon protocol. My rule is: only when I say "approve" does the agent delete the CR file and commit the code.

A New Standard

In the AI era, the focus of code review should shift from catching small mistakes to:

Checking for code smells
Checking for over-engineering
Checking for implementations that clash with the project's style
Checking whether the code actually meets the requirements
And a new concern: checking whether the PR is too big

That last one emerged with agent coding. An oversized PR is a problem in itself. If a PR runs to thousands of lines and can't be trimmed down, the task itself was too big — it should have been split into multiple small, independently verifiable tasks and implemented step by step. A PR should never be too big to review; if it is, that's a code smell in its own right.

A reasonable PR should focus on one thing, and even if that thing involves a lot of code, the core idea should be simple and easy to grasp. For example, if you batch-modify code that follows a fixed pattern, there may be many changed lines, but the repetition is easy to see. The human brain skips over the repeated parts — they don't burden your thinking or scatter your attention.

New Actions

Reading becomes asking. In the old days, reviewing meant going through the code line by line ourselves. Now we should make a habit of asking the agent about its intent and design. Rapid-fire questions are the fastest way to understand the code — and I've found that in the process of answering, the agent often discovers the problems on its own.

Fixing code becomes fixing rules. When a review uncovers a problem in agent-written code, we should not fix the code by hand. Even if you fix it this time, the agent will make the same mistake next time. Instead, instruct the agent to fix the code — and then instruct the agent to update the rule documents. I call these documents the ABS (Agent Behavior Specification): files like CLAUDE.md, BEST_PRACTICE.md, and so on.

A New Cadence

We used to require a human approval on every PR before merging. But the situation has changed:

Single-person projects are becoming common
Agents produce code faster than humans can review it
Given the same rules, an agent can repeatedly deliver the same quality of code for similar requirements

So we no longer need to review every single change throughout the entire life of a project. Instead:

In the early phase of a project, review every change, and gradually build up the rule base
In the mid-to-late phase, skip review for simple changes — but set a threshold. Once the number of skipped reviews hits the threshold, do a human review to see whether the rules need refinement

A New Name: Code Audit

This new way of reviewing has these characteristics:

Full review in the early phase of a project; spot checks once the project matures
What matters is not guaranteeing the code is correct, but guaranteeing that the way the code is written is compliant

That sounds a lot like a financial audit. So I think this new way of reviewing project code deserves a better name: the code audit.

About the Author

I'm CodePlato.

I believe human creativity is the true tree of AI Coding. Code and models are only shadows projected onto the walls of the cave.

X: @codeplato2026
https://x.com/codeplato2026

Money-Saving Tips Every OpenClaw User Should Know

code plato — Fri, 03 Jul 2026 05:31:22 +0000

Another AI Horror Story

Like many AI horror stories — except I didn't wake up to a $1,000 bill.

Last week, I suddenly received an email from OpenAI saying my balance had run out and I needed to top it up. I was startled, because my OpenClaw connects via OAuth — it shouldn't be touching my Credits. But as OpenClaw's token consumption suddenly spiked, it started drawing from my Credit balance. Whether this was caused by OpenClaw's fallback strategy or OpenAI's own fallback mechanism, I'm not entirely sure. Either way, it happened.

My first instinct was to panic — I deleted and reinstalled the entire OpenClaw app, then started a brand new conversation in Discord. That worked, but it was a bit of an overreaction. Today I'll walk you through a technique that every OpenClaw user should know, yet most people never use.

Root Cause

Here's what's actually happening. The model itself has no memory. Every time you talk to it, it has no idea who you are, who it is, or what you've discussed before. You need to supply context — telling it who it is, who you are, what you've talked about, and what you need it to do right now. Everything beyond your current message can be called "context." This context is typically maintained by a Harness. Common harnesses include OpenClaw, Hermes Agent, Claude Code, and others.

"Harness" is a fairly technical term, so most people just call them Agents.

Multi-layer Context

Context itself is layered:

App layer: This layer records who you are and what the app is. Ask "Who are you?" in ChatGPT and it'll say it's ChatGPT. Ask the same in OpenClaw and it'll say it's OpenClaw — even if OpenClaw is running on an OpenAI model under the hood.
Session layer: This is the context for your current chat. That's why something you said in one chat isn't necessarily recognized in another. The upside is isolation — you can have one chat where it plays a lawyer and another where it acts as a therapist.

At the app layer, OpenClaw injects a large amount of context on your behalf, including but not limited to:

AGENTS.md
SOUL.md
USER.md
MEMORY.md

Context Compression

Here's the problem. As the app is used over time, and as individual chats run longer, your context keeps growing — until costs start to spike. Sometimes the agent triggers Context Compression to relieve the pressure. But you'll quickly notice the agent seems to have gotten dumber. It hasn't completely forgotten your instructions; it just remembers some things and misses others. That's because compression loses detail from your earlier instructions. And even after compression, the context can still be enormous.

So if compression isn't enough, what can we do?

Solutions

Build Good Habits

First, ask yourself whether you're relying on a single chat to handle repetitive tasks. For example, you might have opened one chat and kept asking it to translate documents or visit certain websites on a schedule. Over time, you dread closing that chat because rebuilding it feels like too much work.

If that sounds familiar, it's time to build a better habit:

Whenever something repeats more than three times, distill it into a Skill.

If that feels too involved, you can switch to Hermes Agent — now you understand why it's become so popular. That said, I still prefer manually crafting my own Skills in OpenClaw.

Also make a habit of locking long-term information into preloaded context files. For example:

If you've designed a persona you love, make sure those details are in SOUL.md.
If you want certain personal information — like your address or phone number — to be remembered long-term without having to repeat it, make sure it's recorded in USER.md.

Reset Context

Once you've built those habits, you can confidently reset your context whenever costs start to spike again. The reset has two steps:

App layer: Clear MEMORY.md and the memory folder. Since your habits have already been distilled into Skills, this memory is usually not critical and can be safely deleted.
Session layer: When you finish a major task, or when a chat has been running for over a week, use /new to start a fresh chat.

That clears the two largest components of your context.

Benefits

Doing this has two direct benefits:

Dramatically reduces token consumption, lowering your usage costs.
Reduces OpenClaw's error rate. The cleaner the context, the easier it is for the model to focus on the current task — fewer omissions, fewer misunderstandings. Fewer do-overs means higher effective productivity.

About the Author

I'm CodePlato.

I believe human creativity is the true tree of AI Coding. Code and models are only shadows projected onto the walls of the cave.

X: @codeplato2026
https://x.com/codeplato2026

From Code to ABS: A New Development Paradigm for the AI Era

code plato — Mon, 15 Jun 2026 23:09:32 +0000

Perspectives

There are roughly three schools of thought on AI-assisted programming today:

Distrust AI entirely — use it only as a code snippet generator. Copy the output into your project, but keep your development workflow exactly as it was before.
Trust AI completely — pure Vibe Coding. Never read the generated code; just keep feeding in best practices you find online and increasingly detailed acceptance criteria. As long as the criteria pass and enough constraints are in place, you get a working product.
Partial trust — hand all code-writing to AI, but not design or testing. Stay involved through Ask mode to guide architecture, or have the AI scaffold tests while you write the actual test cases.

Which of these is actually the right direction?

The Confusion

In this era, with the rise of Loop Engineering, source code no longer seems to belong to the programmer. UI design no longer seems to belong to the designer; test scripts no longer belong to the QA engineer; even requirements docs are no longer fully owned by the product manager.

And yet, without any human involvement at all, it's genuinely difficult to ship a usable product. So what work is left for humans? Where exactly is the gap between the human brain and the model?

A New Paradigm

From Circuit Boards to Integrated Circuits

My undergraduate degree was actually in electrical engineering, not computer science. Early circuit design meant hand-soldering discrete components onto boards — transistors and other logic-capable devices included. Then integrated circuits arrived and all that low-level logic got encapsulated. Engineers started writing HDL, and complex circuit structures were generated automatically.

No one cares anymore how one transistor is wired to another. Our thinking shifted to a higher level of abstraction — away from the connections between components, toward bigger, more abstract problems.

From Code to ABS

What Is ABS?

ABS stands for Agent Behavior Specification.

Files like AGENTS.md, CLAUDE.md, and MEMORY.md that you see in projects today are, at their core, files that specify how an Agent should behave. They all belong to ABS.

How to Practice It

An engineer's job should not be writing code line by line — nor auditing code line by line. But it's also not about ignoring the Agent's implementation entirely and only checking the final result. Engineers still need to retain the ability to dive into details. You'll still do deep code reviews during early project phases or at certain critical milestones.

But the nature of that review has changed. In the past, you reviewed code in order to ship. Now you review code in order to calibrate the Agent. After reading it, instead of immediately fixing code, docs, or config, you ask yourself: Why did the Agent do this? What rule was missing? What experience deserves to be distilled?

Then you let the Agent make the fix while you draw the lesson and write it into the ABS. For example:

Areas for improvement go into a best-practices file, like BEST_PRACTICES.md.
Mistakes that must never be repeated go into a prohibitions file, like NEVER.md.
Architectural adjustments go into an architecture definition, like ARCHITECTURE.md.
Other long-term rules continue to accumulate in the appropriate ABS files.

In the AI era, an engineer's most important output is no longer the code itself — it's the ABS files. ABS is the new source code. Code is just the compiled output of ABS.

Single File vs. Multiple Files

Is one CLAUDE.md or AGENTS.md enough, or should you split things into ARCHITECTURE.md, STACK.md, NEVER.md, and so on? The community already has many different approaches. Which is better?

Once you accept that ABS is the new source code, this question answers itself.

First, which granularity is better? Multiple files. For exactly the same reasons as traditional software engineering: clearer separation of concerns, better support for team collaboration, easier maintenance, easier debugging, and fewer conflicts.

Second, which naming convention is better — STACK.md or ARCHITECTURE.md? It doesn't really matter. Just like software development today, what matters isn't the file name — it's whether you've achieved a sensible division of responsibilities. You need to know which content belongs at the architecture layer, which belongs at the best-practices layer, and which belongs at the prohibitions layer. The specific file names are secondary. The organizational thinking is what counts.

A Day in the Life

So what does an engineer's workday actually look like in the AI era? The following scenario might give you a feel for where software development is headed.

Tom arrives at the office at 9 a.m., makes a cup of coffee, and sits down to start his day.

The Orchestration Panel

He opens the Agentic Development Workflow panel (the name is long enough to be self-explanatory). First, he checks the status of each Agent. Which ones are blocked? How many PRs did each Agent submit overnight? Which ones are showing a noticeable drop in throughput? These signals set the agenda for his day.

Editing the ABS

He spots an Agent that's stuck — it needs human-in-the-loop support. He resolves the issue and writes the solution into NEVER.md so other Agents don't run into the same problem later.

After unblocking everything, he reviews yesterday's monitoring data. He notices one Agent wrote hundreds of lines of unit tests for an extremely simple feature. Something feels off. He reads the tests carefully and finds the Agent produced a brittle, implementation-coupled test suite — heavily mocked, tightly bound to internal details.

He asks the Agent to rewrite the tests, this time leaning toward the Chicago school rather than the London school. Then he adds the lesson to BEST_PRACTICES.md.

Agent Behavior Monitoring

The system panel pings him with a notification: one Agent has been running unattended for 10 consecutive iterations. Based on the threshold he configured, it's time to switch to human-assisted mode.

In this mode, the Agent no longer auto-commits or auto-reviews code — every step requires human sign-off. Reviewing the recent work log, he spots early signs of architectural drift. Suspecting other Agents may have similar issues, he audits a few others and updates ARCHITECTURE.md and BEST_PRACTICES.md accordingly.

Tackling a Hard Problem

In the afternoon, his manager hands him a particularly difficult task — a large-scale architectural change that the model can't yet handle on its own.

He switches the Agent into human-assisted mode. Over the next few hours, he and the Agent work together on the architecture design, solution validation, and implementation. Meanwhile, the more routine tasks — bug fixes, UI tweaks, config updates — continue to run autonomously on other Agents.

And that's the day.

Tom shuts his laptop and heads home.

His Agents keep working.

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.