When I started out, I told anyone who’d listen that cloud storage was trivial. “How hard could it be? Just rsync the diffs and call it a day.”
Here’s what I didn’t understand: Dropbox isn’t rsync. It’s a distributed consensus algorithm wrapped in delta encoding, layered atop conflict resolution heuristics, with background sync threads that don’t die when your laptop sleeps, and version history that survives accidental deletions, ransomware, and the inevitable “oops I deleted my entire directory” moments.
That weekend proof-of-concept script I wrote? It worked beautifully for seven minutes. Then two files collided, the merge failed silently, and I lost three hours of work.
The gap between “it works once” and “it works reliably for five years while 10 million users depend on it”? That’s not a feature gap. That’s the SDLC. That’s operations. That’s the difference between a hacker and an engineer.
“Doing something once makes you a wizard. Doing it over and over again for years makes you an engineer.”
We’re seeing this play out again with AI-assisted development. “Vibe coding” — throwing prompts at Claude, accepting every suggestion without reading the output, shipping whatever the LLM generates. The HN discussion on why there’s no “vibe engineering” hits the nail on the head: https://news.ycombinator.com/item?id=43533539
Here’s what the AI tools don’t tell you:
- Your bus factor just dropped to zero. The bus factor is how many team members could get hit by a bus before the project fails. With AI code, it’s not just low — it’s nonexistent. You can’t maintain what you didn’t write, and the “author” (the LLM) isn’t available tomorrow.
- Debugging AI-generated code is debugging someone else’s hallucination. Without understanding the control flow, you’re patching symptoms, not causes.
- Security reviews become impossible when you don’t understand the logic. An auditor can’t verify what they can’t trace.
- Technical debt compounds faster when the code was written by a probabilistic model. There’s no documentation, no commit history explaining why, and no maintainer to ask.
This tweet below hit close to home. A startup builds their own Jira clone because existing tools are “too bloated,” vibecoded by a QA lead. Six months later, maintaining it takes more bandwidth than the actual product work. They went back to Linear.
Sometimes, boring tech is the right call. Sometimes, the vendor lock-in trade-off is worth the time you save on not having to build your own infrastructure from scratch. Innovation tokens are finite. Spend them on what differentiates your business, not on reinventing project management software with an LLM.
Quick wins never account for O&M costs. AI doesn’t change that equation — it accelerates technical debt accumulation at compound interest.
So yeah, welcome to engineering. It’s humbling. And if you’re lucky, you learn the hard way before production burns down.
Related Reading
- Original Nordic Track Hacking Post — Vendor lock-in in consumer hardware
- SQLite to PostgreSQL Migration — Why data migrations earn respect quietly
- Innovation Tokens Deep Dive — Dan McKinley’s framework for architectural decisions
#Engineering #SoftwareDevelopment #SDDLC #DevOps #VendorLockIn #BoringTech #InnovationTokens #AI #LLM #VibeCoding