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.
But infrastructure is actually made out of concrete, which can be poured almost like water into any mold you can fashion to hold it, and it then hardens into something stone-like.
It’s written in the first person and does not have many of the AI tells that I’ve grown used to, but a couple paragraphs in, I am inclined to agree that this is largely AI generated. It’s like the written version of a monotone voice: it carries on methodically for way too long without any real build up or character.
And now I wonder if I’m just harping on some poor human who needs to spice up their writing a bit. Was there any one thing that gave it away to you?
Yeah this is clearly total slop output. could come straight out of "claude write post about how ai can write more code but we have to do system engineering"
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.
> What AI will allow these software engineers to do, is bypass their employers and serve customer niches directly, capturing more of the revenue themselves.
It's going to enable me to do less software development and more marketing? Goodie, I'm so happy I could puke.
> It's going to enable me to do less software development and more marketing? Goodie, I'm so happy I could puke.
If you hate marketing, don't do it. If you enjoy software development, have fun doing it.
However, you will remain an employee and you have to appreciate the pros and cons of being an employee.
As I said in the parent it's not for everyone but a lot more people who were struggling to start their own venture will now be more capable of and have more freedom.
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?
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.
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.
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.
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.
But infrastructure is actually made out of concrete, which can be poured almost like water into any mold you can fashion to hold it, and it then hardens into something stone-like.
That's interesting. What is the software equivalent of pouring something into a mold?
Test Driven Development I guess?
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.
It’s written in the first person and does not have many of the AI tells that I’ve grown used to, but a couple paragraphs in, I am inclined to agree that this is largely AI generated. It’s like the written version of a monotone voice: it carries on methodically for way too long without any real build up or character.
And now I wonder if I’m just harping on some poor human who needs to spice up their writing a bit. Was there any one thing that gave it away to you?
Yeah this is clearly total slop output. could come straight out of "claude write post about how ai can write more code but we have to do system engineering"
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.
> What AI will allow these software engineers to do, is bypass their employers and serve customer niches directly, capturing more of the revenue themselves.
It's going to enable me to do less software development and more marketing? Goodie, I'm so happy I could puke.
> It's going to enable me to do less software development and more marketing? Goodie, I'm so happy I could puke.
If you hate marketing, don't do it. If you enjoy software development, have fun doing it.
However, you will remain an employee and you have to appreciate the pros and cons of being an employee.
As I said in the parent it's not for everyone but a lot more people who were struggling to start their own venture will now be more capable of and have more freedom.
Engineering the system means stepping outside of the system.
Not standing on the factory floor reviewing PR widgets.
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?
> 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.
"Programming as Theory Building" still relevant on the AI age.
https://news.ycombinator.com/item?id=10833278
Maybe for 6 months.
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.
agreed. views are very similar to my talk https://youtu.be/X7vf7koPxKg
...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.