This aligns with my thoughts on a recent post here about code being "clay" now (as opposed to stone, which must be chiseled with great effort, skill, and time expenditure). Clay is much easier to work with and mold to our desired shape.

My point was, you still didn't build infrastructure out of great lumps of clay. You don't slap down some clay in the middle of a stream and vibe-build a bridge. Infrastructure was still built of stone. Or, if clay, out of individual bricks.

Similarly, LLM-generated code should be used to build discrete bricks of code that can be read, tested, and most importantly, understood. Then you take those bricks and architect and engineer your application with them. This is how you build a platform that can survive actual use.

You can make a model of a bridge with the clay...but the actual bridge is an entirely different pursuit. This is a discipline we need to develop as engineers, since LLM-generated code won't go away. It can be used to make bricks faster but we have to make the engineering decisions that create reliable, secure applications.

Does anyone find it annoying to read AI generated/assisted posts like this?

It's like reading Claude 5+ output verbatim.

Maybe it's been edited by a human, or maybe not. I could not last more than a few paragraphs.

In my day job I *heavily* use agents for almost everything, so I think I've got a good sense for when AI wrote most of the content.

Ironically this makes me lose interest in reading any "blog" posts that weren't written by a human or at least have a human-sounding voice.

There's a lot of 'business logic / business decisions' that an AI would need to understand in order to achieve the goal of the process. I'm currently going through a deconstruction of a complex topic for which there is minimal documentation about how it should work, and so AI-help is limited to explaining what it does do.

If the information doesn't exist, then AI can't create it for you, but it can help identify the areas in which to be asking the questions; where exist the vagaries and assumptions?

Posts like these aren't wrong but they miss the forest for the trees.

A lot of software engineers don't write code at their place of employment because they enjoy spinning up pods to serve their Django apps - it gets them paid so they can then do what they actually enjoy.

What AI will allow these software engineers to do, is bypass their employers and serve customer niches directly, capturing more of the revenue themselves.

This isn't for everyone, specially those software engineers who do write code at their place of employment because of the pleasure of it, but its an unlock for those who couldn't just make the leap before.

And that's precisely where AI provides tremendous leverage and why the economy will expand rather than contract.

Find a section of customers your employer isn't particularly excited about serving, find out if they will be your ideal customers and serve them directly.

Yes but you can take the help of AI to even architect it.

"Programming as Theory Building" still relevant on the AI age.

https://news.ycombinator.com/item?id=10833278

> the reasons behind architectural choices

Should go into a historical document, not a durable record of decisions for an AI to follow unless those reasons are themselves decisions for it to act on.

Engineering the system means stepping outside of the system.

Not standing on the factory floor reviewing PR widgets.

...for now.

All of these types of articles for me seem more like hopium than sustainable mindsets.

Given the massive gains of capability in software for AI over the past couple of years it's only a matter of time until this too will be needed less and less.

It may be time to look beyond these small hills to the mountains of possibility before us.

agreed. views are very similar to my talk https://youtu.be/X7vf7koPxKg

Summaries keep the rule and drop the "because". That's where it breaks.

I honestly kind of disagree. Maybe a more accurate take these days is we still have to engineer the assembly line harness that engineers the system. "KISS" is turning out to be a surprisingly good nudge token to throw at Claude Code.

Maybe for 6 months.

...For now.

Frontier models are generating sensible abstract engineering decisions for nontrivial code bases. Phase 1 (GPT 4 era) was "fancy autocomplete": it could generate a function or complete a clause before losing the plot. Phase 2 (Opus 4.x era) was the spec-driven development era, involving careful construction of guardrails and guidelines and steering the agents as they worked. Phase 3 is the beginning of the "software factory" era. You can now one-shot nontrivial apps with a prompt that leaves most of the specifics up to the agents. You just can't do this for like, a whole enterprise—maybe a microservice.

Another phase or two, and you can pretty much say goodbye to 95% of SWE jobs. The only people left involved in the software development process will be business analysts, product managers, and perhaps designers if they don't want the UI to look all "AI ass-ugly". A handful of trillion-dollar companies will retain a few really smart people who could code by hand if they wanted to, to keep the models trained and topped up on good practices. But line-of-business, which was the bread and butter for software engineers for going on 70 years now, will be done by machine. Humans will specify, and humans will QA the results, and that's it.

[flagged]

[dead]

[flagged]

[dead]

[dead]