These articles keep popping up, analyzing an hypothetical usage of AI (and guessing it won’t be useful) as if it wasn’t something already being used in practice. It’s kinda weird to me.<p>“It won’t deal with abstractions” -> try asking cursor for potential refactors or patterns that could be useful for a given text.<p>“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<p>“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.<p>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.
I have not had the same experience as the author. The code I have my tools write is not long. I write a little bit at a time, and I know what I expect it to generate before it generates it. If what it generates isn't what I expect, that's a good hint to me that I haven't been descriptive enough with my comments or naming or method signatures.<p>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.<p>And quite honestly, for me that's the dream. Reducing the friction of human-machine interaction is <i>exactly the goal</i> 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.
It's the "Day-50" problem.<p>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.<p>Ultimately AI coding efficacy is an HCI relationship and you need different relationships (workflows) at different points in time.<p>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.<p>So the real problem isn't the Day-0 solution, it's solving the HCI workflow problem to get productivity gains at Day-50.<p>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.<p>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.<p>I talked about what I'm doing to empower new workflows over here: <a href="https://news.ycombinator.com/item?id=43814203">https://news.ycombinator.com/item?id=43814203</a>
This is a funny opinion, because tools like Claude Code and Aider let the programmer spend more of their time thinking. The more time I spend diddling the keyboard, the less time I have available to be thinking about the high-level concerns.<p>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 <i>ALL</i> I have to think about, I now have time to think about all sorts of other problems.<p>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. <a href="https://snot-22.linsomniac.com/" rel="nofollow">https://snot-22.linsomniac.com/</a><p>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.<p>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.<p>I think that's the difference between "software engineer" and "programmer". ;-)
4 lines of JS. A screenful of “reasoning”. Not much I can agree with.<p>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).<p>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”.<p>Add value? Heck yes - although I am still very wary of letting LLM-written code into production without a thorough review.
> But AI doesn't think -- it predicts patterns in language.<p>Boilerplate code <i>is</i> a pattern, and code is a language. That's part of why AI-generated code is especially effective for simple tasks.<p>It's when you get into more complicated apps that the pros/cons of AI coding start to be more apparent.
I haven't been using AI for coding assistance. I use it like someone I can spin around in my chair, and ask for any ideas.<p>Like some knucklehead sitting behind me, sometimes, it has given me good ideas. Other times ... <i>not so much</i>.<p>I have to carefully consider the advice and code that I get. Sometimes, it works, but it does not work <i>well</i>. I don't think that I've ever used suggested code verbatim. I <i>always</i> need to modify it; sometimes, heavily.<p>So I still have to think.
A programmer's JOB is not to think. It's to deliver value to their employer or customers. That's why programmers get paid. Yes, thinking hard about how to deliver that value with software is important, but when it comes to a job, it's not the thought that counts; it's the results.<p>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?<p>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.
It seems like the traditional way to develop good judgement is by getting experience with hands-on coding. If that is all automated, how will people get the experience to have good judgement? Will fewer people get the experiences necessary to have good judgement?
>But AI doesn't think -- it predicts patterns in language.<p>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.<p>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 disagree. It's all about how you're using them. AI coding assistants make it easy to translate thought to code. So much boilerplate can be given to the assistant to write out while you focus on system design, architecture, etc, and then just guide the AI system to generate the code for you.
Call it AI, ML, Data Mining, it does not matter. Truth is these tools have been disrupting the SWE market and will continue to do so. People working with it will simply be more effective. Until even them are obsolete. Don't hate the player, hate the game.
I get massive value out of Agentic coding.<p>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.<p>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.<p>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.
Software ate the world, it's time for AI to eat the software :)<p>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.<p>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.<p>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.<p>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.
This is a tired viewpoint.<p>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.
I think there's some truth here in that AI can be used as a band-aid to sweep issues of bad abstractions or terse syntax under the rug.<p>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.<p>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.
Reading just the title:<p>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.<p>Reading the post as well: It didn't change my mind. As for what it actually says, my reaction is a shrug, "whatever".
In the past I've worked at startups that hired way too many bright junior developers and at companies that insisted on only hiring senior developers. The arguments for/against AI coding assistants feel very reminiscent of the arguments that occur around what seniority balance we want on an engineering team. In my experience it's a matter of balancing between doing complex work yourself and handing off simple work.
I am very sceptical and cautious user of AI tools, but this sounds like someone who didn't figure out a workflow which works for himself:<p>> Nothing indicates how this should be run.<p>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.<p>Also you can ask for calling examples.<p>> ... are not functions whose definitions are available within the script. Without external context, we don't know what they do.<p>Are already solved by having proper IDE or LSP.<p>> run in E environments with V versions<p>Fair enough, stick to "standard" libraries which don't change often. Use boring technology.<p>> The handler implicitly ignores arguments<p>Because you probably didn't specify how arguments are to be handled.<p>In general, AI is very helpful to reduce tedium in writing common pieces of logic.<p>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.<p>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.
If AI coding assistants provide little value then why is Cursor IDE a 300m company and why does this study say it makes people more 37% more productive?<p><a href="https://exec.mit.edu/s/blog-post/the-productivity-effects-of-generative-ai-chatgpt-MCBHVNDCBTJNG3FHXHXUWIJ37YPQ" rel="nofollow">https://exec.mit.edu/s/blog-post/the-productivity-effects-of...</a>
Some problems require using a different kind of modeling other than language:<p><a href="https://medium.com/@lively_burlywood_cheetah_472/ai-cant-solve-prompts-beyond-zork-4fab6a54b8ea" rel="nofollow">https://medium.com/@lively_burlywood_cheetah_472/ai-cant-sol...</a>
Title is a bit provocative and begs the question (is thinking the part being replaced?), but the bigger issue is what “little” means here. Little in absolute terms? I think that’s harsh. Little in relation to how it’s touted? That’s a rational conclusion, I think.<p>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.<p>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”.
My experience has been quite mixed. For creating small automation tools and tests for my day it saves lot of time. For creating code, it depends. If it is something very common it work fairly well, but I need to be sure to read it carefully. If it is something more complex or uncommon it fails usually making me loose more time than if I did that myself.
For bug fix it is not helpful at all.<p>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.<p>Not sure if it made me more efficient on average tbh
It's nice that the author was kind enough to make his obviously wrong thesis righ in the title.<p>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.<p>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.<p>If you're a hobbyist, do whatever you want: use a handsaw, type code in notepad, mill your own flour, etc.
I prefer a more nuanced take. If I can’t reliably delegate away a task, then it’s usually not worth delegating. The time to review the code needs to be less than the time it takes to write it myself. This is true for people and AI.<p>And there are now many tasks which I can confidently delegate away to AI, and that set of tasks is growing.<p>So I agree with the author for most of the programming tasks I can think of. But disagree for some.
It's more like an assistant that can help you write a class to do something. You could write on your own but feeling lazy. Sometimes it's good, other times it's idioticly bad.
Need to keep it in check and keep telling it what it needs to do because it has a tendency to dig holes it can't get out of. Breaking things up into
Smaller classes helps to a degree.
"Writing code is easy"<p>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.
Honestly, o3 has completely blown my mind in terms of ability to come up with useful abstractions beyond what I would normally build. Most people claiming LLMs are limited just arent using the tools enough, and cant see the trajectory of increasing ability
I am the first to criticize LLMs and dumb AI hype. there is no nothing wrong with using an LSP, and a coding assistant is just an enhanced LSP if that is all you want it to be. my job is to solve problems, and AI can slightly speed that up.
The term "assistant" is key.<p>In any given field of expertise, the assistant isn't <i>supposed</i> to be doing the professional thinking.<p>Nonetheless, the value that a professional can extract from an assistant can vary from little, to quite significant.
One point AI helps me with is to keep going.<p>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.
On the contrary. Just yesterday, we've had here on HN one of the numerous reposts of "Notation as a tool of thought" by Ken Iverson, the creator of APL.<p>Think of AI bots as a tool of thought.
<i>engineering workflows should be more about thinking and discussing than writing code</i><p>This is also the best case for using AI. You think, you discuss, then instruct the AI to write, then you review.
As a SWE the comments on this page scare me if I'm being honest. If we can't define the value of a programmer vs an AI in a forum such as this then the obvious question is there to ask from an employer's perspective - in the world of AI is a programmer/SWE no longer worth employing/investing in long term? This equally applies to any jobs in tech where the job is "to do" vs "to own" (e.g. DevOps, Testing, etc etc)<p>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.<p>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.<p>To a lay person reading this thread - in a few years (maybe two) there won't be a point of doing CS/SWE anymore.
Couldn't agree more. And I'm regards to some of the comments here, generating the text isn't the hard OR time consuming part of development, and that's even assuming the generated code was immediately trustworthy. Given that it isn't must be checked, it's really just not very valuable
A programmers job is to provide value to the business. Thinking is certainly a part of the process, but not the job in itself.<p>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.
And yet I keep meeting programmers who say AI coding assistants are saving them tons of time or helping them work through problems they otherwise wouldn't have been able to tackle. I count myself among that group at this point. Maybe that means I'm just not a very good programmer if I need the assistance, but I'd like to think my work speaks for itself at this point.<p>Some things where I've found AI coding assistants to be fantastic time savers:<p><pre><code> - 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 APIs</code></pre>
I wish people would realize you can replace pretty much any LLM with GitHub code search. It's a far better way to get example code than anything I've used.
It doesn't seem like the author has ever used AI to write code. You definitely can ask it to refactor. Both ChatGPT and Gemini have done excellent work for me on refactors, and they have also made mistakes. It seems like they are both quite good at making lengthy, high-quality suggestions about how to refactor code.<p>His 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.<p>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.
Object-oriented languages provide little value because a programmer’s job is to think<p>Memory-safe languages provide little value because a programmer’s job is to think<p>…
I'm sorry to say, but the author of this post doesn't appear to have much, if any experience with AI and sounds like he's just trying to justify not using it and pretend hes better without it.
I fear this will not age well.<p>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?<p>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?<p>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.