- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
cross-posted from: https://programming.dev/post/56563524
We’re about to learn a painful lesson about delayed gratification in software engineering.
New data from China, 26,811 students tracked January 2023 through June 2025. Students using AI for homework saw their scores jump 20 percent. Completion time dropped nearly half. They aced the assignments.
Then exam season came. Those same students scored 20 to 40 percent worse when they couldn’t use the tool.
The homework phase is over. The exam phase is coming.
We’re doing this in software right now. Vibe coding feels incredible. Features ship fast. Nobody’s asking what happens in Month 18 when the original dev has left and nobody understands the codebase.
Commercial pilots fly with autopilot for most of every flight. They’re required to maintain manual flying proficiency regardless. If the system fails mid-air and the pilot can’t take over, people die.
Most teams using AI right now have forgotten how to fly manually. They’ve become passengers in their own systems. The autopilot flies, nobody checks instruments, and the first sign of trouble will be a breach notice or outage.
Three rules:
- Command the mission. Define architecture before prompting. Ambiguity kills in code and in flight. Delegate selectively. Offload mechanical work. Keep design and security reviews human. Verify everything. Audit before production.
- Never trust the automation without checking instruments.
- Quick wins feel good. Sustainable engineering feels boring. Boring keeps systems standing.
Organisations surviving the next two years won’t ship the fastest. They’ll be the ones who remember how to fly without the aids.
people insisting that you actually be skilled, independently of your tools, doesn’t make them Luddites. Rather, being unable to do so makes you a phony.
You must log in or # to comment.
I think this is great! Because I have written so much code by hand, I’ll always have an edge over the pure vibe coders. As time goes on, I’ll be worth more and more! Muwahahaha!
Seriously, though: There’s a great big difference between someone who uses the AI to architect their code and someone who uses AI to just speed things up a bit.
If you let AI make code architecture decisions it’ll almost always get it wrong. It’ll make mind-bafflingly bad decisions about security (especially separation of privilege and permissions management), programming patterns, and almost always fails the Unix style of separation of concerns (e.g. write a tool/module that does one thing but does it well).
When you let the AI model handle too much you end up with so much technical debt you end up having to start over from scratch. Actually, you end up having to do that anyway but if you know what you’re doing that’s not a big deal because “starting over from scratch” means remaking a tiny module or even a single function instead of the whole application.
Making architecture decisions with AI is fine. Don’t let it choose one and just go forward with it.
There is no free lunch.
