Agentic Development – Steve's AI Diaries

If you’ve been in technology long enough, you remember the rise of Shadow IT.

It never started with rebellion. Nobody woke up and decided to undermine corporate governance. A department needed something. IT couldn’t move fast enough. Someone built a spreadsheet. Someone else signed up for a SaaS platform on a company card. A manager ran an Access database for three years before anyone in the centre knew it existed.

Each decision made sense in isolation. The problem only became visible when you zoomed out. Suddenly nobody knew what systems existed, who owned them, what data they held, or what would happen if they disappeared tomorrow. The organisation hadn’t intentionally designed an architecture. It had accidentally accumulated one.

We are about to do exactly the same thing with AI agents.

A few weeks ago I wrote about a question a colleague asked while watching me work: “How do you know what your agents are going to build?” That post was about the missing specification layer between intent and implementation.

This is the follow-on question. What happens when those agents leave development and enter production? What happens when there are hundreds of them?

I sit on an AI committee at work. I see the race for agentic capability from the inside. The energy is real and the pressure is genuine — teams across every function want agents, want them now, and are building them faster than any central function can review. That’s not a complaint. The capability is real and the business cases are solid.

But I’ve noticed something. The teams that will win this race aren’t the ones deploying the most agents. They’re the ones who can keep deploying because they built the operating model before they needed it. Everyone else will hit a wall: a question they can’t answer, an audit they can’t pass, a failure they can’t explain. And at that point the agents stop until someone builds the governance they skipped.

Agent sprawl starts with success

The dangerous thing about agents is that useful ones are easy to justify.

A claims team deploys one to triage work. Customer service deploys one to prepare responses. Engineering builds one to review pull requests. Finance builds one to reconcile reports. Each has a business case. Each saves time. Each makes someone’s life easier.

That is exactly why they spread.

Bad agents die quickly. Useful agents multiply.

Before anyone notices, the organisation hasn’t deployed an agent. It has deployed an estate.

One agent is a use case. Ten agents are a portfolio. Hundreds of agents scattered across business units, vendor platforms, and local scripts are an estate. Estates do not run on vibes. They need mechanisms.

The question nobody can answer

I run a personal AI infrastructure: Jarvis on a Raspberry Pi, Hermes on a Hetzner server, monitoring agents watching both. Even at that scale I’ve had to make deliberate decisions about agent identity, access scope, and what happens when something breaks. I decommissioned one entire runtime when I couldn’t confidently answer basic questions about what it was doing. Painful call. Right call.

Now multiply that by a department operating in a regulated industry.

Six months after a workflow has been running, an auditor asks: which agent prepared this recommendation? What data did it use? What did it ignore? What policy applied, and what did the reviewer actually see before approving the output?

And the room goes quiet.

Not because anything went wrong. Because nobody designed the system to remember. That is the failure mode that keeps enterprise architects awake at night. Not rogue AI. Missing evidence.

The harness tools solve the wrong problem

When teams do think about governance, they reach for observability tools. LangSmith. Langfuse. Tracing integrations inside LangChain. These are genuinely useful. They tell you what happened: which tools the agent called, what the prompt looked like, where it failed, how long it took.

But observability tells you what happened. It does not tell you whether it should have happened.

Those are different questions. Logging that an agent accessed a production database is observability. Preventing that agent from accessing the database unless it has been explicitly granted permission, in that environment, at that stage of its lifecycle, by someone with authority to grant it: that is governance. No harness tool does the second thing.

The result is organisations with excellent visibility into what their agents are doing and no mechanism for controlling whether they should be doing it. The dashboard is green. Whether that means the right things are happening is a different question entirely.

Three surfaces, not one

Most governance conversations stop at agents. That is too narrow.

Agents are the obvious starting point, but an agent without version control is a liability. If the one running today behaves differently from the one running last month because someone changed the system prompt, and you cannot reconstruct what the original was doing, you do not have a production system. You have a guess with a nice interface.

Agents need what software has had for decades: source control, environments, promotion gates, and the ability to roll back. An actual lifecycle: draft, test, staging, production, monitoring, and retirement. Including retirement. An agent with no active owner, no current use case, and persistent access to production systems is a risk sitting quietly in your infrastructure.

Skills are the discrete capabilities agents call on: the function that searches your knowledge base, the one that classifies an intent, the one that drafts a response. They’re often shared across agents, and that is where it gets interesting. If a shared skill changes, every agent using it changes. If it has a bug, every agent inherits it. Skills need versioning, ownership, and controlled promotion. They are code. Treat them that way.

Tools are the connections to real systems: databases, APIs, CRMs, payment platforms. A tool is where an agent stops reading and starts acting. Tool access needs to be explicit, scoped, and auditable. Not “the agent can access the claims database.” Which agent? Which environment? Which scope? Granted by whom, reviewed when?

Capability is not permission. Confidence is not clearance. The level of control required scales with how close a tool gets to systems of record. An agent answering from approved documentation is one risk profile. An agent executing transactions is another entirely.

Agents need an SDLC

No engineering team ships code to production without source control, a review process, environment gates, and a way to audit what changed. The code running your business has owners. It has history. It has a path from idea to production that somebody can reconstruct.

Your agents are code. Your skills are code. Your tool integrations are code.

The argument against treating them that way is speed: “We’ll add governance once we’ve proven the value.” That logic holds until something unexpected happens in production and nobody can explain why. At that point governance stops being optional. It becomes the difference between being able to answer a question and not.

Before the next agent goes live: who owns it, what environment does it run in, what can it access, what lifecycle stage is it in, and how was it approved for production? If those five questions don’t have answers, the agent might be useful. It is not ready for production.

What a real control plane covers

A genuine control plane is not a dashboard. It is the layer that makes basic questions answerable.

What agents exist, who owns each one, where they run, what model they use, what workflow they support. What skills those agents draw on. What tools they can call and in which environments. Who approved each agent for production and when. What changed between versions. Which agents are retired and why.

Beyond inventory, it handles three things that should never blur together: what the agent can see, what it can do, and what it is permitted to decide without human approval. An agent may need broad context to prepare useful work and still have no authority to act on anything without sign-off. Letting those boundaries drift is how workflows accumulate permissions nobody intended to grant.

It also handles human review properly. A human in the loop is not governance if the reviewer sees a polished summary and a green button. Real oversight means seeing the sources, the proposed action, the downstream impact, and having a genuine path to reject or escalate. Without those, human approval is theater with better UX.

And it handles traceability: not just logs, but the reconstructible path showing which sources the agent used, which tools it called, what the human approved, and what changed downstream. Autonomy without traceability is operational debt with better marketing.

The window is still open

Most organisations are somewhere in the middle of this right now. Agents are live, useful, and multiplying. The governance conversation is either not happening or stalling because someone thinks it will slow things down.

That window will not stay open. As agents move closer to systems of record, the cost of not having a control plane increases. Vendors will mature. Regulators will catch up. And internally, the teams that built governance early will be the ones with room to keep moving. They can expand autonomy because they can verify it is working. They can answer the audit question because they designed for it. They stay in the race.

The ones that didn’t will be retrofitting governance onto a live estate, agent by agent, skill by skill, tool by tool, while trying not to break anything people now depend on. That is a slow, expensive way to fall behind.

We have seen this before. We called it Shadow IT. We spent years cleaning it up.

The estate is already forming. The question is whether you will be able to govern it when it matters.

I run Jarvis and Hermes, a personal AI infrastructure across a Raspberry Pi and Hetzner, as a way to stay close to how these systems actually behave. Most of what I write here comes from things I’ve had to figure out the hard way.

A couple of weeks ago I was in our Chicago office, working with a group of colleagues as we looked to leverage our agentic framework on one of our premier products. The goal of the week was a thought experiment: using our agentic framework, could we leverage AI to completely modernise the tech stack. Ordinarily this would be 12 months of work. We had 5 days.

During the very first session, my colleague Jim Pucci was going through a PRD, a project requirements document I use to drive agentic development through FADE, our framework for keeping agentic development on the rails across long sessions. The PRD was solid. Requirements were clear. The agent was about to start building.

Jim read it, looked up, and asked:

“These are the requirements. How do you know what you’re going to build?”

I didn’t have a clean answer. And the more I sat with that question, the more I realised it had exposed a gap in my own framework.

What FADE actually does

FADE injects context. It locks in the frame the agent works inside: vision, constraints, coding standards, architectural principles, the things you’ve learned from previous sessions. It’s why I can hand an agentic developer a complex task at 5pm on a Monday afternoon and have it work all night so we can pick up again on Tuesday morning to working software to review, built to standard.

FADE.md sets the frame. progress.md tracks state. learned.md captures memory across sessions. It works. I’ve shipped real things with it.

But Jim’s question was about something FADE doesn’t do. The frame tells the agent the world it’s building in. The PRD tells it what the business wants and why. Neither tells you, before a line of code is written, what is actually going to be built.

That decision: the architecture, the structure, the patterns, the schemas, the contracts between modules. It’s happening at runtime, inside the reasoning engine, on the fly. Two FADE runs against the same PRD, with the same frame, can produce materially different builds. You only find out which one you got after the fact.

The role we forgot

In a normal engineering team, this isn’t how it works. The PRD is a contract between the business and the architect. It says what the business wants. The architect’s job is to translate that into a spec: how it will be built, what the structural commitments are, which patterns will be used. That spec is then the contract between the architect and the developer. The developer implements the spec faithfully, not re-derives the architecture from requirements every time.

We’ve had this model for decades. Classical software engineering with the roles named honestly.

What’s new is that the agent has been quietly doing the architect’s job inside the reasoning engine, without anyone signing off on it. FADE gave it enough frame to do that job reasonably well. That’s why it works at all. But it never made the architect’s output a visible artifact. The build decisions are real. They have consequences. Right now they’re invisible until they’re already code.

Jim’s question lands because in human teams, the architect’s work is written down and reviewed before the build starts. With agents, we skipped that step and called it productivity.

What plan mode gets right, and where it stops

GitHub Copilot and Cursor have plan modes now. Before the agent touches your code, it tells you what it’s going to do. You can push back. That’s a step forward.

But it’s still one developer, in one session, reviewing what one agent is about to do. The plan isn’t a document. The architect doesn’t see it before the work starts. Security doesn’t sign off on the auth model. QA finds out what was built when there’s something to test. One person saw the decisions. Then they became code.

For a solo project, fine. For a team in financial services, insurance, or healthcare, that’s a problem.

These industries have governance processes and audit requirements for real reasons. When something goes wrong, the question isn’t “what did you build.” It’s who reviewed the approach, when, and what they approved. A plan mode session doesn’t produce that evidence. A private FADE.md doesn’t either.

The gap isn’t developer visibility. Developers have that. The gap is that there’s no written spec, reviewed and agreed before the build starts, that the whole team can sign off on. Not just the developer. The architect, security, QA — the people whose names go on the approval. In a regulated environment, where clients need demonstrable evidence that what you built is secure, testable, supportable, and built to scale, “the agent had a plan mode” isn’t an answer anyone will accept.

What the spec layer should look like

If FADE’s evolution is a spec layer between PRD and build, a few things follow.

The spec is owned by the architect role. That might be a human, or agent-assisted, or the agent drafting while a human signs off. The form doesn’t matter much. Somebody has to be the architect. Accountability sits there. The agent can propose; the architect signs.

The spec generator isn’t a blank-page exercise. It’s grounded in three inputs:

The PRD, for intent.
The standards, for constraints. The FADE frame already covers most of this.
The existing codebase, for context. What patterns are already in use. What the auth model is. Where the seams are. What the team has already committed to.

A spec produced against the codebase fits the codebase. It can’t propose an architecture that contradicts what already exists without that contradiction being visible. The architect reviewing it sees “this reuses the existing pattern” or “this proposes a new one” as an explicit decision, not a runtime accident.

That makes the spec a negotiation surface. The agent proposes, the architect pushes back. “You’ve reused the auth module, good, but you’ve bypassed the rate limiter, fix it.” That conversation is worth having before the code exists, not after.

The bar I’d want to hold it to

Here’s a test for whether the spec layer is doing its job: a different agent, or the same agent in a fresh session, should be able to pick up the spec and produce substantially the same build.

If they can, the spec is committing the architectural decisions properly. If they can’t, the spec is too thin and too much is still being decided at runtime.

That’s a falsifiable bar. You can actually tell whether you’re winning.

What I haven’t worked out

I’m not going to pretend I’ve solved this. There’s a stack of open questions:

Granularity. Is the spec one document per PRD, or per feature, or per module? Probably depends on size, but I haven’t drawn the line yet.
Sync. A spec drifts from the PRD on one side and from the code on the other. How do you keep all three honest as the build evolves?
Codebase reading. This is the hard bit. A spec generator is only as good as its ability to actually understand the codebase it’s reading. Most agents read code shallowly: grep for keywords, miss the actual structure. A spec generator that reads badly will produce specs that look grounded but aren’t, which is worse than no spec at all because it hides the architecture decisions behind a veneer of rigour.

That last one is the real engineering challenge. It’s the next post.

The principle

Agents can be developers. Agents can assist architects. But somebody has to be the architect. Their output has to be visible.

A PRD tells you what the business wants. It doesn’t tell you what you’re going to build. Until that decision is written down and signed off, you haven’t authorised anything. You’ve just hoped the reasoning engine picks well.

FADE gave me the frame. Jim gave me the question. The spec layer is what comes next.

The Next Shadow IT Isn’t Software. It’s Agents.