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.
I generally agree but it starts to get interesting again once you have the first solid bricks in place. The LLM is incredibly good at seeing where you are going. You can place one brick and the next few become obvious.
I've been working on a project for the last 18 months, and over that time LLMs have advanced to the point where they've become useful. I can write a section of UI and ask the LLM to write all the front end and backend services. There are enough examples that it writes exactly the code I would have written myself. It can build entire sections of code quickly and efficiently because there aren't very many questions without an answer somewhere in the codebase, which it is very good at finding. If it finds any gaps, it can raise it as a question. It analyzes, asks questions, and then completes the work.
The impression that I'm starting to form is that you do not want to use AI very much early in a project, except to ask questions and check your code. But it's usefulness at assisting with code scales with the size of the project.
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.
But working with concrete is nothing like working with clay. It's not iterative at all. The mold has to be planned out and set up precisely ahead of time or else everything will be a mess and you are not going to be able to correct it. Working with concrete is really working with timber (or whatever material you are making the mold of)
Oh, good one, yes, the tests are the shape and then you fill that in automatically. I never thought of it that way, this is a very interesting insight. I wonder whether the effort you have to put into the mold versus the effort that goes in the object has been quantified.
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"
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.
> 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. The other thing you have to appreciate is that the number of employees writing code who are AI, are cheaper than any human on the planet and works 24x7 without complaining or asking for a raise is going to go up. Likely exponentially.
This doesn't mean demand for good software developers is going to go down, but increasingly, software development is likely going to look like how one human Amazon warehouse worker wears special harnesses that allow them to lift far more weight, walk longer distances and interact with dozens of robots in the warehouse.
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.
It might very well turn out that in a few years, the only way to enjoy software development the way you like it, is to establish your own boutique software development company.
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.
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.
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.
I generally agree but it starts to get interesting again once you have the first solid bricks in place. The LLM is incredibly good at seeing where you are going. You can place one brick and the next few become obvious.
I've been working on a project for the last 18 months, and over that time LLMs have advanced to the point where they've become useful. I can write a section of UI and ask the LLM to write all the front end and backend services. There are enough examples that it writes exactly the code I would have written myself. It can build entire sections of code quickly and efficiently because there aren't very many questions without an answer somewhere in the codebase, which it is very good at finding. If it finds any gaps, it can raise it as a question. It analyzes, asks questions, and then completes the work.
The impression that I'm starting to form is that you do not want to use AI very much early in a project, except to ask questions and check your code. But it's usefulness at assisting with code scales with the size of the project.
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.
But working with concrete is nothing like working with clay. It's not iterative at all. The mold has to be planned out and set up precisely ahead of time or else everything will be a mess and you are not going to be able to correct it. Working with concrete is really working with timber (or whatever material you are making the mold of)
That's interesting. What is the software equivalent of pouring something into a mold?
Test Driven Development I guess?
Oh, good one, yes, the tests are the shape and then you fill that in automatically. I never thought of it that way, this is a very interesting insight. I wonder whether the effort you have to put into the mold versus the effort that goes in the object has been quantified.
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?
"It's full of, of, of things that are only correct because they're grammatical, but they're tough on the ear, you see..." —Orson Welles
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"
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.
> 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. The other thing you have to appreciate is that the number of employees writing code who are AI, are cheaper than any human on the planet and works 24x7 without complaining or asking for a raise is going to go up. Likely exponentially.
This doesn't mean demand for good software developers is going to go down, but increasingly, software development is likely going to look like how one human Amazon warehouse worker wears special harnesses that allow them to lift far more weight, walk longer distances and interact with dozens of robots in the warehouse.
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.
It might very well turn out that in a few years, the only way to enjoy software development the way you like it, is to establish your own boutique software development company.
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]
[dead]
[flagged]
[dead]