We're halfway through 2026, and you know what's wild? This one team—small, overworked, drowning in backlog—is still writing most of their code by hand. Manual ideation, manual system design, manual code reviews on every single change going out the door. In the year of our lord 2026, when AI agents can allegedly build your entire startup while you sleep, that's either admirable or borderline masochistic. The author, writing under the name Usama, isn't anti-AI—they tinker with these tools constantly on passion projects—but they've decided to exercise serious restraint at their day job in the medical domain (even though they're not a medical device software company). And they just published their reasoning.

Why Bother With Rules At All?

Here's the thing: you can only resist the siren song of vibecoding for so long. The backlog keeps growing, opportunities are staring you down, and everyone's already tasted blood from using LLMs on side projects. Usama gets it. But they argue that handing control to invisible AI agents without guardrails is how you end up with a codebase held together by vibes and prayer. So they're setting rules—not because AI is bad, but because unchecked AI at scale is how 1x engineers become 0.5x engineers when everything breaks and no one knows why.

The Usama Doctrine: Seven Rules for Human-AI Collaboration

First up: specify the actual need. Don't hand off work just because you can. Ask yourself if it solves a real, known problem. Can you name who benefits? Would they pay for this? Tangible benefit or it's not worth the risk. Second—and this one's crucial—do your own thinking before you let AI anywhere near design decisions. Read, form opinions, then use the LLM as a sparring partner, not your ghost writer. Third: write the task description yourself in your own words. Doesn't need to be an essay for small stuff, but hand it off only after you've articulated what success looks like.

Separation of Concerns Is Not Optional

Here's where Usama gets really practical. The agent you use for research and brainstorming is NOT the one writing code. The model that writes code is NOT the one reviewing it. Full separation of duties—no single AI touchpoint handles end-to-end delivery. Humans stay in the loop too: you're the first reviewer, then AI review comes second, another human last. And perhaps most importantly—never ship immediately after an AI-coded release. There needs to be a fixed rollback window because when something breaks in production? That's on you, not the agent.

The Realistic Goal: 1x to 1.5x

Usama is refreshingly honest about expectations. This isn't about becoming a 10x engineer overnight. It's about going from 1x to maybe 1.5x while actually maintaining quality standards. In a small team where every bug has real consequences—especially in healthcare adjacent work—that tradeoff calculus matters more than the productivity hype. The rules exist precisely because the author knows how tempting it is to just let the LLM take over when you're buried.

Key Takeaways

  • Specify tangible benefits before handing off any task to AI—solve known problems, not imagined ones
  • Always do your own thinking first; use LLMs as sparring partners, not ghost architects
  • Write task requirements in your own words before delegation
  • Separate research agents from coding agents from review agents—no single point of failure
  • Human reviewers come BEFORE AI review, not after
  • Enforce rollback windows on any release coded with AI assistance—you own it

The Bottom Line

This isn't a manifesto against AI-assisted development—it's a playbook for not becoming dependent on black boxes you don't understand. Usama's rules are common sense wrapped in hard-won experience: stay in control, maintain accountability, and remember that productivity gains mean nothing if you're shipping technical debt at scale. The tools will keep getting better. Your discipline has to keep pace.