Every Engineer Is a Manager Now

The new engineering job is not just writing code faster.

It is managing work that can now produce code faster than the team can understand it.

That is the part of the AI conversation that feels under-described. People keep asking whether AI will replace developers. The better question is whether developers can manage the work AI makes possible.

Because every engineer is a manager now.

Not necessarily a people manager. Not necessarily someone with direct reports, hiring authority, performance reviews, or budget ownership. I mean manager in the operational sense: someone responsible for intent, sequencing, delegation, review, risk, communication, and maintenance.

When an AI coding agent can create a pull request from a prompt, the engineer becomes the person who decides:

• what should be built,
• why it matters,
• which constraints apply,
• what the agent is allowed to touch,
• how the work will be verified,
• how teammates will coordinate around it,
• what evidence stakeholders will trust,
• who owns the artifact after the demo.

That is management work.

The strange part is that junior engineers, senior engineers, data scientists, data strategists, analysts, designers, and consultants are all being pulled toward it at once. AI did not wait for org charts to update.

The Tooling Shift Is Already Here#

The research trend is clear enough to stop treating AI-assisted development as a novelty.

Google's 2025 DORA report summary says AI adoption among software development professionals reached 90%, with a median of two hours per day spent working with AI. It also makes the useful organizational claim: AI acts as a mirror and multiplier. Cohesive organizations get leverage. Fragmented ones expose weakness faster.

GitHub's Octoverse 2025 report points in the same direction from platform activity: more repositories using LLM SDKs, more merged pull requests, more issue closure, and more agent-shaped development work flowing through GitHub.

But the trust gap is just as important. The 2025 Stack Overflow Developer Survey reports that more developers distrust the accuracy of AI tool output than trust it, and that the largest AI frustration is the almost-right answer. "Almost right" is dangerous because it moves work forward while quietly increasing review cost.

The lesson is not that AI is bad. The lesson is that the bottleneck moved.

The bottleneck used to be typing, searching, and boilerplate. Now it is judgment, coordination, and verification.

A Sanitized Scenario#

On a regulated enterprise data engagement, a small cross-functional team had to produce an analytical workflow and a stakeholder-ready recommendation. The team shape was familiar: two data scientists, one data strategist, and a business stakeholder group that needed a clear answer, not a pile of notebooks.

Everyone had access to language-model tools. Some used them for SQL and notebook scaffolding. Some used them for exploratory analysis. Some used them for stakeholder summaries, chart copy, and quality checks. Nobody was trying to be reckless. Everybody was trying to move faster.

The first failure was not dramatic. It was ordinary.

Two parallel workstreams used slightly different definitions for the same metric. One agent-assisted analysis treated a population filter one way. Another treated it another way. Both outputs looked polished. Both were plausible. A stakeholder deck could have absorbed both and looked coherent on the surface.

But the artifacts were not comparable.

That is the kind of failure AI makes easier to miss. The output looks finished before the work is aligned.

We fixed the shape of the work, not just the prompt. We made definitions explicit. We tracked which artifacts supported which conclusion. We wrote down owners. We separated exploratory output from stakeholder-ready output. We stopped treating an agent-generated table as evidence until the assumptions, source, and validation path were clear.

The lesson stayed with me: in AI-assisted team work, the hard part is not only "what is my agent doing?" It is also "what is your agent doing, and do those outputs belong in the same decision?"

That is horizontal management.

The Engineer Becomes Three Roles at Once#

The 2027 engineer cannot be only a code producer. I would not say development skill stops mattering. That goes too far. You still need enough technical depth to know when the output is wrong, unsafe, unmaintainable, or inconsistent with the system.

But code production alone is no longer the center of gravity.

The useful engineer starts to look like a hybrid of three roles.

First, a technical writer.

The engineer has to turn intent into precise instructions: requirements, acceptance criteria, constraints, task boundaries, runbooks, comments that matter, decision records, stakeholder explanations, and handoff notes. The model is sensitive to ambiguity, but teams are even more sensitive to it. Good writing becomes a control system.

Second, a system architect.

The engineer has to understand how the artifact fits into the larger system: data contracts, module boundaries, dependency risk, security posture, observability, deployment paths, and maintenance cost. AI can create a local solution that violates the global shape. Someone has to protect the shape.

Third, a product manager.

The engineer has to ask what outcome the work is supposed to produce. What user behavior changes? What stakeholder decision improves? What is out of scope? What is good enough? What should be deferred? An agent can implement a feature nobody should own. Product thinking prevents that.

For consultants and domain experts, this becomes even more pronounced. The old "T-shaped" model still helps: depth in one domain, breadth across adjacent skills. But AI pushes the horizontal bar wider. A data strategist, data scientist, cloud engineer, or application engineer now needs enough communication, product, governance, and architecture skill to direct agent work and explain it to humans.

You do not need to become everything. You do need to become legible across more of the system.

Agents Are Not Employees, But They Create Management Load#

It is tempting to talk about agents as workers. The metaphor is useful until it becomes dangerous.

An agent can take a task, inspect files, make changes, run commands, open a pull request, and summarize what happened. Claude Code's best-practices docs explicitly frame the tool as agentic: it can read files, run commands, make changes, and work through problems while the human redirects or steps away. The docs also emphasize verification, planning, context management, subagents, and checkpoints.

So yes, some of the interaction feels like delegation.

But an agent is not a teammate with judgment, memory, accountability, or context from last quarter's stakeholder meeting. It does not own consequences. It does not understand political risk. It does not know which shortcut will become an operational obligation unless the team encodes that boundary.

Treat agents like fast contractors with no institutional memory.

Give them a scoped task. Give them context. Give them constraints. Require proof. Review the output. Decide what becomes part of the system.

The management load appears in five places:

• managing intent: what problem the agent is solving,
• managing scope: what it may and may not touch,
• managing context: which files, docs, decisions, and examples matter,
• managing verification: how output becomes evidence,
• managing coordination: how one agent's work interacts with another person's agent work.

The last one is the quiet trap. Individual agent use can feel productive while team-level alignment gets worse.

Horizontal Agent Management#

Imagine three people on the same team using three coding agents in parallel.

One agent refactors the data model. Another updates the API route. Another drafts the stakeholder report. Each task is locally reasonable. The combined result may still be incoherent if the team does not share definitions, dependencies, and proof.

The operating question changes from:

What am I working on?

to:

What work is being produced across humans and agents, and how do we know it composes?

Without a shared surface, every agent session becomes its own little universe.

With a shared surface, the team can answer:

• which task is active,
• who owns it,
• which agent produced which artifact,
• which files or datasets changed,
• which assumptions were used,
• which tests or validations passed,
• which stakeholder claim the artifact supports,
• what still needs human review.

That surface can be a GitHub project, Linear board, Jira board, shared Markdown file, spreadsheet, or repo-local worklog.md. The tool matters less than the discipline.

The Artifact Has to Earn Its Place#

AI slop is not just ugly prose or weird code.

AI slop is any generated artifact that enters the system without ownership, evidence, or a maintenance path.

It can be a function. It can be a dashboard. It can be a data quality rule. It can be a slide. It can be a Mermaid diagram. It can be a "temporary" script that becomes the only way to produce a stakeholder metric.

The question is not whether AI touched it. The question is whether the artifact deserves to stay.

Use a promotion path:

# Artifact Promotion Checklist
 
## Identity
- What is this artifact?
- Who owns it?
- What decision, user need, or operational process does it support?
 
## Source
- Which prompt, issue, ticket, or requirement created it?
- Which data sources, files, APIs, or assumptions does it depend on?
- Is any private or regulated information included?
 
## Verification
- What tests, checks, reviews, or reconciliations passed?
- What adjacent behavior could be affected?
- What remains unverified?
 
## Maintenance
- Where will this live?
- Who updates it when requirements change?
- What breaks if it becomes stale?
- Should it be deleted after the immediate use?
 
## Decision
- Promote to production/system of record.
- Keep as exploratory artifact.
- Archive with notes.
- Delete.

This is the work that prevents polished trash from becoming technical debt.

What Product-Minded Engineering Looks Like#

Product-minded engineering is not asking engineers to become mini CEOs. It is asking them to connect implementation choices to consequences.

When working with AI agents, that means asking sharper questions before the prompt:

• What outcome are we trying to achieve?
• Who will use the result?
• What decision will this support?
• What is the smallest valuable artifact?
• What should not be built?
• What would make this expensive to maintain?
• What would make stakeholders trust or reject it?
• What evidence do we need before this leaves the team?

This is especially important in consulting work. A consultant is rarely paid only to create assets. They are paid to reduce uncertainty for a client or stakeholder group. The deliverable may be code, a model, an analysis, a platform recommendation, or a deck, but the value is the decision it enables.

AI can generate more deliverables than a team can responsibly absorb. Product thinking keeps the team from mistaking artifact volume for client value.

The New Team Cadence#

I would run AI-assisted team work with three lightweight rituals.

First, an intent check.

Before agents start work, the team agrees on the outcome, constraints, and division of labor.

# Intent Check
 
Outcome:
- What decision, behavior, or operational capability should change?
 
Scope:
- What is included?
- What is explicitly out of scope?
 
Agent assignments:
- Who is using an agent?
- What is each agent allowed to touch?
- What artifacts should each agent produce?
 
Risk:
- What could become technical debt?
- What could mislead stakeholders?
- What private or regulated data must stay out of prompts?
 
Proof:
- What tests, reconciliations, screenshots, or reviews are required?

Second, an artifact review.

Generated work is reviewed as a team asset, not as a personal scratchpad.

# Artifact Review
 
Artifact:
Owner:
Generated by:
Linked task:
 
Claims it supports:
- 
 
Evidence:
- 
 
Known limitations:
- 
 
Maintenance decision:
- Production
- Internal reference
- Exploratory only
- Delete

Third, a stakeholder translation.

The team converts technical output into business-facing evidence.

# Stakeholder Translation
 
What changed:
 
Why it matters:
 
What we verified:
 
What we did not verify:
 
Decision needed:
 
Risks or tradeoffs:
 
Recommended next step:

These rituals are deliberately small. Heavy governance will make people route around the process. Lightweight management gives the team enough structure to coordinate without turning every prompt into a ceremony.

The Real Tradeoff#

There is a temptation to make everything faster.

More agents. More parallel sessions. More auto-generated tests. More drafts. More diagrams. More PRs. More stakeholder updates.

The tradeoff is that every generated artifact creates review burden. Every parallel stream creates coordination burden. Every polished output creates trust burden. Every "temporary" script creates maintenance risk.

Speed is useful only when the team can absorb the output.

The best AI-assisted teams will not be the ones with the most agents running. They will be the ones with the clearest ownership model.

That means sometimes the right managerial act is saying no:

• no, do not generate the full feature yet,
• no, do not create a new abstraction,
• no, do not turn exploratory analysis into a stakeholder claim,
• no, do not run three agents against the same files,
• no, do not merge code that only the agent understands,
• no, do not keep an artifact that nobody will maintain.

This is not anti-AI. It is pro-accountability.

A Managerial Skill Map for Engineers#

If I were coaching an engineer or consultant for this environment, I would not tell them to abandon development skills. I would tell them to build management muscles around those skills.

The map looks like this:

• Technical writing: requirements, prompts, handoffs, runbooks, decision records.
• Architecture: boundaries, contracts, dependencies, security, observability, failure modes.
• Product thinking: user outcomes, prioritization, non-goals, stakeholder value.
• Review discipline: diffs, tests, validation, evidence quality, rollback paths.
• Facilitation: aligning teammates, clarifying ownership, surfacing decisions.
• Presentation: explaining technical work in business language without hiding uncertainty.
• Domain judgment: knowing which details matter in the industry, workflow, or data context.

That is a lot. It is also the shape of senior engineering work becoming visible earlier.

The junior engineer using AI needs some of it. The staff engineer needs more of it. The consultant needs it constantly because the work crosses organizational boundaries.

AI does not remove the need for expertise. It raises the cost of shallow expertise because shallow expertise can now generate convincing artifacts quickly.

What to Do Differently#

Treat every AI-assisted project as a management system.

Write the objective before the prompt. Name the owner before the artifact. Define done before the agent starts. Keep a shared work surface across teammates. Promote artifacts only when they have evidence. Translate technical work into stakeholder decisions. Delete generated work that does not deserve a maintenance path.

Most importantly, stop measuring the team by how much AI output it can produce.

Measure whether the output becomes reliable software, trustworthy analysis, clearer decisions, or reduced operational load.

The engineer who thrives in 2027 will not be the one who merely types code with AI nearby.

It will be the one who can manage a system of humans, agents, artifacts, constraints, and consequences without letting speed turn into debt.