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:

  1. 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.
  1. Never trust the automation without checking instruments.
  1. 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 are viewing a single comment's thread
view the rest of the comments
[–] 10 points 19 hours ago (5 children)

i’d say it’s not quite like a compiler because you still need to know what the code does… a compiler you largely don’t care, and it’s deterministic… an LLM hallucinates, so you can’t just trust it, which means you have to be able to assess when it’s doing the wrong thing

i agree that setting an agent going helping you learn a codebase is reasonable, largely because it can quickly point out connections in the code quicker than you can understand the architecture, and its guesses are usually just as good as your guesses until you get knowledgeable with the codebase

however, and that’s a very load-bearing however, i don’t think you should just jump into a codebase and just go ahead and tell the LLM to write new code without understanding what it’s done… the understanding is exactly what this graph is trying to show: actually learning is critical, so your review of the code becomes doubly important: you’re gaining institutional knowledge, and you’re making sure the output isn’t slop

  • source
  • parent
  • hideshow 5 child comments
  • [–] -3 points 18 hours ago (4 children)

    an LLM hallucinates, so you can’t just trust it, which means you have to be able to assess when it’s doing the wrong thing

    Unless you can define what the right thing is. Then you just have it write proper tests, and it’s able to verify itself.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 3 points 14 hours ago

    an LLM frequently writes shit tests… you’re just moving the architecture problem: either you properly understand and review the initial code, which means you catch not just binary “correct input/output” but also performance, layout, DRY, style, heaps of things

    OR

    you properly review the tests because “passing” doesn’t mean tested

  • source
  • parent
  • [–] 2 points 13 hours ago

    Don't let an AI verify itself, it will just make the exact same mistakes.

    Verification should still be done by a human. You can use a different AI in addition to human verification, but a human should still be in the chain somewhere.

  • source
  • parent