Quote of the main point in the article:
In other words, the hard part moves from recall (“How do I write this?”) to judgment (“Does this actually make sense?”)
I am looking at the subtitle:
The future of software development will belong to those who can think clearly at scale, maintain durable mental models amid rapid change, and integrate machine-generated output into human-directed intent.
Wasn't this always the case? Maybe I just take this for granted because I am dumb Army guy and this is the only lens through which we dumb Army people see the world.
Whenever the subject of AI comes up in connection to programming it feels like the conversation always misses the human element. When you look at this only in terms of human behavior I am not seeing anything new with AI.
Maybe, its because I write in JavaScript and maybe its different in other areas of programming. In JavaScript it has always been a race to the bottom. The product is never the goal. The goal is always hiring and regarding code as a commodity that is designed to fail elegantly and frequently. So, when I look at AI writing code for developers I can't help but ask: What's different? Isn't that why Angular and React became popular, because they abstract away writing code?
It’s the same with writing: AI writing is coherent on the surface, but is impossible to edit because it’s built on no real insight.
Now the sharpening of a coherent point, challenging one’s assumptions, and editorial decisions of what (not) to include are super important because they’re no longer a byproduct of the writing process.
Human insight can emerge from attacking the semblance of sense in the LLM's output.
Much of the cognitive work in writing emerges in the labor of writing prose and challenging assumptions against the model you build in your head as you go. I've found this process is inverted when working with an LLM: it in effect emits a provisional structure first, and I discover what I actually think by finding where its output is vague, overconfident, incomplete or outright false.
Accepting surface-level coherence as finished thought is the failure mode to avoid.
Sure this is true. And if an AI draft helps in creating quality writing, great!
I was thinking more when it comes to stuff other people send me (like a freelance writer) and “editing” is basically writing the first draft because no cognitive effort has yet been spent on the piece
> It’s the same with writing: AI writing is coherent on the surface, but is impossible to edit because it’s built on no real insight.
LLMs lie in the unhappy-medium between an abstract machine we can reason-about versus a person we can instinctively model and simulate.
Instead it's a complicated machine that evades both reasoning and intuition.
It's somehow more tiring, reading complex plans in response to your guidance, and then making decision after decision. Reminds me of this Alan Watts bit...
A farmer who ordered a farmhand quickly discovered he was an extraordinarily efficient worker.
The first day, he put him on sawing logs, and the farmhand sawed more logs than anybody else, ever. It was fantastic — but the wood-cutting work was all done in one day.
So, the next day, the farmer put him onto mending fences. There were all kinds of broken fences around the farm. And, again, the farmhand had all the work done in one day.
So the farmer thought, “What am I going to do with this guy?”
The next day, he took the farmhand to a basement and said, “Look, here all the potatoes that have come in from this harvest. I want you to sort them into three groups: those we sell, those we use for seeding, and those we throw away.”
He left the farmhand to it. And at the end of the day, the laborer came back and said, “Well, that’s enough, mister, I quit.”
“Oh,” the farmer replied, “You can’t quit. I’ve never had such an excellent worker. I’ll raise your salary — I’ll do anything to keep you around me.”
The farmhand said, “No. It’s all right mending fences and chopping wood, but this potato business is decision after decision after decision.”
> It's somehow more tiring, reading complex plans in response to your guidance, and then making decision after decision.
This is the world of a manager working with a development team hah. When writing the code yourself is it not the same? If you're writing the code by hand then you're still making the decisions and still having to plan and design. I mean someone/something has to...
Historically, we make systems to make these decisions - build a method to sort potatoes. Or build a method that can build a method to sort potatoes.
Ai, as a cognitive technology, has the potential to climb that hierarchy.
Yes, current software developers need to make more decisions now. But that is just until the methodologies settle.
Then it is over.
If the AI is asking you questions and requiring you to make decision after decision, then perhaps it's a spec issue. I know I've written a good spec if the AI does not ask any questions and doesn't get anything wrong after implementing the user story.
You're not wrong, but isn't that just moving the same amount of decision making to earlier in the process?
How many times can we have the same discussion.
That's the neat thing, with LLMs we can fully automate this discussion and have it at thousands of tokens per second and millions of tokens per dollar.
:P
Yeah, I believe I’ve seen this topic posted on HN many times now.
Code has always been cheap, even before AI/LLMs. It’s your ability to understand your client’s problem and come up with a good solution that’s what gets you paid.
It's existential crisis Tuesday
I'm stealing this for an office sign.
Until we've all finally let go of the past.
Until the people foolish enough to think that you can replace people with an LLM learn their lesson.
Never let possibility get in the way of a value-signaling business decision, I always say.
>"How many times can we have the same discussion."
Until the people wishing it to be true are thoroughly sated.
The reality is that this is the end of programming as a large scale well paying white collar profession as we knew it.
Today a co-worker told me he thought this would mean programmers would get more money because we have been making so much, so quickly, with much fewer bug reports, it's saving the company lots of money on man hours.
AI merely reduces the difficulty of coding, without directly increasing the difficulty of architectural judgment. It merely brings to light the actual difficulty of this task. Moreover, I believe that in the future, AI will also possess certain architectural judgment capabilities. However, the cost of such AI might even be higher than that of humans.
> Code becomes only one representation of thought among many overlapping ones.
This is wrong, code is the concrete "truth" being executed, the rest (plans, prompts, agent instructions) are just temporary artifacts used to generate the code. What's left is the code alone.
LLMs don't have any semantics, they can't execute anything with 100% certainty. So far programming languages are the only langugues that can do that.
> What's left is the code alone.
The necessary work is more than just the deliverable. Even a simple patch implies an indefinite number of other approaches not-taken, and sometimes not-taken for good reasons.
Sometimes we explicitly document those, sometimes we trust that a human expert decided against them. Those other aspects of work still exist, even if they are getting skipped/mismanaged with LLMs.
I think you misunderstand. Code is also representing something. It may be what gets executed, but that does not make it "correct".
It does make it correct in the reality sense
If someone says something happens and the code says something else, the code wins.
That's technically correct but consider the following:
You're implementing quicksort. The actual algorithm is a conceptual piece of math. You write the code. But sometimes the code produces output that isn't sorted.
The code "wins" in that whatever the code says is what actually happens. But the code is wrong. It must be edited to match the algorithm. The _algorithm_ is the thing that is proven correct; the _algorithm_ is what we wanted to execute. The code is a representation of the algorithm.
No, I think it's correct. One artefact of programming for decades is that I ended up thinking in code directly without "translating" from English first.
Thus the push to use LLMs has felt a little bit like being a fluent French speaker being told that all of the best French writers are using google translate to write French translated from English now.
Nope. Code is a representation. Even low level code. The fact that you do not understand this is concerning.
It's true that there are new skills to acquire (and that those with talents for the old skills may be less talented with the new skills).
It's absolutely not true that it "just" moved the difficulty around. If that were true then I'd be just as well off continuing to use my decades of programming expertise just as I always have; but the reality is I can get more done, and get better work done (depending on level of vibing), than ever before.
Thing is, though, making programming easier doesn't mean programmers will work less hard. That's how competitive markets work. LLMs made programming easier. Capitalism prevents workers from capturing that value.
> It's true that there are new skills to acquire
What new skills?
It can be both at the same time - easier and different.
But the thesis of the OP is that it is !easier && different
Which I disagree with hence my comment?
I think the bigger issue in defining this is that “programming” is too big a task to say whether it got easier or harder.
Some YAML formalities now take zero effort while architectural thinking became way more important and difficult.
>architectural thinking became way more important and difficult.
Did it though? I think the architectural stuff was always there and was always hard. And still is. I don't buy that it got harder now that you've got a pretty smart AI you can bounce ideas off, ask to investigate stuff, maybe make a quick mockup trivial test of both options on an architectural choice you face, send off to do research etc.
...so in my mind the aggregate {{programming}} got easier because the hard parts are still hard and the trivial parts got AI'd.
The only step up in complexity imo is wrangling a bunch of agents. Even very good coders report mental exhaustion from that
Yes some parts of that are easier with AI, but I think comparatively to other activities, architecture is much harder.
And I also think what you describe is true in some contexts where you know exactly what you’re after.
You also don’t make architecture decisions in a vacuum, so the decision others make also affect you and you need to sell your decisions to others.
Tackling software architecture is not programming, that is architecture. They're called different things for a reason. It is now easier to write working code via AI. Anyone that can type can do it. The syntax (language) barrier is fully removed. I'm done with syntax, looking up the new right way to do things, etc. It works via prompting. Tell it what to write and it comes out the other end with a working program. That's programming, and that's not an opinion. This alone makes it easier to program.
I don't think I write or read or code anymore, bar prs from juniors or senior colleagues wanting a review.
I didn't think it would work just 6 months ago, but reality is that at this point AI writes better code than me and I'm not the average developer, but someone who loved the craft and was good at it.
Lots of effort was required to get the repositories to a good level, best practices, documentation, etc, but reality is that once you do that and have strong rails most of your work is having it to write a plan focused on business logic, review it, have it derive an implementation plan, review it and then it's mostly on its own.
Codebases have never been healthier, cleaner, better documented, consisted and thoroughly tested as they are now. There was just no spare time and mental energy to bring them there before, now there is and experimenting to get there was cheap.
Needless to say I no longer enjoy the job anymore and thinking of changing domain. I loved tinkering about implementation details, etc, but the job nowadays is more of qa and architectural design than writing or reviewing code.
It's way easier. People don't need to read code anymore, nor will they have to care about building mental models about the system as this article suggests.
The way to think about coding agents is that a good one should in theory literally replace the developer entirely. No, a whole organisation of developers.
In theory a product owner should just be able to dictate how they want to product to function at a high level and the AI should take care of the rest in the same way a human programmer or team of programmers would have in the past. If there are conflicts in what's being requested, then the AI should be able to recognise that and ask for production direction.
As always with every generation of AI people seem to way over index on the now.
- "They're good for autocomplete, that's about it"
- "They're good for quickly mocking up small functions, but they make a lot of mistakes"
- "They're good for scaffolding some parts of the system if you're good at prompt engineering"
- "They're good at writing most of the code, but humans will always need to do the last 10%"
- "They can write all of the code, but humans will still need to architect the system"
You are here. Perhaps this is where progress stops. I wouldn't bet on that however.
AI is making programming an irrelevent field.
Yup!. Over 30 years experience here. Landed on the same place with the added feeling of "We were always intended to develop the judgement of what makes sense and maintainable, where is the surprise here?"
People want the "Fluent Text Generator" to think for them because its marketing calls it AI. At the end is just a tensor collection, probabilistically backtracked adjusted, text generator. It does produces fluency in the answer, but the fact that it sounds correct, to the point of passing a compiler approval, has nothing to do with been well thought out.
Yes a LLM is mostly an information memory de vice, but as a worker you still have to vet it.
I believe the human constraint made us find ways to layer and modularize systems so it is easier to check. Now the LLM produces a lot of code and abstraction have to be enforced. Something is missing.. (resonates with the latest Pocoo blog)
Yep, I feel fortunate that programmers that made it well before AI are going to be very sort after in a world where software development is going to explode and be in very high demand.
Sort?
Sought
[delayed]
That's where I've landed too. Maybe I'm just delusional and telling myself a comfortable story, but I think my ~15 years of experience building software by hand lets me utilize these robots in a way that people lacking it simply can't.
I still absolutely loathe talking to them and using them. But I feel less scared about losing my career these days. Work wants me to use it, I'm using it at work. In my hobby projects I still code by hand.
Yep, that's definitely true... for now.
The thing that concerns me, however, is that just a year ago it was only useful for doing things like reminding me how to read in a file. Now it's at the level of a competent junior, who can almost do the whole task from start to finish but needs a little supervision.
All the AI companies are retaining the messages we're sending to their agents to train the next models. I wouldn't be surprised if the agents will be able to do what I'm doing in a year or two.
UPDATE: I'm getting a lot of replies to this thread and while I'm not trying to be argumentative here, I have to ask if a lot of them aren't rooted in denial... it's been a hard adjustment process for me too.
> All the AI companies are retaining the messages we're sending to their agents to train the next models. I wouldn't be surprised if the agents will be able to do what I'm doing in a year or two.
Some things are very easy to solve via code (see https://xkcd.com/1425/), and others are extremely difficult.
For LLM based AI, it can be trained to write functionally correct code easily - there's tons of pre-existing code and documentation that can let AI learn patterns (LAMP stack, messaging queue, etc) and syntax.
Judgement is much more difficult. For some things "Should I go with a message queue for this problem?", there's a known set of solutions as to what works best in a specific situation, sure, LLMs can answer that easily.
But when it comes to turning human goals into code that does the job correctly and is maintainable and stable?
That's a heck of a lot different. Without human guidance and having tons of context gained by years of experience dealing with the very nuanced and situational judgement calls needed, LLMs are going to fail at doing a decent job.
LLMs (and junior people) don't know what they don't know. I think it will be really difficult to get a LLM to work well at a senior / staff level where it's more about coordination, working with human beings, handling situations based on legacy code, knowing what will and won't be fragile, etc.
Exactly, tacit knowledge is not easily added as AI training data.
> Some things are very easy to solve via code (see https://xkcd.com/1425/), and others are extremely difficult.
Note that comic is about a task that AI has already conclusively solved...
Understanding the fundamentals of anything will always be a valuable skill, and that only comes from hard work and experience. And much of the experience lies in tacit knowledge, not easily added as AI training data.
That, combined with knowing what to build, and more importantly what NOT to build, I don’t think AI ever will take away from us.
People were saying the exact same thing exactly a year ago. “Last years models were no good, but this year we can do anything; so what about next years models?” the people said in July of 2025.
Well... Now we have next years models, and people are still saying: “Last years models were no good, but this year we can do anything; so what about next years models?” And I am pretty sure in July 2027 (if this whole thing hasn’t collapsed in on it self by that point [very likely]) you all will be saying: “Last years models were no good, but this year we can do anything; so what about next years models?”
For anything that isnt generic I find the effectiveness drops off very quickly.
It's already 100x better at writing todo apps than the average senior developer but when I get it to try and achieve something unusual using a relatively obscure library it flails.
> Now it's at the level of a competent junior, who can almost do the whole task from start to finish but needs a little supervision.
Define tasks!
The most important aspects is that they’ve always been good at applying patterns, but have no discernment into why and the specific adjustments that needs to be done for a particular contexts. It’s rare that I can’t find discrepancy at the edges if several patterns have been used.
We already have good tools for patterns. It’s called code reusability. So frameworks, libraries, code generators, paradigms, snippets, and the mighty copy and paste (there’s a reason vim has like 26 registers).
Software development is all about managing complexity, which LLM are notoriously bad at. A little supervision won’t cut it.
I find myself just jumping up the abstraction ladder, aiming for more and more ambitious projects. It's like electric mountain bikes; at first there was a lot of objection across the purists (and there still is), but eventually people understood you put in the same effort just go longer and faster. I work the same hours and strain my thought just as much but my output is significantly more ambitious. Left to their own devices even SOTA models like Fable would produce a complete mess over time, fine locally but awful globally. Admittedly, I don't know if it's the nature of the beast or if I'm just not thorough enough with my prompting and let the LLM guess what I want to end up with; but clearly some directional expertise is required.
I wonder about this. One would think new programmers, like old, will learn through experience to care most about the things that matter, and ignore things that don’t. In 10 years my pre-AI experience may condition me to waste time thinking about struct packing, while younger developers simply won’t know or care
> thinking about struct packing, while younger developers simply won’t know or care
That particular ship sailed more than 15 years ago. Back then if you asked people trained on high level GC-based languages about low level details or memory allocation, they wouldn't know.
But I feel like over the last ~10 years there's been a trend back towards learning more about them (e.g., with Rust and new C# features, or with Win32 programming becoming a cool hipster thing somehow)? Or maybe that's just my own personal bubble.
I think the problem will be that there was only so much we could do wrong while we were learning 15+ years ago and our mentors had a reasonable scope to watch around us as we learned. People learning now can get a coding agent to build the entire system for them and it is much harder for the mentor to review that work.
My concern is how much damage could be done by someone learning 15+ years ago vs someone learning now.