> I don’t use AI when I write, for the very reason that writing itself is the act of organizing and clarifying my own thought. Letting the bot write for me would be like paying someone else to exercise for me and hoping that gets me in shape.
I don't know why the author chooses to distinguish writing prose and writing code here. [Software is made of decisions](https://siderea.dreamwidth.org/1219758.html) and at least I usually like to flesh out those decisions through the act of writing code, which forces a level of precision that makes it hard (though not impossible) to handwave away important decisions.
"you haven’t done any of the hard thinking you would normally do in writing the code yourself"
It's true, I spend less time solving problems that arise naturally from the process of implementation. But implementation errors have a poor signal-to-noise ratio. For every error that exposes a real design problem there are 10 others that involve routine fixes: type errors, scope issues, import resolution, dependencies. There's a common argument I see being thrown around, which is "how will junior engineers develop into senior engineers if they don't get reps in with implementation?" But to me it feels like "programmer" and "architect" are becoming more and more orthogonal as the models improve in capability. If my goal is to be an architect, getting more reps in as an architect is in my best interest, and letting the agents do the dirty work frees up space for me to spend the mental effort where it counts. And anecdotally, the scope of projects I've started taking on has scaled roughly linearly relative to how much work I'm able to delegate, while the mental engagement has stayed constant.
| type errors, scope issues, import resolution, dependencies.
I write code myself and use the LLM to find mistakes then fix them manually. I recommend inverting the conventional wisdom on LLMs:
1. Don't use it to write code. It's a terrible
programmer. But it's an intelligent rubber duck
and a solid analysis tool.
2. Write the code yourself. It'll go faster than
figuring it out as you go along. It's just typing
if you have a plan.
3. Use an LLM to sanity check what you wrote.
It can find potential design issues or future
problems or breaks from convention. Decide based on
your experience how much you want to address these
issues before moving on.
Is this as fast as AI writing the code? Not at first but possibly over time. Maybe faster. Certainly better quality.
Plus you don't lose any of your skills in the process.
You're still doing the gruntwork necessary to keep your skillset.
And the token cost is a small fraction of what it takes to get LLMs to write good code.
> Don't use it to write code. It's a terrible programmer.
I see this sentiment often, and I’m honestly not sure where this comes from, as it’s really not been my experience. I feel like this must come from people feeling threatened and just moving the goals posts, or not knowing how to use the tools effectively.
One of the things I've started doing is to write the high level scaffold myself, create stubs (with comments) and have it fill out the details. I haven't done this for long, but I feel like my mental model of the code rots less, and I can review code faster.
I used to do this in the past, when these models were not all that capable, now there is a huge temptation to leave everything to the model. But long term I lose track of whats going on, and have a hard time even communicating with the model about the changes I want. Just a total decay of my mental model of the system, and it's really hard to recover from that state.
This is half question, half thought experiment: What exactly is it that makes us think „great, I can delegate coding to the agent, and focus on architecture myself“, instead of „great, I can delegate coding to the agent, and I can delegate architecture to the agent, and I can focus on <third thing> myself“?
And how many levels up can you construct this sentence before things go south?
What I‘m implying with this question is, of course: What makes us so confident that these things are not also better architects than us?
After all there is a huge corpus on how to architect applications correctly, and that’s in the training data just as much as Python best practices and C++ style recommendations.
You can delegate architecture to agents, as long as you know different architectures and decide which one is the most fit for a given scenario. AI can choose one but it will usually pick the one that is more present in the training corpus.
React + NextJS is a terrible architectural decision for most projects that LLMs recommend all the time.
Business has tried and mostly failed to do this since the beginning of programming. Architects that stop coding long enough tend to become shitty architects as their abstractions increasingly become disconnected from the concrete requirements of the actual problem space rather than the idealized version in their head.
ironically llm prove the its not possible to just think "abstract thoughts" . we cannot remove concrete "implmenation" facts like paris is capital of france and retain just abstract "countries have capitals"
> 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...
> 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),
That isn't the vast majority of traditional software engineering work, and arguably is better called applied physics or applied science. Super interesting though - and definitely uses programming as a core skill/tool - but it leans heavily into traditional engineering and science.
Such a creative era was until early 1990s. Back then, we have to implement almost everything that is provided by standard library and popular frameworks we take it for granted for now.
Also typically new features resemble ones I implemented in the past and I won’t learn that much from implementing them. Often times I immediately know what to do and although I do enjoy typing I do prefer just having it done in way less time.
In the meantime I can concentrate on more interesting problems.
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’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”.
You said it: you are working on a "program for yourself". Hobbyist craft programming will always be here. The question is what kind of software engineering will be paid for, and a career can be built on.
I don't see much of a market for pure software engineers anymore. You also need to be a product manager, scientist, or have some other domain knowledge adjacent to software that relates to the real world.
I say this with empathy for those who just enjoyed the craft of designing and building software, and thought that alone would provide them a livelihood and career in perpetuity, but have found a big chunk of what they loved doing (and getting paid for) overtaken by AI coding agents.
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
> 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
That's because the systems and problem spaces at FAANG companies are so large that you need(ed) a lot more division of labor to make anything work. The division of the technical side of the house between those focused on product management and those focused on building software allowed both to be done more effectively, but both roles have had a lot of their work overtaken by LLMs.
Also, From what I've heard, FAANG companies are going through big (and painful) transitions to align their staffing with the reality of what current AI tools are capable of.
Writing and coding are not the same thing; coding is a means to an end, since you don’t use the code, you use the software. This means the mechanism by which the code was created is orthogonal to the software as you’d experience it as a user.
There are many reasons to curate what goes into the software - for example, if it must be maintainable, if it must conform to standards that cannot be fully codified into the software (eg. regulatory requirements), or if you just really darn well like writing code!
But it takes a mountain of code to make an outwardly simple thing so why not use a work-amplifying tool to produce that code and get to working software more cheaply.
On the other hand writing is the act of creating the exact product that will be consumed. Every detail matters and there’s no leverage to trying to write faster.
So it’s a false equivalence. Hopefully I’ve elucidated the subtlety.
> But it takes a mountain of code to make an outwardly simple thing so why not use a work-amplifying tool to produce that code and get to working software more cheaply
The same reason we didn't just wholesale copy and paste from open source repos in the past?
> AI does not know whether the code it just added violates some legal requirement to which your product is subject.
The rest of the paragraph is a list of similar complaints.
All of these can be codified - the new work is the (fascinating!) challenge of working out how and codifying them, then giving the codified checker logic to the agent to run at will - thus taking yourself out of all of those loops.
They don’t even need to be deterministic checks - a shell script that wraps a `claude -p` - and maybe fetches some online resources to stuff into the context - can do your agent’s legal check for it.
As a result, you’re only being effective if you can engineer (not hack, not vibe) an agent that can produce work your company can use with as little cleanup as possible - and with less cleanup over time.
You get job by codifying what you know - what most don’t account for is that there’ll never be a limit to what there is to know, and codifying expertise will be challenging for a long time to come.
> They don’t even need to be deterministic checks - a shell script that wraps a `claude -p` - and maybe fetches some online resources to stuff into the context - can do your agent’s legal check for it.
No. It can't. If you think that injecting legal text into the context window and appending "make sure the output complies with this law" will solve your problems you have not understood how an LLM works. The kind of checks you are talking about cannot be codified.
I wonder if we're being overly selfish here and ignore the positive effects of democratizing programming and making software more accessible to less well funded causes and organizations. A good software engineer used to cost 100k/year, very few businesses could afford that.
I also disagree that AI results are lower quality. Codex Pro results I get are marvelous but they sometimes miss things that humans understand naturally - all of the edges - coherence of visuals, passage of time, etc.
What AI does is the exact polar opposite of "democratizing". We're going from a world where high-quality learning content is plastered all over the internet for free, where open-source projects are desperate for contributors and full of "good first issue" tickets, and where the tools you need to code can be run on any crappy laptop from the past 15 years—to a world where the majority of content about programming is unverified AI slop, where open-source projects are locking down access to protect against an avalanche of drive-by AI garbage, and where you need a $200/month subscription or a $3,000 GPU to run AI models for coding.
One thing I just discovered is that I’m no longer interested in choosing a novel tech stack. What used to engage me now just feels shallow to me so I stick with what I already know.
Not sure if that’s fine though since I get to the point of a project being interesting a lot faster instead of wiring tools together.
It is extremely mentally demanding to do both, even for someone with an overactive brain. I reached a point of severe burnout in 2025 and cut back to part-time work. I'll have to ramp up my hours again soon because, contrary to one of the other comments, I didn't get rich during 1990s/2000s boom.
As for how I did it, I would wake up very early and put in a few hours of writing, then I would put in a full day's work at the office. After my first twelve years or so in the industry, coding was almost second nature and came quite easily. Also, I do much of my writing and programming in my head while I'm walking, running or biking. (I bike to work and back every day.) By the time I sit down to write or code, I already know what I'm going to write, so it's just a matter of getting it through the keyboard.
But yeah, do both for a few years and it really taxes your brain. In both novel writing and programming, you're carrying an entire world in your brain: the plot and characters are one world, the architecture of the software you're working on is another. By 2025, I truly, literally felt like I needed to be shipped off to a madhouse in the countryside. A hundred years ago, people used to call that "the rest cure for a nervous breakdown."
Anyway, cutting back to part-time work has been a huge help. Sanity restored.
Thanks for this. I've been trying to learn this writing thing on top of my full-time job and it's been a struggle. It's helpful to hear how you managed it.
One of the things that's neat about the software field in this day and age is that you can see when someone started out 20+ years ago, when things were pretty easy (relatively) and the boom was still on the horizon.
It's pretty common that someone who was born around the right time to the right people in the right location to become a millionaire by writing some php may do something else, but still consider themselves an engineer.
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.
We already have such position and it's called manager.
The manager's job is to manage multiple programmers to let them write code. A good manager should focus on management rather than write code himself.
But keep doing for many years will make manager out of touch from modern coding so he is starting to mismanage people or issue technically wrong order.
Machine hater and manual labour worshiper..he thinks he got stupid because he stopped doing if/else and for-loops. Life is full of complexity and it might be helpful to get one level-up in abstraction to try to solve real problems and other people actually care about.
For me the biggest issue with AI coding model is not that it writes code, or how it writes code, or whether it will replace me or not. I mean, these are real problems, but just not the ones that makes the difference to me daily. Instead what sets my feeling about the AI is simple: the experience of working with AI models, because it's the worse experience of my life so far.
Every single LLM will make up stuff, go down rabbit holes I didn't even ask it to visit and infuriate me all day long by doing ALMOST what I asked it to do, but just not quite. Take "yes" to one question as an approval to some other question. Come up with a plan but one you review the plan and accept it it hits some minor issue and then throws away the plan and do whatever it wants. Or when I reject some line of code or don't approve a command it wants to run 9/10 times it just tries to re-add or re-run it as if my rejection was meaningless. And no amount of rules and markdown files ever seems to change its behaviour for long, if at all.
It's like working with a sociopath who just doesn't remember anything that happened 5 minutes ago.
It's the classic case of "my computer doesn't do what I want, only what I tell it".
And all of that would be fine if it didn't pretend to be a human, if all the UX didn't create the illusion that you interact with some intelligent being, because as long as I remember that this is a cli tool it's all good, I manage my expectations, but the experience sooner or later makes you annoyed and frustrated - and if this was a person they would either stop or you wouldn't never work with them again.
> doing ALMOST what I asked it to do, but just not quite
This is my exact experience. LLMs get 95% of the way to my personal quality bar, and for simple tasks 100% of the way.
More complex things, no. This means that, in practice, I end up having to understand the code pretty much as much deeply as I would anyway, without agents.
So, essentially, my experience is that it's automated away the easy bits, but left the hard bits, so all of my time is spent doing the hard bits, which is mentally exhausting.
Maybe Fable would be good enough to get to 100% of my quality bar on more complex tasks, but I never got chance to try it.
> So, essentially, my experience is that it's automated away the easy bits
Yes, which is great for “easy” but mundane and time consuming tasks like refactoring structs when you have a ton of tests that look at snapshots of nested structs etc.
Squeezing that last few bits of “make comments consistent with the style and tone of existing comments”, or “stop adding docs that make it sound like an academic paper” or just keep the overall feel of the code same across all files take a lot of effort and energy.
I agree with this. I recently went back to writing more code by hand again for this reason: the amount of effort / mental toll it takes me to steer the LLM is sometime just not worth it. I might be slower but I enjoy my work much more again.
The only reflection that matters, now, is that every company that sells software for money is now a confidence game. How long can you con your users into believing they have any reason not to type the 5-word prompt “recreate <product> make no mistakes” and cut you, the middle man, out?
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.
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.
For websites this work. But now you are a core developer of the GTA6 engine. Your task is to create a fast efficiënt occlusion mapper. One that works from all angles. Has cavities and rt support. Good luck doing this with Claude. It's not gonna achieve this. Because only a handful of games achieved this partly. Maybe next gen AI can do it. But for complex tasks LLMs are still not good enough.
Current AI cannot be comparable with "machinery and assembly lines".
Current AI companies stole much data from Internet without permissions, and used the knowledge of many people directly shamelessly.
It cannot resolve many practical problems well, even in programming area.
Do you want the software-assistant to do the important or enjoyable things instead of you? Do you want your assistant in real life to eat the delicious food instead of you?
How do you want to define "clearly positive impact on the economy"? NVDA and a bunch of other stocks are way up. If you got in early, you're sitting pretty. I'd call that positive for those lucky people.
Please prove this is an age of AI, could you confirm it?
If a real programmer does use "AI" usually, or use AI to solve all problems about programming, and AI does the all programming tasks, after 1 or 2 years, do you think his/her skills of programming are improving or declining? He/She will lose big part of programming skills very probability. Do you think he/she is a real-programmer then?
> I don’t use AI when I write, for the very reason that writing itself is the act of organizing and clarifying my own thought. Letting the bot write for me would be like paying someone else to exercise for me and hoping that gets me in shape.
I don't know why the author chooses to distinguish writing prose and writing code here. [Software is made of decisions](https://siderea.dreamwidth.org/1219758.html) and at least I usually like to flesh out those decisions through the act of writing code, which forces a level of precision that makes it hard (though not impossible) to handwave away important decisions.
"you haven’t done any of the hard thinking you would normally do in writing the code yourself"
It's true, I spend less time solving problems that arise naturally from the process of implementation. But implementation errors have a poor signal-to-noise ratio. For every error that exposes a real design problem there are 10 others that involve routine fixes: type errors, scope issues, import resolution, dependencies. There's a common argument I see being thrown around, which is "how will junior engineers develop into senior engineers if they don't get reps in with implementation?" But to me it feels like "programmer" and "architect" are becoming more and more orthogonal as the models improve in capability. If my goal is to be an architect, getting more reps in as an architect is in my best interest, and letting the agents do the dirty work frees up space for me to spend the mental effort where it counts. And anecdotally, the scope of projects I've started taking on has scaled roughly linearly relative to how much work I'm able to delegate, while the mental engagement has stayed constant.
| type errors, scope issues, import resolution, dependencies.
I write code myself and use the LLM to find mistakes then fix them manually. I recommend inverting the conventional wisdom on LLMs:
Is this as fast as AI writing the code? Not at first but possibly over time. Maybe faster. Certainly better quality.Plus you don't lose any of your skills in the process.
You're still doing the gruntwork necessary to keep your skillset.
And the token cost is a small fraction of what it takes to get LLMs to write good code.
> Don't use it to write code. It's a terrible programmer.
I see this sentiment often, and I’m honestly not sure where this comes from, as it’s really not been my experience. I feel like this must come from people feeling threatened and just moving the goals posts, or not knowing how to use the tools effectively.
> Don't use it to write code
One of the things I've started doing is to write the high level scaffold myself, create stubs (with comments) and have it fill out the details. I haven't done this for long, but I feel like my mental model of the code rots less, and I can review code faster.
I used to do this in the past, when these models were not all that capable, now there is a huge temptation to leave everything to the model. But long term I lose track of whats going on, and have a hard time even communicating with the model about the changes I want. Just a total decay of my mental model of the system, and it's really hard to recover from that state.
This is half question, half thought experiment: What exactly is it that makes us think „great, I can delegate coding to the agent, and focus on architecture myself“, instead of „great, I can delegate coding to the agent, and I can delegate architecture to the agent, and I can focus on <third thing> myself“?
And how many levels up can you construct this sentence before things go south?
What I‘m implying with this question is, of course: What makes us so confident that these things are not also better architects than us?
After all there is a huge corpus on how to architect applications correctly, and that’s in the training data just as much as Python best practices and C++ style recommendations.
You can delegate architecture to agents, as long as you know different architectures and decide which one is the most fit for a given scenario. AI can choose one but it will usually pick the one that is more present in the training corpus.
React + NextJS is a terrible architectural decision for most projects that LLMs recommend all the time.
Business has tried and mostly failed to do this since the beginning of programming. Architects that stop coding long enough tend to become shitty architects as their abstractions increasingly become disconnected from the concrete requirements of the actual problem space rather than the idealized version in their head.
ironically llm prove the its not possible to just think "abstract thoughts" . we cannot remove concrete "implmenation" facts like paris is capital of france and retain just abstract "countries have capitals"
> 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...
> 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),
That isn't the vast majority of traditional software engineering work, and arguably is better called applied physics or applied science. Super interesting though - and definitely uses programming as a core skill/tool - but it leans heavily into traditional engineering and science.
Such a creative era was until early 1990s. Back then, we have to implement almost everything that is provided by standard library and popular frameworks we take it for granted for now.
Also typically new features resemble ones I implemented in the past and I won’t learn that much from implementing them. Often times I immediately know what to do and although I do enjoy typing I do prefer just having it done in way less time.
In the meantime I can concentrate on more interesting problems.
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’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”.
You said it: you are working on a "program for yourself". Hobbyist craft programming will always be here. The question is what kind of software engineering will be paid for, and a career can be built on.
I don't see much of a market for pure software engineers anymore. You also need to be a product manager, scientist, or have some other domain knowledge adjacent to software that relates to the real world.
I say this with empathy for those who just enjoyed the craft of designing and building software, and thought that alone would provide them a livelihood and career in perpetuity, but have found a big chunk of what they loved doing (and getting paid for) overtaken by AI coding agents.
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
> 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
That's because the systems and problem spaces at FAANG companies are so large that you need(ed) a lot more division of labor to make anything work. The division of the technical side of the house between those focused on product management and those focused on building software allowed both to be done more effectively, but both roles have had a lot of their work overtaken by LLMs.
Also, From what I've heard, FAANG companies are going through big (and painful) transitions to align their staffing with the reality of what current AI tools are capable of.
Writing and coding are not the same thing; coding is a means to an end, since you don’t use the code, you use the software. This means the mechanism by which the code was created is orthogonal to the software as you’d experience it as a user.
There are many reasons to curate what goes into the software - for example, if it must be maintainable, if it must conform to standards that cannot be fully codified into the software (eg. regulatory requirements), or if you just really darn well like writing code!
But it takes a mountain of code to make an outwardly simple thing so why not use a work-amplifying tool to produce that code and get to working software more cheaply.
On the other hand writing is the act of creating the exact product that will be consumed. Every detail matters and there’s no leverage to trying to write faster.
So it’s a false equivalence. Hopefully I’ve elucidated the subtlety.
> But it takes a mountain of code to make an outwardly simple thing so why not use a work-amplifying tool to produce that code and get to working software more cheaply
The same reason we didn't just wholesale copy and paste from open source repos in the past?
> AI does not know whether the code it just added violates some legal requirement to which your product is subject.
The rest of the paragraph is a list of similar complaints.
All of these can be codified - the new work is the (fascinating!) challenge of working out how and codifying them, then giving the codified checker logic to the agent to run at will - thus taking yourself out of all of those loops.
They don’t even need to be deterministic checks - a shell script that wraps a `claude -p` - and maybe fetches some online resources to stuff into the context - can do your agent’s legal check for it.
As a result, you’re only being effective if you can engineer (not hack, not vibe) an agent that can produce work your company can use with as little cleanup as possible - and with less cleanup over time.
You get job by codifying what you know - what most don’t account for is that there’ll never be a limit to what there is to know, and codifying expertise will be challenging for a long time to come.
> They don’t even need to be deterministic checks - a shell script that wraps a `claude -p` - and maybe fetches some online resources to stuff into the context - can do your agent’s legal check for it.
No. It can't. If you think that injecting legal text into the context window and appending "make sure the output complies with this law" will solve your problems you have not understood how an LLM works. The kind of checks you are talking about cannot be codified.
So we should give up before we even tried?
I wonder if we're being overly selfish here and ignore the positive effects of democratizing programming and making software more accessible to less well funded causes and organizations. A good software engineer used to cost 100k/year, very few businesses could afford that.
I also disagree that AI results are lower quality. Codex Pro results I get are marvelous but they sometimes miss things that humans understand naturally - all of the edges - coherence of visuals, passage of time, etc.
What AI does is the exact polar opposite of "democratizing". We're going from a world where high-quality learning content is plastered all over the internet for free, where open-source projects are desperate for contributors and full of "good first issue" tickets, and where the tools you need to code can be run on any crappy laptop from the past 15 years—to a world where the majority of content about programming is unverified AI slop, where open-source projects are locking down access to protect against an avalanche of drive-by AI garbage, and where you need a $200/month subscription or a $3,000 GPU to run AI models for coding.
One thing I just discovered is that I’m no longer interested in choosing a novel tech stack. What used to engage me now just feels shallow to me so I stick with what I already know.
Not sure if that’s fine though since I get to the point of a project being interesting a lot faster instead of wiring tools together.
How does Andrew manage being a full-time software developer and an author? Both jobs are so cognitively demanding.
It is extremely mentally demanding to do both, even for someone with an overactive brain. I reached a point of severe burnout in 2025 and cut back to part-time work. I'll have to ramp up my hours again soon because, contrary to one of the other comments, I didn't get rich during 1990s/2000s boom.
As for how I did it, I would wake up very early and put in a few hours of writing, then I would put in a full day's work at the office. After my first twelve years or so in the industry, coding was almost second nature and came quite easily. Also, I do much of my writing and programming in my head while I'm walking, running or biking. (I bike to work and back every day.) By the time I sit down to write or code, I already know what I'm going to write, so it's just a matter of getting it through the keyboard.
But yeah, do both for a few years and it really taxes your brain. In both novel writing and programming, you're carrying an entire world in your brain: the plot and characters are one world, the architecture of the software you're working on is another. By 2025, I truly, literally felt like I needed to be shipped off to a madhouse in the countryside. A hundred years ago, people used to call that "the rest cure for a nervous breakdown."
Anyway, cutting back to part-time work has been a huge help. Sanity restored.
Thanks for this. I've been trying to learn this writing thing on top of my full-time job and it's been a struggle. It's helpful to hear how you managed it.
One of the things that's neat about the software field in this day and age is that you can see when someone started out 20+ years ago, when things were pretty easy (relatively) and the boom was still on the horizon.
It's pretty common that someone who was born around the right time to the right people in the right location to become a millionaire by writing some php may do something else, but still consider themselves an engineer.
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.
That was very nice to read. Refreshing to see a deep take that’s optimistic.
> Programming is ultimately the work of constructing a mental model, and that mental model is inherently personal
So that’s why we now have as many different tech stacks as we have developers at work. Conway’s law taken to its logical conclusion?
We already have such position and it's called manager.
The manager's job is to manage multiple programmers to let them write code. A good manager should focus on management rather than write code himself.
But keep doing for many years will make manager out of touch from modern coding so he is starting to mismanage people or issue technically wrong order.
Machine hater and manual labour worshiper..he thinks he got stupid because he stopped doing if/else and for-loops. Life is full of complexity and it might be helpful to get one level-up in abstraction to try to solve real problems and other people actually care about.
For me the biggest issue with AI coding model is not that it writes code, or how it writes code, or whether it will replace me or not. I mean, these are real problems, but just not the ones that makes the difference to me daily. Instead what sets my feeling about the AI is simple: the experience of working with AI models, because it's the worse experience of my life so far.
Every single LLM will make up stuff, go down rabbit holes I didn't even ask it to visit and infuriate me all day long by doing ALMOST what I asked it to do, but just not quite. Take "yes" to one question as an approval to some other question. Come up with a plan but one you review the plan and accept it it hits some minor issue and then throws away the plan and do whatever it wants. Or when I reject some line of code or don't approve a command it wants to run 9/10 times it just tries to re-add or re-run it as if my rejection was meaningless. And no amount of rules and markdown files ever seems to change its behaviour for long, if at all. It's like working with a sociopath who just doesn't remember anything that happened 5 minutes ago. It's the classic case of "my computer doesn't do what I want, only what I tell it".
And all of that would be fine if it didn't pretend to be a human, if all the UX didn't create the illusion that you interact with some intelligent being, because as long as I remember that this is a cli tool it's all good, I manage my expectations, but the experience sooner or later makes you annoyed and frustrated - and if this was a person they would either stop or you wouldn't never work with them again.
> doing ALMOST what I asked it to do, but just not quite
This is my exact experience. LLMs get 95% of the way to my personal quality bar, and for simple tasks 100% of the way.
More complex things, no. This means that, in practice, I end up having to understand the code pretty much as much deeply as I would anyway, without agents.
So, essentially, my experience is that it's automated away the easy bits, but left the hard bits, so all of my time is spent doing the hard bits, which is mentally exhausting.
Maybe Fable would be good enough to get to 100% of my quality bar on more complex tasks, but I never got chance to try it.
> So, essentially, my experience is that it's automated away the easy bits
Yes, which is great for “easy” but mundane and time consuming tasks like refactoring structs when you have a ton of tests that look at snapshots of nested structs etc. Squeezing that last few bits of “make comments consistent with the style and tone of existing comments”, or “stop adding docs that make it sound like an academic paper” or just keep the overall feel of the code same across all files take a lot of effort and energy.
I agree with this. I recently went back to writing more code by hand again for this reason: the amount of effort / mental toll it takes me to steer the LLM is sometime just not worth it. I might be slower but I enjoy my work much more again.
The only reflection that matters, now, is that every company that sells software for money is now a confidence game. How long can you con your users into believing they have any reason not to type the 5-word prompt “recreate <product> make no mistakes” and cut you, the middle man, out?
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.
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.
I don’t have those problems
You have to build your architecture modularly so you’re never having to reason about more than the schema and api-contracts for IPC
GOTO3 and loop? Don't you mean GOTO2 and loop ;)
At the moment the list goes 1, 2, 2, 3…
You’re the founder and CEO of an AI startup but also vibecoding side gig work?
Not CEO because I don’t like title, but yes
In addition to many other things (like being a dad and farming peaches - hopefully 50 lbs this year)
For websites this work. But now you are a core developer of the GTA6 engine. Your task is to create a fast efficiënt occlusion mapper. One that works from all angles. Has cavities and rt support. Good luck doing this with Claude. It's not gonna achieve this. Because only a handful of games achieved this partly. Maybe next gen AI can do it. But for complex tasks LLMs are still not good enough.
Yeah I’d agree especially in gaming
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.
There are still bespoke craftsman in this era of machinery and assembly lines.
You choosing to do something in one specific manner is more the exception that proves the rule then any rebuttal.
Current AI cannot be comparable with "machinery and assembly lines".
Current AI companies stole much data from Internet without permissions, and used the knowledge of many people directly shamelessly.
It cannot resolve many practical problems well, even in programming area.
Do you want the software-assistant to do the important or enjoyable things instead of you? Do you want your assistant in real life to eat the delicious food instead of you?
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.
How do you want to define "clearly positive impact on the economy"? NVDA and a bunch of other stocks are way up. If you got in early, you're sitting pretty. I'd call that positive for those lucky people.
> I am developing my own app 2+ years manually, and not use "AI" at all.
How does this mean this isn't an age of AI? Because you're The Representative of Programmers?
> so many not-real-programmers
Oh sorry I missed this part. It seems that you really are!
Please don't cross into personal attack, no matter how right you are or feel you are. All it does is damage the container and make things worse.
https://news.ycombinator.com/newsguidelines.html
Please prove this is an age of AI, could you confirm it?
If a real programmer does use "AI" usually, or use AI to solve all problems about programming, and AI does the all programming tasks, after 1 or 2 years, do you think his/her skills of programming are improving or declining? He/She will lose big part of programming skills very probability. Do you think he/she is a real-programmer then?
The force of "AI" companies hype is very strong now, they are everywhere. If you research the articles very carefully, you will feel this force.
The force cannot beat the reality or truth.