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.
When Antigravity's agent mode matured enough to handle real production work on my own apps — wallpaper, meditation, and productivity titles I maintain solo — 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.
Enforcing the Boundary in Code, Not Just Prose
Writing a boundary into AGENTS.md doesn't guarantee the agent respects it. That isn't a hypothetical concern — it was the actual tool behavior for a while.
Antigravity CLI 1.1.3, released on 16 July 2026, shipped two fixes to headless execution (-p). The first: tools requiring confirmation would either hang waiting for a response, or get silently auto-approved. The second: in always-proceed mode, file writes outside the workspace were being auto-approved by mistake.
After the fix, unpermitted tools are soft-denied and the allow rule name needed for approval is printed to stderr. If you run long agent sessions unattended overnight, that changes your assumptions about what was actually happening.
Reading that changelog sent me back to my own allow rules. Several of them were written six months earlier in a "let's just open this up for now" mood, and had never been revisited.
A boundary written in prose only works if something reads it. So I started dropping a small post-run gate into each project — a check that runs after the agent finishes and asks whether anything landed in territory I'd marked as mine.
#!/usr/bin/env bash
# scripts/delegation-gate.sh — boundary check to run after an agent session
set -euo pipefail
# Paths corresponding to the "human decision required" list in AGENTS.md
PROTECTED=(
"src/features/billing/"
"src/features/privacy/"
"src/i18n/messages/errors."
)
BASE="${1:-HEAD}"
CHANGED="$(git diff --name-only "$BASE")"
HIT=0
while IFS= read -r file; do
[ -z "$file" ] && continue
for p in "${PROTECTED[@]}"; do
case "$file" in
"$p"*) echo "⚠️ protected path modified: $file"; HIT=1 ;;
esac
done
done <<< "$CHANGED"
if [ "$HIT" -eq 1 ]; then
echo "→ Not auto-merging. Review this diff by hand."
exit 1
fi
echo "✅ No protected paths touched ($(echo "$CHANGED" | grep -c .) files checked)"The prefix match via case rather than grep -q is deliberate. A substring search for billing would flag src/utils/billing-format-test.ts, which nobody needs to review. Anchoring at the start of the path catches the directory you actually care about and nothing else.
Exiting non-zero matters because it lets the same script sit in CI. Run locally, it simply guarantees the diff gets your eyes before it gets merged.
In the first few weeks after adding this, the gate fired twice. Once it caught a change I genuinely didn't want, and I was glad to be stopped. The other time my protected path was written too broadly and it was a false positive — which turned out to be useful anyway, because it made me tighten the definition.
Prose boundaries and mechanical boundaries do different jobs. The first explains your reasoning to the agent and to your future self. The second is insurance for the nights when you're tired and inclined to merge without looking.
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
Working solo for years now, 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.