The AI Engineering Lead for Claude Code

Scoping engineering work before any code is written is the hardest problem in AI-assisted development, and the one that every mainstream AI tool skips entirely. It is the moment where the wrong decision compounds: too narrow a scope and you are back in three weeks with a bigger refactor; too broad and you have burned sprint capacity on work nobody asked for; wrong specialist and you have a competent output in the wrong domain. Generalist chatbots and autocomplete tools treat this moment as if it does not exist. They interpret a brief and start producing output, optimizing for momentum rather than precision. What a real ai engineering lead needs to do is pause before the keyboard, inventory the actual system, weigh the options, and return a structured decision, not a code suggestion. That gap between instinct and engineering discipline is exactly what Apex was built to fill.

Why the generalist approach breaks down

When you take a complex engineering problem to ChatGPT or Claude.ai, you get a response shaped by the question you typed, not by a systematic read of the system you are building on. A generalist diving into auth work will write code before scoping; an engineering lead decides what depth of work the auth refactor actually needs. The generalist has no mechanism for presenting you with three options of increasing investment and letting you pick one. It has no concept of coordinating a handoff to a security specialist after the scope is set. It will write the function and stop, having produced something that looks complete but skips every architectural decision you actually needed to make.

Cursor and GitHub Copilot solve a different problem. They are excellent autocomplete layers, fast, context-aware, tightly integrated into the editor. But an autocomplete layer is not a lead. It does not produce a project brief. It does not look at your git history and tell you what the real state of the codebase is. It does not dispatch a backend specialist when the work requires one and a security specialist when that work intersects auth. When you ask Cursor to scope a multi-tenant refactor, you get a suggestion for the first file to edit. When you ask Apex to scope the same brief, you get three options with time and token cost estimates, and then, if you pick one, the right specialists are dispatched.

The fundamental mismatch is role. A generalist tool plays one role, code responder, and plays it in every situation, regardless of whether the situation calls for a responder or a planner. Engineering projects require a layered team: someone who leads and decides, someone who scopes and estimates, someone who delegates to the right domain expert, and specialists who own their respective disciplines. Trying to compress that entire structure into a single generalist prompt chain creates the worst of both worlds: a tool that is too opinionated to be a blank slate and too shallow to replace a real lead. The output looks productive in the short term and creates chaos at integration time.

What an engineering lead actually does

In a human engineering team, the tech lead or engineering manager is the person who translates ambiguous business intent into executable technical plans. They scope work before it starts, not after. They decide which engineer is best suited for a given problem, and they review the result for cross-cutting concerns that any individual contributor would reasonably miss. They are not the person writing the most code, they are the person ensuring that the right code gets written by the right people at the right depth. Their output is plans, handoffs, reviews, and status visibility. The code is downstream of all of that.

The engineering lead role is also the hardest to replicate with AI because it requires judgment that operates above the code level. It is not about knowing the syntax of a programming language or the API surface of a framework. It is about knowing when a request is underspecified, when a quick fix will accumulate technical debt, when a system needs a new abstraction instead of another patch, and when the right answer is to route the work to a specialist rather than proceed alone. These are judgment calls that require context: context about the current codebase state, about the investment the team can make, about which risks are acceptable and which are not. That requires a different kind of agent, one built for the lead role specifically, with the right skills to scope, delegate, and review, not one that was trained to do everything and is deployed for everything as a result.

Meet Apex

Apex is the engineering lead of the Tonone team for Claude Code, a purpose-built agent that occupies the lead role rather than the contributor role. Where Tonone's 22 specialist agents each own a technical domain (infrastructure, backend, security, data, mobile, and so on), Apex sits above them: scoping work, dispatching the right specialists, reviewing cross-cutting concerns that cross domain boundaries, and producing the kind of clear-eyed status visibility that a CTO needs to make decisions. Apex does not write the most code in the system. It decides what code should be written, who should write it, and how deep the investment should go.

Tonone's Apex is the AI engineering lead that scopes engineering projects before any code is written, presenting S, M, and L depth options with time and token cost estimates.

What Apex actually does

Planning scope before writing a line

The apex-plan skill is where most sessions start. You give Apex a rough project brief, as informal as a Slack message, as formal as a product requirements document, and it does not immediately produce code. Instead, it reads the brief carefully, asks clarifying questions if anything is underspecified, and then produces a structured scope with three options: a Small option that addresses the core requirement with minimum investment, a Medium option that includes the obvious adjacent improvements, and a Large option that treats the requirement as an opportunity to modernize the relevant system. Each option comes with a time estimate and a token cost estimate so you can make an informed decision about how deep to go before any implementation begins. This is the discipline that generalist tools skip and that experienced engineering leads perform almost instinctively. The plan output is designed to be read by a human, approved or adjusted, and then handed off, either to a specialist agent or to human engineers who now have a clear brief to execute against. The apex-plan output typically runs two to four pages and includes a prioritized risk section so nothing important is buried.

Taking ownership of an existing codebase

One of the most common and most anxiety-inducing situations in engineering is inheriting a codebase you did not build. The apex-takeover skill is designed for exactly this situation. Before proposing a single change, it performs a systematic inventory: it maps the services and modules, reads the dependency tree for version drift and known-vulnerability packages, traces the data flows to find where state lives and where it crosses boundaries, identifies the highest-risk areas (the files that change most frequently, the ones with no test coverage, the ones that touch auth or billing), and produces a written summary of what you have inherited and what you should know before you touch anything. This is not a superficial README-style summary, it is the kind of intake assessment a senior engineer would perform on their first week at a new company. The output from apex-takeover becomes the foundation for everything that follows: scoping new work, deciding which technical debt to address first, briefing incoming contributors, or generating onboarding documentation via Atlas.

Tonone's Apex apex-takeover skill takes ownership of an existing codebase by inventorying services, dependencies, and risk areas before proposing any changes.

Generating CTO-level status from git state

The apex-status skill turns the raw state of a repository into a human-readable status report at the level of detail a CTO or VP of Engineering needs to make decisions. It reads git history, open branches, recent commit patterns, the age of in-flight work, and the overall shape of the codebase to produce a structured report covering what shipped recently, what is in progress, what is blocked or stalled, and what the current risk posture looks like. This is the kind of report that takes an experienced engineering manager two hours to assemble manually from Jira, GitHub, and Slack, Apex produces it from the repository state in minutes. The output is not a raw diff or a commit list; it is an editorial summary with an assessment of velocity, health, and any flags that warrant attention. For teams running on Claude Code, apex-status becomes a lightweight replacement for the Monday morning status email, without requiring anyone to write it.

Cross-cutting review across specialists

Any reasonably complex engineering project touches multiple domains: the backend API, the data layer, the security model, the infrastructure. Specialist agents do excellent work within their domains but are, by design, not responsible for the concerns that live at the boundary between domains. apex-review fills that gap. After specialist work is complete, or in parallel with it, Apex reviews the aggregate output for cross-cutting concerns: is the API contract consistent with what the frontend specialist expects? Does the database schema design create security exposure that Warden would flag? Is the infrastructure spec aligned with the deployment assumptions the DevOps specialist made? This is not a replication of what each specialist reviews; it is the review that only someone with visibility across the whole system can perform. The output is a structured findings report with actionable items, prioritized by severity, and attributed to the right owner to fix.

Tonone's Apex apex-review skill audits cross-cutting concerns that individual specialists miss, reviewing API contracts, security boundaries, and infrastructure assumptions together.

Project reconnaissance before planning

Before Apex can plan work accurately, it needs to understand the project it is planning for. The apex-recon skill performs a fast but thorough reconnaissance of the project: it reads the directory structure, identifies the stack and frameworks in use, locates the key configuration files, finds the test suite (or the absence of one), maps the external integrations, and flags anything that would affect the scope or approach of the planned work. Think of it as the intake step that precedes apex-plan, you run apex-recon when you are starting fresh on a codebase and need Apex to have grounded context before it scopes anything. The recon output is also useful on its own: it produces a concise project brief that captures the current state of the system, which can be shared with new contributors or used as a baseline for an architecture review. For teams that run Apex regularly, apex-recon at the start of each planning session ensures that scoping decisions are grounded in the actual codebase rather than assumptions from the last time anyone looked at it carefully.

A worked example

Say you hand Apex a rough brief: "We need to add multi-tenant auth to the backend." A generalist tool would start writing a JWT middleware function. Apex starts differently. It runs apex-recon to read the existing auth model, maps the current user table schema, checks whether there is an existing session layer, and notes that the project uses an Express-based API with no current organization or tenant concept. Then it produces a structured scope with three options.

The output looks roughly like this, including the estimates that let you decide how much you want to invest before a single line is written:

Apex, Multi-Tenant Auth Scope
Recon: Express API, JWT sessions, Postgres users table, no org/tenant model.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
S, Lightweight tenant column
  Add org_id FK to users table. Scope API reads to tenant context.
  No new auth service. No role model. Admin flag on user row.
  Time estimate:   ~4h
  Token estimate:  ~18k tokens
  Risk:           Low. Reversible. Scope creep risk if org admin
                  requirements grow, plan for M within 3 months.

M, Org service + RBAC
  New orgs table, memberships table, role enum (owner/admin/member).
  Middleware resolves org context from JWT claim.
  Invite flow. Audit log for sensitive actions.
  Time estimate:   ~2d
  Token estimate:  ~55k tokens
  Risk:           Medium. Auth surface expands, route Warden audit
                  after implementation.

L, Full multi-tenant platform
  Tenant isolation at DB level (row-level security or schema-per-tenant).
  OAuth SSO integration (Google Workspace / Okta).
  Scoped API keys per org. Usage metering hooks.
  Time estimate:   ~1.5w
  Token estimate:  ~140k tokens
  Risk:           High. Database migration is non-trivial. Requires
                  Flux (data), Warden (security), and Spine (API)
                  specialists in parallel.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Recommendation: M unless auth is a near-term growth surface.
Next: approve a tier, then Apex dispatches Spine + Warden.

This is the output a senior engineering lead would produce in their first week on the job, three options, grounded in the actual codebase state, with honest estimates, risk flags, and a recommendation. The decision is yours. Apex has done the judgment work of scoping, which means you are making an informed investment decision before committing to an approach, rather than discovering the scope six pull requests in when the work is already tangled. If you approve the Medium option, Apex dispatches Spine for the API design and Warden for the security audit, and coordinates the handoff between them when their work intersects.

Apex vs the alternatives

Apex is not trying to do what Cursor or ChatGPT do, and it is not competing for the same use cases. It occupies a distinct layer of the engineering workflow, the planning and orchestration layer that precedes and coordinates code generation. Cursor and Copilot live at the keystroke level; Apex lives at the project level. ChatGPT and Claude.ai live at the question-and-answer level; Apex lives at the decision-and-delegation level. The comparison below makes the functional differences concrete across the capabilities that matter most when a team is running engineering work with AI.

Tonone's Apex dispatches 22 specialist agents across cloud, backend, security, data, frontend, and product disciplines, coordinating handoffs that no single-agent tool can perform.

Tonone's Apex produces CTO-level status reports from git history and codebase state alone, without requiring any manual input from the engineering team.

Install and try

Tonone is free and MIT-licensed. Install it once and all 23 agents, including Apex, are available in your Claude Code session. You pay only for the Claude Code token usage during work.