"Better Than Human" Code Keeps Breaking in Production

There's a comforting myth going around engineering circles: AI writes better code than humans do. The myth survives because AI writes first — it produces a clean, confident, seemingly finished draft before a human has typed a single line, and that speed gets mistaken for quality. But the bill for that illusion is coming due. Ford spent the last few years quietly bringing back around 350 experienced engineers after its automated quality-control systems couldn't catch what they were supposed to catch. IBM cut roughly 8,000 HR roles in favor of its AskHR system, then announced it would triple entry-level hiring in 2026 once the AI proved unable to handle anything outside a script. Klarna's CEO stood on stage and bragged about replacing 700 customer service employees with AI — then started rehiring humans within a year, saying customers needed to know "there will always be a human."

Robert Half puts the pattern at scale: nearly 29–32% of managers who cut a role citing AI have since rehired for that same role, and Orgvue found 55% of leaders who made AI-driven cuts now admit the decision was wrong. None of this is an argument that AI can't code. It's evidence that "looks done" and "is done" are different things, and AI is very good at the first one.

The gap shows up literally in the code. AI models are trained to produce something that runs and reads cleanly, not something that scales, secures data, or survives a second engineer touching it — and those failures hide well because they don't throw errors on a small test case. Take a function an AI might hand you for "get all orders with customer names," which looks perfectly reasonable at a glance:

def get_orders_with_customers(order_ids):
    orders = []
    for order_id in order_ids:
        order = db.query(f"SELECT * FROM orders WHERE id = {order_id}")
        customer = db.query(f"SELECT * FROM customers WHERE id = {order.customer_id}")
        orders.append({**order, "customer_name": customer.name})
    return orders

It passes every quick manual test. It also has two classic architectural sins baked in: an N+1 query problem (two round-trips to the database per order instead of one batched join, which turns 20ms into 20 seconds at production scale) and a SQL injection vulnerability from string-interpolating order_id directly into the query. A senior engineer would write it as a single joined query with parameterized inputs; an AI, asked in isolation to "fetch orders with customer info," will very often produce exactly the version above, because it's syntactically correct, idiomatic-looking Python, and nothing in the prompt asked it to think about query count or trust boundaries.

The example above is not hullucination, it's a real-life example I have encountered before when reviewing Ai generated code.

Ask an AI to write extractor.py in isolation and it will often do a genuinely good job — the file is self-contained, its inputs and outputs are visible in the same context window, and there's nothing else competing for the model's attention. Ask it to fold that extractor into an existing application with its own auth layer, its own database session handling, its own error-reporting conventions, and its own module boundaries, and the seams start to show: duplicated config, a new logging pattern that ignores the app's existing one, a circular import, a session object opened but never closed because the extractor was written as if it owned the whole process.

Isolated files are a local optimization problem the model can hold in its head; a whole application is a global consistency problem that requires remembering decisions made a hundred files ago, and that's exactly the kind of long-horizon architectural memory current AI tooling doesn't have. Until that changes, the honest read isn't "AI writes better code than humans" — it's "AI writes better first drafts of small, isolated problems," and the deceptively expensive work of turning that into a system that holds together is still, stubbornly and expensively, a human job.