I used to teach people to code. And looking back, I was teaching students to write it by hand while the tools that write it for them were getting better every single month. So what should a coding classroom actually look like now?
Every legacy codebase is a palimpsest: layers of decisions written on top of each other, none fully erased. Geoffrey Dhuyvetters argues that what looks like technical debt is often stratigraphy, and you read it before you rewrite it.
In part three, we look at both sides of the AI contribution debate. A working patch, real demand, never submitted, rejected because AI was involved. But maintainers are unpaid volunteers, and AI halved the cost of contributing without touching the cost of review. Both sides have a point.
Developers don't skip standards because they're careless, they skip them because there are fifteen things to remember and the code was the hard part. The real question isn't which tasks your LLM handles well. It's what's still slipping through ungated.
Technical debt used to justify meetings, trade-offs, and dedicated sprints. AI has changed that. Cleanup is now fast, cheap, and continuous. Teams that stop debating and start fixing unlock faster delivery and better outcomes.
AI made writing code faster, but the real economics of software engineering were never about typing code in the first place.
Go for one codebase or multiple repositories? A question multiple CTOs and technical founders have asked. It can be a surprisingly expensive decision nobody warns you about.
LLMs generate code on demand, but they do not replace maintainers, communities, or years of shared learning. This piece explores how AI-assisted coding risks fragmenting logic, increasing technical debt, and slowly eroding the open source ecosystem.
Vibe coding or AI-assisted development? The choice isn't binary, but getting it wrong at the wrong stage will cost you. This piece breaks down when to embrace speed over architecture, when to take back control, and why the best teams don't pick sides.