AI Writes the Code, But Nobody Knows Anything Anymore

The problem is not the AI code, but nobody knows anything anymore

When AI generates entire codebases, the real crisis isn't the code's quality—it's that teams no longer understand their own systems. A viral tweet from an engineer at a large company describes specs, tests, and tickets all written by Claude Code, with engineers working 12-hour days just pressing enter. The author argues that intent, taste, and architecture become critical as maintenance remains the ultimate challenge.

I am done with this shit. It is over. The state of engineering right now is horrible. It has been half a month since I started a new role at a big company. Nobody knows anything here. The specs, code, tests, PRDs, tickets, resolution of those tickets, reports, etc., everything is made by Claude Code.
  1. zero_shift

    I was reflecting on this on Saturday in an unformed way, trying to trace the lineage of a decision made at work.

    The code change itself doesn't specifically matter. But suffice to say, it was about an AI feature in one of our products.

    The code was stamped by Claude driven by a prompt. The prompt was for a ticket generated with the Atlassian AI integration. Atlassian had digested docs made with AI. The docs came from strategy memos I'm 90% sure were written entirely by Claude.

    The strategy was chosen by management at the urging of exec leadership. The execs now communicate mostly via AI written memos. I do not know how they make decisions, but they reference tech influencers, market conditions, customer expectations.

    This gave me pause. Who had actually made the decision then? Arguably there has been several layers of human review, but the actual source of the decision was hard to pin down.

    We were not building the feature because we wanted it. We were building it because we thought other people expected it.

    Perhaps reflecting on the state of the market, I thought, could indicate who was actually in control.

    Where do investor and customer expectations come from in 2026? It is very murky, at least in tech. There appears to be hype. Some hype comes from true believers, some comes from cynics. But both respond to market incentives that reward bigger and bigger claims.

    Where does the market's "action" come from? What is the driver?

    Investors do not really seem to understand what […]

  2. glouwbug

    When you write something you constantly remodel your understanding through refactors and rewrites until you internalize it. By internalizing it you gain the capacity to reason about it (during critical downtime) and communicate it. An entire team that can communicate can solve problems together, from one guy's vision to products white boarding to engineering's infrastructure to UX and UI's artistry.

    It boggles me we completely forgot that the world operated like this just 4 years ago

  3. MomsAVoxell

    I am finding this, professionally, not so dramatic - but mostly because the industries in which I've consistently shipped code at scale involve review as a first principle, as in no un-tested, un-reviewed code gets shipped, because: safety critical/realtime requirements and certification specs, say so.

    And having AI code to review is no different than any other code that ever was to review, so the review tooling is - as it necessitates - also benefited by lugubrious application of .. more AI. But: all AI is human reviewed.

    So it's not a big impact. We just don't ship code that isn't 100% human reviewed, If that's insurmountable: you're doing it wrong. Use AI to make code readable again.

    And then, also, put AI back in its box. Don't give devs 100% full-time API access to subscriptions: give them actual hardware to use, to go 100% local.

    Local AI is, thus, the best AI, folks. Don't use more than you can run locally, is a great way to keep AI code properly maintainable.

    The industry will prove this, itself, sooner or later: If you can't put your AI in its box for safe-keeping, you're doing it wrong, anyway... and should've already learned this practice as a habit, decades ago, vis a vis future-proof tooling... (See also: not logging everything you do with an AI? Big fail.)

    Sure, the absolutely intoxicating addiction of Big Metal AI™ is going to put a lot of consumers in a deep, deep pit of Neo-Illiteracy - however: 'good' AI code is actually just good code.

  4. bengold14

    I see this everyday. The problem is code is the wrong abstraction for the work we do. LLMs have solved coding, but they haven't solved systems, collaboration or system maintenance.

    Edit: Since I seem to have touched a nerve - I've been working on a project to solve this: https://www.archme.io if you want to know my thoughts on the right abstraction

  5. ecshafer

    AI is going to make, long term, Software Engineering more important. Getting requirements, user feedback, tests, product vision. These are key differentiators now.

    If you can really get a good set of requirements, go and write all of your test cases out, and then throw it at an AI that will one shot it. Its perfect.

  6. hollowonepl

    AI is not for programmers, they will always complain and given time and resources can of course produce better atomic code. AI is for a combination of a business analyst, architect and product manager in one person who has capacity in coding but decided this is limited role in the whole software engineering lifecycle. With the right attitude and of course certain level of micro management over AI (which they had to do with human programmers as well) they can achieve the same or similar results with much less communication friction, less people to maintain that teamwork and get closer to solving issues they find rather than discussing philosophy of programming and other manifestos of the craft that stopped being prestigious or unique and that’s the key point of complaint when AI is given wrong people to use.

  7. vld_chk

    I feel related to it. I switched companies at the end of July. First 4 weeks AI was giving me the feeling of freedom. No longer I need to understand tens thousand of lines of legacy codebases. Never onboarding was so easy. Just ask Claude and it tells me what happens here and how.

    But after 2 months it starts to backfire me. I still know nothing. I have some understanding of the system design and core components but I have zero clue about how certain things are done under the hood. Because AI read code for me and code for me and I take it as my own understanding.

    In last week I end up limiting my AI usage and forcing myself (it is really hard) to read and code at least a bit by myself to start having any idea about what is going on here.

  8. bentt

    In this moment there are a million ways to do things wrong.

    But there are also some ways, maybe less than a million, to do things right.

    Here's an anecdote about a way to do this wrong.

    I have found with AI coding methods that there's a line where it becomes a hail-mary (in the American Football sense).

    A hail-mary is when you throw the ball to the end zone and just pray someone catches it. This is almost always at the end of the game.

    This moment with AI code is indicative that you can't put together a coherent plan so you just tell the agent to "make it good". It used to be that the results here would suck, but now the agents are really competent, so the results might be good.

    But at that moment, that's your cue to back up. Because as soon as you take a solution that's so far detached from your understanding, you're underwater. The hail mary is not part of a larger game plan. It's the last play of the game. There's nothing after.

    So as soon as you reach that moment in your coding, you're signaling that you're done understanding not just the code, but even the way it works at a high level. If you're still going to work with this code after, then back up and work with the AI to get more understanding of the problem.

More from this day

2026-09-28