The most interesting thing AI has changed about my work is not how quickly I can generate a function. It is the size of the problem I am willing to take on. With Codex and Claude agent workflows helping me inspect unfamiliar code, compare approaches, run verification, and prepare reviewable changes, projects that once felt too broad for one person become possible to approach systematically.
That leverage should make an engineer more ambitious. It should not make them less responsible. I do not think the right goal is to remove the person from the loop or to celebrate how much code an agent can produce. The goal is to spend less human attention on repetitive execution so more of it can go toward product judgment, architecture, testing, and the consequences of what gets shipped.
My working hypothesis is that well-structured LLM agents can accelerate roughly 80% of routine engineering execution when the remaining work is protected by human review. That number is not a universal benchmark or a claim that most engineering judgment disappears. It describes a practical split I see repeatedly: agents are strong at gathering evidence, applying bounded changes, running verification, and producing reviewable artifacts; people still need to define the outcome, resolve ambiguity, and own the consequences.
The useful unit is not a magical autonomous engineer. It is a small task with a clear boundary, an observable result, and a reviewer who knows what evidence would make the result trustworthy. Once work is decomposed that way, several agents can operate like a fleet. One investigates the current behavior. Another maps tests and ownership. Another implements a narrowly approved change. A final pass checks the combined result against the original intent. Parallelism helps, but the bigger gain comes from making interfaces between tasks explicit.
Delegation starts with the source of truth
Agents amplify whatever context they receive. If the starting assumption is wrong, speed only produces a larger wrong answer. I begin with a source-of-truth check: current repository state, live configuration when relevant, the actual backend or client path, and the user-visible behavior we are trying to change.
This prevents a common failure mode where an agent explains a screenshot from stale local code. The right first task is often not “fix the bug.” It is “identify the code path that owns this behavior and show the read and write boundaries.” That investigation can run independently from a second task that prepares deterministic reproduction data.
The handoff between those tasks is evidence, not confidence. A useful handoff says which files, functions, requests, and states were verified. It distinguishes observation from inference. The implementation agent can then work from a bounded contract instead of rereading an entire system or inheriting a vague conclusion.
Fleet work needs interfaces
Parallel agents are valuable only when their outputs can be composed. I define each task with four fields:
- Consumes: the inputs and facts the task may trust.
- Produces: the exact artifact or interface the next task receives.
- Must not change: the boundaries that protect adjacent work.
- Verification: the command or observation that proves completion.
For a cross-service feature, one task might produce an API contract and fixtures. Another consumes that contract to build the UI. A third prepares deployment wiring. They can proceed in parallel only if names, types, and error behavior are already agreed upon. Otherwise the apparent speed becomes integration debt.
This is why I prefer plans that name actual files and signatures. “Add error handling” is not an interface. “Return { success, errorCode } and treat a false success flag as a failed send” is something another task can use and test.
The same idea applies outside code. A content agent can prepare public-safe project summaries while an engineering agent builds the site, provided the content schema is fixed. A release agent can assemble checks while implementation continues, provided it cannot publish before the build artifacts and privacy gates are satisfied.
Human review is part of the architecture
Review should not be a vague final glance. It should be placed where uncertainty and impact are highest.
I use three kinds of review gates:
- Direction gate: a person confirms the outcome and trade-offs before implementation.
- Evidence gate: a person or independent check validates root cause, data ownership, and regression coverage.
- Mutation gate: a person approves consequential external writes such as production data changes, public publishing, account settings, or irreversible operations.
Not every task needs all three. A local formatting change may need only automated verification. A public profile update needs a direction gate and a mutation gate because the content affects a person’s identity. A data repair needs evidence about the exact target set before any write occurs.
The key is to make review cheap by preparing the decision. Agents should bring a small diff, a before-and-after observation, test output, and unresolved risks. A reviewer should not have to reconstruct the entire investigation to decide whether the result is safe.
Verification should be adversarial
Agents are good at producing green output, so the verification design has to guard against shallow success. I want at least one check that would fail if the implementation were missing.
For code, that means a red-green regression test, not a test written after the change that passes immediately. For data, it means reading the live record after the mutation, not trusting a successful command. For a website, it means opening the production URL on desktop and mobile after deployment, not stopping at a local build. For privacy settings, it means rereading the final value after every profile save.
An independent review pass is especially useful when the first agent both chose and implemented the approach. The reviewer should trace the actual render or data path, look for state the happy path omits, and compare the diff to the stated constraints. It does not need to invent a different architecture to be valuable. Its job is to find where evidence is missing.
What belongs in the remaining twenty percent
The human-owned portion includes more than approval clicks. It contains the parts of engineering where goals are incomplete, values conflict, or external consequences matter.
Examples include deciding whether a product should add friction to an irreversible action, choosing which private work can be described publicly, interpreting an ambiguous customer report, or deciding whether a temporary operational shortcut is acceptable. Agents can research options and simulate outcomes, but the decision depends on context that is broader than the code.
Humans also own taste. A portfolio can be valid, accessible, and fast while still feeling generic. A game economy can pass simulations while feeling unfair. An agent can generate variants and critique them, but someone must decide what the product is trying to feel like.
Finally, people own accountability. If an automation changes a profile, schedules a job, or writes production state, the fact that an agent executed the step does not transfer responsibility away from the person who authorized the workflow.
Practical limits
Fleet coordination has overhead. For a task that takes ten minutes and touches one file, parallel delegation is usually slower. Agents also share environmental constraints: the same test device, branch, external rate limit, or authenticated browser. Two tasks that mutate shared state are not independent simply because their descriptions differ.
I use parallel agents when work can be separated by artifact or source of truth. Research across independent repositories, audits of unrelated code paths, content drafting, and isolated component implementation are good candidates. Sequential execution is better when each decision materially changes the next task or when a single environment is the bottleneck.
The safest fleet is also willing to stop. Missing credentials, ambiguous targets, repeated verification failures, and conflicting live state are signals to return to a person, not challenges to route around.
What I would carry forward
Treat agents as bounded executors connected by explicit interfaces. Start from the real source of truth, make handoffs evidence-based, and place human review where uncertainty or consequence is highest. Use red-green tests and live read-backs so green output proves something. The goal is not maximum autonomy; it is faster, more legible work with clear human ownership.