AI Is a Bad Tool(bytecode.news) |
AI Is a Bad Tool(bytecode.news) |
> 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.
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?
I love monkey-patching some python or js. But never have I ever suggested that anyone would should do it. Writing everything in Haskell sounds lovely but I wouldn't advise that either.
I honestly don't care what language I'm writing in. LLMs bring us back to the smalltalk days: your code is data and your data is code. LLMs bring a translation layer so that even if you're writing some high-level language, some DSL that exists only on some 1-off platform that no one else is aware of, _everybody_ has access to a self-bootstrapping codebase.
I feel more empowered to _code_ than ever: now, every single input carries semantic weight that gets carried through the "compiler." Every claim of determinism can much more easily be fuzz-tested and made more robust. "'sup, this broke, fix yo" and "Would you be so kind as to fix this error?" contain semantic context that actually affects the output of the generated code. That restores empowerment around code _authorship_ while still preserving the guarantees we want from the published artifact.
"Deep understanding" doesn't disappear when you gain the ability to be more expressive. "Deep understanding" disappears when people become incurious.
But most of the time coding is a means to an end. I bet your friend in HVAC was not told to use a manual drill to have a deeper understanding of how to make holes for installation. AI is simply a power tool.
> 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?
So I go from typing to prompting and reviewing diffs.
There is no way I install an agent on my laptop so I stick to web UI
For me, it is not about the syntax nor the mechanics of typing though. My enjoyment comes from thinking about problems and breaking them down, or thinking about what architecture would best serve them. I guess I'm meant to be a systems design guy, so I'm lucky that AI-coding fits this well (AI models have limited context windows, relative to the size of codebases, so doing the big picture thinking is still important, and fun for me).
What happen is that their boss gets a 3 page email screed with pictures of how they fucked up the thermostat wiring in trying to gerry-rig a new heat pump/air handler that supports only electric resistance backup heat into my house which has an oil boiler for backup. And I get shit from my wife about why our $10k new heat pump is blowing cold air on her during defrost cycles.
Like honestly I’m losing my mind, when people claim I haven’t written code in a year. You had the wrong job your whole life and whilst you think you are so frontier now by using agenst your market value is actually decreasing.
Imagine a painter saying, I’m so happy I don’t have to paint anymore. Or a tennis player. I’m so happay that I don’t have to play tennis anymore.
wtf is going on?
We all become knowledge experts especially when the data we see inside our glasses is always 100% correct. This could take Years but that's where we are heading and Im sure no one now likes the sound of it.
However, I love putting something in front of users, seeing them use it and get value out of it. And AI lets me get there 10x faster.
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.
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.
Companies are paying for software, not for owning the code.
And frontier models routinely crush all the above in a way I couldn't, at speeds unattainable to mere flesh and blood like me.
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.
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.
> 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.
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.
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.
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.
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).
Came for the bad AI take, stayed for the P=NP claim.
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?
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.
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.
> 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.
Honestly, I am starting to feel it’s Groundhog Day every day here, reaching the same discussion we’ve been having for years now.
"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.
I can prompt a fix or a new feature, have it coded in a couple of minutes, and I have enough domain knowledge to look at a diff and understand what's happening pretty quickly. It is ABSOLUTELY faster. And if Claude goes down, I could easily keep working.
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.
The code is your responsibility, and it's your responsibility to understand it and maintain it (using the tools your have available).
Strange article. If their point was "…but vibe coding is really tempting, so you have to exercise a lot of discipline" I'd be on board.
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?
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.
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.
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.
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.
I could not disagree more strongly
Using a power tool does not erode your ability to think about how to build a shelf.
Using AI to write for you absolutely erodes your ability to think about what you're writing, be it software or blog posts
I pretty strongly think it doesn't resemble coding even a little
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."
I see a lot more of "AI coding doesn't work well in this specific case, therefore it's entirely useless".
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.
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".
I don't think my job was ever to type fast, nor do I make any claim that I'm ontologically better than someone writing code by hand - but for what I need to do, I'm way faster now.
You might think he's an AI shill, but I was pretty compelled by simonw's post and idea - "your job is to deliver code that works" [1]. I think I can deliver more code that I can prove to work, faster now. The productivity is nice, but as I've said on other parts of the thread, it's also just fun to spend more time thinking, less time hitting the semicolon on my keyboard?
[1]: https://simonwillison.net/2025/Dec/18/code-proven-to-work/
Edit: should have used [1] in the first place instead of an asterisk.
Also the jury's out on if they're losing market value. We have yet to see which way the wind blows, but I personally think the genie might be out of the bottle on this one.
Full disclosure: I'm personally working up the courage to quit, take a fat paycut (maybe) and do something bucholic with the rest of my working life. I don't find much enjoyment in the tech landscape anymore (I'm 37).
LLMs are categorically a different thing. Instead of soundly translating between formal languages, they adjust how you interact with the formal language.
The enjoyment people get from coding has absolutely nothing to do with the pure volume of code they produce, to the point that this has long been a cliche!
Yeah, equating LLMs with compilers is sloppy thinking (though, I'm sure some sloppy thinkers will defend to death). It's an over-eager pattern match, not everything that takes input and produces output is the same kind of thing.
I bet in our new AI utopia, we'll get more sloppy thinking. All kinds of people will be talking about how they used to think, but now they "no longer have to do it."
The pleasure comes from the "the only right lines of code" instead of "the most lines of code".
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.
And before you post the obvious response, no, if you're truly "100x faster", you're not reading or even thinking about anything the AI is outputting. The time math doesn't add up.
Surely at some point you would stop saying "I built this house", even if you ordered and financed it?