Let me start with something our team personally experienced, especially when everyone is excited at the start of a new project.
Open an AI coding tool, describe the requirement, and a few minutes later hundreds of lines of code appear. The result even looks pretty good. On day one, progress feels astonishing. Within a week, the main features are almost there. Then things start to go wrong.
In week two, AI changes one feature and accidentally breaks another, and nobody notices. In week three, the same data is stored in two places; one side gets updated, the other is forgotten, and production starts showing strange behavior. By the second month, the most common conversations in the team become:
"Who wrote this logic?"
"No idea. AI wrote it."
"Can we still touch this part?"
"Better not."
The codebase has multiplied in size, but the team's sense of control over the system has disappeared.
Looking back, the problem was not that AI was bad at writing code. Quite the opposite: it wrote code so quickly and smoothly that the steps that used to make us slow down and think clearly, such as discussing direction, aligning on a plan, and reviewing the approach, were all bypassed.
Speed amplified productivity, and it also amplified chaos.
Over the past half year, we have done a lot of experiments around how humans and AI should collaborate on software development. We stepped into plenty of traps and gradually formed a working method. This article is not about tool tips. It is about a deeper question: once AI makes "writing code" extremely cheap, what becomes the most valuable work inside a development team?
There are six rules. Every one of them came from real cost.
1. If the direction is unclear, faster execution only makes the deviation bigger
The first trap: asking AI to start before the direction is clear.
During one feature refactor, someone said in a requirements discussion, "This should not be hard." After the meeting, another teammate asked AI to start implementing it. The code came out quickly. Only during review did we realize that the target user had been misunderstood, the core flow had drifted, and a new framework that the team had never used had been introduced along the way. Rework took longer than starting from scratch.
Since then, we have set a rule: for complex projects, the core questions must be answered before technical implementation is discussed.
-
Who is the target user?
-
What core problem are we solving?
-
What outcome counts as success?
-
And just as importantly: what are we explicitly not doing?
This sounds like common sense, but it matters even more in the AI era. In the past, there was a high development cost between "thinking it through" and "starting implementation", so you could not avoid thinking. Now the cost of starting approaches zero, so "let's build first and see" becomes the most natural impulse.
But high-speed execution in the wrong direction is worse than no execution. It not only wastes effort, it also leaves behind a pile of code that someone has to clean up.
Our current practice is this: for any new project or major change, first create a short direction agreement that states the user, core flow, success criteria, excluded scope, and constraints. Reuse an existing agreement when there is one. It does not need to be long, but it must exist, and it must be easy to review later.
First clarify what to build and why. Then discuss how the system should support it. The order cannot be reversed.
2. A plan is not authorization
The second rule cost us the most.
AI is good at making plans. Give it a task and it can produce an implementation plan that looks quite complete: clear steps, separated modules, and even tests arranged. The first time we saw this, our reaction was, "Looks good. Let's do it."
Then we learned to regret it.
Hidden inside the plan were wrong assumptions: it believed an old module could be reused when it could not; it missed a data migration risk; it proposed a single change that would actually break the boundaries between two modules. These issues only appeared after the code was written, when the cost was already high.
Now the team has an iron rule: the first plan from AI is only a discussion draft, not permission to start construction.
When the plan appears, the process stops. A human reviews it: is this plan solving the problem we actually want to solve? Are the goal, scope, and irreversible choices correct? Then we run a systematic challenge: user value, reuse of existing capabilities, whether it introduces unnecessary things, how every step will be verified, and how failure will be rolled back.
One detail is worth mentioning. If review finds a serious problem in the plan, we ask AI to generate a complete alternative plan instead of patching the old one. A plan made of patches on top of patches will inevitably become chaotic halfway through execution.
Only when the goal, scope, dependencies, risks, rollback path, and verification method have no blocking issues is the plan authorized for implementation.
This extra step looks slow, but we have done the accounting: reviewing a plan takes half an hour; one round of rework can take three days.
3. Everything in the system needs exactly one owner
The third rule is about architecture, explained as plainly as possible.
AI has a tendency: to make the current step work, it uses whatever is convenient locally. Add a table here, store a bit of state there, create a temporary API somewhere else. Each individual step may look reasonable, but together they become a disaster: the same data is stored in two places, the same logic has two paths, and when something breaks nobody can say which source to trust.
We call this "loss of source-of-truth control."
The corresponding rule is: data, state, permissions, retry mechanisms, and external side effects must each have exactly one responsible owner.
Before implementation begins, we need answers for where a feature belongs, where the data is stored, and who owns failure handling. If an AI plan introduces a "second source of truth" or a "temporary compatibility path", it must provide a strong reason and an exit condition, or it gets rejected.
The paired principle is to reuse mature capabilities first. Before building, ask whether an existing module can meet the need. Check whether the team's accepted stack already has a solution. If a new framework, database, or queue is proposed, first prove that existing capabilities are not enough, then explain how to exit later.
Ultimately, architecture discipline protects the team's own ability to understand the system. Every "exception" in the system is a future late-night debugging session.
4. Replace "task lists" with "acceptance milestones"
The fourth rule is about managing progress.
Traditional breakdowns look like this: "improve the authentication module", "optimize the data layer", "integrate a third-party service". This style is especially dangerous in the AI era, because AI can very efficiently mark these vague tasks as "done" one by one, and you end up with a system that appears to have lots of work completed but cannot actually be verified.
Our replacement is to break work into "acceptance milestones".
An acceptance milestone is a delivery stage with an explicit observable result and evidence that can be reviewed. The judgment is simple: does it describe an observable outcome, or just a set of actions?
"Users can log in and restore a session" is an acceptance milestone.
"Improve the authentication module" is not.
Each acceptance milestone states four things:
-
What observable result will be delivered
-
Which scopes are allowed to change
-
What prerequisites it depends on
-
How it will be verified
Work on only the current milestone at a time. Finish it, verify it, integrate it, and then move to the next one.
The biggest change is the reporting style. We no longer accept reports such as "70% complete" or "changed 15 files". Capability status has only one useful expression: which acceptance scenarios actually passed, and what evidence proves it.
Task counts, file counts, and percentages are not progress. Passed acceptance is progress.
5. Draw a decision boundary between humans and AI
The fifth rule may be the most useful for people leading teams: where should the boundary of responsibility be drawn?
We draw it by "reversibility".
AI is responsible by default for:
-
Reading repositories, reading documentation, and filling in facts
-
Comparing technical options and making a clear recommendation, not throwing a pile of context-free options back to a human
-
Deciding local and reversible implementation details
-
Designing tests, rollback paths, and recovery methods
-
Challenging incorrect or low-quality plans; an AI that only obeys is not a good teammate
Humans must confirm:
-
Product goals, target users, and business priorities
-
Irreversible or high-cost changes in technical direction
-
Production data changes, external releases, and paid resources
-
Permission expansion, security exceptions, and risk acceptance
-
Final decisions when multiple options involve real product tradeoffs
In short: AI is responsible for factual evidence, technical judgment, and implementation quality. Humans decide only when product judgment is required or when someone must take responsibility for irreversible consequences.
Two extremes should both be avoided. One is letting AI decide everything and only discovering irreversible problems afterward. The other is sending every technical detail back to a human: "Should we use library A or B?" "Should we add this parameter?" That asks a person without full context to make technical decisions for AI, which is inefficient and error-prone. For reversible technical choices, AI should research and recommend directly. That is part of its job.
High-quality collaboration is neither blind AI obedience nor full human micromanagement.
6. Do not trust "done"
The final rule is also the shortest: do not trust "done".
When AI says "done", the sentence itself contains no useful information. Every delivery must include evidence: which commands actually ran, what the results were, which checks passed, which failed, which were not verified, and what risks remain. Failures and unverified items must be reported honestly and directly.
Verification also needs a method. For small changes, after each meaningful increment, run the nearest and cheapest check first: if one module changed, run that module's test first. After everything is complete, run the full regression and real execution verification. Keep both module tests and integration tests: the former proves that the parts work, and the latter proves that the assembled system works.
This requirement had an unexpected benefit. Once "honestly report failure" became the norm, AI delivery quality improved noticeably. It knew that vague reporting would not pass, so it started doing verification more thoroughly before delivery.
Closing thoughts
Looking back at the past half year, the biggest lesson is this: AI reduces the cost of writing code to almost zero, so the value of every other step is amplified. Clarifying direction, reviewing plans, protecting architecture boundaries, defining responsibility, and verifying rigorously used to be partly protected by the high cost of development. Now they must be maintained through discipline.
If your team is also using AI for development, you can start with three small practices:
-
Before the next feature starts, spend twenty minutes writing down the target user, success criteria, and what you will not do, then align with AI.
-
Treat the first implementation plan from AI, no matter how complete it looks, as a discussion draft. Challenge it point by point before authorizing it.
-
Starting today, reject every "done" report that has no verification evidence.
Tools will keep evolving, and models will keep getting stronger. But the underlying logic of collaboration, think clearly first and then build solidly, probably will not go out of date.
Because the truly scarce capability has never been the ability to produce code. It is the ability to take responsibility for results.
What is the deepest trap your team has stepped into when collaborating with AI? Share it in the comments. If you know a colleague currently suffering from AI "acceleration", send this article to them.