Skip to main content

Documentation Index

Fetch the complete documentation index at: https://agentic.proxify.io/llms.txt

Use this file to discover all available pages before exploring further.

You’ll learn: the mindset shift, how to size tasks for delegation, when to step in, and how to match autonomy to risk.
The shift from “coding with AI assistance” to “delegating work to AI agents” — this isn’t about prompting tricks. It’s a different way of working.

​
Mindset

Most engineers treat Claude Code like a chatbot. Vague request in, vague result out, blame the tool. The engineers getting 10x results are doing something different — they’ve stopped writing code and started designing systems that write code reliably.

​
The job changed

WhatStatus
Software developmentWriting code, running tests, committing changesAutomated. ~$10/hr, 24/7, never tired.
Software engineeringBuilding rails, managing failure domains, creating verification loopsStill you.
You’re a locomotive engineer, not a cargo carrier. The cargo still moves — you’re just not carrying it by hand anymore.

​
The questions change

BeforeAfter
How do I write this code?How do I specify this so an agent writes it correctly?
How do I review this PR?How do I build verification that catches issues before review?
How do I debug this issue?How do I patch my system so this class of issue stops happening?
Every question shifts from “how do I do X?” to “how do I design a system that does X reliably?” That’s the whole mindset in one sentence.

​
Earn trust through engineering

Every objection to agent autonomy — “what if it breaks production?”, “what if it makes bad decisions?” — is an engineering problem, not a reason to avoid delegation. Engineer rollback mechanisms. Engineer verification loops. Engineer back-pressure. The job is to engineer away the concerns. But don’t reach for the jackhammer before you’ve mastered the screwdriver. Start manual, understand why things work, then graduate to higher autonomy. If you skip straight to full automation without understanding the fundamentals, you’ll get terrible results.
User vs. practitioner — The user fixes bugs. The practitioner fixes the system that produced the bug. Every correction is a signal: what’s missing from my system that let this happen? That discipline is what compounds. See system evolution.

​
Delegation Levels

Match autonomy to risk. Start at Draft until you trust the agent’s output in your codebase.
LevelYou doAgent doesExample
SuggestDecide + implementAnalyze and recommend”What’s the best caching approach here?”
DraftReview + approvePlan and implement”Add pagination to the users endpoint.”
ExecuteVerify afterPlan, implement, and verify”Fix this failing test. All tests must pass.”
AutonomousSpot checkFull cycle including PRBackground agents, CI agents

​
Task Sizing

Not every task is a good fit for delegation. Good agent tasks are:
  • Well-defined — clear success criteria the agent can verify
  • Scoped — fits within one context window without losing important details
  • Testable — has tests or a verifiable output
  • Reversible — if it goes wrong, you can undo it (commit before starting)
Vague direction (“make this better”), tasks requiring external knowledge Claude doesn’t have, anything where failure is expensive and irreversible.

​
Context

The agent’s effectiveness is bounded by what it knows. You control that through three levers:

​
CLAUDE.md

Project-level context that persists across every session — commands, architecture, conventions, warnings. See the CLAUDE.md guide.

​
Skills

Domain knowledge that loads when relevant. Instead of explaining your testing philosophy every session, encode it in a skill. See the skills stack for how to get started.

​
Conversation

What you tell Claude in the current session. Be specific. Include error messages, file paths, expected vs. actual behavior. The agent can’t read your mind, but it can read your codebase — point it in the right direction.

​
When to Intervene

Let it runStep in
Making steady progress toward the goalGoing in circles (same failed approach)
Changes are small, incremental, and testableMaking changes you didn’t ask for
You can verify the outputApproach is fundamentally wrong
About to do something irreversible

​
Brownfield

Most real work is brownfield — existing codebases with history, tech debt, and implicit knowledge.
  • A good CLAUDE.md — the agent needs your conventions, gotchas, and architecture
  • Tests — the safety net that lets the agent make changes confidently
  • Incremental changes — small PRs that are easy to review, not massive rewrites
  • Git discipline — commit before delegating, branch for risky changes, review diffs carefully
The core tension — The agent doesn’t know what it doesn’t know. Your job is to fill the gaps with context (CLAUDE.md, skills, conversation) and catch what slips through (review, tests, hooks).