Confessions of an AI‑Drunk Developer: The Seven Sins We Won’t Admit in Meetings
Ask us in a formal meeting, and we’ll give you the company line. We’ll talk about rigorous CI/CD, clean architecture, and maintainable code. We’ll throw around weighty words like determinism, idempotency, and domain‑driven design. We sound like model engineers.
But after hours, when the managers are gone and our IDEs are in dark mode, the truth comes out. We are utterly, hopelessly drunk on AI. We summon LLMs like mad wizards, committing software engineering sins that would make Fred Brooks weep. Let’s drop the pretence and admit what we’re actually doing.
1. We’ve decided that deep knowledge is overrated
Object‑oriented programming? Functional programming? The CAP theorem? Design patterns? Honestly, we’ve stopped caring. We don’t even keep track of which frameworks or runtimes we’re using anymore—the AI just figures it out. We’ve freed up our mental bandwidth for more important things, like our side project (a novel about AI taking over the world). Okay, maybe that’s an exaggeration. Maybe.
2. We haven’t read the docs in years
We still say “RTFM” to juniors, but we haven’t actually cracked a vendor manual since 2023. Stack Overflow is a ghost town. When we hit a weird exception, we don’t trace the stack or read the release notes. We copy the 200‑line error dump, paste it into the chat, and wait for the machine to spoon‑feed us the fix.
Even better, our agentic IDE just spots the error, proposes a fix, and asks if we want it applied. We might glance at it if we’ve been going in circles for a while—maybe. We used to buy chunky reference books; now we just ask an AI to transliterate our JavaScript into Rust. We’ve gone from methodical engineers to glorified copy‑paste operators.
3. We have no clue how the back end is wired
If you asked us to describe the data flow, we’d act like we meticulously designed it. In reality, we asked the AI to scaffold the whole deployment, hooked it to a database, and just… ran it.
The security rules? AI wrote them—they seem to work, which is nice. The schema? We skimmed it for about four seconds—looked reasonable. The infrastructure‑as‑code? We hit deploy and hoped it wouldn’t blow the budget. If management asked us to do it all manually, without our chat window, we’d just stare blankly. (But hey, management is using AI to manage the project, too.)
4. Our tests are uncomfortably incestuous
TDD used to be a noble but distant dream. Now, we magically hit 95% test coverage. The secret? We ask the exact same AI that wrote the complex logic to write the test suite that validates it.
It’s a closed, hermetically sealed loop of self‑congratulation. The mocks, the edge cases, and the assertions are all just an echo chamber of the model’s original assumptions. The machine is grading its own homework—and giving itself an A+. We’re perfectly happy with this, because when the code changes, the AI just hallucinates new tests to match.
5. We pass off AI‑generated architecture as our own strategy
AI writes stunning design documents. They’re beautifully formatted, perfectly bridge business goals and technical specs, and even include those fancy sequence diagrams that management loves.
In Tuesday’s sprint meeting, we lean back, sip our coffee, and humbly accept the team’s praise. What we don’t mention is that we spent four seconds generating it. Sure, these documents might harbour a foundational logic bomb that will doom the project later. But the markdown is so crisp, and the bullet points so persuasive, that nobody notices. We’ll worry about that bridge when it catches fire.
6. We’re secretly addicted to “vibe coding”
Publicly, we mock the term. We roll our eyes at the kids on TikTok building startups with vibe coding. We cling to our identities as hardened professionals who understand memory management and bitwise operators.
But late at night, when nobody is watching? We love it. We throw a chaotic, half‑baked thought at the canvas, pour a drink, and watch the AI magically spin up a functioning app. “Create a crypto tracker that looks like the Neuromancer interface”—and 30 seconds later, it’s there. It feels like magic. The deeper our roots in the old‑school realities, the sweeter this guilty pleasure.
7. We beat the problem into submission with prompts
Like a gambler on a losing streak, we’re convinced the next prompt will fix everything. When things go off the rails, we don’t put on our debugging boots. Instead, we cycle through tonal adjustments:
- The condescending: “Look closely. The error is right here.”
- The desperate: “We’ve been on this for hours!”
- The pathetic: “Can’t you just try a different approach?”
And the astonishing part? It often works.
When the context window collapses and the regressions cascade, we drop all pleasantries. We switch to ALL CAPS. We feed the same failing stack trace back over and over, explicitly forbidding libraries, pasting release notes—narrowing the model’s path until the code finally stops throwing errors. We don’t debug anymore. We just apply relentless, iterative pressure until the machine surrenders. Then we push to production.
The final black box
Writing is the only profession more addicted to AI than programming. But here’s the troubling part: it used to be that only other programmers could understand what a programmer was doing. Now, even that isn’t true. Only the machine knows what the machine is doing. We just keep it tethered to our aims.
Hopefully.