If it’s broken and the dev can’t debug it, the business won’t have much of a choice.

There is a lot of space between broken and high quality that won't necessitate any business letting people "learn" on the job.

That’s also true without AI. Engineers want more time to polish and businesses want to ship the 80/20 solution that’s good enough to sell. There's always going to be a tension there regardless of tools.

Don't you see the problem? Now engineers literally do not have any leverage. Did the model make it work? Yes? Then ship it, what are we waiting around for?

That sounds pretty much the same as it’s always been? It used to be: “Does the happy path work? Then ship it! There’s no time to make it robust or clean up tech debt.”

Now there actually is time to make things robust if you learn how to do it.

> Now there actually is time to make things robust if you learn how to do it.

What makes you think you are going to be given time to polish it? You would be pushed to another project. You have more responsibilities with none of the growth.

It takes very little time to polish now.

Again, provided you either had the skills.

Or you’re getting the model to do the polishing, thereby developing no skills of your own, and we’re back to the start.

Getting the model to do it is the skill.

That's an adorable idea, but requires willfully ignoring the existence of the Jevons Paradox.

You’re assuming that building something robustly is significantly more time consuming than the “quick and dirty” version. But that’s not really true anymore. You might need to spend another hour or two thinking through the task up front, but the implementation takes roughly the same amount of time either way.

One cannot build something robust just by thinking about it _a priori_, and while this was somewhat at the periphery of the author's argument, it is important.

You can’t get every detail right up front, but you can build a robust foundation from the beginning.

The argument seems to be that AI is causing managers to demand faster results, and so everything has to be a one-shotted mess of slop that just barely works. My point is that it doesn’t take much longer to build something solid instead. Implementation time and quality/robustness are not tightly coupled in the way they used to be.

This is what I have been thinking. Business will always try to do more with less because their only true goal is figuring out how to make more money. They will sacrifice giving those juniors time to learn from their mistakes for the sake of making more widgets (code). From the wider generational view, they will rob today's juniors from the chance to learn and thereby keep the talent pipeline full so they can profit today, the future (and the developers who will arrive there) be damned. The economic game is flawed because it only ever comes down to a single output that is optimized for: money. One solution? I think software people might consider forming unions. I know that's antithetical to the lone coder ethos, but if what this comment reflects is true, the industry needs a check and balance to prevent it from destroying its foundation from the inside.

Why would a business train anyone when they can lean on the govt to provide unbankruptable loans to the student to go to university to learn themselves