Reading always was a worse way to learn than doing. When we stop doing, we will have to triple our reading (if that's even enough), but will we do that or just trust the agents more and more?
Just yesterday, I was trying to use Claude Opus 4.7 to debug an issue in a program that I wrote, and its solution was to remove a feature, change the design to eliminate the problem without consulting me. I only found out that it had removed this feature through testing. Imagine not reviewing things like that. How can people argue for this with a straight face? We'll probably get there eventually, but there's no need to rush before the tech is ready. Doing that is just being clueless.
Nobody can be sure of what the LLM will output for a certain prompt. If you don't review what it outputs, it will not necessarily match your expectations. You could argue that it is the same as when you assign an intern to the task, but I personally would check what the intern writes (and in my experience they are more reliable than current AIs, of course not as quick).
but, according to the worst offending and persistent ai-hyper comments on this site, this is apparently a paradigm shift unlike anything that’s done before. according t them we don’t even need to understand high level languages, let alone machine code. which is frankly ridiculous.
i’m an “AI luddite”. but i accept there are useful use cases. that’s not where all the wasted money is going though.
Your CTO was just shown a demo where a fairly complex piece of software was spat out in MVP form within a few hours. Something that used to take months is now more-or-less completed in a two-week period, including deployment.
The CTO knows that competitors are seeing the exact same thing and are going to try it for themselves. Now your company has to use the LLM because that's going to enable the development speed seen in the demo if they want to stay in business.
There's the iron triangle of engineering: fast, cheap, good. You used to have to pick two. And in reality, you still have to pick two, but a lot of this technology is sold as allowing you to pick all three. It lets you pump out a MVP:
1. fast - it's done in a few days 2. cheaply - you don't have to pay engineers as much or at all 3. it's "good" - it looks good enough for the client to accept it instead of suing you and give you revenue.
The third part is where this breaks down. Like you say, people aren't reviewing this code. It's probably 85%-95% of the way to fulfilling all use cases, but that 5%-15% is the critical part where there's SLA violations and risks to business, property, or people. The thing is, clients have to find that within the first 90 days to have it impact the books for that quarter, and they probably won't. Also, you have lawyers who can drag it out further. If the company really gets screwed by quality problems, well, sell to a competitor or someone and return value to shareholders that way. There's always some way to get cash back.
So we've pushed out code faster, gotten revenue booked, and have a way to not lose money in the short-term, which is ultimately the only term that matters. The goal was never making good code; it was making money as fast as possible. Velocity. LLMs deliver on that.
But at least for me, I really read a lot of code, a lot of PRs from others and evaluated them.