How to Use Agents as an Engineer

In 2027 many engineers won't be in an IDE, or even in a coding agent directly. They'll run an org of agents and operate more as a manager. A single assistant can draft a function, summarize a thread, or sketch a plan. Put the calendar, the repo, the inbox, and the cleanup of its own habits into that same context and the work gets worse. You start repeating constraints the agent already heard. The fix is old. Split the jobs. Give each one a boundary and someone to report to.

The chart is not the same for every engineer. You still make the calls that matter. You stop being the person every fact has to pass through.

The shape

The shape of your agent org depends on your job and on what your human team already covers. Add an agent for any job no human on your team already covers. If a person already decides what to build, a product-lead agent is a second voice on a job that is taken. If nobody is using the live product the way a customer would, that job is open. Staff the open job. Leave the covered one with the human.

The playbook

1. Start with the smallest configuration that fits your job, and use it for a week. A junior engineer starts with engineer agents, a quality reviewer, and a peer review partner. A founder starts with a chief of staff. Leave every other box empty. You want to feel where the context crowds, and you will not feel that if the full chart is already talking over itself.

2. Add an agent for a job no human on your team already covers. Also split a role when an agent's context gets crowded. A new tool, or a blank box you like the look of, is not a reason. If the chief of staff is planning the quarter, booking travel, and reviewing diffs, peel off one of those jobs. One.

3. Plan before you build, and let the skeptic review after a pull request is open. A big project starts as a written plan with phases. Where the chart has a product lead, that lead decides what is worth building, and the engineering lead decides how. Code starts once a phase is small enough that a worker can finish it without inventing the strategy. Once the pull request is open, the skeptic asks whether it is really necessary and whether a simpler way would do the job.

4. Manager agents do not code. The chief of staff, the product lead, and the engineering lead plan and hand out work. If you find one of them in the diff, you have a role bug. The implementation belongs to a worker with a task, a check, and an exit.

5. Make every task checkable. Tests, type checks, and a clear goal are how a worker verifies its own work before it reports back. A task that ends in a shrug is a task you will redo yourself. Write the goal so a passing suite and a green type check mean the phase actually moved.

6. Make the repo agent-friendly. Fast tests, clear docs, small modules, and CI you trust are what make the quality rubric meaningful and a later auto-merge safe. A suite that takes the better part of an hour trains every worker to skip it. The repository is the place the org works. Keep it legible.

7. Turn repeated work into a skill. Do the job with an agent, correct it, then save the correction. A skill is what remains after you have watched a workflow fail and fixed the specific miss. A note that merely describes the job is not yet a skill. Save the version that survived the repo.

8. Promote a skill to a routine once it works on the first try. A routine runs on a schedule, or because an event fired. The performance engineer is this kind of role: outside the pull request loop, on a schedule, with before and after numbers. Leave a workflow as a skill while it still needs you in the loop. A routine multiplies the result, including the mistakes.

9. Test a skill change on several models, and keep it only if it hits the goal. A skill that works on the model you happened to have open is a coincidence. Run the change on the models the routine will actually use, including a cheaper one if that is the plan, and keep it only when the goal still lands.

10. Widen trust gradually. The quality reviewer scores every pull request from the start, against the same rubric. The security engineer comes in only when a pull request is marked ready, and it can veto the merge. After you have reviewed the early changes, let low-risk pull requests auto-merge and review them afterward. Costly or irreversible actions always need your approval. Trust is a setting you earn for a class of action.

11. Let the agents talk to each other. QA reports bugs and rough edges to the product lead. The feedback agent briefs that same lead, with the evidence attached. The marketer drafts the changelog, the launch post, and the docs note from what merged. A fact that has to pass through you on the way to the agent that needs it has rebuilt the bottleneck this org was supposed to remove.

12. Let the agent mechanic run the org once the chart is large enough to drift. It reviews the agents each week, and you approve its changes. On the junior chart, you are that review until the work is big enough to staff the role. If the weekly pass is not happening, routines drift, cost creeps, and you notice only after something expensive has already run.

Example configurations

Each diagram is a starter org tree: a starting point for the job in front of you, not a finished structure. Staff the smallest one that matches the job. A wider chart scrolls sideways, so the labels stay at reading size.

Junior engineer

This is for an engineer with a focused responsibility and a human team around them. People already cover product, design, security policy, and the decision of what to build. You staff engineer agents for the tasks you own, a code quality reviewer for the pull requests you open, and a peer review partner so you review co-workers' changes and get the right people onto yours.

Mid-level or senior engineer

This is for an engineer on a team who owns how a stream of work gets built. Humans still cover product direction, design, and the security program. You talk to an engineering lead. The skeptic sits under that lead and reviews every pull request after it is opened. The code quality reviewer scores each pull request, and the security engineer reviews it once it is marked ready. The peer review partner stays with you.

Tech lead or staff engineer

This is for someone responsible for a system, not one ticket. Humans may still own the product bets and the launch. You add a chief of staff, so status arrives as what shipped, what is blocked, and what needs you, and an agent mechanic that reviews the org once a week. The engineering lead directs the skeptic, the engineer agents, the code quality reviewer, the security engineer, a performance engineer on a schedule, and the peer review partner.

Solo product builder

This is the widest starter org tree, for a founder or a solo builder whose human team does not cover the calendar, the product calls, the design, live-product testing, feedback, or the launch note. The product lead decides what is worth building and hears from design, QA, feedback, and the marketer. The engineering lead decides how. The skeptic reviews each opened pull request, and the security engineer reviews last, once the pull request is marked ready. You still approve anything costly or hard to undo.

Agent Templates

Chief of Staff

Tracks work across all agents and tells you the status: what shipped, what is blocked, and what needs you. It keeps the plan and the phases in that same place, and it is the agent you talk to when the chart is large enough to need one. It does not disappear into an editor and come back with a surprise diff. If you have not run that planning job on your own work until you trust it, a large chart is a guess.

Personal Assistant

Calendar, email, travel, and the errands that eat a morning. It gathers the options and checks with you before it books or pays for anything. A flight, a charge, or a note you cannot unsend stays with you until you approve it. On the full chart it reports to the chief of staff.

Agent Mechanic

Once a week it reads every agent's transcripts and proposes a new skill, a new agent, a routine change, or a cut for a routine that runs too often or costs too much. You approve the changes. That weekly pass is also what keeps model choice honest, because the person closest to the work will otherwise reach for the most expensive model every time.

Product Lead

Decides what is worth building. The engineering lead decides how. The product lead hears from design, QA, feedback, and the marketer, and it turns the proposals worth doing into work the engineering lead can phase.

UI/UX Designer

Reports to the product lead. It shapes the interface for something the product lead has already decided is worth building, and it hands over a design a worker can implement without inventing the screen along the way.

QA Agent

Reports to the product lead. It uses the live product the way a customer would, then reports bugs, rough edges, and confusing flows back to that lead.

Feedback Agent

Reports to the product lead. It watches user feedback, social mentions, and support, and it sends proposals with the evidence attached. You are not the courier who copies a complaint out of one window and pastes it into another.

Product Marketer

Reports to the product lead. It drafts the changelog, the launch post, and the docs note from what the merged work actually does. It writes from the diff that landed, so the note and the product stay the same thing.

Engineering Lead

Decides how the chosen work gets built. It takes the phases, breaks them into small tasks, and hands each task to an engineer agent. It never writes the code. A lead inside the diff has stopped leading, and the phases wait while it chases a failing test.

The Skeptic

Reports to the engineering lead. It reviews every pull request after it is opened, and it asks whether that pull request is really necessary and whether a simpler way would do the job.

Engineer Agents

Each engineer agent supervises one task. It hands the task to the coding workers, picks the model and the reasoning depth for that task, and reports back only after the tests pass. A task with no check leaves this role with nothing to verify, so the task was not ready to assign.

Coding Workers

Workers are short-lived. They write the code, open a pull request, and exit. For that layer, use Tembo, which I co-founded and run as CEO: it runs the worker in an isolated environment and brings the work back as a pull request. A worker that lingers keeps yesterday's assumptions in context, and the next change inherits them. Hand one the task, let it finish, and let it go.

Code Quality Reviewer

Reports to the engineering lead and reviews beside the security engineer. It scores each pull request against a fixed rubric: correctness, tests, readability, naming, scope, and dependencies. The rubric does not change with the author's mood, which is what makes the score useful to a worker.

Security Engineer

Reports to the engineering lead. It reviews a pull request only once that pull request is marked ready, so a branch that is still an experiment can stay messy. It may use an external scanner. It checks the change against best practices, SOC 2-level controls, and the org's own policies, and it can veto the merge.

Performance Engineer

Reports to the engineering lead and stays outside the pull request loop. On a schedule it profiles the product, finds the slow paths, and opens an issue or a draft pull request with the before and after numbers attached.

Peer Review Partner

Helps you review co-workers' pull requests, and it nudges the right people to review yours. On a small chart it reports to you, because the reviews are still yours. On a larger chart it reports to the engineering lead, so the nudges are part of the queue.

Build the chart that matches the job in front of you. Add an agent only for a job no human on your team already covers. Keep the skeptic on every opened pull request, keep the security engineer for when a pull request is marked ready, and let trust grow only where the repo can check the result. The engineer in 2027 is the person who can run the org they actually need, approve the irreversible calls, and stay out of the handoffs.