There's a moment every developer hits when working with AI agents: you delegate a task, the code comes back clean, tests pass — and yet something feels off. The agent did exactly what you asked, but not quite what you meant.
I've been building apps independently since 2014, with a catalog that has crossed 50 million total downloads across wallpaper, meditation, and productivity apps. When Antigravity's agent mode matured enough to handle real production work, I leaned into it hard. And in the first six months, I made some expensive mistakes — not because the AI was incapable, but because I hadn't thought clearly about what I was actually asking for.
Here's what I've worked out since then.
What Agents Are Genuinely Great At
The clearest mental model I've found: AI agents excel at reaching a well-defined destination efficiently. When the goal and constraints are explicit, they move faster and more consistently than I can.
Boilerplate and transformation work. Type definitions, unit test scaffolding, i18n translation passes — tasks where the pattern is clear and the output is verifiable. Before I started using agents for multilingual support (my apps cover 15+ languages), this kind of work consumed days per release. Now it's a matter of minutes.
Scoped refactoring with a clear target state. "Convert this function to a pure function" or "split this class into composable pieces" — when the goal is precise, the agent rarely misses. The critical word is scoped. "Make this cleaner" doesn't have a verifiable finish line, so the agent will optimize for its own aesthetic, which may not match yours.
Hypothesis generation for debugging. Pasting an error log and asking for three plausible causes is one of my most-used patterns. The agent won't always be right, but it surfaces angles I might not have considered for another hour. The final diagnosis and fix still requires my judgment — but the search space shrinks dramatically.
Documentation and changelog generation. I keep git commit messages fairly disciplined, so I can ask an agent to generate a user-facing release note from a range of commits. The result usually needs editing, but the structural work is done. For a solo developer, this turns a chore into a five-minute review.
What Belongs to You
Last autumn, I handed off a significant refactor of the in-app purchase flow in one of my wallpaper apps. Technically, the result was excellent: cleaner code, higher test coverage, better performance under the profiler.
A few weeks later, subscription cancellation rates ticked upward. When I traced it back, the agent had made a technically sound but experientially awkward decision in the UI flow — one that subtly undermined the moment users feel good about their purchase. The agent had no way to know that. It had never talked to my users.
Three things that only you can carry into a delegation:
User context. Why this particular app matters to this particular user. This lives in years of support emails, App Store reviews, and intuition — none of it is in your codebase.
Business logic priorities. Where the tradeoffs sit right now between speed, quality, and revenue. That balance shifts with every sprint.
Future intent. What this code needs to become in three months. An agent optimizes for the present state of your instructions.
Naming and tone decisions. Button labels, error messages, onboarding copy — language that carries emotional weight with users. Agents can generate competent copy, but they don't know what voice has been working for your community for years.
The 5-Minute Design Note
After enough frustrating experiences, I started writing what I call a delegation note before starting any agent task of significance. It's three short lines:
Purpose: [Why this work matters — user value or technical necessity]
Done looks like: [A concrete, verifiable end state]
Constraints: [What must not change; context the agent needs]
For the purchase flow refactor I should have written:
Purpose: Migrate to StoreKit 2 receipt validation for iOS 17+ compatibility.
Done looks like: All existing tests pass; purchase flow tap count stays identical.
Constraints: Do not modify UI copy (managed separately);
do not change the number of screens in the purchase flow.
Five minutes upfront. The habit has saved me more than a few multi-hour debugging sessions.
There's a useful secondary effect: if you can't complete those three lines, that's a signal that you haven't finished the design yourself yet. That's valuable information — delegate after you're clear, not before.
Using AGENTS.md as a Boundary Marker
Antigravity's support for AGENTS.md at the project root isn't just for teams. For solo developers, it's a way to encode your accumulated judgment into the agent's context.
My typical structure:
# AGENTS.md
## Architectural intent
- All billing logic lives in src/features/billing/.
Other modules do not touch it directly.
- UI components reflect user research findings;
don't change them for purely technical reasons.
## Delegate freely
- Test generation (snapshot + unit)
- i18n string additions
- Type definition generation from API specs
## Human decision required
- Any change to purchase or subscription UI
- Privacy-related processing that affects App Store compliance
- Error message copywritingThis file does two things: it tells the agent where the boundaries are, and it reminds you of decisions you've already made. Both matter.
I update this file whenever I make a decision I don't want to revisit — which, for a solo developer, is effectively a way of committing reasoning to the project, not just code.
Recognizing the Failure Mode Early
There are a few warning signs I've learned to watch for that usually mean a delegation is about to go sideways.
The instruction keeps growing. If you find yourself adding more and more clarifications to a prompt, you're probably working around an underspecified task. Stop, write the delegation note, and start fresh with a precise scope.
You don't have a way to verify the output. Before delegating, ask yourself: how will I know this is done correctly? If the answer is "I'll read through the code," that's not verification — that's review. For anything business-critical, build a test or a concrete acceptance criterion first.
You're delegating because you're avoiding the problem. Sometimes the hardest part of a task is figuring out what to build, not building it. Delegation doesn't solve that — it just produces code faster around the unresolved question. The decision still has to happen; it just gets deferred into a debugging session.
The Economics of Delegation for a Solo Developer
One frame I find useful: think of delegation not as "handing off work" but as "buying back decision bandwidth."
Every delegation frees up cognitive space to think about something else. The question is whether the thing you freed yourself from required your judgment — or just your fingers.
Boilerplate never required your judgment. Debugging hypotheses can be crowd-sourced from the model. But the decision about whether a subscription modal should appear before or after a user has experienced the core feature? That's yours. It depends on things only you know — your conversion data, your churn patterns, the shape of the community around your app.
Use agents to move faster on the implementation that follows decisions. Reserve your attention for the decisions themselves.
A Practical Checklist Before You Delegate
After enough cycles, I've condensed my pre-delegation check to five questions. I run through these mentally before starting any Antigravity agent session that touches production code.
1. Can I state the end state in one sentence? If not, the task isn't ready to delegate. Spend five more minutes clarifying.
2. What would a test for this look like? If I can't describe a test, I don't yet know what "done" means. Write the test description first.
3. Is there anything in this task that touches user-facing behavior? If yes, add an explicit constraint about what cannot change. Don't assume the agent knows.
4. Does this task cross an architectural boundary I care about?
If so, put the boundary in AGENTS.md now, before the session. Not after.
5. Am I delegating to decide faster, or to avoid deciding? Honest answer required. If it's the latter, the delegation will cost more than it saves.
This checklist takes under two minutes. The return on those two minutes is consistently positive.
Start by Clarifying What You're Deciding
Over twelve years of solo development, I've come to think of accumulated judgment as the most valuable thing I own as a developer — the knowledge of why certain decisions were made, built up through thousands of support conversations and product iterations that never made it into any commit message.
That judgment is not something I can delegate.
What I can delegate is the work of getting to a decision faster. The agent prepares the terrain; I decide what to build on it.
Before handing off the next task, take one minute to ask: what decision am I actually making here? If you can answer that clearly, you're ready to delegate. If you can't, the five minutes you'd spend writing a delegation note will be among the most productive of your day.