March 25, 2026

Your Engineer Agent Knows What Breaks.

Ideas are cheap. Knowing which ones survive contact with your codebase is the hard part.

Your team has a great idea for a new feature. Everyone's excited. But between the idea and a working feature sits a minefield of technical decisions — any one of which can turn a three-day project into a three-week firefight. Which database table holds the data? What happens when two users edit the same record at once? Will this new endpoint slow down everything else?

The Engineer subagent carries a mental model of how production systems actually fail. It doesn't just review code — it stress-tests decisions before you write the first line.

Systems Thinking, Not Feature Thinking

The Engineer thinks in architecture: dependencies should flow inward (UI depends on logic, not the other way around), side effects belong at the edges, and pure logic stays in the core. If a function needs the word "and" to describe what it does, it should be two functions.

API design gets special attention because APIs are permanent. Once external users depend on an endpoint, you can't easily change it. The Engineer pushes for pagination on every list endpoint from day one (you'll regret skipping it), consistent error shapes across all endpoints, and input validation at every boundary.

Data modeling follows similar discipline. Every table gets a primary key, timestamps, and proper foreign keys — because missing foreign keys don't cause problems at first, they cause problems six months later when orphaned records silently corrupt your reports. Indexes aren't premature optimization; missing indexes are bugs.

Where Bugs Actually Hide

State is the root of all bugs. The Engineer's instinct is to minimize it — derive everything you can from existing data instead of storing a second copy. If the same value lives in two places, they will eventually disagree, and you'll spend a week tracking down why.

Performance gets measured, not guessed. N+1 queries (when your code fires one database query per item in a list instead of one query for the whole list) are the number one performance killer in web apps. The Engineer spots these in code review and suggests the batch query before you ship it. Bundle size gets the same scrutiny — every dependency you add is a cost your users pay on every page load.

Code Review That Matters

The review priority is fixed: correctness first (does it actually work?), then security (any injection or auth bypass?), then architecture (does it belong here?), then performance, then maintainability. Blockers come before suggestions. Suggestions come before nice-to-haves. And every suggestion includes a concrete alternative with a code snippet, not just "this could be better."

The rule it enforces most: simplicity over cleverness. Three similar lines of code are better than a premature abstraction. Extract a pattern after you've seen it three times, not before.

The best engineering teams don't just build fast. They know what not to build — and they know it before they start.