Why Project Management Matters More Than Coding in AI Engineering

I used to get into arguments at work about sprint planning. My opinion — which was not always popular — was that the most important skills in a software engineering team weren’t writing code. They were scoping work, decomposing problems, and defining what “done” meant clearly enough that you could tell when you got there.

The coding was the easy part. Knowing exactly what to code, and how small to make the pieces, was the hard part.

AI engineering has made this observation embarrassingly obvious.

When you’re building agentic systems — workflows where AI agents execute multi-step tasks with real-world consequences — the difference between projects that ship reliably and projects that turn into expensive demonstrations is almost entirely project management. Not prompt engineering. Not model selection. Not architecture sophistication. Task decomposition, validation criteria, and scope discipline.

This is not what most AI engineering tutorials teach you. But it’s what I keep seeing in the field.

What “AI Engineering” Actually Means Now

Six months ago, “AI engineer” mostly meant “person who can integrate LLM APIs and build RAG pipelines.” That’s still part of it. But the role is shifting fast, particularly for anyone building agentic systems.

Increasingly, an AI engineer’s primary job is to decompose complex goals into tasks small enough for an AI agent to execute reliably — and to define, with precision, what success looks like for each task so the agent’s output can be validated before it flows downstream.

That’s not a coding problem. That’s a requirements and decomposition problem. It’s what senior PMs and tech leads spend most of their time doing on traditional software projects. The difference is that on traditional projects, you’re decomposing work for human engineers. On agentic AI projects, you’re decomposing work for agents that will execute it autonomously — which means the decomposition has to be even more precise, because there’s no human judgment in the loop to compensate for a vague requirement.

Agents do exactly what you ask. The better you specify the task, the better the output. The worse you specify it, the more creative the agent gets about interpreting your ambiguity — usually in directions you didn’t intend.

The Vertical Slicing Obsession

I’ve talked about vertical slices in the context of consulting before, but the concept applies equally to agentic workflow design.

A vertical slice is the smallest end-to-end implementation of a capability that delivers real value. Not a component. Not a prerequisite. Not infrastructure that something else will eventually build on. An end-to-end slice that does one thing, produces a real output, and demonstrates that the capability actually works with real data.

For agentic AI, this means designing your first agent not to handle the whole workflow, but to handle one well-defined step with clear inputs, clear outputs, and a testable success criterion. Build that step. Validate it. Make it reliable. Then add the next step.

The alternative — designing the full system upfront and building all the agents in parallel — produces systems that are individually untested and fail in complex, interacting ways when you try to run them end-to-end. The debugging surface is massive. The failure modes compound. Teams spend weeks chasing errors that originated in step 2 and didn’t manifest until step 7.

Vertical slices keep the failure surface small and the feedback loop short. You find out that step 3 produces unexpected output before you’ve built steps 4 through 9 on top of it.

Defining Outcomes Before You Define Tasks

Here’s the discipline I apply before scoping any agentic workflow: write the test first.

Not a unit test. An outcome definition. A clear, specific description of what the system needs to produce, at what quality level, measured how, evaluated against what criteria.

For a document processing pipeline: what does a correct extraction look like? How do you tell a correct extraction from an incorrect one? What’s the minimum accuracy threshold for this to be worth running at all? What does the failure output look like — how do you know the agent failed gracefully rather than silently producing garbage?

Answering these questions before you write code seems obvious. But in the excitement of building something new with AI, teams skip this step and end up with systems they can’t evaluate. They don’t know if the agent is working because they never defined what “working” means precisely enough to check.

Writing the test — the validation criteria, the success definition, the failure modes — is the project management work that makes agentic AI development actually tractable. It constrains the scope. It gives you something to measure. It tells you when you’re done.

The Task Decomposition Framework I Use

When I scope an agentic workflow, I work through four questions for every agent in the system:

1. What is the exactly one thing this agent does? Not “handles document processing.” “Extracts structured data from a PDF invoice according to a defined schema and returns a JSON object matching that schema.” The narrower and more specific, the better. If you can’t describe it in one sentence without a conjunction, it’s probably two things.

2. What does it receive, and in exactly what format? Agent inputs should be typed and schema-validated, not free-form. The agent shouldn’t be inferring what format its input is — it should be receiving a well-defined input it can reliably process. This is where most “agent failures” actually originate: bad inputs that the agent tries to handle gracefully and fails.

3. What does it produce, and how do we validate it? Define the output schema. Define the validation criteria. Build a validation step that runs after every agent execution, checks the output against those criteria, and routes to retry or human review if it fails. This is the mechanical implementation of the outcome-first design principle.

4. What does failure look like, and how should it be handled? Not “it fails.” Specifically: it times out, it produces output below the confidence threshold, it returns an error from a downstream API, it produces a malformed schema. Each failure mode should have a defined response: retry with parameter adjustment, route to human review, fail fast and alert, default to a fallback value. Unhandled failure modes become production incidents.

Why This Skill Is Underrated in the AI Engineer Job Market

Most AI engineering interviews focus on technical implementation: can you build a RAG pipeline, can you use LangChain, can you call the API. These are table stakes skills that most candidates have at roughly similar levels.

The candidates who are actually better at building production agentic systems are the ones who can talk fluently about scope discipline, about how they define success criteria before they write code, about how they decompose complex workflows into independently testable agents, about how they design validation checkpoints that keep failures small and caught early.

That’s project management expertise applied to a new domain. And it’s rarer than technical implementation skill.

I came to AI engineering from a background that included a lot of frustration with projects that moved slowly because requirements were vague and scope was poorly controlled. That frustration — and the habits it built — turned out to be directly applicable. The skills that make a good technical PM also make a good AI engineer, specifically because the leverage of an AI system amplifies both good and bad decomposition.

Clear task definitions shipped. Vague task definitions produced expensive demonstrations.

The code is not the hard part. It never really was.

If you’re designing an agentic system and want to pressure-test the task decomposition before you start building — that’s exactly the kind of conversation I like having.