4 ms·

AI is a bad tool

80 points by shtgnwrng 4mo ago

m_w_ 4mo ago
I can only imagine that people who say things like: > If you use AI for anything else, and in particularly if you use it to generate code, you're wasting your time. Have not used frontier models in at least a year. It is nearly inconceivable to me that I would ever go back to writing code by hand, in any context. Even if no new model was ever released, the combination of GLM 5.2 and DeepSeek V4 flash is more than sufficient to do real work. It's not hard to imagine that a distillation of Mythos/5.6S or whatever is a couple generations away will push me even further in this direction.
- adamddev1 4mo ago
  Are you writing code for end-user applications, or for tools or libraries that other stuff is built with?
  - grim_io 4mo ago
    Not the guy you asked, but honestly, I'm not sure which one of those I'd consider better use cases, not worse.
    - adamddev1 4mo ago
      I ask because I think there's a huge difference between the two. People making end-user applications might think they can tolerate more errors and bloat from AI. Just because they can get away with doing that with AI (and that's debatable) does not mean that people can also get away with that in developing tools, libraries, languages etc. The errors, bloat and instability bubbles up exponentially as people build on it. There seems to be this fallacy of "I don't have to write code anymore, therefore nobody will have to write code anymore."
      - orangecat 4mo ago
        There seems to be this fallacy of "I don't have to write code anymore, therefore nobody will have to write code anymore." I see a lot more of "AI coding doesn't work well in this specific case, therefore it's entirely useless".
  - adamtaylor_13 4mo ago
    Both. And internal tools. And infrastructure scaffolding a la terraform. And visual design. And frontier models routinely crush all the above in a way I couldn't, at speeds unattainable to mere flesh and blood like me.
    - adamddev1 4mo ago
      I still think internal tools are kind of in a category closer to end-user applications. They are limited in how widely they are used, and therefore they don't have to be as solid as say libraries used by millions.
  - m_w_ 4mo ago
    Generally end-user applications, depending on how you classify internal tools. I'm generally very happy with the output of Opus 4.X with a moderately structured CLAUDE.md and some investment in detection/avoidance of anti-patterns (Next.js+ts). I imagine that the bitter lesson is true here, and these heuristic guidelines will become increasingly unnecessary w/ smarter models. Library-type work has mostly been side/toy projects, although fwiw, with a standard/spec on hand (CommonMark for example), I'm also happy w/ the output. It's often possible to "close the loop" and have the coding agent autonomously iterate until the standard is adhered to.
    - adamddev1 4mo ago
      Thanks for the answer. From what I can see, most people who are enthusiastic and optimistic about AI use are producing end-user apps, internal tools (limited use) or just hobby libraries. The fuzziness may be tolerable on the edges of immediate use. Creating something that is solid enough for widespread, reliable building is just in another category. And I wish people recognized this distinction more when they say we don't need to look at code anymore.
  - devin 4mo ago
    Judging by parent's CV, it kind of looks like they are relatively new to the industry and working in areas where they are heavy on the greenfield side of the equation. I get the sense that they've probably had some good success on smallish projects where they are in charge of keeping it all in their head. That's not to say that isn't earned or otherwise valuable experience, but it surely is not the way a lot of software projects are situated. Parent: I hope you won't take my comment here as a slight. I mean no offense, just pointing out what I think is probably valuable context.
    - m_w_ 4mo ago
      Yes - this is certainly true. I would have to concede that I could not speak to how my thesis would map onto a truly colossal codebase. That said - I would (again, maybe naively) suppose it's not hugely different - much of the work I do occurs in code where many people have and will work on it, and where the size of the codebase dwarfs model context windows. In that case, I feel the same - current frontier models, when properly oriented to a task, with some assist on the big-picture thinking - are more than capable of generating good code that can slot into big codebases with many moving pieces. Of course, I'd have to point to other people's work to defend this, but I think that's still pretty reasonable especially against the declared "LLMs are worse than useless for generating code".
- champagnepapi 4mo ago
  How are you verifying all the code that's generated? Do you think that verifying properly would take you as much effort as the original implementation would've?
  - nextos 4mo ago
    I think this is the real problem. I am sympathetic towards automated code synthesis. But without formal verification and a human reviewing specifications to ensure alignment, I think code will end up being broken in unexpected ways or drift away from the original intent.
  - Foobar8568 4mo ago
    Have you ever worked in a company? Have you ever worked in a F100? Companies are paying for software, not for owning the code.
  - m_w_ 4mo ago
    I guess I'm of two minds on it. Sometimes, I will review every line, test the front-end in a staging environment, verify the backend contract, et cetera. Over time, though, I realized that many of these reviews just didn't result in any necessary changes. The current model (with guidance/claude.md/etc) was able to one-shot the task. Not to overly personify, but imagine how you might treat a junior colleague. You start by reviewing everything they do with a microscope, later you review the broad-strokes, and eventually, for low-stakes or well-scoped tasks, you just play with the demo and the ticket and approve it. Otherwise it's not materially different than a pre-AI world - you've got sample I/O, test cases, hand-review, look at the application on different screen sizes, contrive some edge cases, test against a spec if there is one - et cetera.
  - doug_durham 4mo ago
    The same way that I verified all of the code that was written before AI. Just because you hand type the code doesn't mean that you don't have to test and verify. I can test much more thoroughly with AI that without.
- datakan 4mo ago
  Do you not enjoy coding? I'm not trying to be snarky, just a genuine question. People used to enjoy it but lately all I see are people talking about they "no longer have to do it" I see both sides of the argument people endless have over this. I have been hesitant to take a solid position, first because I suck at coding and second because I dont really have a dog in this fight. The only context I have is my friend in HVAC from many years ago that went to a school that taught everything manually because they wanted people to have a deep understanding of it. What happens to code in the future when people don't have a deep understanding?
  - wmichelin 4mo ago
    I enjoy building things. I do not enjoy the act typing out code by hand. > Do you not enjoy coding? I'm not trying to be snarky, just a genuine question To follow this debate through, to maximize coding enjoyment, shouldn't we be avoiding compilers? They take away a lot of the code we need to write. Frameworks as well?
    - datakan 4mo ago
      Thanks for the honesty and I think I get it. The AI doing the code leap frogs you to a finished product which is the reward. I do worry about craftmanship in that scenario though.
      - wmichelin 4mo ago
        The finished product alone does not have to be the reward. The reward can still be building a great tool, a great application, etc. With AI we can build it 100x faster, freeing us up to think deeper about our test coverage, our design, our scaling, our observability. There is no excuse for lazy execution using AI, that is, IMO, equivalent to shoddy software engineering. it's just faster and more accessible now. "AI slop" is just poor execution delivered more quickly. The onus is still on the human in the drivers seat to deliver quality outcomes.
        bakugo 4mo ago
- Ken_At_EM 4mo ago
  nailed it
- couchdb_ouchdb 4mo ago
  1000% this person has no idea what they are talking about.
- IshKebab 4mo ago
  He's obviously wrong for saying "If you use AI to generate code you're wasting your time" - that's empirically wrong. As you say, anyone who has used recent models knows you can absolutely save time with them (hell even the earlier ones were useful for one-off scripts). But... > It is nearly inconceivable to me that I would ever go back to writing code by hand, in any context. In any context? Sorry but they aren't that good yet. There are definitely areas where they are going to struggle. Maybe fewer than before. Maybe you can say "in any context where a junior-to-mid programmer would be ok", which I would agree with.
kierenj 4mo ago
I'd welcome someone pointing out where I'm wrong in my critique of this critique.. "The reason AI is a bad tool is that generally speaking, it is completely opaque." "The real question is, who can verify that what the AI built is good and true?" Well, you? The developer? The person responsible for using the tool, no? Isn't this article just saying, "using a tool blindly and not checking the result" is bad? Which, of course, it would be.
- levkk 4mo ago
  I think most tools, according to the UNIX philosophy, do one thing (and do it well). AI is a tool that does _a lot_ of things...to various degrees of success. While you can verify that the output of `sed` or `grep` is valid, you can't with 10k lines of code you have no context on (without _significant_ effort). Same with Gimp, Firefox, and your terminal. Tools, all, do many easily verifiable things. AI isn't verifiable without an existing framework, and that's why it's so "good" at rewriting code from language A to language B, but not at zero-to-one building real world software.
- idontwantthis 4mo ago
  Or the users? At some point it either works or it doesn’t. And I can use AI to write 100 api tests and run them in the pipeline on day 1 when that would probably be a year 2 project otherwise. And I can document business decisions in plain english and the AI will read those and almost certainly honor them.
- em-bee 4mo ago
  the problem is that a lot of AI use is done blindly. how much of that bun rewrite in rust was verified by a human?
- jottinger 4mo ago
  It is, I think. I published the article on BCN (the preface is me, the rest is a reader submission) and I find I agree with relatively little of the article, but I think it has observations worth looking at, even so.
- kenferry 4mo ago
adamddev1 4mo ago
Great article. Yes, often what's needed are better (rock-solid) abstractions that we can manipulate around quickly and confidently (think Abelson/Sussman SICP style), not a machine that can take good guesses at piles of spaghetti code.
adamtaylor_13 4mo ago
Is this satire? That's my most charitable interpretation. This smells like it was written by someone who doesn't actually write code. How does one make the logic leap that any code AI is able to write, is only because that code is "trivial"? The author doesn't even bother defending that claim. I suppose the only other charitable interpretation would be to say, "Well then 99% of the code I'm paid to write is 'trivial'." If that's the case, then you have to separate "code as means to an end" (which is clearly well within the wheelhouse of AI) from "code as a mathematical art" which is okay, but the latter doesn't pay my bills or create value for my clients.
pineaux 4mo ago
I get their point, but they are probably wrong. Not saying the AIs will not get better and better. They probably will, but I see a chance that there are smaller and smaller gains and the AIs cant make those gains happen. But coding with llm's doesnt say its shoddy code per se. I view it as: We used to use hand saws to make cabinets. Then we had tracksaws. Then we had CNC saws... You still need to understand woodworking to make a nice table in all these scenarios.
- adamddev1 4mo ago
  All those things (handsaws, tracksaws, CNC saws) are analogous to deterministic, clearly designed tools (assemblers, compilers, language servers). The jump to LLMs is a jump to a completely different category.
semiquaver 4mo ago
Pure sophistry, divorced from reality. It starts with the assumption that nothing coming from AI can be useful or trusted and uses that to demonstrate that AI is not useful or safe.
- llm_nerd 4mo ago
  Right at the outset it opines that AI finding vulnerabilities ("allegedly") is useless because people have to verify those vulnerabilities, which is such a logically braindead bit of nonsense that I knew it was going to be worthless, and somehow it got even worse with every subsequent paragraph. I get that there are people who are scared, and the change is coming fast and hard and there is a lot of doom and concerns, but good god do people think authoring or upvoting shit like the submitted nonsense is going to stem the tide or change the path? Pathetic.
buzzin__ 4mo ago
In this article you can learn that it takes the same amount of effort to verify if a security hole is real, as it takes to find it in the first place. (?)
samuelknight 4mo ago
Has the author used an LLM to brainstorm architecture, explore trade-offs, challenge assumptions, or refine a design? Models are not just 'a data distiller'. "How could I implement X feature in Y project?" requires systematic planning. The agentic paradigm is about balancing (expensive) human and (cheap) machine cognition. Frontier models chew through requirements and if you don't like what they come up with you can TALK to them about it.
- Foobar8568 4mo ago
  I am really annoying by these post (not yours, but op), they are basically the reverse of linkedin. Between LinkedIn that is packed with AI slope, and HN which is "I am smarter than you, AI is awful"...Where are the interesting news?
bensyverson 4mo ago
This article starts off by saying AI can be useful for question-answering, but then quickly states that if you're using AI to generate code "you're wasting your time:" > The reason AI is a bad tool is that generally speaking, it is completely opaque. The author is missing the fact that you can use those great question-answering and knowledge distillation capabilities to ask the AI questions about the code it wrote. Later, they write: > Who is going to verify that it is doing what it is supposed to? What? If you hire a writer to write a blog post, who is going to verify that they didn't just fill in gibberish? It's you. You there, in the front. You're the one. If you can't find any way to independently verify that the software is doing what you think it should do, I don't think you have any business generating it, whether you use AI or code it by hand. That's like commissioning a portrait of someone you've never seen.
spankalee 4mo ago
This statement is just ridiculous: > Recently, there's a lot of talk about AI allegedly finding security flaws in software. That is an unsubstantiated claim. As such, it would need to be verified by a non-machine, and arguably, the verification process would require the same amount of effort or more than would be required to find the issue to begin with. Once a security issue is found, it is often far less effort to verify it. Digging through millions of lines of codes to find high-probability vulnerabilities is the hard part.
furyofantares 4mo ago
The idea that it only reveals missing abstractions and that this is bad, is pretty off the mark in a lot of ways. First off, there's plenty of cases where it make no sense for me to spend all my time abstracting everything possible in my pipeline. Maybe I'm a game developer who doesn't want to spend all my time abstracting away all the initial scaffolding for game prototype and just make a dang game prototype. Or maybe the abstraction would needs to much confirmation to not really be any different than code (again, games.) Or maybe the LLM is indeed a perfectly good abstraction for such a task, reliable and customizable. Just keep writing abstractions all the way up the chain until you're so abstracted that you take english input and can product whatever is asked for, and, oh right.
dgacmu 4mo ago
> Recently, there's a lot of talk about AI allegedly finding security flaws in software. That is an unsubstantiated claim. As such, it would need to be verified by a non-machine, and arguably, the verification process would require the same amount of effort or more than would be required to find the issue to begin with. This is simply not true. Security flaws are a great use-case for AI specifically because they're easy to verify. If you can drive a program to segfault based on inputs, you've got a good indicator it is, in fact, a security vulnerability (at minimum a DoS, but usually you find out later it was exploitable). You could even have the AI generate an exploit PoC. Shell? Valid hole. Done. The bad use cases for AI are the ones where it's as or more expensive to verify correctness as it would have been to find the solution in advance.
rick_dalton 4mo ago
This article feels weirdly anachronistic with talking points I haven't really heard anyone mention since like 2023.
sodafountan 4mo ago
Yes. AI (in its current state) is phenomenal for research on just about any topic; you can dive deep and cross-reference the material more easily than ever. AI (in its current state) is not so good at actually doing things; we're a long ways off from simply speaking software into existence.
- orangecat 4mo ago
  we're a long ways off from simply speaking software into existence I wanted a Chinese language tutor that uses a local LLM to generate sentences and evaluate my translations. I asked Claude to build that, and an hour later it was working pretty much exactly how I imagined it. It's true that there's a lot more to shipping serious projects than getting the code to work, but you can absolutely speak software into existence today.
jrockway 4mo ago
I don't really agree with this. I was VERY skeptical about AI, but then I started using frontier models everyday, and my feelings have changed dramatically. I use AI to refine designs. I use AI for "where are all the codepaths where we return an HTTP 499 error". I use AI to write code (in "manually accept edits" mode, and I am picky about every single diff) and the results are really good. Most of the time, exactly what I typed in. Doing stuff like "add this config and plumb it through the helm chart" is amazing. Editing Go templates that generate YAML is absolutely miserable, it is my least favorite task. Claude gets it right without fuss every time. I have not stopped engineering software, but I type in less code. I still understand every line in our codebase and why it's there, but I spend a lot less time dealing with the mechanics. LLMs are super impressive for the software engineering work I do. I don't have a fleet of agents making 20 major changes to the codebase every day. I do about as much work with AI as I did before I used AI. But I think the quality has gone way up, and I am a stickler for pretty perfect code. Claude keeps me honest and reduces the cost of exploring alternate approaches, writing hairy tests, doing refactors, keeping docs up to date, keeping production stable and understandable, etc. I basically do not agree with this article at all. Frontier models are like switching from dabbrev-mode to IntelliSense, something I was very resistant to at the time. "It's important that I know the APIs that I use everyday." Not really. Having your IDE remember whether it's HasPrefix(string, substring) or HasPrefix(substring, string) frees up my brain for something more important and I couldn't live without it. AI is the same way. It's a tool that makes me better at my work. Yes, it's expensive. That's the only downside I see. I am lucky that I can use as much Fable 5 as I want at work... I always feel bad when I share something that it did that was cool with someone who can't afford it. But costs will come down. I think this AI think is here to stay in the software engineering space. I don't think it removes the need for qualified software engineers at the controls. At least today.
- zahlman 4mo ago
  > Editing Go templates that generate YAML is absolutely miserable, it is my least favorite task. Claude gets it right without fuss every time. As I understood it, the article's thesis is that your system shouldn't require "Go templates that generate YAML" in the first place. Which is the sort of thing I'm very sympathetic to, but seems overstated here. There's a balance to strike.
sph 4mo ago
The AI posts will continue until morale improves. Honestly, I am starting to feel it’s Groundhog Day every day here, reaching the same discussion we’ve been having for years now.
skwirl 4mo ago
> The real question is, who can verify that what the AI built is good and true? Recently, there's a lot of talk about AI allegedly finding security flaws in software. That is an unsubstantiated claim. As such, it would need to be verified by a non-machine, and arguably, the verification process would require the same amount of effort or more than would be required to find the issue to begin with. Came for the bad AI take, stayed for the P=NP claim.
- xigoi 4mo ago
  Are you arguing that writing a correct program is an NP problem?
sublinear 4mo ago
> Maybe being passionate about something you build, understanding it fully, owning it completely, and abstracting it properly This is the actual job description. It doesn't matter whether AI is used for writing the literal code. All that can really be said is that AI alone is inadequate for this job. None of this back and forth has ever really been about AI. So, can we just cut the crap already and go back to the clarity we used to have on this? Bad leadership leads to bad outcomes. Bad leadership wants to use any tool at their disposal to micromanage and cut costs. Bad leadership is terrified of a younger and more capable workforce that will replace them. Bad leadership will do everything to deflect blame including calling you "out of touch" for not using AI enough or at all. Not all workplaces are like this. I am actually glad AI has put a massive spotlight on these longstanding tensions. Aging is happening faster than AI. It's far more likely there will be a time soon when all these software devs will no longer code because they're management (or burned out and changed careers). It's more important to start thinking about your integrity now before your lack of it gets you fired in the future anyway. I don't blame young people for being so naive, but this is a blindspot. Get a grip now.
aogaili 4mo ago
Condescending, ignorant, and the author doesn't know what he is talking about. I'll not explain why, and that would be as deep as the author explanation of his coping. Why those articles get to hacker news?
distalshores 4mo ago
I think a lot of people who write about AI haven't been regular old, run-of-the-mill software devs in a while. For small companies, or large companies broken into small teams, I'm not really sure why there's this assumption that AI will "take care of all the trivial code." Someone has to transmute the project manager's wishes into working code, and it's never going to be the product manager. From that point of view, whether I'm cobbling the code together from Stack Overflow snippets or using AI to generate it, my job hasn't changed all that much. I neither fear the reaper nor do I dismiss the impact GPTs have had on the industry. I just don't think small development teams' mandates have changed that much, apart from a somewhat faster pace of development (work expands to fill the vacuum, after all).
deterministic 4mo ago
I 100% disagree. I'm the maintainer of a large, business-critical C++ application with over a million lines of code that's used by major international companies. Claude Code routinely handles large and complex code changes correctly. I review every line that Claude Code adds or changes, so this isn't speculation. It's an empirical fact. These days my job is mostly to direct Claude Code, review its changes, and test the results. I still write code by hand when it's faster than explaining what I want, but that's becoming less common.

80 points by shtgnwrng 4mo ago

m_w_ 4mo ago

I can only imagine that people who say things like: > If you use AI for anything else, and in particularly if you use it to generate code, you're wasting your time. Have not used frontier models in at least a year. It is nearly inconceivable to me that I would ever go back to writing code by hand, in any context. Even if no new model was ever released, the combination of GLM 5.2 and DeepSeek V4 flash is more than sufficient to do real work. It's not hard to imagine that a distillation of Mythos/5.6S or whatever is a couple generations away will push me even further in this direction.

adamddev1 4mo ago
Are you writing code for end-user applications, or for tools or libraries that other stuff is built with?
- grim_io 4mo ago
  Not the guy you asked, but honestly, I'm not sure which one of those I'd consider better use cases, not worse.
  - adamddev1 4mo ago
    I ask because I think there's a huge difference between the two. People making end-user applications might think they can tolerate more errors and bloat from AI. Just because they can get away with doing that with AI (and that's debatable) does not mean that people can also get away with that in developing tools, libraries, languages etc. The errors, bloat and instability bubbles up exponentially as people build on it. There seems to be this fallacy of "I don't have to write code anymore, therefore nobody will have to write code anymore."
    - orangecat 4mo ago
      There seems to be this fallacy of "I don't have to write code anymore, therefore nobody will have to write code anymore." I see a lot more of "AI coding doesn't work well in this specific case, therefore it's entirely useless".
- adamtaylor_13 4mo ago
  Both. And internal tools. And infrastructure scaffolding a la terraform. And visual design. And frontier models routinely crush all the above in a way I couldn't, at speeds unattainable to mere flesh and blood like me.
  - adamddev1 4mo ago
    I still think internal tools are kind of in a category closer to end-user applications. They are limited in how widely they are used, and therefore they don't have to be as solid as say libraries used by millions.
- m_w_ 4mo ago
  Generally end-user applications, depending on how you classify internal tools. I'm generally very happy with the output of Opus 4.X with a moderately structured CLAUDE.md and some investment in detection/avoidance of anti-patterns (Next.js+ts). I imagine that the bitter lesson is true here, and these heuristic guidelines will become increasingly unnecessary w/ smarter models. Library-type work has mostly been side/toy projects, although fwiw, with a standard/spec on hand (CommonMark for example), I'm also happy w/ the output. It's often possible to "close the loop" and have the coding agent autonomously iterate until the standard is adhered to.
  - adamddev1 4mo ago
    Thanks for the answer. From what I can see, most people who are enthusiastic and optimistic about AI use are producing end-user apps, internal tools (limited use) or just hobby libraries. The fuzziness may be tolerable on the edges of immediate use. Creating something that is solid enough for widespread, reliable building is just in another category. And I wish people recognized this distinction more when they say we don't need to look at code anymore.
- devin 4mo ago
  Judging by parent's CV, it kind of looks like they are relatively new to the industry and working in areas where they are heavy on the greenfield side of the equation. I get the sense that they've probably had some good success on smallish projects where they are in charge of keeping it all in their head. That's not to say that isn't earned or otherwise valuable experience, but it surely is not the way a lot of software projects are situated. Parent: I hope you won't take my comment here as a slight. I mean no offense, just pointing out what I think is probably valuable context.
  - m_w_ 4mo ago
    Yes - this is certainly true. I would have to concede that I could not speak to how my thesis would map onto a truly colossal codebase. That said - I would (again, maybe naively) suppose it's not hugely different - much of the work I do occurs in code where many people have and will work on it, and where the size of the codebase dwarfs model context windows. In that case, I feel the same - current frontier models, when properly oriented to a task, with some assist on the big-picture thinking - are more than capable of generating good code that can slot into big codebases with many moving pieces. Of course, I'd have to point to other people's work to defend this, but I think that's still pretty reasonable especially against the declared "LLMs are worse than useless for generating code".
champagnepapi 4mo ago
How are you verifying all the code that's generated? Do you think that verifying properly would take you as much effort as the original implementation would've?
- nextos 4mo ago
  I think this is the real problem. I am sympathetic towards automated code synthesis. But without formal verification and a human reviewing specifications to ensure alignment, I think code will end up being broken in unexpected ways or drift away from the original intent.
- Foobar8568 4mo ago
  Have you ever worked in a company? Have you ever worked in a F100? Companies are paying for software, not for owning the code.
- m_w_ 4mo ago
  I guess I'm of two minds on it. Sometimes, I will review every line, test the front-end in a staging environment, verify the backend contract, et cetera. Over time, though, I realized that many of these reviews just didn't result in any necessary changes. The current model (with guidance/claude.md/etc) was able to one-shot the task. Not to overly personify, but imagine how you might treat a junior colleague. You start by reviewing everything they do with a microscope, later you review the broad-strokes, and eventually, for low-stakes or well-scoped tasks, you just play with the demo and the ticket and approve it. Otherwise it's not materially different than a pre-AI world - you've got sample I/O, test cases, hand-review, look at the application on different screen sizes, contrive some edge cases, test against a spec if there is one - et cetera.
- doug_durham 4mo ago
  The same way that I verified all of the code that was written before AI. Just because you hand type the code doesn't mean that you don't have to test and verify. I can test much more thoroughly with AI that without.
datakan 4mo ago
Do you not enjoy coding? I'm not trying to be snarky, just a genuine question. People used to enjoy it but lately all I see are people talking about they "no longer have to do it" I see both sides of the argument people endless have over this. I have been hesitant to take a solid position, first because I suck at coding and second because I dont really have a dog in this fight. The only context I have is my friend in HVAC from many years ago that went to a school that taught everything manually because they wanted people to have a deep understanding of it. What happens to code in the future when people don't have a deep understanding?
- wmichelin 4mo ago
  I enjoy building things. I do not enjoy the act typing out code by hand. > Do you not enjoy coding? I'm not trying to be snarky, just a genuine question To follow this debate through, to maximize coding enjoyment, shouldn't we be avoiding compilers? They take away a lot of the code we need to write. Frameworks as well?
  - datakan 4mo ago
    Thanks for the honesty and I think I get it. The AI doing the code leap frogs you to a finished product which is the reward. I do worry about craftmanship in that scenario though.
    - wmichelin 4mo ago
      The finished product alone does not have to be the reward. The reward can still be building a great tool, a great application, etc. With AI we can build it 100x faster, freeing us up to think deeper about our test coverage, our design, our scaling, our observability. There is no excuse for lazy execution using AI, that is, IMO, equivalent to shoddy software engineering. it's just faster and more accessible now. "AI slop" is just poor execution delivered more quickly. The onus is still on the human in the drivers seat to deliver quality outcomes.
      - bakugo 4mo ago
Ken_At_EM 4mo ago
nailed it
couchdb_ouchdb 4mo ago
1000% this person has no idea what they are talking about.
IshKebab 4mo ago
He's obviously wrong for saying "If you use AI to generate code you're wasting your time" - that's empirically wrong. As you say, anyone who has used recent models knows you can absolutely save time with them (hell even the earlier ones were useful for one-off scripts). But... > It is nearly inconceivable to me that I would ever go back to writing code by hand, in any context. In any context? Sorry but they aren't that good yet. There are definitely areas where they are going to struggle. Maybe fewer than before. Maybe you can say "in any context where a junior-to-mid programmer would be ok", which I would agree with.

kierenj 4mo ago

I'd welcome someone pointing out where I'm wrong in my critique of this critique.. "The reason AI is a bad tool is that generally speaking, it is completely opaque." "The real question is, who can verify that what the AI built is good and true?" Well, you? The developer? The person responsible for using the tool, no? Isn't this article just saying, "using a tool blindly and not checking the result" is bad? Which, of course, it would be.

levkk 4mo ago
I think most tools, according to the UNIX philosophy, do one thing (and do it well). AI is a tool that does _a lot_ of things...to various degrees of success. While you can verify that the output of `sed` or `grep` is valid, you can't with 10k lines of code you have no context on (without _significant_ effort). Same with Gimp, Firefox, and your terminal. Tools, all, do many easily verifiable things. AI isn't verifiable without an existing framework, and that's why it's so "good" at rewriting code from language A to language B, but not at zero-to-one building real world software.
idontwantthis 4mo ago
Or the users? At some point it either works or it doesn’t. And I can use AI to write 100 api tests and run them in the pipeline on day 1 when that would probably be a year 2 project otherwise. And I can document business decisions in plain english and the AI will read those and almost certainly honor them.
em-bee 4mo ago
the problem is that a lot of AI use is done blindly. how much of that bun rewrite in rust was verified by a human?
jottinger 4mo ago
It is, I think. I published the article on BCN (the preface is me, the rest is a reader submission) and I find I agree with relatively little of the article, but I think it has observations worth looking at, even so.
kenferry 4mo ago

adamddev1 4mo ago

Great article. Yes, often what's needed are better (rock-solid) abstractions that we can manipulate around quickly and confidently (think Abelson/Sussman SICP style), not a machine that can take good guesses at piles of spaghetti code.

adamtaylor_13 4mo ago

Is this satire? That's my most charitable interpretation. This smells like it was written by someone who doesn't actually write code. How does one make the logic leap that any code AI is able to write, is only because that code is "trivial"? The author doesn't even bother defending that claim. I suppose the only other charitable interpretation would be to say, "Well then 99% of the code I'm paid to write is 'trivial'." If that's the case, then you have to separate "code as means to an end" (which is clearly well within the wheelhouse of AI) from "code as a mathematical art" which is okay, but the latter doesn't pay my bills or create value for my clients.

pineaux 4mo ago

I get their point, but they are probably wrong. Not saying the AIs will not get better and better. They probably will, but I see a chance that there are smaller and smaller gains and the AIs cant make those gains happen. But coding with llm's doesnt say its shoddy code per se. I view it as: We used to use hand saws to make cabinets. Then we had tracksaws. Then we had CNC saws... You still need to understand woodworking to make a nice table in all these scenarios.

adamddev1 4mo ago
All those things (handsaws, tracksaws, CNC saws) are analogous to deterministic, clearly designed tools (assemblers, compilers, language servers). The jump to LLMs is a jump to a completely different category.

semiquaver 4mo ago

Pure sophistry, divorced from reality. It starts with the assumption that nothing coming from AI can be useful or trusted and uses that to demonstrate that AI is not useful or safe.

llm_nerd 4mo ago
Right at the outset it opines that AI finding vulnerabilities ("allegedly") is useless because people have to verify those vulnerabilities, which is such a logically braindead bit of nonsense that I knew it was going to be worthless, and somehow it got even worse with every subsequent paragraph. I get that there are people who are scared, and the change is coming fast and hard and there is a lot of doom and concerns, but good god do people think authoring or upvoting shit like the submitted nonsense is going to stem the tide or change the path? Pathetic.

buzzin__ 4mo ago

In this article you can learn that it takes the same amount of effort to verify if a security hole is real, as it takes to find it in the first place. (?)

samuelknight 4mo ago

Has the author used an LLM to brainstorm architecture, explore trade-offs, challenge assumptions, or refine a design? Models are not just 'a data distiller'. "How could I implement X feature in Y project?" requires systematic planning. The agentic paradigm is about balancing (expensive) human and (cheap) machine cognition. Frontier models chew through requirements and if you don't like what they come up with you can TALK to them about it.

Foobar8568 4mo ago
I am really annoying by these post (not yours, but op), they are basically the reverse of linkedin. Between LinkedIn that is packed with AI slope, and HN which is "I am smarter than you, AI is awful"...Where are the interesting news?

bensyverson 4mo ago

This article starts off by saying AI can be useful for question-answering, but then quickly states that if you're using AI to generate code "you're wasting your time:" > The reason AI is a bad tool is that generally speaking, it is completely opaque. The author is missing the fact that you can use those great question-answering and knowledge distillation capabilities to ask the AI questions about the code it wrote. Later, they write: > Who is going to verify that it is doing what it is supposed to? What? If you hire a writer to write a blog post, who is going to verify that they didn't just fill in gibberish? It's you. You there, in the front. You're the one. If you can't find any way to independently verify that the software is doing what you think it should do, I don't think you have any business generating it, whether you use AI or code it by hand. That's like commissioning a portrait of someone you've never seen.

spankalee 4mo ago

This statement is just ridiculous: > Recently, there's a lot of talk about AI allegedly finding security flaws in software. That is an unsubstantiated claim. As such, it would need to be verified by a non-machine, and arguably, the verification process would require the same amount of effort or more than would be required to find the issue to begin with. Once a security issue is found, it is often far less effort to verify it. Digging through millions of lines of codes to find high-probability vulnerabilities is the hard part.

furyofantares 4mo ago

The idea that it only reveals missing abstractions and that this is bad, is pretty off the mark in a lot of ways. First off, there's plenty of cases where it make no sense for me to spend all my time abstracting everything possible in my pipeline. Maybe I'm a game developer who doesn't want to spend all my time abstracting away all the initial scaffolding for game prototype and just make a dang game prototype. Or maybe the abstraction would needs to much confirmation to not really be any different than code (again, games.) Or maybe the LLM is indeed a perfectly good abstraction for such a task, reliable and customizable. Just keep writing abstractions all the way up the chain until you're so abstracted that you take english input and can product whatever is asked for, and, oh right.

dgacmu 4mo ago

> Recently, there's a lot of talk about AI allegedly finding security flaws in software. That is an unsubstantiated claim. As such, it would need to be verified by a non-machine, and arguably, the verification process would require the same amount of effort or more than would be required to find the issue to begin with. This is simply not true. Security flaws are a great use-case for AI specifically because they're easy to verify. If you can drive a program to segfault based on inputs, you've got a good indicator it is, in fact, a security vulnerability (at minimum a DoS, but usually you find out later it was exploitable). You could even have the AI generate an exploit PoC. Shell? Valid hole. Done. The bad use cases for AI are the ones where it's as or more expensive to verify correctness as it would have been to find the solution in advance.

rick_dalton 4mo ago

This article feels weirdly anachronistic with talking points I haven't really heard anyone mention since like 2023.

sodafountan 4mo ago

Yes. AI (in its current state) is phenomenal for research on just about any topic; you can dive deep and cross-reference the material more easily than ever. AI (in its current state) is not so good at actually doing things; we're a long ways off from simply speaking software into existence.

orangecat 4mo ago
we're a long ways off from simply speaking software into existence I wanted a Chinese language tutor that uses a local LLM to generate sentences and evaluate my translations. I asked Claude to build that, and an hour later it was working pretty much exactly how I imagined it. It's true that there's a lot more to shipping serious projects than getting the code to work, but you can absolutely speak software into existence today.

jrockway 4mo ago

I don't really agree with this. I was VERY skeptical about AI, but then I started using frontier models everyday, and my feelings have changed dramatically. I use AI to refine designs. I use AI for "where are all the codepaths where we return an HTTP 499 error". I use AI to write code (in "manually accept edits" mode, and I am picky about every single diff) and the results are really good. Most of the time, exactly what I typed in. Doing stuff like "add this config and plumb it through the helm chart" is amazing. Editing Go templates that generate YAML is absolutely miserable, it is my least favorite task. Claude gets it right without fuss every time. I have not stopped engineering software, but I type in less code. I still understand every line in our codebase and why it's there, but I spend a lot less time dealing with the mechanics. LLMs are super impressive for the software engineering work I do. I don't have a fleet of agents making 20 major changes to the codebase every day. I do about as much work with AI as I did before I used AI. But I think the quality has gone way up, and I am a stickler for pretty perfect code. Claude keeps me honest and reduces the cost of exploring alternate approaches, writing hairy tests, doing refactors, keeping docs up to date, keeping production stable and understandable, etc. I basically do not agree with this article at all. Frontier models are like switching from dabbrev-mode to IntelliSense, something I was very resistant to at the time. "It's important that I know the APIs that I use everyday." Not really. Having your IDE remember whether it's HasPrefix(string, substring) or HasPrefix(substring, string) frees up my brain for something more important and I couldn't live without it. AI is the same way. It's a tool that makes me better at my work. Yes, it's expensive. That's the only downside I see. I am lucky that I can use as much Fable 5 as I want at work... I always feel bad when I share something that it did that was cool with someone who can't afford it. But costs will come down. I think this AI think is here to stay in the software engineering space. I don't think it removes the need for qualified software engineers at the controls. At least today.

zahlman 4mo ago
> Editing Go templates that generate YAML is absolutely miserable, it is my least favorite task. Claude gets it right without fuss every time. As I understood it, the article's thesis is that your system shouldn't require "Go templates that generate YAML" in the first place. Which is the sort of thing I'm very sympathetic to, but seems overstated here. There's a balance to strike.

sph 4mo ago

The AI posts will continue until morale improves. Honestly, I am starting to feel it’s Groundhog Day every day here, reaching the same discussion we’ve been having for years now.

skwirl 4mo ago

> The real question is, who can verify that what the AI built is good and true? Recently, there's a lot of talk about AI allegedly finding security flaws in software. That is an unsubstantiated claim. As such, it would need to be verified by a non-machine, and arguably, the verification process would require the same amount of effort or more than would be required to find the issue to begin with. Came for the bad AI take, stayed for the P=NP claim.

xigoi 4mo ago
Are you arguing that writing a correct program is an NP problem?

sublinear 4mo ago

> Maybe being passionate about something you build, understanding it fully, owning it completely, and abstracting it properly This is the actual job description. It doesn't matter whether AI is used for writing the literal code. All that can really be said is that AI alone is inadequate for this job. None of this back and forth has ever really been about AI. So, can we just cut the crap already and go back to the clarity we used to have on this? Bad leadership leads to bad outcomes. Bad leadership wants to use any tool at their disposal to micromanage and cut costs. Bad leadership is terrified of a younger and more capable workforce that will replace them. Bad leadership will do everything to deflect blame including calling you "out of touch" for not using AI enough or at all. Not all workplaces are like this. I am actually glad AI has put a massive spotlight on these longstanding tensions. Aging is happening faster than AI. It's far more likely there will be a time soon when all these software devs will no longer code because they're management (or burned out and changed careers). It's more important to start thinking about your integrity now before your lack of it gets you fired in the future anyway. I don't blame young people for being so naive, but this is a blindspot. Get a grip now.

aogaili 4mo ago

Condescending, ignorant, and the author doesn't know what he is talking about. I'll not explain why, and that would be as deep as the author explanation of his coping. Why those articles get to hacker news?

distalshores 4mo ago

I think a lot of people who write about AI haven't been regular old, run-of-the-mill software devs in a while. For small companies, or large companies broken into small teams, I'm not really sure why there's this assumption that AI will "take care of all the trivial code." Someone has to transmute the project manager's wishes into working code, and it's never going to be the product manager. From that point of view, whether I'm cobbling the code together from Stack Overflow snippets or using AI to generate it, my job hasn't changed all that much. I neither fear the reaper nor do I dismiss the impact GPTs have had on the industry. I just don't think small development teams' mandates have changed that much, apart from a somewhat faster pace of development (work expands to fill the vacuum, after all).

deterministic 4mo ago

I 100% disagree. I'm the maintainer of a large, business-critical C++ application with over a million lines of code that's used by major international companies. Claude Code routinely handles large and complex code changes correctly. I review every line that Claude Code adds or changes, so this isn't speculation. It's an empirical fact. These days my job is mostly to direct Claude Code, review its changes, and test the results. I still write code by hand when it's faster than explaining what I want, but that's becoming less common.