19 ms·

Generative AI coding tools and agents do not work for me

• careful_ai 1y ago
  Miguel nails the core issue: LLMs often feel like interns with no memory—raw, forgetful, and unreliable for anything beyond boilerplate. As many commenters point out, they need constant supervision and never actually learn your patterns or architecture. We ran into the same problem when rolling out AI-assisted code reviews and code generation pipelines. What helped us was adopting AppMod.AI's Project Analyzer: - Memory & context retention: It parses your full repo, builds architecture diagrams and dependency maps—so AI suggestions stay grounded in real code structure. - Human-in-the-loop chat interface: You can ask clarifying questions like, “Does this function follow our performance pattern?” and get guided explanations from the tool before merging. - Collaborative refactor tracking: It tracks changes and technical debt over time, making it easy to spot drift or architectural erosion—something pure LLMs miss. - Prompt-triggered cost and quality metrics: You can see how often you call AI, what it costs, and its success rates in passing your real tests—not just anecdotal gains. It’s far from perfect, but it shifts the workflow from “LLM writes → you fix” to “LLM assists within your live code context, under your control.” Others have noted similar limitations in Copilot and GPT-4 based tools—where human validation remains essential . In short: LLMs aren’t going to replace senior devs—they’re tools that need tooling. Blending AI insights with architecture-aware context and built-in human validation feels like the best middle path so far.
  • aayushi_1607 1y ago
    Wow, this is such a refreshing take—and totally agree with the “intern with no memory” analogy! We’ve all felt that disconnect when LLMs generate decent code but miss the bigger picture (like architectural patterns, naming conventions, or even basic repo logic).
• jumploops 1y ago
  > It takes me at least the same amount of time to review code not written by me than it would take me to write the code myself, if not more. As someone who uses Claude Code heavily, this is spot on. LLMs are great, but I find the more I cede control to them, the longer it takes to actually ship the code. I’ve found that the main benefit for me so far is the reduction of RSI symptoms, whereas the actual time savings are mostly over exaggerated (even if it feels faster in the moment).
  • hooverd 1y ago
    Is anybody doing cool hybrid interfaces? I don't actually want to do everything in conversational English, believe it or not.
    • jumploops 1y ago
      My workflow is to have spec files (markdown) for any changes I’m making, and then use those to keep Claude on track/pull out of the trees. Not super necessary for small changes, but basically a must have for any larger refactors or feature additions. I usually use o3 for generating the specs; also helpful for avoiding context pollution with just Claude Code.
      • adastra22 1y ago
        I do similar and find that this is the best compromise that I have tried. But I still find myself nodding along with OP. I am more and more finding that this is not actually faster, even though it certainly seems so.
    • bdamm 1y ago
      Isn't that what Windsurf or Cursor are?
  • cbsmith 1y ago
    There's an implied assumption here that code you write yourself doesn't need to be reviewed from a context different from the author's. There's an old expression: "code as if your work will be read by a psychopath who knows where you live" followed by the joke "they know where you live because it is future you". Generative AI coding just forces the mindset you should have had all along: start with acceptance criteria, figure out how you're going to rigorously validate correctness (ideally through regression tests more than code reviews), and use the review process to come up with consistent practices (which you then document so that the LLM can refer to it). It's definitely not always faster, but waking up in the morning to a well documented PR, that's already been reviewed by multiple LLMs, with successfully passing test runs attached to it sure seems like I'm spending more of my time focused on what I should have been focused on all along.
• royal__ 1y ago
  I get confused when I see stances like this, because it gives me the sense that maybe people just aren't using coding tools efficiently. 90% of my usage of Copilot is just fancy autocomplete: I know exactly what I want, and as I'm typing out the line of code it finishes it off for me. Or, I have a rough idea of the syntax I need to use a specific package that I use once every few months, and it helps remind me what the syntax is, because once I see it I know it's right. This usage isn't really glamorous, but it does save me tiny bits of time in terms of literal typing, or a simple search I might need to do. Articles like this make me wonder if people who don't like coding tools are trying to copy and paste huge blocks of code; of course it's slower.
  • kibibu 1y ago
    My experience is that the "fancy autocomplete" is a focus destroyer. I know what function I want to write, start writing it, and then bam! The screen fills with ghost text that may partly be what I want but probably not quit. Focus shifts from writing to code review. I wrest my attention back to the task at hand, type some more, and bam! New ghost text to distract me. Ever had the misfortune of having a conversation with a sentence-finisher? Feels like that. Perhaps I need to bind to a hot key instead of using the default always-on setting. --- I suspect people using the agentic approaches skip this entirely and therefore have a more pleasant experience overall.
    • atq2119 1y ago
      It's fascinating how differently people's brains work. Autocomplete is a total focus destroyer for me when it comes to text, e.g. when writing a design document. When I'm editing code, it sometimes trips me up (hitting tab to indent but end up accepting a suggestion instead), but without destroying my focus. I believe your reported experience, but mine (and presumably many others') is different.
  • skydhash 1y ago
    That usage is the most disruptive for me. With normal intellisense and a library you're familiar with, you can predict the completion and just type normally with minimal interruption. With no completion, I can just touch type and fix the errors after the short burst. But having whole lines pop up break that flow state. With unfamiliar syntax, I only needs a few minutes and a cheatsheet to get back in the groove. Then typing go back to that flow state. Typing code is always semi-unconscious. Just like you don't pay that much attention to every character when you're writing notes on paper. Editing code is where I focus on it, but I'm also reading docs, running tests,...
• zmmmmm 1y ago
  I think there's a key context difference here in play which is that AI tools aren't better than an expert on the language and code base that is being written. But the problem is that most software isn't written by such experts. It's written by people with very hazy knowledge of the domain and only partial knowledge of the languages and frameworks they are using. Getting it to be stylistically consistent or 100% optimal is far from the main problem. In these contexts AI is a huge help, I find.
• handfuloflight 1y ago
  Will we be having these conversations for the next decade?
  • ken47 1y ago
    Longer.
  • adventured 1y ago
    The conversations will climb the ladder and narrow. Eventually: well, but, the AI coding agent isn't better than a top 10%/5%/1% software developer. And it'll be that the coding agents can't do narrow X thing better than a top tier specialist at that thing. The skeptics will forever move the goal posts.
    • jdbernard 1y ago
      If the AI actually outperforms humans in the full context of the work, then no, we won't. It will be so much cheaper and faster that businesses won't have to argue at all. Those that adopt them will massively outcompetes those that don't. However, assuming we are still having this conversation, that alone is proof to me that the AI is not that capable. We're several years into "replace all devs in six months." We will have to continue wait and see it try and do.
      • wiseowise 1y ago
        > If the AI actually outperforms humans in the full context of the work, then no, we won't. IDEs outperform any “dumb” editor in full context of work. You don’t see any less posts about “I use Vim, btw” (and I say this as Vim user).
        • jdbernard 1y ago
          You're getting down-voted, I think, because you're missing the point. I would argue that the "I use Vim, btw" articles are themselves proof that there are still people for whom Vim is actually more performant. Similarly, you don't see people being passed over in hiring because of editor choice because it does but less to consistent results. Compare to a hand saw. You still see them in specialty work and hobby shops, but you don't see them on construction sites. You see circular saws. Same with hammers. You'll probably still see them in job sites, but with far less usage than nail guns. And in many contexts nail guns have completely replaced hammers. There are still people griping about power tools but the industry doesn't care. I know a fair number of people in the trades and I can't imagine any of them seriously suggesting that you don't need to know how to use power tools. My argument is that, assuming AI fulfills the expectation of those who hype it (and that assumption has yet to be proven), we will see a similar effect in software. The results will speak for themselves and make the arguments irrelevant. That hasn't happened yet, leaving room for genuine debate.
• fshafique 1y ago
  "do not work for me", I believe, is the key message here. I think a lot of AI companies have crafted their tools such that adoption has increased as the tools and the output got better. But there will always be a few stragglers, non-normative types, or situations where the AI agent is just not suitable.
  • lexandstuff 1y ago
    Maybe, but there's also some evidence that AI coding tools aren't making anyone more productive. One study from last year found that there was no increase in developer velocity but a dramatic increase in bugs.[1] Granted, the technology has advanced since this study, but many of the fundamental issues of LLM unreliability remain. Additionally, a recent study has highlighted the significant cognitive costs associated with offloading problem-solving onto LLMs, revealing that individuals who do so develop significantly weaker neural connectivity than those who don't [2]. It's very possible that AI is literally making us less productive and dumber. Yet they are being pushed by subscription-peddling companies as if it is impossible to operate without them. I'm glad some people are calling it out. [1] https://devops.com/study-finds-no-devops-productivity-gains-from-generative-ai https://devops.com/study-finds-no-devops-productivity-gains-... [2] https://arxiv.org/abs/2506.08872 https://arxiv.org/abs/2506.08872
    • fshafique 1y ago
      One year ago I probably would've said the same. But I started dabbling with it recently, and I'm awed by it.
• frankc 1y ago
  I just don't agree with this. I am generally telling the model how to do the work according to an architecture I specify using technology I understand. The hardest part for me in reviewing someone else's code is understanding their overall solution and how everything fits together as it's not likely to be exactly the way I would have structured the code or solved the problem. However, with an LLM it generally isn't since we have pre-agreed upon a solution path. If that is not what is happening than likely you are letting the model get too far ahead. There are other times when I am building a stand-alone tool and am fine wiht whatever it wants to do because it's not something I plan to maintain and its functional correctness is self-evident. In that case I don't even review what it's doing unless it's stuck. This is more actual vibe code. This isn't something I would do for something I am integrating into a larger system but will for something like a cli tool that I use to enhance my workflow.
  • ken47 1y ago
    You can pre-agree on a solution path with human engineers too, with a similar effect.
    • bigbuppo 1y ago
      Don't try to argue with those using AI coding tools. They don't interact well with actual humans, which is why they've been relegated to talking to the computer. We'll eventually have them all working on some busy projects to help with "marketing" to keep them distracted while the decent programmers that can actually work in a team environment can get back to useful work free of the terrible programmers and marketing departments.
      • wiseowise 1y ago
        > that can actually work in a team environment can get back to useful work free of the terrible programmers Is that what you and your buddies talk about at two hour long coffee/smoke breaks while “terrible” programmers work?
        • 1y ago
• strangescript 1y ago
  Everyone is still thinking about this problem the wrong way. If you are still running one agent, on one project at a time, yes, its not going to be all that helpful if you are already a fast, solid coder. Run three, run five. Prompt with voice annotation. Run them when normally you need a cognitive break. Run them while you watch netflix on another screen. Have them do TDD. Use an orchestrator. So many more options. I feel like another problem is deep down most developers hate debugging other people's code and thats effectively what this is at times. It doesn't matter if your Associate ran off and saved you 50k lines of typing, you would still rather do it yourself than debug the code. I would give you grave warnings, telling you the time is nigh, adapt or die, etc, but it doesn't matter. Eventually these agents will be good enough that the results will surpass you even in simple one task at a time mode.
  • kibibu 1y ago
    I have never seen people work harder to dismantle their own industry than software engineers are right now.
    • strangescript 1y ago
      What exactly is the alternative? Wish it away? Developers have been automating away jobs for decades, its seems hypocritical to complain about it now.
      • hooverd 1y ago
        who gets the spoils?
    • marssaxman 1y ago
      We've been automating ourselves out of our jobs as long as we've had them; somehow, despite it all, we never run out of work to do.
      • kibibu 1y ago
        We've automated bullshit tedium work, like building and deploying, but this is the first time in my memory that people are actively trying to automate all the fun parts away. Closest parallel I can think of is the code-generation-from-UML era, but that explicitly kept the design decisions on the human side, and never really took over the world.
• bdamm 1y ago
  No offense intended, but this is written by a guy who has the spare time to write the blog. I can only assume his problem space is pretty narrow. I'm not sure what his workflow is like, but personally I am interacting with so many different tools, in so many different environments, with so many unique problem sets, that being able to use AIs for error evaluation, and yes, for writing code, has indeed been a game changer. In my experience it doesn't replace people at all, but they sure are powerful tools. Can they write unsupervised code? No. Do you need to read the code they write? Yes, absolutely. Can the AIs produce bugs that take time to find? Yes. But despite all that, the tools can find problems, get information, and propose solutions so much faster and across such a vast set of challenges that I simply cannot imagine going back to working without them. This fellow should keep on working without AIs. All the more power to him. And he can ride that horse all the way into retirement, most likely. But it's like ignoring the rise of IDEs, or Google search, or AWS.
  • ken47 1y ago
    > rise of IDEs, or Google search, or AWS. None of these things introduced the risk of directly breaking your codebase without very close oversight. If LLMs can surpass that hurdle, then we’ll all be having a different conversation.
    • bdamm 1y ago
      This is not the right way to look at it. You don't have to have the LLMs directly coding your work unsupervised to see the enormous power that is there. And besides, not all LLMs are the same when it comes to breaking existing functions. I've noticed that Claude 3.7 is far better at not breaking things that already work than whatever it is that comes with Cursor by default, for example.
    • stray 1y ago
      A human deftly wielding an LLM can surpass that hurdle. I laugh at the idea of telling Claude Code to do the needful and then blindly pushing to prod.
    • wiseowise 1y ago
• skydhash 1y ago
  I do agree with these points in my situation. I don't actually care for speed or having generated snippets for unfamiliar domains. Coding for me has always be about learning. Whether I'm building out a new feature or solving a bug, programming is always a learning experience. The goal is to bring forth a solution that a computer can then perform, but in the process you learn about how and more importantly why you should solve a problem. The concept of why can get nebulous in a corporate setting, but it's nevertheless fun to explore. At the end of the day, someone have a problem and you're the one getting the computer to solve it. The process of getting there is fun in a way that you learn about what irks someone else (or yourself). Thinking about the problem and its solution can be augmented with computers (I'm not remembering Go Standard Library). But computers are simple machines with very complex abstractions built on top of them. The thrill is in thinking in terms of two worlds, the real one where the problem occurs and the computing one where the solution will come forth. The analogy may be more understandable to someone who've learned two or more languages and think about the nuances between using them to depict the same reality. Same as the TFA, I'm spending most of my time manipulating a mental model of the solution. When I get to code is just a translation. But the mental model is difuse, so getting it written gives it a firmer existence. LLMs generation is mostly disrupting the process. The only way they help really is a more pliable form of Stack Overflow, but I've only used Stack Overflow as human-authored annotations of the official docs.
• waprin 1y ago
  To some degree, traditional coding and AI coding are not the same thing, so it's not surprising that some people are better at one than the other. The author is basically saying that he's much better at coding than AI coding. But it's important to realize that AI coding is itself a skill that you can develop. It's not just , pick the best tool and let it go. Managing prompts and managing context has a much higher skill ceiling than many people realize. You might prefer manual coding, but you might just be bad at AI coding and you might prefer it if you improved at it. With that said, I'm still very skeptical of letting the AI drive the majority of the software work, despite meeting people who swear it works. I personally am currently preferring "let the AI do most of the grunt work but get good at managing it and shepherding the high level software design". It's a tiny bit like drawing vs photography and if you look through that lens it's obvious that many drawers might not like photography.
  • dingnuts 1y ago
    > You might prefer manual coding, but you might just be bad at AI coding and you might prefer it if you improved at it. ok but how much am I supposed to spend before I supposedly just "get good"? Because based on the free trials and the pocket change I've spent, I don't consider the ROI worth it.
    • goalieca 1y ago
      And how often do your prompting skills change as the models evolve.
    • stray 1y ago
      You're going to spend a little over $1k to ramp up your skills with AI-aided coding. It's dirt cheap in the grand scheme of things.
      • dingnuts 1y ago
        do I get a refund if I spend a grand and I'm still not convinced? at some point I'm going to start lying to myself to justify the cost and I don't know how much y'all earn but $1k is getting close
• roxolotl 1y ago
  > But interns learn and get better over time. The time that you spend reviewing code or providing feedback to an intern is not wasted, it is an investment in the future. The intern absorbs the knowledge you share and uses it for new tasks you assign to them later on. This is the piece that confuses me about the comparison to a junior or an intern. Humans learn about the business, the code, the history of the system. And then they get better. Of course there’s a world where agents can do that, and some of the readme/doc solutions do that but the limitations are still massive and so much time is spent reexplaining the business context.
  • freeone3000 1y ago
    Put the business context in the system prompt.
  • xarope 1y ago
    I think this is how certain LLMs end up with 14k worth of system prompts
    • Terr_ 1y ago
      "Be fast", "Be Cheap", "Be Good". *dusts off hands* Problem solved! Man, am I great at management or what?
  • viraptor 1y ago
    You don't have to reexplain the business context. Save it to the mdc file if it's important. The added benefit is that the next real person looking at the code can also use that to learn - it's actually cool for having good up to date documentation is now an asset.
    • adastra22 1y ago
      Do you find your agent actually respecting the mdc file? I don’t.
      • 1y ago
• ed_mercer 1y ago
  > It takes me at least the same amount of time to review code not written by me than it would take me to write the code myself, if not more. Hard disagree. It's still way faster to review code than to manually write it. Also the speed at which agents can find files and the right places to add/edit stuff alone is a game changer.
  • __loam 1y ago
    You are probably not being thorough enough.
  • Winsaucerer 1y ago
    There's a difference between reviewing code by developers you trust, and reviewing code by developers you don't trust or AI you don't trust. Although tbh, even in the worse case I think I am still faster at reviewing than writing. The only difference is though, those reviews will never have had the same depth of thought and consideration as when I write the code myself. So reviews are quicker, but also less thorough/robust than writing for me.
    • bluefirebrand 1y ago
      > also less thorough/robust than writing for me. This strikes me as a tradeoff I'm absolutely not willing to make, not when my name is on the PR
  • sensanaty 1y ago
    I'm fast at reviewing PRs because I know the person on the other end and can trust that they got things correctly. I'll focus on the meaty, tricky parts of their PR, but I can rest assured that they matched the design, for example, and not have to verify every line of CSS they wrote. This is a recipe for disaster with AI agents. You have to read every single line carefully, and this is much more difficult for the large majority of people out there than if you had written it yourself. It's like reviewing a Junior's work, except I don't mind reviewing my Junior colleague's work because I know they'll at least learn from the mistakes and they're not a black box that just spews bullshit.
• satisfice 1y ago
  Thank you for writing what I feel and experience, so that I don't have to. Which is kind of like if AI wrote it: except someone is standing behind those words.
• deleted 1y ago
  [deleted]
• block_dagger 1y ago
  > For every new task this "AI intern" resets back to square one without having learned a thing! I guess the author is not aware of Cursor rules, AGENTS.md, CLAUDE.md, etc. Task-list oriented rules specifically help with long term context.
  • stray 1y ago
    You can lead a horse to the documentation, but you can't make him think.
    • wiseowise 1y ago
      Think is means to an end, not the end goal. Or are you talking about OP not knowing AI tools enough?
      • stray 1y ago
        The word "think" rhymes with "drink." The saying is, "You can lead a horse to water, but you can't make him drink." I intended no more profound meaning than that. A quip. Nothing more.
  • adastra22 1y ago
    Do they? I have found that with Cursor at least, the model very quickly starts ignoring rules.
• Mila-Cielo 1y ago
  [dead]
• hooverd 1y ago
  The moat is that juniors, never having worked without these tools, provide revenue to AI middlemen. Ideally they're blasting their focus to hell on short form video and stimulants, and are mentally unable to do the job without them.
  • Terr_ 1y ago
    Given some the creeping appeal of LLMs as cheating tools in education, some of them may be arriving in the labor market with their brains already cooked.
• deleted 1y ago
  [deleted]
• danieltanfh95 1y ago
  AI models are fundamentally trained on patterns from existing data - they learn to recognize and reproduce successful solution templates rather than derive solutions from foundational principles. When faced with a problem, the model searches for the closest match in its training experience rather than building up from basic assumptions and logical steps. Human experts excel at first-principles thinking precisely because they can strip away assumptions, identify core constraints, and reason forward from fundamental truths. They might recognize that a novel problem requires abandoning conventional approaches entirely. AI, by contrast, often gets anchored to what "looks similar" and applies familiar frameworks even when they're not optimal. Even when explicitly prompted to use first-principles analysis, AI models can struggle because: - They lack the intuitive understanding of when to discard prior assumptions - They don't naturally distinguish between surface-level similarity and deep structural similarity - They're optimized for confident responses based on pattern recognition rather than uncertain exploration from basics This is particularly problematic in domains requiring genuine innovation or when dealing with edge cases where conventional wisdom doesn't apply. Context poisoning, intended or not, is a real problem that humans are able to solve relatively easily while current SotA models struggle.
  • adastra22 1y ago
    So are people. People are trained on existing data and learn to reproduce known solutions. They also take this to the meta level—a scientist or engineer is trained on methods for approaching new problems which have yielded success in the past. AI does this too. I’m not sure there is actually a distinction here..
    • danieltanfh95 1y ago
      Of course there is. Humans can pattern match as a means to save time. LLM pattern match as the only mode of communication and “thought”. Humans are also not as susceptible to context poisoning, unlike llms.
      • adastra22 1y ago
        Human thought is associative (pattern matching) as well. This is very well established.
• lexandstuff 1y ago
  Great article. The other thing that you miss out on when you don't write the code yourself is that sense of your subconscious working for you. Writing code has a side benefit of developing a really strong mental model of a problem, that kinda gets embedded in your neurons and pays dividends down the track, when doing stuff like troubleshooting or deciding on how to integrate a new feature. You even find yourself solving problems in your sleep. I haven't observed any software developers operating at even a slight multiplier from the pre-LLM days at the organisations I've worked at. I think people are getting addicted to not having to expend brain energy to solve problems, and they're mistaking that for productivity.
  • Mentlo 1y ago
    There’s software domains where there’s very little work past solving the business problem. And there’s software domains where once you’ve architected the solution, there isn’t much problem solving to continue, there’s just a long slog of stuff to write. The later is not making any neuron embedding tradeoff when they hand of the slog to agents. There’s a lot of software development in that latter category.
  • nerevarthelame 1y ago
    > I think people are getting addicted to not having to expend brain energy to solve problems, and they're mistaking that for productivity. I think that's a really elegant way to put it. Google Research tried to measure LLM impacts on productivity in 2024 [1]. They gave their subjects an exam and assigned them different resources (a book versus an LLM). They found that the LLM users actually took more time to finish than those who used a book, and that only novices on the subject material actually improved their scores when using an LLM. But the participants also perceived that they were more accurate and efficient using the LLM, when that was not the case. The researchers suggested that it was due to "reduced cognitive load" - asking an LLM something is easy and mostly passive. Searching through a book is active and can feel more tiresome. Like you said: people are getting addicted to not having to expend brain energy to solve problems, and mistaking that for productivity. [1] https://storage.googleapis.com/gweb-research2023-media/pubtools/7713.pdf https://storage.googleapis.com/gweb-research2023-media/pubto...
• p1dda 1y ago
  It would be interesting to see which is faster/better in competitive coding, the human coder or the human using AI to assist in coding.
  • asciimov 1y ago
    It would only be interesting if the problem was truly novel. If the AI has already been trained on the problem it’ll just push out a solution.
  • wiseowise 1y ago
    It already happened. Last year AI submissions completely destroyed AoC, as far as I remember.
  • Snuggly73 1y ago
    New benchmark for competitive coding dropped yesterday - https://livecodebenchpro.com/ https://livecodebenchpro.com/ Apparently models are not doing great for problems out of distribution.
    • p1dda 1y ago
      It goes to show that the LLMs aren't intelligent in the way humans are. LLMs are a really great replacement for googling though
• karl11 1y ago
  There is an important concept alluded to here around skin in the game: "the AI is not going to assume any liability if this code ever malfunctions" -- it is one of the issues I see w/ self-driving cars, planes, etc. If it malfunctions, there is no consequence for the 'AI' (no skin in the game) but there are definitely consequences for any humans involved.
• sneak 1y ago
  It’s harder to read code than it is to write it, that’s true. But it’s also faster to read code than to write it. And it’s faster to loop a prompt back to fixed code to re-review than to write it.
  • AlotOfReading 1y ago
    I've written plenty of code that's much faster to write than to read. Most dense, concise code will require a lot more time building a mental model to read than it took to turn that mental model into code in the first place.
• sagarpatil 1y ago
  What really baffles me is the claims from: Anthropic: 80% of the code is generated by AI OpenAI: 70-80% Google/Microsoft: 30%
  • nojs 1y ago
    This does not contradict the article - it may be true, and yet not significantly more productive, because of the increased review burden.
  • root_axis 1y ago
    The use of various AI coding tools is so diffuse that there isn't even a practical way to measure this. You can be assured those numbers are more or less napkin math based on some arbitrary AI performance factor applied to the total code writing population of the company.
  • layer8 1y ago
    Microsoft and Google have the much larger and older code bases.
• dvt 1y ago
  I'm actually quite bearish on AI in the generative space, but even I have to admit that writing boilerplate is "N" times faster using AI (use your favorite N). I hate when people claim this without any proof, so literally today this is what I asked ChatGPT: write a stub for a react context based on this section (which will function as a modal): ``` <section> // a bunch of stuff </section> ``` Worked great, it created a few files (the hook, the provider component, etc.), and I then added them to my project. I've done this a zillion times, but I don't want to do it again, it's not interesting to me, and I'd have to look up stuff if I messed it up from memory (which I likely would, because provider/context boilerplate sucks). Now, I can just do `const myModal = useModal(...)` in all my components. Cool. This saved me at least 30 minutes, and 30 minutes of my time is worth way more than 20 bucks a month. (N.B.: All this boilerplate might be a side effect of React being terrible, but that's beside the point.)
  • Winsaucerer 1y ago
    This kind of thing is my main use, boilerplate stuff And for scripts that I don't care about -- e.g., if I need a quick bash script to do a once off task. For harder problems, my experience is that it falls over, although I haven't been refining my LLM skills as much as some do. It seems that the bigger the project, the more it integrates with other things, the worse AI is. And moreover, for those tasks it's important for me or a human to do it because (a) we think about edge cases while we work through the problem intellectually, and (b) it gives us a deep understanding of the system.
  • skydhash 1y ago
    For this case, i will probably lift off the example from the library docs. Or spend 5 minutes writing a bare implementation as it would be all I need at the time. That’s an issue I have with generated code. More often, I start with a basic design that evolves based on the project needs. It’s an iterative process that can span the whole timeline. But with generated code, it’s a whole solution that fits the current needs, but it’s a pain to refactor.
    • dvt 1y ago
• dpcan 1y ago
  This article is just simply not true for most people who have figured out how to use AI properly when coding. Since switching to Cursor, my coding speed and efficiency has probably increased 10x conservatively. When I'm using it to code in languages I've used for 25+ years, it's a breeze to look over the function it just saved me time by pre-thinking and typing it out for me. Could I have done it myself, yeah, but it would have taken longer if I even had to go lookup one tiny thing in the documentation, like order of parameters for a function, or that little syntax thing I never use... Also, the auto-complete with tools like Cursor are mind blowing. When I can press tab to have it finish the next 4 lines of a prepared statement, or it just knows the next 5 variables I need to define because I just set up a function that will use them.... that's a huge time saver when you add it all up. My policy is simple, don't put anything AI creates into production if you don't understand what it's doing. Essentially, I use it for speed and efficiency, not to fill in where I don't know at all what I'm doing.
  • asciimov 1y ago
    Out of curiosity how much are you spending on AI? How much do you believe a programmer needs to layout to “get good”?
    • epiccoleman 1y ago
      I am currently subscribed to Claude Pro, which is $20/mo and gives you plenty to experiment with by giving you access to Projects and MCP in Claude Desktop and also Claude Code for a flat monthly fee. (I think there are usage limits but I haven't hit them). I've probably fed $100 in API tokens into the OpenAI and Anthropic consoles over the last two years or so. I was subscribed to Cursor for a while too, though I'm kinda souring on it and looking at other options. At one point I had a ChatGPT pro sub, I have found Claude more valuable lately. Same goes for Gemini, I think it's pretty good but I haven't felt compelled to pay for it. I guess my overall point is you don't have to break the bank to try this stuff out. Shell out the $20 for a month, cancel immediately, and if you miss it when it expires, resub. $20 is frankly a very low bar to clear - if it's making me even 1% more productive, $20 is an easy win.
    • 1y ago
• b0a04gl 1y ago
  [dead]
• euleriancon 1y ago
  > The truth that may be shocking to some is that open source contributions submitted by users do not really save me time either, because I also feel I have to do a rigorous review of them. This truly is shocking. If you are reviewing every single line of every package you intend to use how do you ever write any code?
  • abenga 1y ago
    You do not need to review every line of every package you use, just the subset of the interface you import/link and use. You have to review every line of code you commit into your project. I think attempting to equate the two is dishonest dissembling.
    • euleriancon 1y ago
      To me, the point the friend is making is, just like you said, that you don't need to review every line of code in a package, just the interface. The author misses the point that there truly is code that you trust without seeing it. At the moment AI code isn't as trustworthy as a well tested package but that isn't intrinsic to the technology, just a byproduct of the current state. As AI code becomes more reliable, it will likely become the case that you only need to read the subset of the interface you import/link and use.
      • root_axis 1y ago
        > At the moment AI code isn't as trustworthy as a well tested package but that isn't intrinsic to the technology, just a byproduct of the current state This remains to be seen. It's still early days, but self-attention scales quadratically. This is a major red flag for the future potential of these systems.
      • bluefirebrand 1y ago
        This absolutely is intrinsic to the workflow Using a package that hundreds of thousands of other people use is low risk, it is battle tested It doesn't matter how good AI code gets, a unique solution that no one else has ever touched is always going to be more brittle and risky than an open source package with tons of deployments And yes, if you are using an Open Source package that has low usage, you should be reviewing it very carefully before you embrace it Treat AI code as if you were importing from a git repo with 5 installs, not a huge package with Mozilla funding
• kachapopopow 1y ago
  AI is a tool like any other, you have to learn to use it. I had AI create me a k8s device plugin for supporting sr-iov only vGPU's. Something nvidia calls "vendor specific" and basically offers little to not support for in their public repositories for Linux KVM. I loaded up a new go project in goland, opened up Junie, typed what I needed and what I have, went to make tea, came back, looked over the code to make sure it wasn't going to destroy my cluster (thankfully most operations were read-only), deployed it with the generated helm chart and it worked (nearly) first try. Before this I really had no idea how to create device plugins other than knowing what they are and even if I did, it would have easily taken me an hour or more to have something working. The only thing AI got wrong is that the virtual functions were symlinks and not directories. The entire project is good enough that I would consider opensourcing it. With 2 more prompts I had configmap parsing to initialize virtual functions on-demand.
  • Drunkfoowl 1y ago
    [dead]
• marssaxman 1y ago
  So far as I can tell, generative AI coding tools make the easy part of the job go faster, without helping with the hard part of the job - in fact, possibly making it harder. Coding just doesn't take that much time, and I don't need help doing it. You could make my coding output 100x faster without materially changing my overall productivity, so I simply don't bother to optimize there.
  • Jonovono 1y ago
    Are you a plumber perhaps?
    • worik 1y ago
      I am. That is the mental model I have for the work (computer programing) i like to do and am good at. Plumbing
      • Jonovono 1y ago
        I like it!
    • kevinventullo 1y ago
      I’m not sure I follow the question. I think of plumbing as being the exact kind of verbose boilerplate that LLM’s are quite good at automating. In contrast, when I’m trying to do something truly novel, I might spend days with a pen and paper working out exactly what I want to do and maybe under an hour coding up the core logic. On the latter type of work, I find LLM’s to be high variance with mostly negative ROI. I could probably improve the ROI by developing a better sense of what they are and aren’t good at, but of course that itself is rapidly changing!
    • marssaxman 1y ago
      Not if I can help it, no; I don't have the patience.
  • resource_waste 1y ago
    I have it write algorithms, explain why my code isnt working, write API calls, or make specific functions. The entire code? Not there, but with debuggers, I've even started doing that a bit.
• worik 1y ago
  There are tasks I find AI (I use DeepSeek) useful for I have not found it useful for large programming tasks. But for small tasks, a sort of personalised boiler plate, I find it useful
• nreece 1y ago
  Heard someone say the other day "AI coding is just advanced scaffolding right now." Made me wonder if we're expecting too much out of it, at-least for now.
• tptacek 1y ago
  I'm fine with anybody saying AI agents don't work for their work-style and am not looking to rebut this piece, but I'm going to take this opportunity to call something out. The author writes "reviewing code is actually harder than most people think. It takes me at least the same amount of time to review code not written by me than it would take me to write the code myself". That sounds within an SD of true for me, too, and I had a full-time job close-reading code (for security vulnerabilities) for many years. But it's important to know that when you're dealing with AI-generated code for simple, tedious, or rote tasks --- what they're currently best at --- you're not on the hook for reading the code that carefully, or at least, not on the same hook. Hold on before you jump on me. Modern Linux kernels allow almost-arbitrary code to be injected at runtime, via eBPF (which is just a C program compiled to an imaginary virtual RISC). The kernel can mostly reliably keep these programs from crashing the kernel. The reason for that isn't that we've solved the halting problem; it's that eBPF doesn't allow most programs at all --- for instance, it must be easily statically determined that any backwards branch in the program runs for a finite and small number of iterations. eBPF isn't even good at determining that condition holds; it just knows a bunch of patterns in the CFG that it's sure about and rejects anything that doesn't fit. That's how you should be reviewing agent-generated code, at least at first; not like a human security auditor, but like the eBPF verifier. If I so much as need to blink when reviewing agent output, I just kill the PR. If you want to tell me that every kind of code you've ever had to review is equally tricky to review, I'll stipulate to that. But that's not true for me. It is in fact very easy to me to look at a rote recitation of an idiomatic Go function and say "yep, that's what that's supposed to be".
  • kenjackson 1y ago
    I can read code much faster than I can write it. This might be the defining line for Gen AI - people who can read code faster will find it useful and those that write faster then they can read won’t use it.
    • autobodie 1y ago
      I think that's wrong. I only have to write code once, maybe twice. But when using AI agents, I have to read many (5? 10? I will always give up before 15) PRs before finding one close enough that I won't have to rewrite all of it. This nonsense has not saved me any time, and the process is miserable. I also haven't found any benefit in aiming for smaller or larger PRs. The aggregare efficiency seems to even out because smaller PRs are easier to weed through but they are not less likely to be trash.
• afarviral 1y ago
  This has been my experience as well, but there are plenty of assertions here that are not always true, e.g. "AI coding tools are sophisticated enough (they are not) to fix issues in my projects" … but how do you know this if you are not constantly checking whether the tooling has improved? I think for a certain level of issue AI can tackle it and improve things, but there's only a subset of the available models and of a multitude of workflows that will work well, but unfortunately we are drowning in many that are mediocre at best and many like me give up before finding the winning combination.
  • layer8 1y ago
    You omitted “with little or no supervision”, which I think is crucial to that quote. It’s pretty undisputed that having an AI fix issues in your code requires some amount of supervision that isn’t negligible. I.e. you have to review the fixes, and possibly make some adjustments.
• bilalq 1y ago
  I've found "agents" to be an utter disappointment in their current state. You can never trust what they've done and need to spend so much time verifying their solution that you may as well have just done it yourself in the first place. However, AI code reviewers have been really impressive. We run three separate AI reviewers right now and are considering adding more. One of these reviewers is kind of noisy, so we may drop it, but the others have been great. Sure, they have false positives sometimes and they don't catch everything. But they do catch real issues and prevent customer impact. The Copilot style inline suggestions are also decent. You can't rely on it for things you don't know about, but it's great at predicting what you were going to type anyway.
• andrewstuart 1y ago
  He’s saying it’s not faster because he needs to impose his human analysis on it which is slow. That’s fine, but it’s an arbitrary constraint he chooses, and it’s wrong to say AI is not faster. It is. He just won’t let it be faster. Some won’t like to hear this, but no-one reviews the machine code that a compiler outputs. That’s the future, like it or not. You can’t say compilers are slow because I add on the time I take to Analyse the machine code. That’s you being slow.
  • bluefirebrand 1y ago
    > no-one reviews the machine code that a compiler outputs That's because compilers are generally pretty trustworthy. They aren't necessarily bug free, and when you do encounter compiler bugs it can be extremely nasty, but mostly they just work If compilers were wrong as often as LLMs are, we would be reviewing machine code constantly
  • purerandomness 1y ago
    A compiler produces the same, deterministic output, every single time. A stochastic parrot can never be trusted, let alone one that tweaks its model every other night. I totally get that not all code ever written needs to be correct. Some throw-away experiments can totally be one-shot by AI, nothing wrong with that. Depending on the industry one works in, people might be on different points of the expectation spectrum for correctness, and so their experience with LLMs vary. It's the RAD tool discussion of the 2000s, or the "No-Code" tools debate of the last decade, all over again.
• didibus 1y ago
  You could argue that AI-generated code is a black box, but let's adjust our perspective here. When was the last time you thoroughly reviewed the source code of a library you imported? We already work with black boxes daily as we evaluate libraries by their interfaces and behaviors, not by reading every line. The distinction isn't whether code comes from AI or humans, but how we integrate and take responsibility for it. If you're encapsulating AI-generated code behind a well-defined interface and treating it like any third party dependency, then testing that interface for correctness is a reasonable approach. The real complexity arises when you have AI help write code you'll commit under your name. In this scenario, code review absolutely matters because you're assuming direct responsibility. I'm also questioning whether AI truly increases productivity or just reduces cognitive load. Sometimes "easier" feels faster but doesn't translate to actual time savings. And when we do move quicker with AI, we should ask if it's because we've unconsciously lowered our quality bar. Are we accepting verbose, oddly structured code from AI that we'd reject from colleagues? Are we giving AI-generated code a pass on the same rigorous review process we expect for human written code? If so, would we see the same velocity increases from relaxing our code review process amongst ourselves (between human reviewers)?
  • bluefirebrand 1y ago
    > When was the last time you thoroughly reviewed the source code of a library you imported? Doesn't matter, I'm not responsible for maintaining that particular code The code in my PRs has my name attached, and I'm not trusting any LLM with my name
    • didibus 1y ago
      Exactly, that's what I'm saying. Commit AI code under its own name. Then the code under your name can use the AI code as a black box. If your code that uses AI code works as expected, it is similar to when using libraries. If you consider that AI code is not code any human needs to read or later modify by hand, AI code is modified by AI. All you want to do is just fully test it, if it all works, it's good. Now you can call into it from your own code.
• globnomulous 1y ago
  Decided to post my comment here rather than on the author's blog. Dang and tonhow, if the tone is too personal or polemical, I apologize. I don't think I'm breaking any HN rules. Commenter Doug asks: > > what AI coding tools have you utilized Miguel replies: > I don't use any AI coding tools. Isn't that pretty clear after reading this blog post? Doug didn't ask what tools you use, Miguel. He asked which tools you have used. And the answer to that question isn't clear. Your post doesn't name the ones you've tried, despite using language that makes clear you that you have in fact used them (e.g. "my personal experience with these tools"). Doug's question isn't just reasonable. It's exactly the question an interested, engaged reader will ask, because it's the question your entire post begs. I can't help but point out the irony here: you write a great deal on the meticulousness and care with which you review other people's code, and criticize users of AI tools for relaxing standards, but the AI-tool user in your comments section has clearly read your lengthy post more carefully and thoughtfully than you read his generous, friendly question. And I think it's worth pointing out that this isn't the blog post's only head scratcher. Take the opening: > People keep asking me If I use Generative AI tools for coding and what I think of them, so this is my effort to put my thoughts in writing, so that I can send people here instead of having to repeat myself every time I get the question. Your post never directly answers either question. Can I infer that you don't use the tools? Sure. But how hard would it be to add a "no?" And as your next paragraph makes clear, your post isn't "anti" or "pro." It's personal -- which means it also doesn't say much of anything about what you actually think of the tools themselves. This post won't help the people who are asking you whether you use the tools or what you think of them, so I don't see why you'd send them here. > my personal experience with these tools, from a strictly technical point of view > I hope with this article I've made the technical issues with applying GenAI coding tools to my work clear. Again, that word: "clear." No, the post not only doesn't make clear the technical issues; it doesn't raise a single concern that I think can properly be described as technical. You even say in your reply to Doug, in essence, that your resistance isn't technical, because for you the quality of an AI assistant's output doesn't matter. Your concerns, rather, are practical, methodological, and to some extent social. These are all perfectly valid reasons for eschewing AI coding assistants. They just aren't technical -- let alone strictly technical. I write all of this as a programmer who would rather blow his own brains out, or retire, than cede intellectual labor, the thing I love most, to a robot -- let alone line the pockets of some charlatan 'thought leader' who's promising to make a reality of upper management's dirtiest wet dream: in essence, to proletarianize skilled work and finally liberate the owners of capital from the tyranny of labor costs. I also write all of this, I guess, as someone who thinks commenter Doug seems like a way cool guy, a decent chap who asked a reasonable question in a gracious, open way and got a weirdly dismissive, obtuse reply that belies the smug, sanctimonious hypocrisy of the blog post itself. Oh, and one more thing: AI tools are poison. I see them as incompatible with love of programming, engineering quality, and the creation of safe, maintainable systems, and I think they should be regarded as a threat to the health and safety of everybody whose lives depend on software (all of us), not because of the dangers of machine super intelligence but because of the dangers of the complete absence of machine intelligence paired with the seductive illusion of understanding.
• animex 1y ago
  I write mostly boilerplate and I'd rather have the AI do it. The AI is also slow, which is great, which allows me to run 2 or 3 AI workspaces working on different tickets/problems at the same time. Where AI especially excels is helping me do maintenance tickets on software I rarely touch (or sometimes never have touched). It can quickly read the codebase, and together we can quickly arrive at the place where the patch/problem lies and quickly correct it. I haven't written anything "new" in terms of code in years, so I'm not really learning anything from coding manually but I do love solving problems for my customers.
• edg5000 1y ago
  A huge bottleneck seems the lack of memory between sessions, at least with Claude Code. Sure, I can write things into a text file, but it's not the same as having an AI actually remember the work done earlier. Is this possible in any way today? Does one need to use Llama or DeepSeek, and do we have to run it on our own hardware to get persistence?
• nurettin 1y ago
  I simply don't like the code it writes. Whenever I try using llms, it is like wrestling for conciseness. Terrible code which is almost certainly 1/10 error or "extras" I don't need. At this point I am simply using it to motivate me to move forward. Writing a bunch of orm code feels boring? I make it generate the code and edit. Importing data? I just make it generate inserts. New models are good at reformatting data. Using a third party Library? I force it to look up every function doc online and it still has errors. Adding transforms and pivots to sql while keeping to my style? It is a mess. Forget it. I do that by hand.
• edg5000 1y ago
  It's a bit like going from assembly to C++, except we don't have good rigid rules for high-level program specification. If we had a rigid "high-level language" to express programs, orders or magnitude more high-level than C++ and other, than we could maybe evaluate it for correctness and get 100% output reliability, perhaps. All the languages I picked up, I picked them up when they were at least 10 years old. I'm trying to use AI a bit these days for programming, but it feels like what it must have felt like using C++ when it just came available; promising but not usable (yet?) for most programming situations.
• socalgal2 1y ago
  > Another common argument I've heard is that Generative AI is helpful when you need to write code in a language or technology you are not familiar with. To me this also makes little sense. I'm not sure I get this one. When I'm learning new tech I almost always have questions. I used to google them. If I couldn't find an answer I might try posting on stack overflow. Sometimes as I'm typing the question their search would finally kick in and find the answer (similar questions). Other times I'd post the question, if it didn't get closed, maybe I'd get an answer a few hours or days later. Now I just ask ChatGPT or Gemini and more often than not it gives me the answer. That alone and nothing else (agent modes, AI editing or generating files) is enough to increase my output. I get answers 10x faster than I used to. I'm not sure what that has to do with the point about learning. Getting answers to those question is learning, regardless of where the answer comes from.
  • socalgal2 1y ago
    To add, another experience I had. I was using an API I'm not that familiar with. My program was crashing. Looking at the stack trace I didn't see why. Maybe if I had many months experience with this API it would be obvious but it certainly wasn't to me. For fun I just copy and pasted the stack trace into Gemini. ~60 frames worth of C++. It immediately pointed out the likely cause given the API I was using. I fixed the bug with a 2 line change once I had that clue from the AI. That seems pretty useful to me. I'm not sure how long it would have taken me to find it otherwise since, as I said, I'm not that familiar with that API.
    • nottorp 1y ago
      You remember when Google used to do the same thing for you way before "AI"? Okay, maybe sometimes the post about the stack trace was in Chinese, but a plain search used to be capable of giving the same answer as a LLM. It's not that LLMs are better, it's search that got entshittified.
      • Philpax 1y ago
        Google has never identified the logical error in a block of code for me. I could find what an error code was, yes, but it's of very little help when you don't have a keyword to search.
• joelthelion 1y ago
  I think it's getting clear that, in the current stage, Ai coding agent are mostly useful for people working either on small projects, or isolated new features. People who maintain a large framework find it less useful.
• aryehof 1y ago
  These days, many programmers and projects are happy to leave testing and defect discovery to end users, under the guise of “but we have unit tests and CI”. That’s exacerbated when using LLM driven code with abandon. The author is one who appears unwilling to do so.
• Zaylan 1y ago
  I've had a similar experience. These tools are pretty helpful for small scripts or quick utility code, but once you're working on something with a more complex structure and lots of dependencies, they tend to slow down. Sometimes it takes more effort to fix what they generate than to just write it myself. I still use them, but more as a support tool than a real assistant.
  • deleted 1y ago
    [deleted]
• Aeolun 1y ago
  > The part that I enjoy the most about working as a software engineer is learning new things, so not knowing something has never been a barrier for me. To me the part I enjoy most is making things. Typing all that nonsense out is completely incidental to what I enjoy about it.
• pSYoniK 1y ago
  I've been reading these posts for the past few months and the comments too. I've tried Junie a bit and I've used ChatGPT in the past for some bash scripts (which, for the most part, did what they were supposed to do), but I can't seem to find the use case. Using them for larger bits of code feels silly as I find subtle bugs or subtle issues in places, so I don't necessarily feel comfortable passing in more things. Also, large bits of code I work with are very business logic specific and well abstracted, so it's hard to try and get ALL that context into the agent. I guess what I'm trying to ask here is what exactly do you use agents for? I've seen youtube videos but a good chunk of those are people getting a bunch of typescript generated and have some front-end or generate some cobbled together front end that has Stripe added in and everyone is celebrating as if this is some massive breakthrough. So when people say "regular tasks" or "rote tasks" what do you mean? You can't be bothered to write a db access method/function using some DB access library? You are writing the same regex testing method for the 50th time? You keep running into the same problem and you're still writing the same bit of code over and over again? You can't write some basic sql queries? Also not sure about others, but I really dislike having to do code reviews when I am unable to really gauge the skill of the dev I'm reviewing. If I know I have a junior with 1-2 years maybe, then I know to focus a lot on logic issues (people can end up cobbling toghether the previous simple bits of code) and if it's later down the road at 2-5 years then I know that I might focus on patterns or look to ensure that the code meets the standards, look for more discreet or hidden bugs. With an agent output it could oscilate wildly between those. It could be a solidly written search function, well optimized or it could be a nightmarish sql querry that's impossible to untangle. Thoughts? I do have to say I found it good when working on my own to get another set of "eyes" and ask things like "are there more efficient ways to do X" or "can you split this larger method into multiple ones" etc
• cinbun8 1y ago
  As someone who heavily utilizes AI for writing code, I disagree with all the points listed. AI is faster, a multiplier, and in many instances, the equivalent of an intern. Perhaps the code it writes is not like the code written by humans, but it serves as a force multiplier. Cursor makes $500 million for a reason.
• jpcrs 1y ago
  I use AI daily, currently paying for Claude Code, Gemini and Cursor. It really helps me on my personal toy projects, it’s amazing at getting a POC running and validate my ideas. My company just had internal models that were mediocre at best, but at the beginning this year they finally enabled Copilot for everyone. At the beginning I was really excited for it, but it’s absolutely useless for work. It just doesn’t work on big old enterprise projects. In an enterprise environment everything is composed of so many moving pieces, knowledge scattered across places, internal terminology, etc. Maybe in the future, with better MCP servers or whatever, it’ll be possible to feed all the context into it to make it spit something useful, but right now, at work, I just use AI as search engine (and it’s pretty good at it, when you have the knowledge to detect when it have subtle problems)
  • HPsquared 1y ago
    I think a first step for these big enterprise codebases (also applicable to documentation) is to collect it into a big ball and finetune on it.
• Kiro 1y ago
  > I believe people who claim that it makes them faster or more productive are making a conscious decision to relax their quality standards to achieve those gains. Yep, this is pretty much it. However, I honestly feel that AI writes so much better code than me that I seldom need to actually fix much in the review, so it doesn't need to be as thorough. AI always takes more tedious edge-cases into account and applies best practices where I'm much sloppier and take more shortcuts.
• noiv 1y ago
  I've started to finish some abandoned half-ready side projects with Claude Pro on Desktop with filesystem MCP. Used to high quality code, it took me some time to teach Claude to follow conventions. Now it works like a charm, we work on a requirements.md until all questions are answered and then I let Claude go. Only thing left is convincing clients to embrace code assistents.
• nottorp 1y ago
  > The problem is that I'm going to be responsible for that code, so I cannot blindly add it to my project and hope for the best. Responsability and "AI" marketing are two non intersecting sets.
• s_ting765 1y ago
  Author makes very good points. Someone has to be responsible for the AI generated code, and if it's not going to be you then no one should feel obligated to pull the auto-generated PR.
• blueboo 1y ago
  Skeptics find Talking themselves out of trying them is marvellously effective for convincing themselves they’re right
• nilirl 1y ago
  The main claim made: When there's money or reputation to be lost, code requires the same amount of cognition; irrespective of who wrote the code, AI or not. Best counter claim: Not all code has the same risk. Some code is low risk, so the risk of error does not detract from the speed gained. For example, for proof of concepts or hobby code. The real problem: Disinformation. Needless extrapolation, poor analogies, over valuing anecdotes. But there's money to be made. What can we do, sometimes the invisible hand slaps us silly.
  • freehorse 1y ago
    > Best counter claim: Not all code has the same risk. Some code is low risk, so the risk of error does not detract from the speed gained. For example, for proof of concepts or hobby code. Counter counter claim for these use cases: when I do proof of concept, I actually want to increase my understanding of said concept at the same time, learn challenges involved, and in general get a better idea how feasible things are. An AI can be useful for asking questions, asking for reviews, alternative solutions, inspiration etc (it may have something interesting to add or not) but if we are still in the territory "this matters" I would rather not substitute the actual learning experience and deeper understanding with having an AI generate code faster. Similar for hobby projects, do I need that thing to just work or I actually care to learn how it is done? If the learning/understanding is not important in a context, I would say then using AI to generate the code is a great time-saver. Otherwise, I may still use AI but not in the same way.
    • nilirl 1y ago
      Fair. I rescind those examples and revise my counter: When you gain much more from speed than you lose with errors, AI makes sense. Revised example: Software where the goal is design experimentation; like with trying out variations of UX ideas.
• ritz_labringue 1y ago
  AI is really useful when you already know what code needs to be written. If you can explain it properly, the AI will write it faster than you can and you'll save time because it is quick to check that this is actually the code you wanted to write. So "programming with AI" means programming in your mind and then using the AI to materialize it in the codebase.
  • Tzt 1y ago
    Well, kinda? I often know what chunks / functions I need, but too lazy to think how to implement them exactly, how they should works inside. Yeah, you need to have overall idea of what you are trying to make.
• rwmj 1y ago
  > What I think happens is that these people save time because they only spot review the AI generated code, or skip the review phase altogether, which as I said above would be a deal breaker for me. In my experience it's that they dump the code into a pull request and expect me to review it. So GenAI is great if someone else is doing the real work.
  • anelson 1y ago
    I’ve experienced this as well. If management is not competent they can’t tell (or don’t want to hear) when a “star” performer is actually a very expensive wrapper around a $20/mo cursor subscription. Unlike the author of the article I do get a ton of value from coding agents, but as with all tools they are less than useless when wielded incompetently. This becomes more damaging in an org that already has perverse incentives which reward performative slop over diligent and thoughtful engineering.
    • skydhash 1y ago
      Git blame can do a lot in those situations. Find the general location of the bug, then assign everyone that has touched it to the ticket.
      • cardanome 1y ago
        Is that really something you are doing in your job? Most of my teams have been very allergic to assigning personal blame and management very focused on making sure everyone can do everything and we are always replaceable. So maybe I could phrase it like "X could help me with this" but saying X is responsible for the bug would be a no no.
        • skydhash 1y ago
          Not really. I was talking more in the context of the parent comment. If your management is dysfunctional, allowing AI slop without the accountability, then you go with this extreme measure. I don't mind fixing bugs, but I do mind reckless practices that introduce them.
• zacksiri 1y ago
  LLMs are relatively new technology. I think it's important to recognize the tool for what it is and how it works for you. Everyone is going to get different usage from these tools. What I personally find is. It's great for helping me solve mundane things. For example I'm recently working on an agentic system and I'm using LLMs to help me generate elasticsearch mappings. There is no part of me that enjoy making json mappings, it's not fun nor does it engage my curiosity as a programmer, I'm also not going to learn much from generating elasticsearch mappings over and over again. For problems like this, I'm happy to just let the LLM do the job. I throw some json at it and I've got a prompt that's good enough that it will spit out results deterministically and reliably. However if I'm exploring / coding something new, I may try letting the LLM generate something. Most of the time though in these cases I end up hitting 'Reject All' after I've seen what the LLM produces, then I go about it in my own way, because I can do better. It all really depends on what the problem you are trying to solve. I think for mundane tasks LLMs are just wonderful and helps get out of the way. If I put myself into the shoes of a beginner programmer LLMs are amazing. There is so much I could learn from them. Ultimately what I find is LLMs will help lower the barrier of entry to programming but does not mitigate the need to learn to read / understand / reason about the code. Beginners will be able to go much further on their own before seeking out help. If you are more experienced you will probably also get some benefits but ultimately you'd probably want to do it your own way since there is no way LLMs will replace experienced programmer (not yet anyway). I don't think it's wise to completely dismiss LLMs in your workflow, at the same time I would not rely on it 100% either, any code generated needs to be reviewed and understood like the post mentioned.
• zengyue 1y ago
  I think it is more suitable for creation rather than modification, so when repeated attempts still don't work, I will delete it and let it rewrite, which often solves the problem.
• redhale 1y ago
  This line by the author, in response to one of the comments, betrays the core of the article imo: > The quality of the code these tools produce is not the problem. So even if an AI could produce code of a quality equal to or surpassing the author's own code quality, they would still be uninterested in using it. To each their own, but it's hard for me to accept an argument that such an AI would provide no benefit, even if one put priority on maintaining high quality standards. I take the point that the human author is ultimately responsible, but still.
• lvl155 1y ago
  Analogous to assembly, we need standardized AI language/styles.
• ukprogrammer 1y ago
  > “It takes me at least the same amount of time to review code not written by me than it would take me to write the code myself, if not more.” There’s your issue, the skill of programming has changed. Typing gets fast; so does review once robust tests already prove X, Y, Z correctness properties. With the invariants green, you get faster at grokking the diff, feed style nits back into the system prompt, and keep tuning the infinite tap to your taste.
• Dusksky 1y ago
  [dead]
• mentalgear 1y ago
  From all my experience over several years, the best stance towards AI assisted development is: "Trust, but verify" (each change). Which is in stark contrast of brittle "vibe coding" (which might work for demos but nothing else).
  • Tzt 1y ago
    What do you mean several years, it became feasible like 6 months ago lol. No, gpt3.5 doesn't count, it's a completely useless thing.
• varispeed 1y ago
  What is the purpose of this article?
• bawana 1y ago
  Is AI's relationship to knowledge the same as an index fund is to equities? Does the fact that larger and larger groups of people use AI result in more homogeneous and 'blindered' thinking?
• cwoolfe 1y ago
  I have found AI generated code to be overly verbose and complex. It usually generates 100 lines and I take a few of them and adapt them to what I want. The best cases I've found for using it are asking specific technical questions, helping me learn a new code language, having it generate ideas on how to solve a problem for brainstorming. It also does well with bounded algorithmic problems that are well specified i.e. write a function that takes inputs and produces outputs according to xyz. I've found it's usually sorely lacking in domain knowledge (i.e. it is not an expert on the iOS SDK APIs, not an expert in my industry, etc.)
  • mettamage 1y ago
    My heuristic: the more you're solving a solved problem that is just tedious work and memory intensive take a crack at using AI. It will probably one shot your solution with minimal tweaks required. The more you deviate from that, the more you have to step in. But given that I constantly forget how to open a file in Python, I still have a use for it. It basically supplanted Stackoverflow.
• giantg2 1y ago
  The true test is can it write tests? Ask the dev if they use it to write tests. The answers to #1 is it can't really. The answer to #2 should be no. AI can write some tests, but it can't design thorough ones. Perhaps the best way to use AI is to have a human writing thorough and well documented tests as part of TDD, asking AI to write code to meet those tests, then thoroughly reviewing that code. AI saves me just a little time by writing boilerplate stuff for me, just one step above how IDEs have been providing generated getters and setters.
• xpe 1y ago
  > Unfortunately these claims are just based on the perception of the subjects themselves, so there is no hard data to back them up. Did the author take their own medicine and measure their own productivity?
  • dlock17 1y ago
    Somehow you think the burden of proof is on his response rather than the AI maxis initial claims, but regardless, here you go. It was measured. https://arxiv.org/abs/2506.08872 https://arxiv.org/abs/2506.08872
• throwaway12345t 1y ago
  I don’t understand this one at all. Say you need to update a somewhat unique implementation of a component across 5 files. In pseudocode, it might take you 30 seconds to type out whatever needs to be done. It would take maybe 3-4 minutes to do it. I set that up to run then do something different. I come back in a couple minutes, scan the diffs which match expectations and move on to the next task. That’s not everything but those menial tasks where you know what needs to be done and what the final shape should look like are great for AI. Pass it off while you work on more interesting problems.
• xpe 1y ago
  > In recent times I had to learn Rust, Go, TypeScript, WASM, Java and C# for various projects, and I wouldn't delegate this learning effort to an AI, even if it saved me time. Either/or fallacy. There exist a varied set of ways to engage with the technology. You can read reference material and ask for summarization. You can use language models to challenge your own understanding. Are people really this clueless? (Yes, I know the answer, but this is a rhetorical device.) Think, people. Human intelligence is competing against artificial intelligence, and we need to step it up. Probably a good time to stop talking like we’re in Brad Pitt’s latest movie, Logical Fallacy Club. If we want to prove our value in a competitive world, we need to think and write well. I sometimes feel like bashing flawed writing is mean, but maybe the feedback will get through. Better to set a quality bar. We should aim to be our best.
  • Fraterkes 1y ago
    Let me help you remove the beam from your own eye first: this comment leaves me with the impression that your writing isn’t great.
    • xpe 1y ago
      I welcome specific and actionable criticism. Would you like to engage with my (a) substance; (b) tone; (c) something else?
      • saulpw 1y ago
        It's not organized well. As the reader I had to do too much work to discern your point and what was relevant. I'm sure it's obvious to you the writer, but one of the foundational skills of a good writer is empathy for their reader, whoever they may be. Even here, you think you're being open-minded, but you offered a multiple choice question, where the choices are reductive and it comes off as defensive. An open-ended question like "What problem did you have with my writing?" might elicit a better response.
        • xpe 1y ago
• thefz 1y ago
  I learned C# first then async/await then the TPL then MVVM by banging my head against the problems I had to solve. I still retain the knowledge to this day because I had to think long and hard and test a lot, prototype and verify. Having a chatbot telling me what to write would have not sorted the same effect. It's like having someone tell you the solutions to your homework.
• abalashov 1y ago
  I think the point about owning the code is the significant one. If you’re just doing some throwaway prototyping or trying stuff, fine. But if you really need to commit to ownership and maintenance and care and feeding of this code, best just write it yourself, if only for the reason that writing it engenders the appropriate level of understanding while removing the distraction of AI slop code review. Where I find it genuinely useful is in extremely low-value tasks, like localisation constants for the same thing in other languages, without having to tediously run that through an outside translator. I think that mostly goes in the "fancy inline search" category. Otherwise, I went back from Cursor to normal VS Code, and mostly have Copilot autocompletions off these days because they're such a noisy distraction and break my thought process. Sometimes they add something of value, sometimes not, but I'd rather not have to confront that question with every keystroke. That's not "10x" at all. Yes, I've tried the more "agentic" workflow and got down with Claude Code for a while. What I found is that its changes are so invasive and chaotic--and better prompts don't really prevent this--that it has the same implications for maintainability and ownership referred to above. For instance, I have a UIKit-based web application to which I recently asked Claude Code to add dark theme options, and it rather brainlessly injected custom styles into dozens of components and otherwise went to town, in a classic "optimise for maximum paperclip production" kind of way. I spent a lot more time un-F'ing what it did throughout the code base than I would have spent adding the functionality myself in an appropriately conservative fashion. Sure, a better prompt would probably have helped, but that would have required knowing what chaos it was going to wreak in advance, as to ask it to refrain from that as part of the prompt. The possibility of this happening with every prompt is not only daunting, but a rabbit hole of cognitive load that distracts from real work. I will concede it does a lot better--occasionally, very impressively--with small and narrow tasks, but those tasks at which it most excels are so small that the efficiency benefit of formulating the prompt and reviewing the output is generally doubtful. There are those who say these tools are just in their infancy, AGI is just around the corner, etc. As far as I can tell from observing the pace of progress in this area (which is undeniably impressive in strictly relative terms), this is hype and overextrapolation. There are some fairly obvious limits to their training and inference, and any programmer would be wise to keep their head down, ignore the hype, use these tools for what they're good at and studiously avoid venturing into "fundamentally new ways of working".
• osigurdson 1y ago
  That is my experience with Windsurf / Cursor type tools. Faster for some things but generally super annoying and slow. The Codex workflow however really is a game changer imo. It takes the time to ensure changes are consistent with other code and the async workflow is just so much nicer.
• conductr 1y ago
  Has a lot to do with what you’re building. It does front end and crud apps pretty well. Things like games and more complex programs I feel like I’m fighting it more and should just write the code myself
• mellosouls 1y ago
  The author makes the excellent point that LLM-coding still has a human bottleneck at the code review point - regardless of whether the issue at hand is fixed or not. Leaving aside the fact that this isn't an LLM problem; we've always had tech debt due to cowboy devs and weak management or "commercial imperatives": I'd be interested to know if any of the existing LLM ELO style leaderboards mark for code quality in addition to issue fixing? The former seems a particularly useful benchmark as they become more powerful in surface abilities.
  • NoGravitas 1y ago
    > Leaving aside the fact that this isn't an LLM problem; we've always had tech debt due to cowboy devs and weak management or "commercial imperatives": But this is one of the core problems with LLM coding, right? It accelerates an already broken model of software development (worse is better) rather than trying to help fix it.
    • mellosouls 1y ago
      Possibly so - which is why I think research towards quality rather than just test-passing would be a significant benefit.
• wilkinsonsmooth 1y ago
  One thing about AI that I feel like no company that is already inserting into their workforce is thinking about is what the future looks like when your company depends on it. If AI is doing the work that junior employees used to do, then you are losing the base knowledge that your employees used to learn. Maybe in the coming years it starts to take over more and more roles that people used to do and companies can decrease their workforce. AI comes a lot cheaper than real people (at least that's the selling point). Most tech companies however tend to operate following a standard enshittification schedule. First they are very cheap, supported by investments and venture capitalists. Then they build a large user base who become completely dependent on them as alternatives disappear (in this case as they lose the institutional knowledge that their employees used to have). Then they seek to make money so the investors can make their profits. In this case I could see the cost of AI rising a lot, after companies have already built it in to their business. AI eventually has to start making money. Just like Amazon had to, and Facebook, and Uber, and Twitter, and Netflix, etc. From all the talk I see of companies embracing AI wholeheartedly it seems like they aren't looking any further than the next quarter. It only costs so much per month to replace so many man hours of work! I'm sure that won't last once AI is deeply embedded into so many businesses that they can start charging whatever they want to.
• scotty79 1y ago
  > It takes me at least the same amount of time to review code not written by me than it would take me to write the code myself, if not more. Even if that was true for everybody reviews would still be worth doing because when the code is reviewed it gets more than one pair of eyes looking at it. So it's still worth using AI even if it's slower than writing code yourself. Because you wouldn't have made mistakes that AI would made and AI wouldn't make mistakes you would have made. It still might be personally not worth it for you though if you prefer to write code than to read it. Until you can set up AI as a reviewer for yourself.
• mdavid626 1y ago
  I fully agree. People who save lots of time, are the people who don’t care about the code. If it builds and the golden scenario works, it’s good to go. It doesn’t matter, that it’ll cost multiple times more to fix the bugs. Hey, they were fast!
• mdavid626 1y ago
  AI offers many solutions and also brings many problems. Some people like to see only the good side and act, as if there would be no bad side. One of the biggest problem I see with AI is, that it makes people used to NOT to think. It takes lots of time and energy to learn to program and design complex software. AI doesn’t solve this - humans to be able to supervise need to have these skills. But why would new programmers learn them? AI writes their code! It’s already hard to convince them otherwise. This only leads to bad things. Technology without proper control and wisdom, destroys human things. We saw this many times already.
  • maujun 1y ago
    Agreed. StackOverflow makes it easier not think and copy-paste. Autocomplete makes it easier to not think and make typos (Hopefully you have static typing). Package management makes it easier to not think and introduce heavy dependencies. C makes it easier to not think and forget to initialize variables. I make it easier to not think and read without considering evil (What if every word I say has evil intention and effect?)
    • mdavid626 1y ago
      Everything you said, except for Stackoverflow is an abstraction. Abstractions are making you think of different things. They “hide” some detail and allow you to focus on something else. Of course, the abstraction has its price. This is true for AI too. The price is the problem.
• mdavid626 1y ago
  AI is like a factory, which produces goods. People are happy: they have the goods and can improve their lifes. These people see only the goods and are really surprised why some people talk about AI being not useful for them or even having a negative effect. The reality is, that this factory is also leaking toxic waste into the nature. There are people who already see this, and try to warn the rest. Of course, the factory doesn’t care, unless it’s forced to. The toxic waste started to accumulate. People start to get sick… but nobody cares.
• mumbisChungo 1y ago
  The more people that feel this way the better (for those of us who they do work for).
• deterministic 1y ago
  I use non-AI code generators written by myself all the time. It is a huge time saver. Usually about 90% of the code I need for a typical biz application is auto generated => no coding needed, no bugs, no AI weirdness etc. Having said that, for simple ad-hoc code generation (I need a dump function for this data structure for example) AI's work great.