The problem is not AI code, but not knowing about system architecture or intent

zazuke 358 points 227 comments September 28, 2026
www.ssp.sh · View on Hacker News

Discussion Highlights (20 comments)

khelavastr

People don't get fired for dishonesty or persistent failure like you'd expect.

chinathrow

Clicks on blog, sees AI generated template, leaves. Enough, already.

kraftman

We've had team changes and product manager changes and lack of documentation for so long that this was the state of our team anyway: no one knows why it was done and no one wants to break it.

runarberg

I predict we will see more and more of these convoluted rationales (i.e. excuses). All these basically boil down to: “I know AI is crap, but I have found a way to make it useful. Trust me.” I am gonna appeal to Occam’s razor here and say, the integral variable here is AI, and the only variable you need to know is AI. The problem is AI.

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

badrequest

The plural of anecdote is not fact.

simonw

If you don't understand how your system works, your ability to make good decisions about future work on that system quickly degrades. I don't think you need to review every line of code, but you absolutely do need to be able to describe how the system works and its high level structure. As is so often the case with coding agents, having experience as a tech lead or engineering manager really helps here. You are responsible for a large system that has been worked on by multiple different collaborator (both human and agentic). You need to be able to make smart, informed decisions about that system, and talk with credibility to other stakeholders about what it can and cannot do and sensible next steps for the project.

softwaredoug

Yeah we forgot the goal of programming isn’t just to tell the computer what to do, it’s to program the programmer into thinking a deeper understanding of the problem.

benzible

"Nobody is resolving bugs" is weird. Coding agents are great at resolving bugs! So much of what I see posted here seems more about how coding agents are being misused rather than anything inherent to them.

wuliwong

>We’ve had to know everything about the product/business from day 1 I know this is being hyperbolic but I thought this was an odd post to include. I've met plenty of data engineers that don't have great knowledge of the business/product and SWEs that do have that. ¯\_(ツ)_/¯

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 the tech is or its limitations. Some are passive operators. Others are just responding to the overall froth and speculation in the market - which becomes a runaway feedback cycle. This left me lost. Nobody in this ecosystem, I thought, is actually in control here. Nobody is actually orienting work and action to real, concrete goals. It's all based on speculation and anxiety about the future. So it is not only that nobody understands what the code does. It is that we cannot, or at least I cannot, explain the motivation. There doesn't seem to "be" any form of "intention" in this environment. It has all been hollowed out, replaced either be inscrutable machines, or inscrutable incentives. Ironically it rather resembles the kind of "misaligned" superintelligence we are supposed to be avoiding.

meowface

It's not a given. It's about willpower and care. LLMs are the ultimate crutch. I over-rely on the crutch, more and more people will over-rely on the crutch. But it is still inherently a psychological problem. You can still know things and get force multiplication out of LLMs, if you are disciplined and caring enough. In practice, most people won't be. And you can't force other people to be. But you can force yourself to be.

ramsaybolton

A man has to write program for himself and a man has to use the program. A man needs to define in code what the program does. If AI defines what code does then man has not written program for himself.

827a

The future of engineering is product management. I don't believe there is any world left for people whose primary responsibility is opening pull requests; and we're seeing the angst against this happen from both directions. Engineers hate it. Leadership feels they don't need them. The truth is somewhere in the hazy middle; we're just in an uncanny valley right now where neither side can take the leap to cross the valley: the agents aren't good enough yet, and the bigger problem is that there's no job title or corpus of experience leadership can look to and say "Yeah that's the person we need in this role". The labs saw this early, and thus many roles at the labs are "Member of Technical Staff". That's the future for every software team. You're not a software engineer anymore, but you're also not a PM, nor a designer. Think horizontal slices, not vertical: Every human's responsibility is to leverage AI to be an expert on everything necessary to deliver some vertical slice of the business.

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

feverzsj

The problem is always maintainability, which can only be achieved through human understanding of code.

_doctor_love

> But the final boss is, and always will be, maintainability. Always has been, always will be. I am actually hopeful that AI will finally break the industry and force a reckoning around this. Some of it goes to our economic system. New builds are usually capitalizable, flashy, and a great way to get promoted. Doing ten to fifteen years of thankless maintenance, keeping a critical system alive with high quality? Usually nobody cares, and it's OPEX, not sexy.

PaulHoule

Too many young people in startups without enough experience. I was in a Hackathon for students which quite a few staff, like myself, infiltrated. The results were completely unfair, staff and teams with staff (like mine) cleaned up the awards. In my case I was working with a student who was much better at writing platformers in Unity than I was and an another student who could draw the art we needed even if she'd been trained to think every problem we had interacting with each other had something to do with "the patriarchy". Myself I'd been in many startups where the game was make a half-baked demo that you could demo on stage and get people excited about it. So everything from presenting broken software on stage and making it look not just perfect but enticing and developing software that has the qualities it takes to present it that way was routine for me, the bit that isn't routine is onboarding unexperienced people to this life in two days. The more things are unprecedented, the more you need a longer view with more experience.

behnamoh

This article assumes that this problem did not exist before AI. Especially in large companies like Google, the number of people who actually knew what they were doing was relatively small. The vast majority were just piggybacking on other people's work, which I absolutely hate. At least AI has made this obvious, and the difference between people is now their taste, which, for the majority of people, is bad news.

jarjoura

I agree writing completely new systems with LLMs is now near impossible to keep in your head, however, the onus is STILL on you the individual engineer. You are mistaken if you think that's changed. So, if you're pooping out code, and committing it because tests still pass, and that's all you know, you're in for a treat. When an executive wants to know why a b0rked feature lost their department millions of dollars, guess who will have to answer for it, and its not the LLM. My advice is to find ways to keep on top of how it all works, and if you're the only one who cares, well, then, that makes you even more valuable, not less.

Semantic search powered by Rivestack pgvector
7,945 stories · 74,007 chunks indexed