> Someone asks you to add a feature to an existing program
While I empathize with the tone, even before AI the creativity was largely at the feature definition step, not in the implementation.
Outside of the very few computer scientists working on novel algorithms, the vast majority of software development is a mapping problem between the feature request and the mundane technical details, something repeatedly (and correctly) mentioned here in the context of FAANG algorithm fixated interviews. This has now largely been automated by LLMs
What is left is just creativity part - defining the use cases and features to develop in the first place. But the corollary is that software engineers that start after the requirements have already been defined are obsolete, which is a sobering thought for any of us in that vocation.
> Outside of the very few computer scientists working on novel algorithms,
It's a quite a bit broader than that: for instance most of science and engineering is heavily supported by simulations (very useful when the system you're considering doesn't have perfect spherical or cylindrical symmetry), and there is still tons of algorithm development going on. The world is vast, and thus so is the domain of programming.
And halfway through 2026, AI has become a very interesting and helpful partner in algo research too. If it does continue to pull away and zip off to ASI land, hopefully we can leverage the resulting magical technology and catch back up with it...
This is not true. First of all, not all software is written in the context of a FAANG company with “feature requests”. Secondly, writing software is similar to the process of design, this comment reads like “the vast majority of handbag design is mapping problem between features and leather”, ignoring that both the design and implementation can be rewarding to work on. Eg. I’m working on a program for myself and the overall architecture of the program as well as some parts of its implementation are clever and compose well to make the codebase a joy to work in. I am not simply “mapping features to mundane technical details”. It is as much art as the skillfully hand-crafted handbag.
I always think that stuff is funny because it clearly comes from a place of having only worked at faang-level-esque companies. I’ve only ever worked at messy mid-size software companies and have never once had a legit product manager guiding feature work, it’s generally been up to the developers to figure out what needs doing
"1. Someone asks you to add a feature to an existing program."
That someone should do it themselves in a fork then, if you design software like this you run into problems with AI and human coders the same.
Your goal is to think of the form first(!), functionality emerged from that - or cache requests for functionality over at least 3 to 6 months, then refactor from the data structures up.
I know this is not the way businesses write software but if you want to stay relevant you should take a closer look as to what system or software design means to you. Spaghetti belongs to the Italians!
Functionality can be emergent from form - then you get a forced full-stop while trying to bend or hack your structure until you solve the problem system-wide and while solving this you usually get some functionality derived for free - often stuff your company can use now or will need later but does not know about yet.
it just a higher level of abstraction but not high enough that it replaces developers, I don't think the LLMs are even capable of reaching that level. Saying the creative process is gone is laughable. A lot of people make these claims and only have an internal tool that no one uses to show for it.
I built a "simple" storage application recently, uploading large files from a phone is not trivial, you can't just command Claude to do it without giving it good context.
Reading posts on HN, I notice that even across different programming domains, surprisingly similar problems emerge. Seeing this, I can't help but think that programming might ultimately be a matter of organizational theory. Conway's Law speaks to this as well. Code structure and approach shift significantly depending on how an organization is structured. From that perspective, it makes sense why Gen AI coding yields such starkly divided opinions.
Zooming out, the debate largely boils down to the downsides of severed junior pipelines and lost tacit knowledge on one hand, versus the upside of being able to build everything you envisioned on the other.
Honestly, I suspect that programming in the future will become something like the art of bonsai, a form of sculptural cultivation. Just as you dig furrows for water to flow through, and once the water emerges it follows those furrows, Gen AI will pour out an immense volume of code, and we will shape that code into form. It is like when you build with IoC based frameworks. If you do not adopt hexagonal architecture, the code inevitably converges toward the patterns the community recommends anyway. Ultimately, it is less about individual code fragments and more about hoping those fragments do not go wrong, contained by guardrails that ensure they do not exceed certain thresholds. If that is the case, programmers might end up focusing on questions like, "How much loss is acceptable?"
Many programmers say, "You need to know the entire codebase." But as someone who has delivered over 30 projects with codebases of 60,000 lines or more, I know that once my own code alone surpasses 40,000 lines, it becomes nearly impossible to hold it all in memory. So I document it in broad categories. And the next day, I have to retrace where I left off and refresh my memory, which takes a long time. This is one area where Gen AI genuinely excels.
Personally, what I have noticed when looking at other people's code is that those who work at a low level often struggle with high level integration, and vice versa. When cognitive resources become concentrated, specialization deepens in one area while others are neglected. And how one manages those cognitive resources ultimately diverges depending on the domain and the specific problem at hand. Just as the mindset required for architectural design differs from the mindset required for diving deep into implementation.
My workflow, broadly speaking, has not changed. My main job has always been to grasp a legacy codebase, open up the black box, connect debug logs one by one, find safe footholds, and add features. The only difference now is that the black box called "legacy codebase" has simply become "Gen AI code." It is not like I could ever claim my own code was bug free to begin with. Ultimately, what mattered was which bugs to contain and how far to wrap them. Open source programmers, however, are different. Their code blocks serve as their cognitive solutions and their reputation, so their approach differs from delivery oriented code. That is because code quality itself contributes to their prestige. For me, it is the brands and the number of companies I have delivered to that build my reputation. That distinction seems to divide programmers at a fundamental level.
In that sense, I think future programming work will split into roughly three categories. The first is the exceptionally talented group that creates the datasets Gen AI will consume. In other words, the renowned open source groups we already admire. In AI labeling terms, they will be the ones producing the gold standard answer sheets. I believe they will survive and remain admired, just as they are now, though their numbers will shrink even further.
The second group will be those who make Gen AI code flow through industries and organizations. When Gen AI pours out code like water, they will be the ones managing the channels to prevent it from flooding. Most people will migrate into this role.
The third group is QA, and I think they will survive. They will execute Gen AI code and relay to the channel managers when the watercourses are going wrong.
In truth, things are already moving in this direction. It is like how no one thinks about how OOP inheritance maps to vtables anymore. People just treat objects as abstract concepts and move on.
Personally, I think the overall flow in Gen AI coding will shift toward implementing system state in the form of state transition diagrams, a return to the primitive form of Parnas's theory of information hiding. Parnas's theory states that "modules should hide design decisions that are likely to change." Humans interpreted this as something like private variables in OOP, but then leaked internal implementations to the outside anyway. When business policies end up scattered across controllers and services, information hiding has effectively failed. The decisions most likely to change are not hidden in one place. They are dispersed throughout the system. But in the Gen AI era, ironically, information hiding might actually become easier to achieve. You just define the state transition from "payment pending" to "payment completed," and that is it. Ultimately, we might end up circling back to earlier approaches, do you not think?
Anyway, I am not asking for someone else's answer. I need to find my own way. Because my way and someone else's way are different, just as my programming and someone else's programming are different.
Programming is ultimately the work of constructing a mental model, and that mental model is inherently personal.
I’ve been successfully shipping software since 1998. I just got the first payment on a greenish-field software product I’m doing on the side solo (that I couldn’t have done solo in 2019 without the tools). This is my workflow:
1. Client asks you to add a feature(s)
2. Spend two weeks unpaid walking the client through scoping down to the most minimal viable set of features that tests the business hypothesis and roadmap
2. I wrote up a reasonably exhaustive bullet list and sent it to a CGPT to write a draft formal definition of features describing what it should (and should not) do, how users can access it and what the suite of tests that we will need through TDD
3. Chat for 30 minutes with CGPT researching which data structures, algorithms, code libraries and external services might serve best to implement this feature.
4. Generate mockups and data schema alongside CGPT, to build the new feature, the tests to make sure it works as expected, and the documentation telling users how to use it and telling other engineers what they’ll need to know to maintain and debug it.
5. Generate minimum code to test the full data workflow.
6. Send repo and or working application binary to Claude and Gemini to critique
7. Adjust as needed. Deploy for client review and acceptance in sandbox. Promote to production
8. GOTO3 and loop
I can do in a week what would have taken a month a decade ago
Whenever I let these tools look at existing repos they are too influenced by what's already there.
I could even say "feel free to completely refactor or rewrite anything" and they'll still just do small performative changes.
I've now changed my workflow to only using AI for prototyping and rewriting by hand once I can see something is viable. Takes longer but the results are always much better.
> Someone asks you to add a feature to an existing program
While I empathize with the tone, even before AI the creativity was largely at the feature definition step, not in the implementation.
Outside of the very few computer scientists working on novel algorithms, the vast majority of software development is a mapping problem between the feature request and the mundane technical details, something repeatedly (and correctly) mentioned here in the context of FAANG algorithm fixated interviews. This has now largely been automated by LLMs
What is left is just creativity part - defining the use cases and features to develop in the first place. But the corollary is that software engineers that start after the requirements have already been defined are obsolete, which is a sobering thought for any of us in that vocation.
> Outside of the very few computer scientists working on novel algorithms,
It's a quite a bit broader than that: for instance most of science and engineering is heavily supported by simulations (very useful when the system you're considering doesn't have perfect spherical or cylindrical symmetry), and there is still tons of algorithm development going on. The world is vast, and thus so is the domain of programming.
And halfway through 2026, AI has become a very interesting and helpful partner in algo research too. If it does continue to pull away and zip off to ASI land, hopefully we can leverage the resulting magical technology and catch back up with it...
Seems to me that feature requests are not all that unique either.
Seems to me you can get feature requests from user feedback.
I also expect someone will figure out a way to have AI "use" your software and suggest features
This is not true. First of all, not all software is written in the context of a FAANG company with “feature requests”. Secondly, writing software is similar to the process of design, this comment reads like “the vast majority of handbag design is mapping problem between features and leather”, ignoring that both the design and implementation can be rewarding to work on. Eg. I’m working on a program for myself and the overall architecture of the program as well as some parts of its implementation are clever and compose well to make the codebase a joy to work in. I am not simply “mapping features to mundane technical details”. It is as much art as the skillfully hand-crafted handbag.
I always think that stuff is funny because it clearly comes from a place of having only worked at faang-level-esque companies. I’ve only ever worked at messy mid-size software companies and have never once had a legit product manager guiding feature work, it’s generally been up to the developers to figure out what needs doing
This is not an Age of AI. Why do so many not-real-programmers think this is an age of AI? It's just a hype.
I am developing my own app 2+ years manually, and not use "AI" at all.
Using AI usually can cause many problems, which the author pointed at.
Programming should be enjoyable, not an annoyed or unhappy thing.
Yeah it’s gonna be funny looking back in ~5 years. And probably embarrassing for some.
“Age of AI” but most people actively dislike it and hasn’t had a clearly positive impact on the economy after ~4 years.
"1. Someone asks you to add a feature to an existing program."
That someone should do it themselves in a fork then, if you design software like this you run into problems with AI and human coders the same.
Your goal is to think of the form first(!), functionality emerged from that - or cache requests for functionality over at least 3 to 6 months, then refactor from the data structures up.
I know this is not the way businesses write software but if you want to stay relevant you should take a closer look as to what system or software design means to you. Spaghetti belongs to the Italians!
Functionality can be emergent from form - then you get a forced full-stop while trying to bend or hack your structure until you solve the problem system-wide and while solving this you usually get some functionality derived for free - often stuff your company can use now or will need later but does not know about yet.
How does Andrew manage being a full-time software developer and an author? Both jobs are so cognitively demanding.
it just a higher level of abstraction but not high enough that it replaces developers, I don't think the LLMs are even capable of reaching that level. Saying the creative process is gone is laughable. A lot of people make these claims and only have an internal tool that no one uses to show for it.
I built a "simple" storage application recently, uploading large files from a phone is not trivial, you can't just command Claude to do it without giving it good context.
Reading posts on HN, I notice that even across different programming domains, surprisingly similar problems emerge. Seeing this, I can't help but think that programming might ultimately be a matter of organizational theory. Conway's Law speaks to this as well. Code structure and approach shift significantly depending on how an organization is structured. From that perspective, it makes sense why Gen AI coding yields such starkly divided opinions.
Zooming out, the debate largely boils down to the downsides of severed junior pipelines and lost tacit knowledge on one hand, versus the upside of being able to build everything you envisioned on the other.
Honestly, I suspect that programming in the future will become something like the art of bonsai, a form of sculptural cultivation. Just as you dig furrows for water to flow through, and once the water emerges it follows those furrows, Gen AI will pour out an immense volume of code, and we will shape that code into form. It is like when you build with IoC based frameworks. If you do not adopt hexagonal architecture, the code inevitably converges toward the patterns the community recommends anyway. Ultimately, it is less about individual code fragments and more about hoping those fragments do not go wrong, contained by guardrails that ensure they do not exceed certain thresholds. If that is the case, programmers might end up focusing on questions like, "How much loss is acceptable?"
Many programmers say, "You need to know the entire codebase." But as someone who has delivered over 30 projects with codebases of 60,000 lines or more, I know that once my own code alone surpasses 40,000 lines, it becomes nearly impossible to hold it all in memory. So I document it in broad categories. And the next day, I have to retrace where I left off and refresh my memory, which takes a long time. This is one area where Gen AI genuinely excels.
Personally, what I have noticed when looking at other people's code is that those who work at a low level often struggle with high level integration, and vice versa. When cognitive resources become concentrated, specialization deepens in one area while others are neglected. And how one manages those cognitive resources ultimately diverges depending on the domain and the specific problem at hand. Just as the mindset required for architectural design differs from the mindset required for diving deep into implementation.
My workflow, broadly speaking, has not changed. My main job has always been to grasp a legacy codebase, open up the black box, connect debug logs one by one, find safe footholds, and add features. The only difference now is that the black box called "legacy codebase" has simply become "Gen AI code." It is not like I could ever claim my own code was bug free to begin with. Ultimately, what mattered was which bugs to contain and how far to wrap them. Open source programmers, however, are different. Their code blocks serve as their cognitive solutions and their reputation, so their approach differs from delivery oriented code. That is because code quality itself contributes to their prestige. For me, it is the brands and the number of companies I have delivered to that build my reputation. That distinction seems to divide programmers at a fundamental level.
In that sense, I think future programming work will split into roughly three categories. The first is the exceptionally talented group that creates the datasets Gen AI will consume. In other words, the renowned open source groups we already admire. In AI labeling terms, they will be the ones producing the gold standard answer sheets. I believe they will survive and remain admired, just as they are now, though their numbers will shrink even further.
The second group will be those who make Gen AI code flow through industries and organizations. When Gen AI pours out code like water, they will be the ones managing the channels to prevent it from flooding. Most people will migrate into this role.
The third group is QA, and I think they will survive. They will execute Gen AI code and relay to the channel managers when the watercourses are going wrong.
In truth, things are already moving in this direction. It is like how no one thinks about how OOP inheritance maps to vtables anymore. People just treat objects as abstract concepts and move on.
Personally, I think the overall flow in Gen AI coding will shift toward implementing system state in the form of state transition diagrams, a return to the primitive form of Parnas's theory of information hiding. Parnas's theory states that "modules should hide design decisions that are likely to change." Humans interpreted this as something like private variables in OOP, but then leaked internal implementations to the outside anyway. When business policies end up scattered across controllers and services, information hiding has effectively failed. The decisions most likely to change are not hidden in one place. They are dispersed throughout the system. But in the Gen AI era, ironically, information hiding might actually become easier to achieve. You just define the state transition from "payment pending" to "payment completed," and that is it. Ultimately, we might end up circling back to earlier approaches, do you not think?
Anyway, I am not asking for someone else's answer. I need to find my own way. Because my way and someone else's way are different, just as my programming and someone else's programming are different.
Programming is ultimately the work of constructing a mental model, and that mental model is inherently personal.
I just hope I can survive into the next era.
I’ve been successfully shipping software since 1998. I just got the first payment on a greenish-field software product I’m doing on the side solo (that I couldn’t have done solo in 2019 without the tools). This is my workflow:
1. Client asks you to add a feature(s)
2. Spend two weeks unpaid walking the client through scoping down to the most minimal viable set of features that tests the business hypothesis and roadmap
2. I wrote up a reasonably exhaustive bullet list and sent it to a CGPT to write a draft formal definition of features describing what it should (and should not) do, how users can access it and what the suite of tests that we will need through TDD
3. Chat for 30 minutes with CGPT researching which data structures, algorithms, code libraries and external services might serve best to implement this feature.
4. Generate mockups and data schema alongside CGPT, to build the new feature, the tests to make sure it works as expected, and the documentation telling users how to use it and telling other engineers what they’ll need to know to maintain and debug it.
5. Generate minimum code to test the full data workflow.
6. Send repo and or working application binary to Claude and Gemini to critique
7. Adjust as needed. Deploy for client review and acceptance in sandbox. Promote to production
8. GOTO3 and loop
I can do in a week what would have taken a month a decade ago
Part 6 to me seems always totally useless.
Whenever I let these tools look at existing repos they are too influenced by what's already there.
I could even say "feel free to completely refactor or rewrite anything" and they'll still just do small performative changes.
I've now changed my workflow to only using AI for prototyping and rewriting by hand once I can see something is viable. Takes longer but the results are always much better.
You’re the founder and CEO of an AI startup but also vibecoding side gig work?
GOTO3 and loop? Don't you mean GOTO2 and loop ;)
At the moment the list goes 1, 2, 2, 3…