| I don't think it's necessarily a question of laziness. It's more about velocity. 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. |