AI for engineering managers without magic thinking

I led SpotDraft’s agentic software development lifecycle — ADLC for short.

The starting condition was familiar. Engineers were already using coding agents. Some of that was useful. Most of it was private prompting: a ticket in one window, an agent in another, a pull request that still needed the same review comments we had been leaving for years. Usage went up. The development system did not.

The interesting problem was not whether people used agents. It was whether we could put agents into the actual engineering loop and get work that was reviewed, tested, convention-compliant, and ready to land.

That is an engineering-systems problem. Treat it as a toolbox and you get novelty. Treat it as a lifecycle and you can inspect it.

The loop we designed

In July I stood up a working group and wrote down the path we actually wanted:

requirement and acceptance criteria → planning → task breakdown → implementation → small pull requests → review → automated testing → validation → merge-ready PR.

The output target was explicit. Not “generate a PR.” Generate something a human can stand behind in dev.

We split the work the way you split any platform effort:

• make the codebases agent-ready, so conventions and domain context did not have to be re-taught on every ticket
• capture backend and frontend conventions from recurring review comments, not from a style-guide fantasy
• define the planning and orchestration workflow, including specs, Jira, and PR decomposition
• put review and verification in the same loop: tests, acceptance criteria, and the remaining human intervention

I owned backend conventions and the overall cadence. The rest of the group owned frontend context, the agent-ready structure, and the planning workflow. I coordinated the syncs, the action items, and the end-to-end flow.

That last part matters. A working group that only shares prompts will produce a wiki. A working group that has to demo a plan, code, tests, a PR split, and what still needs a human will produce a system.

Agent-ready is the unglamorous half

Agents fail in the same places new engineers fail: they cannot find the module, they put business logic in the wrong layer, they ignore the test base class, they open a pull request that should have been three.

So we treated “agent-ready” as a property of the repository, not a property of the model.

Root instructions became an index, not a documentation dump. Detailed context moved into scoped files for the modules that actually change. Engineering conventions — architecture, testing, PR size, database rules — lived centrally. Business flows lived with the domain. Agents were supposed to navigate from the index to the right place, not reread the same Angular or Django lecture in every folder.

On the backend I wrote rules from recent review comments: layer boundaries, no business logic in views, shared abstractions, migrations, Celery, admin, logging, tests. Then we ran real implementation tasks against those rules, self-reviewed the agent output, and put the misses back into the rules. That loop is the whole method. If the same comment appears twice, the rule is incomplete.

Frontend had the same shape: one entry point, scoped context for the libraries that matter, conventions that an agent can follow without inventing a second design system.

We evaluated existing planning workflows instead of inventing a house methodology from scratch. BMAD, and similar spec-and-plan systems, already covered brainstorming, planning, and specification. The SpotDraft work was the layer on top: Jira and acceptance criteria, our spec templates, repository context, PR decomposition, and the requirement that a normal engineering prompt should enter this workflow without the developer having to remember slash commands.

If people have to select the right skill, you do not have a lifecycle. You have a menu.

What shipped, and what is still the system

We did not stop at a POC in a side channel. The harness now sits on real backend and frontend work: tickets, plans, implementation, tests, pull requests, and the tags that tell us the loop actually ran.

Early feedback is the kind you want. People can see the documentation and PR pieces land. The complaints are specific: it is slower than a raw coding-agent session, and the orchestrator can be better. Those are production-system complaints. They are not “nobody tried it.”

Slow is not automatically a bug. A flow that asks follow-up questions, writes a plan, and looks for edge cases is doing work a fast autocomplete skipped. If the extra time is thinking, keep it. If it is waiting on permissions, context thrash, or an orchestrator that cannot run isolated steps, fix the system.

That is the remaining work: speed where speed is waste, orchestration quality, and whether the output is actually review-ready. Same three questions you ask of any delivery system.

MCP is a follow-on architecture decision, not the product

Once agents are in the loop, they need tools: Jira, Confluence, the product itself.

SpotDraft MCP is that gateway. Sidebar, automations, Legal Intake, and external coding agents consume the same server. The architecture problem is not “add MCP.” It is how a pod registers a tool without breaking every consumer. Tools get tagged by capability, area, and maturity. An audience is a filter on those tags, not a hardcoded list. Preview stays out of production agents until it is evaluated.

I am also the person who should say when MCP is the wrong abstraction. An agent that needs a tool catalog is not the same problem as a deterministic script with an owner. Glue enough servers together and nobody can explain a failure. Skip the layer entirely and the ADLC cannot talk to the systems where the work already lives.

What this changes for managers

If implementation drafts get cheaper, specification quality gets more expensive. If tests can be generated, deciding what to trust gets more expensive. If pull requests arrive faster, review design gets more expensive.

I have been moving my own review time toward architecture, contracts, risks, and high-context decisions, while implementation quality moves through peer and technical-lead review. ADLC makes that split mandatory. A manager who still inspects every diff will drown. A manager who never inspects the new workflow will ship confident nonsense.

People development does not disappear. Engineers still need a progression: task ownership, project ownership, technical judgment, organizational ownership. An agent can draft the spec. It cannot occupy the decision space. If the important call still routes through me by default, they do not own the work yet — regardless of how the PR was generated.

Defaults I would keep

1. Put the agent in the lifecycle, not next to it.
2. Make the repository teach the conventions. Do not re-prompt them.
3. Route a normal engineering prompt into the workflow. Do not make people pick skills.
4. Measure review-ready output on real tickets, not session counts.
5. Keep humans accountable for architecture, acceptance, and the merge.

I like creating reusable things. Internal platforms, developer portals, public API documentation, and now an agentic SDLC are the same instinct: stop paying the same tax in twelve different places.

ADLC is that instinct applied to how engineering happens. If it only lives in a champion’s editor, it will vanish when the champion changes teams.