Por qué dejé de tratar la IA como empleado y empecé a tratarla como subcontrata

Por qué dejé de tratar la IA como empleado y empecé a tratarla como subcontrata

Ago 20, 2026 ai coding agents vibe coding developer workflow git workflow agentic engineering solo development code review ai tools

The Moment Everything Changed: Why I Stopped Treating AI Agents Like Junior Developers

Something happened to me last quarter that completely flipped how I think about AI coding tools.

I was debugging a feature for three hours straight. The agent had done everything right—or so I thought. It committed changes, pushed to production, and even dropped a friendly message saying the task was complete. But here's the thing: the code was fundamentally broken. Not a simple bug. A complete misunderstanding of what we actually needed to build.

That moment broke my mental model.

I had been thinking of these agents as helpful juniors who just needed direction. But real junior developers don't deploy untested code to production while you're getting some sleep.

So I threw out that metaphor and started fresh.

The Subcontractor Mindset

Now I treat AI agents like subcontractors instead of employees.

What's the difference? A subcontractor doesn't get keys to your office. They don't show up unannounced. They finish their assigned work, then send you an invoice—which you review before approving. If the work isn't up to standard, back it goes.

This isn't about being paranoid. It's about aligning incentives and creating real accountability. When an agent knows its job is to deliver something for your review—not to make decisions on its own—it performs better. It's focused. It stays within boundaries.

Making It Work Technically

A mindset shift alone won't cut it. You need actual technical safeguards.

Token Permissions Are Everything

My agents use credentials that literally cannot touch production. They can read from the main codebase, but they only have write access to a separate staging repository. This isn't a policy—it's a cryptographic lock. Even if an agent goes off the rails or hallucinates a git command, it physically cannot modify production. The tokens won't let it.

The Staging Repo Is Like a Drop Box

Nothing auto-merges from staging. The default branch there is literally useless—just a README that says "please use the main branch." Agents push their finished work there and notify me. Then I review, pick what works, and integrate it myself.

This sounds tedious until you remember: this is basically how the Linux kernel has operated for decades. Contributors submit patches. Maintainers decide what gets in.

Human Review Is Non-Negotiable

No agent ever merges its own code. Period. I don't delete a branch until I've independently verified—programmatically—that its changes are safely inside production. "Trust but verify" is weak when verification costs you nothing.

Why This Works When You're Flying Solo

Here's what nobody talks about: when you're building something alone or on a tiny team, you're not just writing code. You're carrying context that exists nowhere in the repository. Your history of incidents. Your edge cases. That one client with the weird setup. The three approaches you tried that flopped.

Agents read files, but they don't understand your world. So the goal isn't to give them more freedom—it's to maximize what they can safely accomplish within your review time.

This is where "vibe coding" gets an unfair reputation. Done badly, it's letting agents do whatever and hoping for the best. Done well, it's using AI to multiply your judgment, not replace it.

The Unexpected Bonus

Once you embrace the contractor relationship, something weird happens: you take more risks.

I now spin up experimental features I'd never have tried before. Why? Because the downside is contained. An agent can't break production. It might deliver something surprisingly good or surprisingly wrong—but either way, I catch it before it matters.

In the last six months, I've started more side projects than in the previous two years combined. Not because I'm working harder—because I'm delegating aggressively within safe guardrails.

How to Apply This Today

If you're using AI agents for development, ask yourself these questions:

  1. What can my agent access right now? If it's production, that's a red flag.
  2. Is there a technical barrier stopping bad actions, or just a verbal agreement?
  3. Who's merging code? If it's not a human, why not?

The tools already exist. Scoped tokens, separate staging repos, branch protection—none of this is exotic Git wizardry. It's the difference between AI-assisted development and AI-caused disasters.

Your judgment is the bottleneck. That's not a flaw—that's the feature. These agents exist to amplify what you're capable of, not to substitute the decisions that make software actually work for real people.

Build with that in mind.

Read in other languages:

EL CS RU BG UZ FI TR SV PL RO PT NB NL HU IT FR DE ZH-HANS DA EN