AI makes programming differently difficult
cacm.acm.org
cacm.acm.org
In other words, the hard part moves from recall (“How do I write this?”) to judgment (“Does this actually make sense?”)
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.
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.
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?”
You seem to want it to collapse, but that's not the argument you person you're responding to is making.
https://hn.algolia.com/?dateEnd=1753056000&dateRange=custom&...
In particular those of us rooting for the collapse of AI were complaining about this speech a year ago as well:
RLing taste and discernment are harder, but don't doubt that researchers can get a model that produces a more performant solution than you, while using less code, and being more secure/robust/etc, in a fraction of the time. Your moat for the moment is alignment with stakeholders and high level taste, enjoy it while you can.
Current models are very good for long horizon agentic tasks, but they lack taste and higher level organizational principles. They can get a tremendous amount done with limited hand holding, but they still tend to build messy slop unsupervised/without intervention.
By this time next year hand writing code will be dead outside the rarest domains, and agents will be able to build larger projects coherently, and in two years human software taste and architectural guidance will be basically redundant. I predicted the complete automation (3+ 9s) of software engineering in 3 years back in mid 2025, if anything we're slightly ahead of schedule.
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.
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.
Note that comic is about a task that AI has already conclusively solved...
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.
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 do think there is a very common denialism that is rampant causing many people to believe on what is essentially faith that AI is going to get just good enough to be a perfect assistant to them, but then magically halt on progress right before it entirely replaces them.
And to be clear I believe LLMs are likely to plateau before they replace literally everyone working in software development, but I also think that a lot more than n% of developers believe they will be part of the n% who will survive unscathed, where n ends up being quite a small number.
I am less optimistic than you, but would love to be wrong.
So true. I was too blinded to not notice the joy of my hobby getting sucked away by not doing it by hand.
My concern is how much damage could be done by someone learning 15+ years ago vs someone learning now.
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.
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.
The code is just wrong a lot. By denying the possibility of emergent phenomemona or model interiority you just hand the hypsters an easy point to score.
The code is just wrong, all the time. You're right about the part that matters and that we can measure.
I do a lot with orchestrating cloud infra, provisioning and deprovisioning workflows, lifecycle management, updating CMDBs, access management, deployment automation, auditing configurations, and some APIs in front. The code is boring, mostly glue. The agents nail it quite consistently, especially with some guidance.
I do know what I want out of it, and that is deterministic quality code to solve specific business problems, so that we don't have people (or their agents) running amok.
这波
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)
Not suggesting anything, but I'm wondering where the culture of having obvious misspellings without editing them out became the norm on HN. It's become the new em dash warning flag for me on forums.
depressing directions.
Cant answer should we without having done a lot of it before. Cant learn unless you actually do it and see the consequences through.
AI is very useful when you dont need to invent anything new
I always have to explicitly state, "we are making a clean break to v1.0, do not implement any compatibility layers".
The future is using LLMs for what they are good for. What that is still being found out. I've had great experience with LLMs reviewing the code (matches with Primagean's ~50% accuracy at finding bugs, which is really good) and for explaining unfamiliar concepts to me.
I firmly believe that the code itself needs to be 100% organic, and if it's not and you're relying on LLMs to generate tons of code, you haven't built enough abstraction to make it unnecessary.
They are also GREAT at writing code based on standards and patterns established by an actual human engineers. They are STILL trash at anything meaningfully complex from the ground up. I will go through hours of planning where I have to kick the hell out of its plans in ways that I don't think someone without a ton of real world experience could do. Even in the fancy new Fable models that remains true. They are not creative and any engineering worth doing requires creativity.
I think that’s the real point the article’s making. Unless you already know the ropes, you can’t tell if a plan is actually any good. I use LLMs all the time for work, but only because I get the system well enough to spot the nonsense or catch when a plan duplicates something that already exists. They really do keep rewriting the same functions over and over in the code.
Over the last four days I've few shotted a 1:1 clone (and improvement) of Fal, OpenRouter, and Replicate in Rust. It's going to be open source.
I've lined up $300k of monthly commitments for it that land at launch. Might apply to YC with it.
Moving "organic" is too slow for the world today.
The ball is moving towards open source and this will include fine tunes and LoRAs, and even more fertile growth after that. There's an abundant future market in that direction.
Several billion dollar businesses started as open source clones of existing things. Some found unique business lines, others simply did a better job.
Then why are you trying to make something?
Why?
Because it's incremental improvement.
Because it's making a dent in the world.
Because creation feels better than consumption.
Because we're maybe 10-20 iterations away (250 years, tops?) from brain uploads and everlasting life harvesting the energy of distant stars. Or at least our descendants are. And that's pretty cool.
You can predict 250 years in the future now and when 'brain uploads' will happen and when everlasting life will happen and when the harvesting of distant stars will happen?
That's impressive because you've made predictions a year into the future and they never came true.
Is this what we've come to?
1: The quality of code varies widely from model to model. In Visual Studio Copilot, I get so-so code from GPT, great code from Claude 4.x, lousy results from Claude 5.x
2: "Novel work" is harder to get from an LLM than when it's following an example. For example, I can get great Blazor / HTML / css from an LLM (and then spend time iterating making small adjustments,) but if I'm writing a complicated DB query or implementing a novel algorithm, it's best to do by hand.
3: But, in the case of a novel algorithm or query, I get great results saying "please write unit tests for XXX". That alone makes me develop code twice as fast!
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.
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.
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
1. Throw some notes, PR links, etc. into copilot and ask for a first draft
2. Go back and forth for a while asking for revisions
3. Trash all of the AI-generated text and rewrite the whole thing myself from scratch, which I can do quickly in a typing frenzy because I now have a clear idea what I want, by way of seeing what I don't want.
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.
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?
The human element is "What do I want?" You have ideas about how you need things to work. Some folks don't care much at all about how things work, just that they can shove a thing out the door and get paid with minimal effort. Sometimes their boss is completely in agreement. Sometimes things fall apart because nobody cared enough to bother, and sometimes even that doesn't matter, and everybody gets paid anyhow.
Sometimes you wish things mattered more, and sometimes they do.
The issue is not the quality per se (I can write hacky things if that’s needed). The issue is when you become responsible for the shoddy things that were rushed and is now hacks on pile of hacks.
The historical evidence disagrees. The point of software is automation and the point of automation is elimination of labor by any means. Nowhere in that is easier.
Clearly developers have forgotten what automation is because the quest for easier satisfies the narcissism of people who lack the ability to see otherwise.
You’re not wrong. I think that’s the confusion in LLM conversation. It seems that most people believe that programmers only think about code like it’s some kind of lego bricks we have to assemble. While the truth is that most projects is about building a sets of concepts that interacts in a specific way. The code is just the medium to do so, like letters helping to create words when writing.
I was reading the OpenBSD code (some investigation about a pen tablet) and the layers in abstraction was the following:
xinput
ws (driverfor x11)
--|ioctl syscall|---
wsmouse (wscons subsystem)
hidms (hid mouse) Some other things use the usb hid format
ums (usb mouse)
uhidev (usb hid device)
usb (root controller hub abstraction)
xhci (usb root controller under the hood, usb side
pci_xhci (usb root controller, pci side)
Programming was always about taking some lower order of things and rearranging it into meaningful concepts for some higher purposes. Whether it’s the DOM api, the jQuery suite of functions, the React model of components and reactive state, the goal is to create UI widgets for a page.
People (sometimes?) see the building blocks (dom api…) and the end result (figma sketch) but have no idea how the two connect.
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.”
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.
See, all the potato-sorting systems and the ones that drive those and so on, those are a hierarchy without end. There'll always be some other efficiency gain. And some other machine. And the whole stack will always need a human to direct and design the hierarchy, design monitoring, remediate failures, and invent new more efficient ways.
AI is not embodied and doesn't have its own drive so it can't subsume human interest and desires - humans will always direct the machines. It will never "be over".
The humans who know this will always always always be at the top, directing the machines & designing the new ones. Yes, some people won't and they will end up in the hierarchy instead of on top. But that doesn't mean it is over. It's just over for them.
You aren't responsible for how others adapt to change. Just.. work out how to not lose. Don't defeat yourself before even trying. I can't tell you how. No one can, it's your journey. But by being here on Hacker News you're already better off than most.
A characterization of a business is to satisfy as much desire as cheaply as possible.
Ai,and in the not so distant future embodied Ai, will likely outdo humans if left unchecked.
Even in areas such as providing companionship, sex, etc.
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...
It's knowing that any moment a manager is going to wander along and change it from under me. So I might as well ask the manager first.
It showed up on my performance reviews that I'm bothering other people with questions and I should make my own choices, so I started doing that and documenting every time the choice I made got overturned by a manager. Next performance review when it came up I brought out my list. My performance reviewer was pissed at me for documenting this and I was let go four months later. :)
I would love a job where people let me make decisions after decision after decision
And yeah you could say that if my manager had to overturn my decisions that often it probably meant that I made bad decisions, and maybe that's true, but I don't think so. It was often things like "this is the best solution but it will take longer", "This low priority, do it the quick way instead". But priorities changed a lot.
And then I need to be able to tell when I can make a decision, and when I don't have enough information to make that decision and therefore need to ask questions of someone who has a better handle on the overall picture.
You can't take a rapidly developing field and pretend progress is going to freeze at its current development level so you can decide how to handle it.
It's a coping mechanism to deal with rapid change by pretending change is going to stoo right here right now and you can get a handle on it.
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.
:P
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.
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.
Furthermore, I predict they will identify massive structural issues, propose huge lifts to redo it correctly, and will instead be told to do patchwork fixes to stop the bleeding.
Now, I do think AI is (or will be) good enough to implement these patchwork fixes when given explicit instructions, but someone will need to figure it out for them.
The problem is if you don’t understand the root cause, you’ll at best feed the LLM a list of symptoms, and it will dutifully fix them. “Our p99 on this endpoint is breaching” becomes “I’ve added an index for this query,” or “I’ve added a caching layer,” when the actual problem may well be that you’re storing huge blobs that bloat your working set, cause buffer pool churn, and saturate your NIC. Is the symptom solved? Yes. Is it scalable? No, you’ll next need to vertically scale the instance, which is more expensive, and has an upper bound. Eventually you’ll decide to shard, which adds complexity, when the actual solution would’ve eliminated all of those issues at once.
Today maybe.
When Cloudflare has an outage does the CEO need to know the root cause though? If he just assigns some engineers to investigate, fix and report back to him – what's the issue with that?
Assuming you agree with my analogy, can you explain what it is that you feel an agent or group of agents assigned to an engineering tasks could not do that a human can? And if can't do it today, why do you believe it wouldn't able to do it in the future?
Are we just disagreeing about timelines here or whether humans have some magical quality which algorithms and AI can never capture?
I feel like it's reasonable to disagree on timelines. It's quite unreasonable to assume human coders are special.
I of course don’t have a crystal ball, and can’t say with certainty that AI will never replace human intelligence and judgment. However, I don’t see a viable path forward where that occurs, and we all still have jobs. Why would I be kept around if a superhuman AI can do my job 1000x better and faster, and at a drastically cheaper price? Or, if I was kept around as a human QA agent, why would I be paid nearly what I am now?
I don’t see humans allowing AI to replace them. UBI is a pipe dream that would be destroyed by rent-seeking behavior anyway, and there’s no way billionaires would go for an AI tax, so we’ll be at an impasse.
Well as an AI doomer I agree with this. In my view you will lose your job, along with everyone else, and we'll just need to hope that those in power will give us some cash to feed our families. Ultimately us regular folks won't have the collective bargaining power of our labour and could not revolt with nation-wide strikes, nor are we any physical threat for those with power anymore.
But that's the good outcome. This assumes AI remains obedient to it's human owners and that bad actors don't have access and can't use it to create biological weapons and other civilisation-level threats.
I know we're not there yet, but the history of AI is one of continuous step changes in capabilities with each algorithmic breakthrough. AIs today are far more knowledgable and much quicker than humans, but still missing a few bits that keep them from being broadly super human. One or two algorithmic breakthroughs is all it takes though. It was just two breakthroughs over the last 8 years that took us from not even having code-autocomplete to having reasoning models advanced enough to solve math problems which have stumped humans for decades.
Generally, yes, but it’s the non-determinism that gets me. Even easy stuff: I’m currently on a road trip, and asked Claude (Fable) to plan various routes, optimizing for scenery while also ensuring a maximum drive time each day, and ending every night in a town that has a decent hotel. Along the way, I’ve made various tweaks, like “we’d like to drive an extra hour or two today, so adjust the rest of the route so we don’t end up with a short intermediate day.” While in general it’s done quite well, it occasionally made errors on distance between stops, something that’s trivially queryable. It wasn’t off by a few miles, either, it was hundreds.
Until they can get the confidently incorrect problem solved, I don’t see it being a viable replacement. Maybe if you have agents that are aggressively checking the main ones’ output, but that seems unnecessarily wasteful of resources to me.
2 years ago AI could even count the number of letters in a word or do basic maths. Now we're at the point where we can't trust it because makes occasional errors.
Don't get me wrong, I agree with you. These are things that need to be solved first, I just don't have reason to believe these are particularly difficult problems.
Anyway, I enjoyed the convo. Was interesting hearing your thoughts. I would give anything to be wrong.
How's about a test? Put all the smart AI researchers/developers onto an airplane that its software was entirely created by AI. Now tell that airplane to travel around the world with airborne refueling and land at an airport. When will this happen and how many of AI advocates will get on this autonomous airplane?
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.
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.
If someone says something happens and the code says something else, the code wins.
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.
So code is just a notation. But one that is executable. In your example, the code is working, it’s just not what you intended. The issue is not the code, the issue is that you don’t know code well enough to “speak” your algorithm.
And that is the main issue with a lot of LLM users. They are translating specs (which they do understand) to code (that they do not understand) and then relying on superficial outputs to see if they got it right. While also telling fluent speakers that they should follow the same workflow. At least with human languages, the other party may detect discrepancy and the fact that you’re not a native speaker. But a computer will execute things blindly.
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.
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.
The fact that you do not understand that is concerning.
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.
What new skills?
Figuring out when it's appropriate to fully wrap your head around the details of a solution, and when it's appropriate to let the agent handle that and only know a bunch of properties of the solution. Knowing when it's appropriate to try 10 things, throw them all away, then go deep. Knowing how to learn from these things so you can make something better, not just faster.
Some YAML formalities now take zero effort while 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
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.
Previously, I would've only thought through the really important high level choices up front (e.g. things that would affect interfaces with other parts of the system, or 'do I need a queue here' etc). For the smaller minutiae of good code structure, appropriate abstractions etc. I would allow myself flexibility to address those while working through the problem.
I found it easier to work at those different levels of granularity in sequence, and the latter one I specifically found easier to see the problem clearly and make a good decision while hand-writing the diff. In that sense, I think good architecture has been made more difficult to practice. For me, at least.