Work With Agents Like Senior Engineers

Current practice, 2026

Prompt engineering is the old conversation.

It is table stakes now. You do not get credit for writing a better prompt. That is how this technology moves: yesterday's magic trick becomes today's login screen.

What actually changed is the agents. They hold more context. They call tools better. They stay with a task longer. They reason across code, tests, docs, tickets, and architecture decisions in one pass. But most teams are still using them like autocomplete with a hoodie, and that gap is the bottleneck.

Last year you prompted an agent like a junior engineer. Tight scope, explicit spec, small task, and you owned all of the thinking. That is no longer the right ceiling. Three things change when you treat one like a senior engineer instead.

Give direction without over-specifying

Lead with your thesis, not just a task. "I think our auth coupling is slowing deployment. Investigate the service boundaries and show me the tradeoffs" beats "Refactor auth." One is leadership. The other is a Jira ticket wearing a fake mustache.

Ask it to wrestle with what good looks like

Not everything fits in an eval. Architecture decisions, modernization paths, platform tradeoffs, migration sequencing, and engineering debt all require judgment. So ask better questions. What are we optimizing for? What are we risking? What breaks first? What would you challenge in this plan? Where am I wrong? That is where the value shows up.

Force it across the full context

Do not let the agent tunnel into one file and declare victory like it found Atlantis in a helper method. Point it at the working set: code, tests, docs, tickets, recent changes, product constraints, operational pain, and your own opinion. Then make it reason across the whole system.

The repo instruction file is where that context lives between sessions: CLAUDE.md or AGENTS.md, the build and test commands, the conventions the code does not make obvious, the architectural rules, the paths never to touch without a human. Keep it short. The test for every line is whether removing it would cause a mistake; if not, cut it, because a 2,000-line instruction file gets ignored the same way a 2,000-line README does. And treat it as code. It is reviewed, versioned, and owned, because rot there is prompt drift at the scale of the whole org.

This is the same pattern strong technical leaders already use with senior engineers. Autonomy with accountability. Context before commands. Room to push back. Clear ownership of the outcome.

Autonomy comes with an identity and a budget

The same deal holds once the agent leaves the IDE and runs in the pipeline. A senior engineer gets autonomy because accountability comes with it, and an agent in CI is a service that gets exactly that: its own identity rather than a personal token belonging to whoever set it up, write access to its own branch namespace and nothing protected, a tool allow list enforced in the harness rather than requested in the prompt, an ephemeral sandbox, and a per-workflow budget so a runaway loop costs twelve dollars instead of twelve hundred.

Then the hard rules, enforced in the workflow rather than written in the prompt, because instruction files are advisory and the model will deviate under pressure. It opens a PR and never pushes to a protected branch. It never modifies an assertion, deletes a test, or adds a skip to make a build pass. Two repair attempts, then it pages a human and stops. Every repair PR carries the original failure log. If it cannot produce a failing test for a bug, it posts its analysis and stops; no patch without a repro. It never approves or merges its own work. The operating model those rules sit inside is in An Operating Model, Not a Tooling Purchase.

Prompt engineering was never really about the words. It was about intent, and intent is best expressed as a sharp series of questions backed by enough context for the agent to do real work.