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

"People are working 12 to 13 hours a day just to press enter. Nobody is reading anything."

Really? Seems like they're not making proper use of the tool. I've been reading MORE not less, and also learning more along the way. Just hitting "enter" is a choice, these tools are so powerful if you invest your curiosity, time and experience.

Sounds like they don't care about what they're doing in the first place, writing code by hand won't fix that.

> 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.

that tweet about the fast moving startups looks like almost the hypothetical AI nightmare situation just dreamed up. Assuming it's real, i mean yeah, people shouldn't work for these stupid high-moving startups I guess. From my perspective, "when did startups NOT suck?". The code was always garbage at startups, the push to work 12 hour days was always at startups, "nobody is resolving bugs" ha well yes, welcome to a startup? I hope the guy is at least getting paid and doesnt have to hire a lawyer to get his checks like I did. startups suck

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

This is almost the same as saying "The problem is not the fentanyl, but that everyone keeps getting addicted or dying." In a very literal sense, yes, absolutely. There is a way to safely use fentanyl. But from a holistic point of view, the way to do so is so specific (ie multiple medical professionals prescribing and possibly even administering and monitoring vitals afterwards) and limited that for the general public is much more useful to just say "It's unsafe to use fentanyl unless following instructions from your medical provider." There's absolutely a way to use AI for coding that doesn't result in not actually knowing about the produced code, but it's so damn hard to get that right and you won't even realize you've fallen away from that knowledge until it's too late.

The point about PMs is I think illustrative of this issue. Yes, great PMs who actually understand the product they want to build and can then turn that into something using engineering teams as a black box system exist. But by and large, no they don't. A massive part of why waterfall fell out of fashion is because it turns out most orgs don't have and can't find PMs/PM adjacent people who can build that knowledge, and you can see how agile attempts to correct for this by turning a pipeline into an OODA loop. If you can prevent pipeline flushes, it will beat that OODA loop, but it turns out as an industry we can't actually prevent enough pipeline flushes for that to be the case and we can (for the most part) use that OODA loop to eventually iterate into something a paying customer might give us money for.

Part of the issue is that we're treating the AI like it's just another compiler or static code generator. It's not. The reason they're not is because they require a complete specification of what to output, ie the code. That level of specificity is what allows engineers to mostly stop caring about the assembler and just stay in their higher level code (the main exception being extremely hot loops in places too complex for the compiler to optimize well) and legitimately be able to say they understand the code without ever looking at the compiler/linker output. The entire point of AI for code generation is taking an incomplete specification and turning it into a completed one. If you review and understand every line of output the way almost no one did even before AI was a thing, then you're not going to fall into the trap of not knowing anything about your system anymore. But at the same time, you're not really going to get much benefit from AI either, because you're just replacing time spent coding with time spent reviewing code. It might even take you longer to review than it would to just code it yourself (i think every senior engineer who's mentored a junior dev knows this exact feeling).

To actually get the benefit from AI you have to let go of looking at the code output at all, because looking at that output is the slow part and because just looking and reviewing still won't give you the same knowledge as actually implementing. The passenger aviation industry handles the second issue by preferring/requiring manual control in critical areas (takeoffs and landing) and using simulators to extensively train for manual recovery outside of the abilities of autopilot. For developers the second bit is actually why reviewing AI output is a fool's errand - it will give you the false confidence in your understanding of the system. That doesn't mean we have to embrace vibe-coding or accept slop. It means changing the engineering process from one that deals with a deterministic system to a stochastic one. As an aside, I think this is why upper level managers and executive are leaning into AI code generation so hard - engineering was already a stochastic black box system to them.

This is the kind of stuff AI-skeptics have warned about daily on this very site for the last year or two. We are met with "you'll be left behind" and "you're just coping" and "the future is coming".

This shit is blatantly obvious. And if people keep pushing and pushing for LLMs to generate things that are actually used directly, the problem will grow so large that most people will barely remember a time when their job was something that could be understood.

This is why generative AI sucks.

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.

[dead]

[dead]

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.

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.

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.