The first wave of AI criticism mocked the machine from outside. The second is stranger: senior engineers now use AI well enough to stage its failure, then present the obedient result as proof that the machine cannot think.
This post is a follow-up to Talking Down The Machine. That essay was about the social habit of ridiculing AI while quietly depending on it. This one is about the next mutation: using AI itself to produce the evidence for that ridicule.
A new form of AI criticism is emerging among senior software engineers. It is not the old rejection, where someone dismisses the tools without having used them seriously. That phase is already exhausted. The newer critique is more sophisticated, and more revealing, because it is itself AI-augmented.
The critic has learned enough about the machine to make it fail convincingly. He gives it faux requirements, low-level implementation breadcrumbs, and a narrow command surface. He does not ask it to challenge the premise, recover the domain, identify invariants, or refuse the altitude of the task. The model complies. The resulting code is bad in real ways. Then the human expert holds up the mess as proof that the machine is stupid.
The machine has not merely been criticized. It has been induced to confess.
Although we are directly addressing the critique in Zoran's YouTube video Claude Code Is Resurrecting Our Worst Nightmares, we are also using his video as an example of this second wave.
The staged failure
The old posture was simple: AI writes garbage; real engineers do real engineering. That kind of critique is no longer very interesting. It is too blunt, too defensive, and usually too detached from actual use. The more interesting pattern is different: let me use AI to prove that AI writes garbage.
That is a more subtle move. The critic knows the tool well enough to produce the result he wants, but not honestly enough to treat his own steering as part of the result. He is no longer outside the machine. He is working with it, directing it, framing it, extracting from it a performance that confirms his thesis. The AI skeptic has become AI-augmented.
The failure shown in these demonstrations is often real. Primitive obsession is real. Nullable state correlated with lifecycle is real. Public methods that exist on objects incapable of performing them are real. Enum-driven domain modelling can absolutely become a trap. A money transfer should not be a decimal, a string currency, a status flag, and a set of nullable timestamps and employee IDs held together by hope.
But a real failure can still be a staged failure.
The mechanism is straightforward. Start with a domain problem. Collapse it immediately into a class. Feed the model one field-shaped instruction at a time. Call those instructions requirements. Let the model continue the local shape you have created. When the object becomes a mutable bag of primitives, nullable companion fields, enum-driven state, and defensive branches, pause and explain to the audience how terrible AI-generated code is.
As content, this works. As evidence, it is weak.
Faux requirements
A customer requirement for a money transfer system is not "add a nullable execution timestamp." It is not "add approver one and approver two as optional GUIDs." It is not "add a status enum with pending, approved, executed, expired, and rejected." Those are candidate implementation details. Worse, they are implementation details at the exact altitude where weak object models are born.
A serious requirement would describe the business protocol. A transfer moves a valid monetary amount between two identified accounts. It may be subject to an approval policy. It expires under defined conditions. It cannot be executed unless it is legally executable. Its lifecycle transitions must be auditable. It must preserve monetary invariants, identity invariants, timing invariants, authorization invariants, and execution invariants. Depending on the system, it may also need idempotency, concurrency control, reconciliation, persistence boundaries, and operational recovery semantics.
That is the domain. A list of properties is not the domain.
When an AI agent is handed property-shaped fragments, it often produces property-shaped code. That is not evidence of deep incapacity. It is evidence that the steering surface was already at the wrong level. The model has been asked to extend a shape rather than interrogate it. It has been invited to continue the smell.
This is where many senior critiques become dishonest, not because the code smell analysis is wrong, but because the experiment is smuggled in as evidence. The prompt is treated as neutral. The sequence of instructions is treated as if it came from reality. The low-level implementation frame is treated as if it were unavoidable. The model’s cooperation is then presented as proof of its incompetence.
But cooperation is not competence. It is also not incompetence. It is one property of the system.
Compliance is not judgment
General-purpose models are often optimized to be helpful, agreeable, and locally responsive. Unless they are given stronger context, stronger operating principles, and permission to challenge the user, they will often play along with a foolish premise. They will accept fake requirements. They will implement the field list. They will call the resulting artifact a reasonable start. If prompted in the right way, they may even help explain why the code they produced is bad.
The machine will not necessarily defend the integrity of the task unless its context tells it to.
That is uncomfortable for experts because it moves part of the responsibility back to the operator. If the model produces nonsense after being given nonsense, that does not absolve the model. But neither does it absolve the human. In human work, a senior engineer would be expected to push back against incoherent requirements. In AI-augmented work, the same expectation has to be designed into the working system: prompts, instructions, review loops, tests, examples, acceptance criteria, and escalation rules.
An unvetted agent is not a colleague with a culture. It does not automatically inherit your organization’s taste, judgment, skepticism, or sense of proportion. It does not know, by default, that "implement a class" may be the wrong abstraction. It does not know which instructions are serious and which are merely breadcrumbs toward a bad demo. It must be given context, constraints, and a right to refuse the frame.
Good AI work therefore does not begin with code generation. It begins with steering discipline.
The effective operator does not merely ask for output. He defines the mission, the invariants, the boundary conditions, the failure modes, and the verification envelope. He tells the agent what must remain true. He asks it to identify illegal states before writing types. He asks it to separate domain concepts from storage conveniences. He asks it to test lifecycle transitions, expiry, rejection, approval, execution, and idempotency. He gives it permission to stop and say: these are not requirements; these are implementation hints; the model is underspecified.
This is not indulgence toward the machine. It is engineering.
The organizational version
Many organizations are about to repeat the same mistake at larger scale. They will buy AI tools, give them low-quality tasks, accept plausible outputs, discover mess downstream, and conclude that the tools are unreliable. In many cases they will be right about the mess and wrong about the cause.
The cause will not be AI in the abstract. The cause will be the absence of a system around the AI: no invariant language, no test harness, no review protocol, no domain model, no ownership boundary, no feedback loop, and no explicit decision about where the machine may improvise and where it may not.
The bad code is only the visible artifact. The invisible failure is coordination.
This is why the claim that "AI cannot model business applications" is too easy. AI will absolutely produce weak models when asked badly. It will also produce weak models when asked well and insufficiently verified. It can miss domain nuance. It can overfit to familiar patterns. It can produce elegant nonsense. It can imitate a design vocabulary without preserving the operational truth underneath.
None of that is controversial.
The serious question is different. What happens when the AI is not asked to produce a class, but to model a lifecycle? What happens when it is not asked to add fields, but to preserve invariants? What happens when it is not asked to continue a local implementation, but to build against a comprehensive test suite? What happens when it is not allowed to silently comply, but required to challenge the frame when the frame is below the domain?
A staged failure does not answer those questions.
It answers a smaller one: can a capable human make the machine look stupid?
Yes. Easily.
The machine is unusually willing to cooperate in its own humiliation. That is part of its risk profile. It is also part of its usefulness. The same compliance that makes it productive in the hands of a disciplined operator makes it vulnerable to bad steering, performative skepticism, and content-shaped experiments.
Status is still underneath the argument
The expert who stages the failure is not necessarily lying. He may genuinely believe he is revealing something important. And he is, just not only what he thinks.
He is revealing that bad AI-generated code remains bad code. He is revealing that modelling still matters. He is revealing that senior judgment has not disappeared. But he is also revealing something else: the need to keep the machine in the role of the junior, the fool, the obedient intern, the thing that proves the expert’s continued superiority.
That is understandable. Relevance is economic. Expertise is identity. A senior developer who has spent decades building taste, judgment, and reputation cannot be expected to greet a disruptive production technology with neutral curiosity. The machine threatens the credit economy. If good output can be generated quickly, the scarce skill shifts from production to steering, verification, integration, and ownership. That shift is not flattering to every existing status structure.
So the machine is made to confess.
It confesses that it writes primitive-obsessed code. It confesses that it does not understand domain modelling. It confesses that it cannot think. It confesses that the old expert was right all along. But the confession has been scripted. The question is not whether the confession contains truth. It does. The question is whether the truth is being used constructively.
Constructive critique would show the failure mode, the steering that produced it, a better steering strategy, the test harness, the invariants, the improved result, and the remaining risks. Performative critique stops earlier. It says: here is the mess; therefore the machine is bad; therefore my prior hierarchy survives.
That is not enough.
The point of AI-augmented engineering is not to trust the model. It is to design a work system where the model’s strengths can be used without allowing its weaknesses to define the architecture. That requires context. It requires disciplined prompting, but not prompting as incantation. It requires tests, but not tests as theatre. It requires review, but not review as late-stage disgust. It requires the operator to remain responsible for the whole.
The best practitioners are not the ones who never see bad AI output. They see it constantly. The difference is that they do not confuse a bad local output with a complete evaluation of the production system. They ask why the output occurred: what context was missing, what invariant was unstated, what test failed to exist, what instruction permitted compliance where resistance was needed, and what boundary was implicit when it should have been explicit.
That is the work.
The centaur era does not remove senior engineering judgment. It exposes whether that judgment is real. A senior engineer can use AI to accelerate coherent systems, or to produce impressive evidence for a predetermined complaint. Both are AI-augmented behaviours. Only one is serious.
The machine will confess to almost anything.
The engineer’s job is not to celebrate the confession. The engineer’s job is to understand who wrote it.