Cognitive capacity is not elastic

The productivity literature talks about running ten or more agent streams in parallel. The practice is less cinematic. Most engineers can effectively manage two or three streams at most, and often fewer when the work requires real design thinking. There is a natural limit to how many parallel changes a human can reason about while still preserving project-level understanding. The agents do not get tired. The person responsible for integrating their output does.

The engineer’s context window is the real bottleneck

Model context windows are growing. Agentic IDEs have knowledge bases, repository search, summarization, and increasingly useful project memory. None of that addresses the real constraint, which is the engineer's own mental model of the codebase. An agent with full repository access but limited project understanding behaves like a technically capable team member who joined yesterday: confident prose, partial inspection, some percentage of conclusions that are wrong in ways you will not discover until production.

Coding ability is a system component

It’s tempting to accept the output of a capable model that closes an entire feature, especially when the code looks correct, tests pass, and the deadline is today's standup. The risk is quiet. Navigation skills fade after years of GPS. The degradation is invisible until the day the signal is gone and the engineer is somewhere unfamiliar. Keeping enough direct contact with the code to understand structure, trade-offs, and failure modes is what separates engineers who own a system from those who are merely adjacent to one.

Match the plan to what you can review

The common advice is to use larger models for planning and smaller ones for implementation. That is partially correct. The more important principle is to match the model, prompt, and task size to your own ability to review the output. A small model implementing a single function with clear input/output contracts and named edge cases can produce a strong result at a fraction of the cost. More importantly, the engineer can actually review it. Drive implementation step by step: interfaces first, then classes, then specific methods, then tests, then review. This reduces total development time by eliminating the cycle of broad prompts, partial fixes, regressions, and adjustment prompts.

Project rules must be machine-readable

Coding standards, naming conventions, testing requirements, logging patterns, API contracts, security constraints, domain-specific assumptions: these have always mattered. In an agentic setting, they carry a second requirement. They must be expressed in a form that the development environment or agentic tool can actually use at generation time. A standards document that lives in Confluence and gets shared in Slack when someone asks is not a project rule. It is a hope. Project rules that are present in the environment when the agent writes code improve the probability that the code is correct from the first draft, not after review.

Token efficiency is reviewability

Responsible agentic development already reduces wasteful prompting. Some tooling makes this considerably more precise. Token efficiency is a reviewability concern before it is a cost concern. The shorter and clearer the generated context, the more likely the engineer can actually understand what the agent produced. An engineer who cannot read the output cannot own it. Tools that compress agent output to its essential information reduce the review surface area and increase the probability that someone actually reads it.