The author lives in a world where nothing has stakes. Where deploying without code review is a process optimization, not something that will break your certification on an audit and potentially the law (claude code doesn’t have a PEng cert). Where deploying a failure means that some users are mildly annoyed, rather than equipment loss and endangering lives.
It’s exactly the same high-churn no-regard-for-the-user that is modern “tech”. I would not use this approach on anything more serious than a SaaS, and I hope nobody else does either.
Maybe what is needed is selective gating - some PRs are the type you REALLY have to make sure are reviewed; others can go through a barrage of AI reviews (security, code-quality etc) and the author can merge.
Either human or AI (or both?) needs to be tagging PRs. Perhaps a traffic light system is appropriate? Red - needs close human review; green - AI review only; yellow - unclear / somewhere in the middle.
Using PRs to merge features gives auditability and traceability to which human merged which thing.
As always, it is situational. AI is exposing new shades of grey.
The coding time is irrelevant and always has been. Time writing code has never been the high cost or challenge especially so in blue sky / green field development cases like those described in all these articles. And as far as ops processes go, we're already lightyears faster than we were even a decade ago. I could rant about ITIL and these integrated flow fantasies, but even that is a distraction.
The bulk of engineering time is spent engineering (not writing code), researching the right thing to build, reviewing plans with product ownership, considering operating context and constraints, adjusting designs and redeveloping based on learnings. Writing code is the easy part when everyone leaves you alone and you just cook. Those meetings aren't going anywhere because at the end of the day it takes a lot of back and forth to even come up with a relatively stable spec.
I agree that ops automation is important, but its hard to take this article seriously.
> Not just a quick hack...proper production-ready code with error handling, logging, environment checks, documentation, the entire implementation. Working, tested, committed to git. … This wasn't copy-paste from Stack Overflow. This was bespoke, production-ready code tailored to my specific Laravel app, following my existing patterns, with proper security considerations.
Why does any of this matter if you're barely bothering to look at/review it and you'll probably throw it out if there's a problem with it? If it only takes 34 seconds to generate, the whole thing is disposable and none of these things that are important for maintenance matter. It doesn't matter if it follows your existing patterns because you're not going to maintain it. Documentation doesn't matter, because you're not bothering to configure it or even understand how it works. And you're not going to figure out why it doesn't work, you're just going to ask the LLM to fix the bug or rewrite it for you.
You're trying to sell someone on using the bespoke, shrink-wrapped software generator by pointing out things that don't matter to people who want to use shrink-wrapped software, and do matter to people who are not interested in shrink-wrapped software.
> If you're a developer: Learn to work with AI tools. Not just as a fancy autocomplete, but as a collaborative partner. The developers who figure this out first will have an insurmountable advantage.
I guess if you can get it to generate code that looks like code you wrote, you can gloss over the fact that you didn't actually write it but still put your name next to it because you typed in the prompt. This is ordering food in a restaurant, and calling yourself a chef.
There's definitely utility, for some people in some situations, to be able to order food and have it delivered to them ready to eat. And there's utility to having a personal chef who will provide anything you ask for. But you don't call that cooking.
The article is complete nonsense because AI generated code is often buggy, and always needs to be reviewed in detail. Also, the code can only be good if the prompt is good and detailed. All of this takes up a significant amount of time. It would seem that the author is technically incapable of reviewing code, which is why it's not even an afterthought.
It took longer to get the API key
(algarch.com)24 points by jdalton 12 June 2025 | 35 comments
Comments
It’s exactly the same high-churn no-regard-for-the-user that is modern “tech”. I would not use this approach on anything more serious than a SaaS, and I hope nobody else does either.
Either human or AI (or both?) needs to be tagging PRs. Perhaps a traffic light system is appropriate? Red - needs close human review; green - AI review only; yellow - unclear / somewhere in the middle.
Using PRs to merge features gives auditability and traceability to which human merged which thing.
As always, it is situational. AI is exposing new shades of grey.
The bulk of engineering time is spent engineering (not writing code), researching the right thing to build, reviewing plans with product ownership, considering operating context and constraints, adjusting designs and redeveloping based on learnings. Writing code is the easy part when everyone leaves you alone and you just cook. Those meetings aren't going anywhere because at the end of the day it takes a lot of back and forth to even come up with a relatively stable spec.
I agree that ops automation is important, but its hard to take this article seriously.
Why does any of this matter if you're barely bothering to look at/review it and you'll probably throw it out if there's a problem with it? If it only takes 34 seconds to generate, the whole thing is disposable and none of these things that are important for maintenance matter. It doesn't matter if it follows your existing patterns because you're not going to maintain it. Documentation doesn't matter, because you're not bothering to configure it or even understand how it works. And you're not going to figure out why it doesn't work, you're just going to ask the LLM to fix the bug or rewrite it for you.
You're trying to sell someone on using the bespoke, shrink-wrapped software generator by pointing out things that don't matter to people who want to use shrink-wrapped software, and do matter to people who are not interested in shrink-wrapped software.
> If you're a developer: Learn to work with AI tools. Not just as a fancy autocomplete, but as a collaborative partner. The developers who figure this out first will have an insurmountable advantage.
I guess if you can get it to generate code that looks like code you wrote, you can gloss over the fact that you didn't actually write it but still put your name next to it because you typed in the prompt. This is ordering food in a restaurant, and calling yourself a chef.
There's definitely utility, for some people in some situations, to be able to order food and have it delivered to them ready to eat. And there's utility to having a personal chef who will provide anything you ask for. But you don't call that cooking.
I prefer smaller companies where you go to account settings and “download API key”.
This pain level is a genuine factor for me in using an big cloud service.
I haven't found a single service provider that made that step trivial
If using systems, securely, isn't trivial, then people will use other ways, or not use the system at all.
Now THAT is a task that I would like AI to deal with for me.