Problem: After the AI Coding honeymoon — code generation is no longer the bottleneck. So what is? —— Trove problem library

Symptom

I still remember the most striking case of my own "honeymoon disillusionment".

A new feature request — adding cross-time-partition computation to a set of operators in a data system — I handed it to an agent powered by the newest model generation.

The result was stunning: in under two working days it went from analyzing the existing code, understanding the requirement and designing the solution, to writing the feature, adding tests and generating docs.

Initial testing found no obvious problems. By traditional flow, this kind of change touches low-level execution logic and multiple operators — weeks of human work.

My first reaction wasn't skepticism, it was excitement: AI Coding really was severely underrated.

Then we widened the test scope, and problems started piling up. The most frustrating part: it wasn't "wrong code". The requirement understanding was basically correct, and the algorithm design had no obvious flaws.

The real problem was — it didn't know the scattered technical constraints behind a few hundred thousand lines of code: which partitioning schemes have special restrictions, which data types aren't supported yet, which capabilities only exist at the SQL layer while the functional interface lacks them, which legacy limitations affect new features.

Those constraints live scattered across code, docs and people's heads — never written down in one place, so of course the agent didn't know them. The testing phase ended up surfacing several categories and dozens of unexpected issues.

The feature took "two days to write" and two weeks of testing and rework.

If you're going through something similar — AI obviously makes writing code faster, but your project isn't getting faster: PRs merge faster but reviews start queuing up; features get implemented but tests reveal more problems than before;

you feel like you have to "watch it", and watching it costs more than writing it would — this article is for you.

It's not a tutorial for one tool. It's the consensus a few people earned by putting AI Coding into real production systems, from their own honeymoon disillusionments: code generation is no longer the bottleneck — the bottleneck has moved.

Cause

Let's answer the counter-intuitive question first: AI code generation is already absurdly fast (one company reports 75% of new code is AI-generated; some teams say nearly 99% of their output tokens come from a coding agent).

Why isn't your delivery speed keeping up?

First, only one station on the delivery line got faster: "writing code". Shipping a requirement is far more than coding: requirements analysis, solution design, development, review, testing, integration, release.

AI optimized exactly one station — even just the "writing" part. Reviews are still done by humans, tests still run by humans, requirements still clarified by humans.

The bottleneck didn't disappear; it moved from "can't write it" to "can't verify it fast enough" and "constraints aren't documented".

Second, implicit constraints are the agent's blind spot. A mature codebase is full of "unwritten rules": which logic has historical baggage, which interface can only be called this way, which pattern triggers a known performance trap.

Humans absorb them through experience, asking around, and stepping on rakes; an agent has none of that — it only has what you feed it.

It can understand the requirement correctly, but "your company's history" is unknowable to it. This isn't the model being dumb; the knowledge was never put where it could read it.

Third, context is a budget, not a window. No matter how large the window, the more permanently-resident content you carry, the lower the cache hit rate and the higher every round costs.

A lot of people dump the whole repo or 20K lines of logs in — the window doesn't overflow, but "what should be remembered isn't, what should be dropped isn't". The agent drowns in noise and output quality drops.

Fourth, the faster generation gets, the more expensive verification becomes. Before, code was written slowly, so errors were produced slowly; now errors roll off an assembly line.

Without matching verification mechanisms (how tests assert, what review checks, how fallbacks work), AI's speed just ships mistakes into production faster.

So the real formula isn't "AI writes code fast = project fast", it's:

Every tip below turns "fast generation" into "fast delivery". They aren't one author's opinion; they're consensus repeatedly validated across independent practices.

Solution

Each experience below follows the same shape: phenomenon → practice → why. None of it is one person's opinion — these are patterns that recur across many independent practices.

Tip 0 (L1 one-liner): The bottleneck isn't generation — it's "verification + constraints + environment"

Stop treating AI Coding like a typewriter. Generation is nearly free now; what actually decides your speed is: ①how clear the constraints are (does the AI know your company's rules?), ②how fast verification is (tests/review/attribution), ③how complete the environment is (knowledge, permissions, fallback chains). In a hurry?

Read only this. Tips 1-5 show how.

Tip 1: Measure the delivery line first — AI only sped up the "coding" station

Phenomenon: After the team adopted AI Coding, I thought efficiency had taken off — until I looked at real numbers: standalone coding time did drop from days to hours, but requirements clarification, review and test-fix time didn't move at all.

Overall delivery barely shortened.

The bottleneck became "code arrives too fast for humans to review".

Practice: ①Split the delivery line into stations: requirements → design → coding → review → testing → integration → release; ②record real time per station (don't estimate — dig through two weeks of project history); ③mark which station AI optimized; the longest remaining station is your real bottleneck;

④invest by bottleneck: slow reviews → smaller PRs + a review checklist; slow tests → make tests a guardrail AI also runs; fuzzy requirements → write the plan before touching code.

Why: Humans naturally overestimate the value of what they're currently doing. A measurement table is the cheapest way to break the illusion — it turns the vague feeling of "AI made me faster" into actionable facts like "coding 3h→0.5h, review still 4h".

The bottleneck is never "the one you feel"; it's the one the data points to.

Tip 2: Make implicit constraints explicit — write down the rules the AI doesn't know, and make it read them first

Phenomenon: After that cross-time-partition feature blew up, I did a postmortem: the agent's understanding of the requirement was correct, but it didn't know "which capabilities only exist at the SQL layer while the functional interface lacks them" or "which partitioning scheme carries historical restrictions" — constraints that lived in the code and in senior people's heads, just not anywhere the agent could read.

The same thing showed up team-wide: AI-generated code was clean and consistent, but it stepped into historical traps the moment it touched core modules.

Practice: ①Create a "constraints list" document: known limitations of this system, capabilities that only exist at certain layers, patterns that are landmines, historical baggage that must not be touched — and make the AI read it before every task; ②Distill the judgments you've learned from rakes into standards: which criterion got changed after being rejected, which regex blew up, which quota got hit — write it down and the next task follows it automatically;

③Make knowledge retrievable, not memorized: docs, skills, example libraries where the agent can look things up last longer than stuffing them into a prompt;

④Any trap a newcomer can step on, an agent will step on too — the constraints list doubles as your onboarding manual.

Why: An agent can't "know" what it was never fed — but it has one virtue: write it once and it complies every time, without human forgetfulness.

Making implicit constraints explicit is translating tribal knowledge into machine-readable standards — and it compounds: write once, the whole team and every future agent benefit.

Tip 3: Context is a budget, not a window — subtract from your agent's config

Phenomenon: When I first configured prompts, my instinct was "add as much as possible": encouragement, background, repeated steps.

Until I ran a sentence-by-sentence test — "if I delete this line, does behavior change?" — and found a quarter of the content changed nothing.

Every permanently-resident line is a cost you pay on every round; a big window is not a license to waste it.

Practice: ①Sentence-by-sentence testing: any prompt line whose removal doesn't change behavior gets removed — classic deletables are "Be thorough", "This is crucial" and other filler prefixes; ②Prefer positive phrasing: write "read the file before editing", not "don't forget to read the file" — negations make the forbidden behavior more "accessible" to the model;

③One skill, one mission: delete overlapping skills, delete pure wrappers, inline things that are really formatting rules — the skill list itself is injected every session; ④Protect what must be protected: config and rule files go on the protection list so auto-compression doesn't prune "the rules themselves";

⑤Set compression thresholds as percentages, not absolute values — swap models or windows without re-tuning.

Why: The core of context economics: every token is a permanent cost; deleting one line of filler pays off across the entire session lifetime. You're not saving one call's money — you're paying less on every single session.

Subtraction is harder than addition in config engineering, and worth more.

Tip 4: Give the agent an "environment", not just a "mouth" — permissions, verification, fallback chains

Phenomenon: For read-only agents (exploration, review, diagnosis), I first gave them one rule: "don't edit". It still ran whatever it wanted, and once nearly executed something dangerous.

So I switched the permission model to "deny by default + explicit allowlist": edit denied, task denied, bash restricted to read-only commands like git status/git diff/git log/rg — the risk surface shrank immediately.

Similarly, code review became dual-axis: one axis checks against the project's standards (style, naming, structure), the other against correctness (boundaries, security, edge cases). Cross-checking both axes beats any single-axis review.

Practice: ①Read-only roles get allowlist permissions: deny by default, only allow the specific read-only commands needed; guard sensitive files both ways — deny reads of .env etc., and add them to the compression protection list so their contents can't be distilled into a summary and leaked;

②Verification mechanisms are worth more than rules: dual-axis review, calibration baselines, fallback chains (cheap model can't handle it → escalate; execution fails → re-plan) — so the system still converges under uncertainty; ③Make action boundaries explicit: look into X is not fix X;

two execution agents never write the same file concurrently — silent write conflicts corrupt output;

④Infrastructure is a lever, not a replacement: databases, compute engines, middleware are battle-tested deterministic capabilities — the AI should understand intent and compose them, not "re-implement" them.

Why: The more capable AI coding becomes, the more its permissions deserve real engineering.

Giving the agent an environment (permissions, knowledge, verification, fallbacks) matters more than giving it more talk — talk improves single-call quality, environment sets the long-term ceiling.

Let AI carry the "implementation", let the engineering system carry the "constraints", let infrastructure carry the "certainty" — and you free yourself for judgment.

Tip 5: Move humans toward judgment — problem definition, verification, accountability

Phenomenon: When interviewing for AI Coding roles, what I dread most is candidates who talk about AI like a news broadcast: DeepSeek, agents, context windows, multimodality, MCP — word after word.

Ask "how do you judge whether the AI's output is correct" and they go blank.

The real test: does the answer naturally contain the rhythm "I think first, let the AI run, I check/judge"?

Practice: ①Trade "writing it" time for "defining it" time: requirements, boundaries and acceptance criteria written clearly before starting cost less in total than letting the AI guess;

②Verification over trust: don't trust "looks right" — trust unit tests, logs, review, regression.

AI amplifies capability, and it amplifies problems too: someone who can already decompose problems gets faster; someone without judgment just ships their mistakes faster; ③Attribute, don't switch models: when it feels slow, break it down — slow to read (trim context), slow to think (turn off reasoning), slow to write (limit output), or the model itself (task-tiering);

④Weld "accountability is not transferable" into the process: "the AI told me to do it" is not an excuse — a human signs off on release decisions and risk ownership.

Why: As code itself gets cheaper, human value doesn't disappear, it shifts: judgment, architecture, experience and accountability get more expensive. When an interviewer asks "will AI replace you", they're not testing slogans — they want to hear "AI replaces low-value execution, but not problem definition, trade-off decisions, accountability and release judgment".

The future doesn't belong to the AI that writes code fastest; it belongs to people with better engineering environments, clearer constraints, and more expensive judgment.

How to apply this to your situation

You don't need to wait for a "team standard" — start tomorrow:

1. Draw a delivery measurement table: dig through two weeks of project history and list the time per station (requirements/coding/review/testing/release). Whichever station is longest is the one AI can't help you with — attack it first.
2. Create a constraints list: open your project and write down five rules that "newcomers and AI will definitely break, and that aren't written anywhere" — then put it where the AI reads before starting. Every time you step on a rake, add one line.
3. Do one subtraction pass on your agent: spend half an hour testing prompts sentence by sentence and deleting lines that don't change behavior; deduplicate skills; switch read-only tasks to allowlist permissions. You'll feel the output get "cleaner" immediately.
4. Upgrade acceptance criteria from "it runs" to "what it asserts": before merging AI-written code, add at least one assertion that proves the business behavior.

One last thing: everyone's AI Coding honeymoon ends.

The difference is only in what you do after — some treat "fast generation" as the destination; others treat it as the starting point and go fix the three things that actually throttle delivery: verification, constraints, environment.

The latter are the ones who stay valuable after code itself became cheap.