The biggest risk in AI-assisted engineering isn’t bad code. It’s what faster output allows teams to avoid.
Author: James Phoenix | Date: July 2026
The Risk Nobody Prices In
AI can write code, draft tests, explain errors, and accelerate almost all of the mechanical work in a software project. In the hands of a capable team it is a genuine multiplier. I use it every day and I am not going back.
But it can’t walk into a meeting and say, “We’re making a mistake.”
It won’t point out that the stakeholders aren’t aligned, that the requirement makes no sense, or that the team is solving the wrong problem. It won’t challenge the plan because everyone in the room looks uncomfortable. It won’t ask whether the project should exist in its current form.
That is still engineering. Not a soft skill next to engineering, not management overhead around engineering. The core of the job.
Projects rarely fail because teams type too slowly. They fail because people delay hard conversations until the consequences become expensive.
The Failure Loop Just Got Faster
The classic failure sequence looks like this. A vague requirement becomes a flawed design. A flawed design becomes a working, but wrong, system. A working system becomes proof that weeks of effort went into solving the wrong problem.
AI does not break that loop. AI makes the loop spin faster.
If nobody understands the requirement, AI will still generate a solution. If the deadline is unrealistic, AI will help the team produce more before the deadline slips. If the stakeholders are confused, AI will turn that confusion into polished specifications, tickets, tests, and code.
The output looks impressive. The result is still wrong.
This is the same mechanism I described in The Most Important Language for Software Engineers Is English: ambiguity used to be a local communication cost, and now it is executable. A coding agent doesn’t stop and ask whether the ticket makes sense. It picks a plausible interpretation and ships it, with tests, at machine speed. That note is about fixing the ambiguity by writing better briefs. This note is about the harder case: the brief is clear, the execution is clean, and the project is still wrong, because the disagreement lives between people, not in the spec.
Polished Output Is Camouflage
There is a second-order effect here that I think is underrated. Before AI, a confused project looked confused. The tickets were vague, the design doc contradicted itself, the prototype was janky. The mess was a signal, and the signal triggered the conversation.
AI removes the signal without removing the mess. A team that doesn’t know what it’s building can now produce a beautifully formatted PRD, a coherent-sounding architecture doc, a full test suite, and a working demo. Every artefact says “this project is healthy.” None of them can say “the two VPs sponsoring this want incompatible things.”
Velocity becomes camouflage for misdirection. The team travels further down the wrong road before anyone checks the map, and by then the sunk cost is bigger, the demo is more convincing, and the conversation is harder to start than it would have been in week one.
This is the organisational version of the pricing bug I wrote about in Developers Are Having an Identity Crisis. Generation got cheap, verification stayed expensive, and the gap gets charged to whoever still checks. At the project level, generation of artefacts got cheap, verification of direction stayed expensive, and the gap gets charged to whoever finally says the uncomfortable thing.
Four Sentences Worth More Than a Thousand Lines
The highest-leverage things an engineer can say on a doomed project are not technical:
- “We don’t understand the requirement.”
- “This deadline isn’t realistic.”
- “The stakeholders want different things.”
- “We’re optimising for the wrong outcome.”
Each of those sentences, said early, is worth more than another thousand lines of code when the project is heading in the wrong direction. Each of them is also socially expensive to say, which is exactly why they get deferred. The cost of the sentence is immediate and personal. The cost of not saying it is delayed and shared.
AI changes nothing about the social cost and everything about the deferral. It gives the team something productive-feeling to do instead of having the conversation. Shipping is the most respectable form of avoidance ever invented, and AI just made avoidance faster.
Judgement Appreciates as Execution Depreciates
I made the economic version of this argument in The Coder Is Obsolete. The Programmer Is Not.: when the coding seat gets automated, the analyst, designer, and programmer seats become the job. Deciding what to build, and whether to build it at all, is the part that appreciates.
The hard conversation is the sharpest edge of that judgement. Knowing when to stop building and question the premise is a skill, and it compounds like any other. AI raises the ceiling on execution, but it doesn’t replace honesty. If anything it makes honesty more valuable, because teams can now travel much further before discovering they chose the wrong road.
What I Actually Do
Doctrine is cheap, so here is the practice:
- Name the conversation as the task. When I notice a premise problem, I don’t fold it into a ticket comment or hope the standup surfaces it. “Get the two stakeholders to agree on the success metric” goes on the board as a work item, because it is one, and it blocks the build items downstream of it.
- Use “success looks like…” as a tripwire. If I can’t finish that sentence for the project (not the ticket, the project), that’s the signal to stop generating and start talking. An unfinishable success sentence is a requirements problem wearing an execution costume.
- Treat impressive output as evidence of throughput, not direction. A working demo proves the team can build. It proves nothing about whether they should. I review direction on its own cadence, separate from sprint review, precisely because sprint review always looks good now.
- Say the sentence early, when it’s cheap. “We don’t understand the requirement” costs a little awkwardness in week one and a rewrite in week six. The price only ever goes up.
Have the hard conversations. Then build faster.
Related
- The Most Important Language for Software Engineers Is English – The spec-side fix: ambiguity is executable now, so write the brief that removes it.
- The Coder Is Obsolete. The Programmer Is Not. – Why deciding what to build appreciates as execution gets automated.
- Developers Are Having an Identity Crisis – The pricing bug: cheap generation, expensive verification, and who absorbs the gap.
- Comprehension Debt Is Refinanceable – You can’t out-discipline a generator running at machine speed.
