“It won’t deal with abstractions” -> try asking cursor for potential refactors or patterns that could be useful for a given text.
“It doesn’t understand things beyond the code” -> try giving them an abstract jira ticket or asking what it things about certain naming, with enough context
“Reading code and understanding whether it’s wrong will take more time than writing it yourself” -> ask any engineer that saves time with everything from test scaffolding to run-and-forget scripts.
It’s as if I wrote an article today arguing that exercise won’t make you able to lift more weight - every gymgoer would raise an eyebrow, and it’s hard to imagine even the non-gymgoers would be sheltered enough to buy the argument either.
AI agents alone, unbounded, currently cannot provide huge value.
> try asking cursor for potential refactors or patterns that could be useful for a given text.
You, the developer, will be selecting this text.
> try giving them an abstract jira ticket or asking what it things about certain naming, with enough context
You still selected a JIRA ticket and provided context.
> ask any engineer that saves time with everything from test scaffolding to run-and-forget scripts.
Yes that is true, but again, what you are providing as a counterfactual are very bounded, aka easy contexts.
In any case, the industry (both the LLM providers as well as tooling builders and devs) is clearly going into the direction of constantly etching out small imoprovements by refining which context is deemed relevant for a given problem and most efficient ways to feed it to LLMs.
And let's not kid ourselves, Microsoft, OpenAI, hell Anthropic all have 2027-2029 plans where these things will be significantly more powerful.
1. I'll tell Claude Code to fix a bug.
2. Claude Code will fail, and after a few rounds of explaining the error and asking it to try again, I'll conclude this issue is outside the AI's ability to handle, and resign myself to fixing it the old fashioned way.
3. I'll start actually looking into the bug on my own, and develop a slightly deeper understanding of the problem on a technical level. I still don't understand every layer to the point where I could easily code a solution.
4. I'll once again ask Claude Code to fix the bug, this time including the little bit I learned in #3. Claude Code succeeds in one round.
I'd thought I'd discovered a limit to what the AI could do, but just the smallest bit of digging was enough to un-stick the AI, and I still didn't have to actually write the code myself.
(Note that I'm not a professional programmer and all of this is happening on hobby projects.)
Yesterday I needed to import a 1GB CSV into ClickHouse. I copied the first 500 lines into Claude and asked it for a CREATE TABLE and CLI to import the file. Previous day I was running into a bug with some throw-away code so I pasted the error and code into Claude and it found the non-obvious mistake instantly. Week prior it saved me hours converting some early prototype code from React to Vue.
I do this probably half a dozen times a day, maybe more if I'm working on something unfamiliar. It saves at a minimum an hour a day by pointing me in the right direction - an answer I would have reached myself, but slower.
Over a month, a quarter, a year... this adds up. I don't need "big wins" from my LLM to feel happy and productive with the many little wins it's giving me today. And this is the worst it's ever going to be.
But even if we ignored those, this feels like goalpost moving. They're not selecting the text - ok, ask LLM what needs refactoring and why. They're not selecting the JIRA ticket with context? Ok, provide MCP to JIRA, git and comms and ask it to select a ticket, then iterate on context until it's solvable. Going with "but someone else does the step above" applies to almost everyone's job as well.
>etching out
Could you explain what you mean by etching out small improvements? I've never seen the phrase "etching out" before.It does take a bit to understand how to prompt in a way that the results are useful, can you share what you tried so far?
Unfortunately, people enjoying a thing and thinking that it works well doesn't actually mean much on its own.
But, more than that I suspect that AI is making more people realize that they don't need to write everything themselves, but they never needed to to begin with, and they'd be better off to do the code reuse thing in a different way.
I am /hoping/ that AI will improve, to the point that I can use it like Google or Wikipedia (that is, have some trust in what's being produced)
I don't actually know anyone using AI right now. I know one person on Bluesky has found it helpful for prototyping things (and I'm kind of jealous of him because he's found how to get AI to "work" for him).
Oh, I've also seen people pasting AI results into serious discussions to try and prove the experts wrong, but only to discover that the AI has produced flawed responses.
Personally i have still yet to find LLMs useful at all with programming.
I can buy “if you use the forklift you’ll eventually lose the ability to lift weight by yourself”, but the author is going for “the forklift is actually not able to lift anything” which can trivially be proven wrong.
This _is_ something that you can do with AI, but it's something that a search engine is better suited to because the search engine provides context that helps you do the evaluation, and it doesn't smash up results in weird and unpredictable ways.
Y'all think that AI is "thinking" because it's right sometimes, but it ain't thinking.
If I search for "refactor <something> to <something else>" and I get good results, that doesn't make the search engine capable of abstract thought.
Y'all think that AI is "thinking" because it's right sometimes, but it ain't thinking.
I know the principles of how LLMs work, I know the difference between anthropomorphizing them and not. It's not complicated. And yet I still find them wildly useful.
YMMV, but it's just lazy to declare that anyone who sees it differently than you just doesn't understand how LLMs work.
Anyway, I could care less if others avoid coding with LLMs, I'll just keep getting shit done.
If you already know how to code, yes AI/LLMs can speed you along at certain tasks, though be careful you don't let your skills atrophy. If you can bench 225 and then you stop doing it, you soon will not be able to do that anymore.
This isn't a concern. Ice-cutting skills no longer have value, and cursive writing is mostly a 20th century memory. Not only have I let my assembly language skills atrophy, but I'll happily bid farewell to all of my useless CS-related skills. In 10 years, if "app developer" still involves manual coding by then, we'll talk about coding without an AI partner like we talk about coding with punch cards.
The bigger risk is skill atrophy.
Proponents say, it doesn’t matter. We shouldn’t have to care about memory allocation or dependencies. The AI system will eventually have all of the information it needs. We just have to tell it what we want.
However, knowing what you want requires knowledge about the subject. If you’re not a security engineer you might not know what funny machines are. If someone finds an exploit using them you’ll have no idea what to ask for.
AI may be useful for some but at the end of the day, knowledge is useful.
And it's okay at basic generation - "write a map or hash table wrapper where the input is a TZDB zone and the output is ______" will create something reasonable and get some of the TZDB zones wrong.
But it hasn't been that great for me at really extensive conceptual coding so far. Though maybe I'm bad at prompting.
Might be there's something I'm missing w/ my prompts.
Honestly, I'm curious why your experience is so different from mine. Approximately 50% of the time for me, LLMs hallucinate APIs, which is deeply frustrating and sometimes costs me more time than it would have taken to just look up the API. I still use them regularly, and the net value they've imparted has been overall greater than zero, but in general, my experience has been decidedly mixed.
It might be simply that my code tends to be in specialized areas in which the LLM has little training data. Still, I get regular frustrating API hallucinations even in areas you'd think would be perfect use cases, like writing Blender plugins, where the documentation is poor (so the LLM has a relatively higher advantage over reading the documentation) and examples are plentiful.
Edit: Specifically, the frustrating pattern is: (1) the LLM produces some code that contains hallucinated APIs; (2) in order to test (or even compile) that code, I need to write some extra supporting code to integrate it into my project; (3) I discover that the APIs were hallucinated because the code doesn't work; (4) now I not only have to rewrite the LLM's code, but I also have to rewrite all the supporting code I wrote, because it was based around a pattern that didn't work. Overall, this adds up to more time than if I had just written the code from scratch.
This may be the crux of it.
Turning slapdash prose into median-grade code is not a problem I can imagine needing to solve.
I think I'm better at describing code in code than I am in prose.
I Want to Believe. And I certainly don't want to be "that guy", but my honest assessment of LLMs for coding so far is that they are a frustrating Junior, who maybe I should help out because mentoring might be part of my job, but from whom I should not expect any near-term technical contribution.
That is not what abstraction is about. Abstraction is having a simpler model to reason about, not simply code rearranging.
> “It doesn’t understand things beyond the code” -> try giving them an abstract jira ticket or asking what it things about certain naming, with enough context
Again, that is still pretty much coding. What matters is the overall design (or at least the current module).
> “Reading code and understanding whether it’s wrong will take more time than writing it yourself” -> ask any engineer that saves time with everything from test scaffolding to run-and-forget scripts.
Imagine having a script and not checking the man pages for expected behavior. I hope the backup games are strong.
Which models have you tried to date? Can you come up with a top 3 ranking among popular models based on your definition of value?
What can be said about the ability of an LLM to translate your thinking represented in natural language to working code at rates exceeding 5-10x your typing speed?
Mark my words: Every single business that has a need for SWEs will obligate their SWEs to use AI coding assistants by the end of 2026, if not by the end of 2025. It will not be optional like it is today. Now is the time you should be exploring which models are better at "thinking" than others, and discerning which thinking you should be doing vs. which thinking you can leave up to ever-advancing LLMs.
Drop me a message on New Year's Day 2027. I'm betting I'll still be using them optionally.
You'll of course be free to use them optionally in your free time and on personal projects. It won't be the case at your place of employment.
I will mark my calendar!
If businesses mandated speed like that, then we’d all have been forced to use emacs decades ago. Businesses mandate correctness and AI doesn’t as clearly help to that end.
For better or worse, you won't find correctness on any business' income statement. Sure, it's a latent variable, but so is efficiency.
Exactly why I authored https://ghuntley.com/ngmi - it's already happening...
I think there are a couple of problems at play: 1) people who don't want the tools to have value, for various reasons, and have therefore decided the tools don't have value; 2) people who tried the tools six months or a year ago and had a bad experience and gave up; and 3) people who haven't figured out how to make good use of the tools to improve their productivity (this one seems to be heavily impacted by various grifters who overstate what the coding assistants can do, and people underestimating the effort they have to put in to get good at getting good output from the models.)
Using AI is like driving a car that decides to turn even if you keep the steering wheel straight. Randomly. At various degree. If you like this because some times it let you turn in a curve without you having to steer, you do you. But some people do prefer having a car turn when and only when they turn the wheel.
Meanwhile I just asked Gemini in VS Code Agent Mode to build an HTTP-like router using a trie and then refactor it as a Python decorator, and other than a somewhat dumb corner case it failed at, it generated a pretty useful piece of code that saved me a couple of hours (I had actually done this before a few years ago, so I knew exactly what I wanted).
Replace programmers? No. Well, except front-end (that kind of code is just too formulaic, transactional and often boring to do), and my experiments with React and Vue were pretty much “just add CSS”.
Add value? Heck yes - although I am still very wary of letting LLM-written code into production without a thorough review.
Oh :) LLMs do work sometimes when you already know what you want them to write.
No offense, but that sounds like every programmer that hasn't done front-end development to me. Maybe for some class of front-ends (the same stuff that Ruby on Rails could generate), but past that things tend to get not boring real fast.
I use Cursor not because I want it to think for me, but because I can only type so fast. I get out of it exactly the amount of value that I expect to get out of it. I can tell it to go through a file and perform a purely mechanical reformatting (like converting camel case to snake case) and it's faster to review the results than it is for me to try some clever regexp and screw it up five or six times.
And quite honestly, for me that's the dream. Reducing the friction of human-machine interaction is exactly the goal of designing good tools. If there was no meaningful value to be had from being able to get my ideas into the machine faster, nobody would buy fancy keyboards or (non-accessibility) dictation software.
The LLM doesn't magically know stuff you don't tell it. They CAN kinda-sorta fetch new information by reading the code or via MCP, but you still need to have a set of rules and documentation in place so that you don't spend half your credits on the LLM figuring out how to do something in your project.
Sure, it would be really bad if everyone just assumes that the current state of the art is the best it will ever be, so we stop using our brains. The thing is, I'm very unlikely to come up with a better approximation to TSP, so I might as well use my limited brain power to focus on domains where I do have a chance to make a difference.
I've never written boilerplate. I copy them from old projects (the first time was not boilerplate, it was learning the technology) or other files, and do some fast editing (vim is great for this).
Memory-safe languages provide little value because a programmer’s job is to think
…
We are in a transition period now. But eventually, most programmers will probably just get to trust the AIs and the code they generate, maybe do some debugging here and there at the most. Essentially AIs are becoming the English -> Code compilers
yes there are now likely going to be less billable hours and perhaps less joy in the work, but at the same time I suspect that managers who decide they can forgo graphic designers and just get programmers to do it are going to lose a competitive advantage
On Day-0, AI is great but by Day-50 there's preferences and nuance that aren't captured through textual evidence. The productivity gains mostly vanish.
Ultimately AI coding efficacy is an HCI relationship and you need different relationships (workflows) at different points in time.
That's why, currently, as time progresses you use AI less and less on any feature and fall back to human. Your workflow isn't flexible enough.
So the real problem isn't the Day-0 solution, it's solving the HCI workflow problem to get productivity gains at Day-50.
Smarter AI isn't going to solve this. Large enough code becomes internally contradictory, documentation becomes dated, tickets become invalid, design docs are based on older conceptions. Devin, plandex, aider, goose, claude desktop, openai codex, these are all Day-0 relationships. The best might be a Day-10 solution, but none are Day-50.
Day-50 productivity is ultimately a user-interface problem - a relationship negotiation and a fundamentally dynamic relationship. The future world of GPT-5 and Sonnet-4 still won't read your thoughts.
I talked about what I'm doing to empower new workflows over here: https://news.ycombinator.com/item?id=43814203
AI coding assistants provide 90% of the time more value than the good old google search. Nothing more, nothing less. But I don't use AI to code for me, I just use it to optimize very small fractions (ie: methods/functions at most).
> The future world of GPT-5 and Sonnet-4 still won't read your thoughts. Chills ahead. For sure, it will happen some day. And there won't be any reason to not embrace it (although I am, for now, absolutely reluctant to such idea).
Scroll through things like https://www.yourware.so/ which is a no-code gallery of apps.
There's this utility threshold due to a 1967 observation by Melvin Conway:
> [O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
https://en.wikipedia.org/wiki/Conway%27s_law
The next step only comes from the next structure.
Lovable's multiplayer mode (https://lovable.dev/blog/lovable-2-0) combined with Agno teams (https://github.com/agno-agi/agno) might be a suitable solution if you can define the roles right. Some can be non or "semi"-human (if you can get the dynamic workflow right)
The old quote might apply:
~"XML is like violence. If it's not working for you, you need to use more of it".
(I think this is from Tim Bray -- it was certainly in his .signature for a while -- but oddly a quick web search doesn't give me anything authoritative. I asked Gemma3, which suggests Drew Conroy instead)
Boilerplate code is a pattern, and code is a language. That's part of why AI-generated code is especially effective for simple tasks.
It's when you get into more complicated apps that the pros/cons of AI coding start to be more apparent.
So if I, with AI augmentation, can deliver the same value as a colleague with 20% less thought and 80% less time, guess whose job is more secure?
I know, I know, AI tools aren't on par with skilled human programmers (yet), but a skilled human programmer who uses AI tools effectively to augment (not entirely replace) their efforts can create value faster while still maintaining quality.
As a software professional what makes it more interesting is that the "trick" (reasoning RL in models) that unlocked disruption of the software industry isn't really translating to other knowledge work professions. The disruption of AI is uneven. I'm not seeing in my circles other engineers (e.g. EE's, Construction/Civil, etc), lawyers, finance professionals, anything else get disrupted as significantly as software development.
The respect of the profession has significantly gone down as well. From "wow you do that! that's pretty cool..." to "even my X standard job has a future; what are you planning to do instead?" within a 3 year period. I'm not even in SV, NY or any major tech hubs.
https://exec.mit.edu/s/blog-post/the-productivity-effects-of...
If you're the 1% of Earth's population for which this is true, then this headline makes sense. If you're the 99% for which this isn't at all true, then don't bother reading this, because AI coding assistance will change your life.
It's like doing math proofs. It's easy when you know maths and have a theoretical solution. So, the first steps is always learning maths and think about a solution. Not jump head first into doing proofs.
If I can just thinking "Implement a web-delivered app that runs in the browser and uses local storage to store state, and then presents a form for this questionnaire, another page that lists results, and another page that graphs the results of the responses over time", and that's ALL I have to think about, I now have time to think about all sorts of other problems.
That's literally all I had to do recently. I have chronic sinusitis, and wanted to start tracking a number of metrics from day to day, using the nicely named "SNOT-22" (Sino-Nasal Outcome Test, I'm not kidding here). In literally 5 minutes I had a tool I could use to track my symptoms from day to day. https://snot-22.linsomniac.com/
I asked a few follow-ups ("make it prettier", "let me delete entries in the history", "remember the graph settings"). I'm not a front-end guy at all, but I've been programming for 40 years.
I love the craft of programming, but I also love having an idea take shape. I'm 5-7 years from retirement (knock on wood), and I'm going to spend as much time thinking, and as little time typing in code, as possible.
I think that's the difference between "software engineer" and "programmer". ;-)
Like some knucklehead sitting behind me, sometimes, it has given me good ideas. Other times ... not so much.
I have to carefully consider the advice and code that I get. Sometimes, it works, but it does not work well. I don't think that I've ever used suggested code verbatim. I always need to modify it; sometimes, heavily.
So I still have to think.
We've moved well beyond that. The above sentence tells me you haven't used the tools recently. That's a useful way to picture what's happening, to remove the magic so you can temper your expectations.
The new tooling will "predict patterns" at a higher level, a planning level, then start "predicting patterns" in the form of strategy, etc... This all, when you start reading the output of "thinking" phases. They sound a lot likea conversation I'd have with a colleague about the problem, actually.
I no longer need to worry about a massive amount of annoying, but largely meaningless implementation details. I don’t need to pick a random variable/method/class name out of thin air. I don’t need to plan ahead on how to DRY up a method. I don’t need to consider every single edge case up front.
Sure, I still need to tweak and correct things but we’re talking about paint by number instead of starting with a blank canvas. It’s such a massive reduction in mental load.
I also find it reductionist to say LLM don’t think because they’re simply predicting patterns. Predicting patterns is thinking. With the right context, there is little difference between complex pattern matching and actual thinking. Heck, a massive amount of my actual, professional software development work is figuring out how to pattern matching my idea into an existing code base. There’s a LOT of value in consistency.
Anything methodical is exactly what the current gen AI can do. Its phenomenal in translations, be it human language to human language or an algorithm description into computer language.
People like to make fun with the "vibe coding" but that's actually a purification process where humans are getting rid of the toolset that we used to master to be able to make the computer do what we tell it to do.
Most of todays AI developer tools are misguided because they are trying to orchestrate tools that were created to help people write and manage software.
IMHO the next-gen tools will write code that is not intended for human consumption. All the frameworks, version management, coding paradigms etc will be relics of the past. Curiosities for people who are fascinated for that kind of things, not production material.
There's a percentage of developers, who due to fear/ego/whatever, are refusing to understand how to use AI tooling. I used to debate but I've started to realize that these arguments are mostly not coming from a rational place.
For example, I often find myself reaching for Cursor/ChatGPT to help me with simple things in bash scripts (like argument parsing, looping through arrays, associative maps, handling spaces in inputs) because the syntax just isn't intuitive to me. But I can easily do these things in Python without asking an AI.
I'm not a web developer but I imagine issues of boilerplate or awkward syntax could be solved with more "thinking" instead of using the AI as a better abstraction to the bad abstractions in your codebase.
It is _because_ a programmer's job is to think that AI Coding assistants may provide value. They would (and perhaps already do) complete the boiler plate, and perhaps help you access information faster. They also have detriments, may atrophy some of your capabilities, may tempt you to go down more simplistic paths etc., but still.
Reading the post as well: It didn't change my mind. As for what it actually says, my reaction is a shrug, "whatever".
> Nothing indicates how this should be run.
That's why I usually ask it to write a well defined function or class, with type annotations and all that. I already know how to call it.
Also you can ask for calling examples.
> ... are not functions whose definitions are available within the script. Without external context, we don't know what they do.
Are already solved by having proper IDE or LSP.
> run in E environments with V versions
Fair enough, stick to "standard" libraries which don't change often. Use boring technology.
> The handler implicitly ignores arguments
Because you probably didn't specify how arguments are to be handled.
In general, AI is very helpful to reduce tedium in writing common pieces of logic.
In ideal world, programming languages and libraries are as expressive as natural language, and we don't need AI. We can marshal our thoughts into code as fast as we marshal it into english, and as succinctly.
But until that happens "AI" helps with tedious logic and looking up information. You will still have to confirm the code, so being at least a bit familiar with the stack is a good thing.
https://medium.com/@lively_burlywood_cheetah_472/ai-cant-sol...
You need three things to use LLM based tools effectively: 1) an understanding of what the tool is good at and what it isn’t good at; 2) enough context and experience to input a well formulated query; and 3) the ability to carefully verify the output and discard it if necessary.
This is the same skillset we’ve been using with search engines for years, and we know that not everyone has the same degree of Google-fu. There’s a lot of subjectivity to the “value”.
It is helpful for things that I would need to ask someone else to do for me. Now I have a set of tools that give me insights during my work.
Not sure if it made me more efficient on average tbh
If you write code professionally, you're really doing yourself a disservice if you aren't evaluating and incorporating AI coding tools into your process.
If you've tried them before, try them again. The difference between Gemini 2.5 Pro and what came before is as different as between GPT 3.5 and 4.
If you're a hobbyist, do whatever you want: use a handsaw, type code in notepad, mill your own flour, etc.
And there are now many tasks which I can confidently delegate away to AI, and that set of tasks is growing.
So I agree with the author for most of the programming tasks I can think of. But disagree for some.
In any given field of expertise, the assistant isn't supposed to be doing the professional thinking.
Nonetheless, the value that a professional can extract from an assistant can vary from little, to quite significant.
Does it do things wrong (compared to what I have in my mind?). Of course. But it helps to have code quicker on screen. Editing / rolling back feels faster than typing everything myself.
Think of AI bots as a tool of thought.
This is also the best case for using AI. You think, you discuss, then instruct the AI to write, then you review.
It’s not humans vs machines.
Truth: AI Coding assistants provide much value since they give a programmer more time to think
Many defenders of AI tools in this thread are basically arguing against the end conclusion of the article which is that "to think" is no longer the moat it once was. I don't buy into the argument either that "people who know how to use AI tools" will somehow be safe - logically that's just a usability problem that has a lot of people seem to be interested in solving.
The impression I'm getting is that even the skill of "using/programming LLM's" is only a transitory skill and another form of cope from developers pro AI - if AI is smart enough you won't need to "know how to use it" - it will help you. That's what commoditization of intelligence is by definition - anything like "learning/intelligence/skills" is no longer required since the point is to artificially create this.
To a lay person reading this thread - in a few years (maybe two) there won't be a point of doing CS/SWE anymore.
I know LLMs are masters of averages and I use that to my advantage.
I agree with the initial point he's making here - that code takes time to parse mentally, but that does not naturally lead to the conclusion that this _is_ the job.
Some things where I've found AI coding assistants to be fantastic time savers:
- Searching a codebase with natural language
- Quickly groking the purpose of a function or file or module
- Rubber duck debugging some particularly tricky code
- Coming up with tests exercising functionality I hadn't yet considered
- Getting up to speed with popular libraries and APIsHis argument about debugging is absolutely asinine. I use both GDB and Visual Studio at work. I hate Visual Studio except for the debugger. GDB is definitely better than nothing, but only just. I am way, way, way more productive debugging in Visual Studio.
Using a good debugger can absolutely help you understand the code better and faster. Sorry but that's true whether the author likes it or not.