Ever feel like your job title quietly changed from "developer" to "AI babysitter" without anyone sending a memo?
That's botsitting. Not a term you'll find in any job description yet — but every developer I know is already doing it. You're not writing code anymore. You're managing something that writes code, which sounds like a promotion until you're on hour three of auditing a function you could've written yourself in 45 minutes.
An LLM can spit out a massive boilerplate framework before you’ve even finished your first espresso. It feels like you're moving at warp speed. But then the reality check hits, and you spend the rest of your afternoon hunting down bizarre edge cases and UI quirks that no human developer would ever commit to git.
Some devs absolutely love this prompt-engineering era. Others are burning out fast because they’re losing the actual joy of building things (yes, programmers are that weird) and hate spending their days auditing a machine's homework.
And that’s how we slip into the dark side: botsh*tting. People get so utterly exhausted by the relentless code reviews that they just shrug and hit approve. The unverified AI slurry goes straight to production, and suddenly the whole architecture is held together by digital duct tape.
So, how do we handle all this?
The Survival Guide for Smart Botsitting
- Pre-load context: Connect your internal wikis and style guides to your LLM tooling so you stop typing the same ground rules every single morning.
- Adopt spec-driven development: Write strict, unambiguous markdown specifications detailing inputs, outputs, and edge cases before letting the AI touch the file.
- Draw boundaries: Decide exactly which repetitive tasks the bot is allowed to draft, and which architectural decisions require human grey matter.
How to Stop the Slurry
- Enforce human ownership: Put a single name on the ticket who is entirely accountable for the code, because if you can't explain how the bot built it, you shouldn't ship it.
- Audit the output: Bake an explicit "AI review" gate into your CI/CD pipeline rather than treating it like standard peer review.
- Measure outcome quality: Stop rewarding teams for how much AI they use, and start rewarding them for how few production fires they have to put out.
- Course-correct the prompt: If the AI derails three times, diagnose the missing context, break the task into smaller sub-functions, and guide it back on track.
Navigating this loop doesn't mean we should fight the tools. Instead, it means realizing that AI forces us to upgrade our skills from raw execution to high-level system engineering. If you treat the machine like a brilliant, hyperactive intern—keep the guardrails tight and manage the output properly—it remains the best force multiplier we've ever had.
