The tempting story about AI and productivity is simple: if software development is the long part of the timeline, make coding faster and the whole process gets faster.

That story is tidy. It is also usually wrong.

In many organizations, the visible delay sits in engineering because engineering is where uncertainty finally becomes impossible to hide. A vague business request can move through planning, budgeting, legal review, and status meetings while still looking like progress. Then it reaches the team that has to turn the idea into a working system, and every unresolved question becomes concrete.

The delay gets assigned to development because that is where the clock is easiest to see. The cause often lives earlier.

AI changes the cost of producing code. It does not automatically change the quality of the input, the clarity of the decision rights, or the number of unresolved assumptions hidden inside a ticket.

The Trap of Optimizing the Longest Bar

Imagine a project timeline with three broad phases:

• scoping,
• development,
• deployment.

If the development bar is much longer than the other two, it is natural to treat development as the bottleneck. That can be true. But “the longest phase” and “the origin of the delay” are not the same thing.

Development work is often long because it absorbs ambiguity from upstream stages.

A feature request says: “Email the user after a sale completes.”

That sounds small until someone has to implement it:

• What exactly counts as a completed sale?
• What happens if payment succeeds but fulfillment fails?
• Does the email go to the buyer, the account owner, the billing contact, or all of them?
• What language and template should be used?
• Should the message be suppressed for refunds, fraud review, test orders, or enterprise contracts?
• Who owns the compliance wording?
• How is the result audited?

None of those questions are “coding speed” questions. They are product, domain, legal, and operational questions. A developer may discover them while coding, but that does not mean the development team created the delay.

This is why process improvement based only on duration can mislead. You see where time was spent, not necessarily where uncertainty was introduced.

Faster Typing Was Never the Limit

Software development is not mostly typing. If it were, companies would send engineers to typing classes and call that transformation.

The actual job is translation. Someone has to turn a messy human goal into a precise machine behavior that works under edge cases, survives production traffic, respects security boundaries, and remains maintainable after the launch meeting is over.

That translation requires enough context to make good choices:

• the real business objective,
• the expected user behavior,
• the domain rules,
• the failure modes,
• the integration contracts,
• the non-negotiable constraints,
• the acceptance criteria.

When those inputs are thin, engineering becomes a discovery function. Developers interview domain experts, reverse-engineer legacy behavior, infer product intent from Slack threads, and write code only after the shape of the problem finally becomes legible.

AI can help inside that loop. It can draft code, generate tests, explore alternatives, explain unfamiliar APIs, and speed up local iteration. But if the team still has to discover the requirements by chasing five stakeholders, the project has not escaped the bottleneck. It has only made one activity inside the bottleneck cheaper.

The AI Shortcut Usually Moves the Work

The strongest version of the AI optimism argument says that the developer becomes less of a builder and more of a project manager. Instead of writing the implementation, the human writes the prompt, supervises the agent, and reviews the result.

That can work for bounded tasks. It does not remove the need for clarity. It often increases it.

An AI system is extremely sensitive to the shape of the request. If the request is vague, the model will fill gaps with plausible assumptions. Sometimes those assumptions are useful. Sometimes they are subtly wrong. In business software, subtle wrongness is where the cost lives.

So the work shifts:

• from coding to specifying,
• from implementation detail to acceptance criteria,
• from manual typing to review,
• from “what should I build?” to “how do I know this is correct?”

That shift can still be valuable. It can reduce implementation time and give experts more leverage. But it is not magic throughput. Someone still has to know what the system is supposed to do.

The uncomfortable part is that good AI-assisted development often asks for the thing software teams have wanted for decades: clear problem statements, useful examples, explicit constraints, and fast access to people who can answer domain questions.

If giving those same inputs to a human team would also make them faster, the improvement is not purely an AI story. It is a process-quality story.

Better Inputs Beat More Capacity

When a legal review is slow because the legal team receives incomplete documents, adding more lawyers may not help. Each new reviewer still has to chase the same missing information. The real improvement is making the intake complete, predictable, and easy to evaluate.

The same principle applies to software teams and AI agents.

A bottleneck needs high-quality input. That means the work item arrives with enough context for the next person or system to make progress without constant interruption.

For engineering, that might look like:

• concrete user scenarios,
• examples of good and bad outputs,
• known edge cases,
• data contracts,
• migration constraints,
• permission rules,
• observability requirements,
• rollback expectations.

For AI-assisted engineering, the bar is even higher in some places. If the model is going to produce a large patch, the verifier has to be strong enough to catch wrong behavior. If the agent writes tests, a human still needs to ask whether those tests prove the right thing. If the change touches money, security, compliance, or customer trust, “the code compiles” is not a meaningful definition of done.

Anthropic’s parallel Claude C compiler experiment is a useful example here. The agent team produced an impressive 100,000-line compiler and showed how far autonomous development can go with carefully designed harnesses. But the write-up also emphasizes the amount of scaffolding required: tests, build scripts, log conventions, progress signals, and human concern about deploying software that has not been personally verified.

That is the lesson for normal companies. AI agents perform best when the surrounding process is engineered for them. They need clean tasks, reliable feedback, and strong verification. Those are process investments, not prompt tricks.

Where AI Actually Helps

None of this means AI is useless for process speed. The opposite is true. AI is useful precisely when you place it where the work is ready for acceleration.

Good places to use AI:

• turning a clear acceptance test into implementation,
• generating first drafts of repetitive code,
• exploring API usage and migration paths,
• producing candidate test cases for human review,
• summarizing discovery notes into a structured spec,
• checking a change against a list of known constraints,
• automating small operational tasks that already have stable rules.

Weak places to use AI:

• replacing unresolved product decisions,
• guessing stakeholder intent,
• inventing compliance policy,
• validating its own work without independent checks,
• turning a one-line feature title into production behavior.

The difference is input quality. AI is much more useful after the problem has been made precise enough to evaluate.

A Practical Process Check

Before asking “how much faster will AI make this team?”, ask a more direct question:

Can the team start work without waiting for missing decisions?

If the answer is no, the first automation target is not code generation. It is intake quality.

A useful review looks like this:

1. Pick a recent project that ran long.
2. Mark every point where work stopped for a missing answer.
3. Separate implementation effort from clarification effort.
4. Identify which questions could have been answered before development began.
5. Change the intake process so the next similar project arrives with those answers.

Then bring AI into the improved flow.

Use it to turn better inputs into faster drafts. Use it to make review checklists easier to apply. Use it to generate examples and edge cases. Use it to reduce mechanical work. But do not expect it to compensate for a process that sends incomplete work downstream and calls the downstream delay “engineering.”

The Real Leverage

AI is a multiplier. Multipliers are strongest when they multiply a healthy system.

If your process already provides clear goals, complete context, fast decisions, and reliable verification, AI can make parts of it dramatically faster. If your process depends on ambiguity flowing downhill until someone in engineering resolves it under deadline pressure, AI will mostly make that dysfunction harder to see for a while.

The better question is not whether AI can write code faster than a human. It often can.

The better question is whether your organization can produce the information needed to know what code should exist, whether it is correct, and whether it should be shipped.

That is where the real bottleneck usually is.

Sources

• I don’t think AI will make your processes go faster
• Discussion thread
• Building a C compiler with a team of parallel Claudes