08 Jun 2026 9 min read AI Infrastructure

The Interesting Part Comes After AI Adoption

The Honeymoon Is Over. Welcome To The Messy Middle.

The problem is no longer whether teams use AI. It is what happens after everyone starts using it.

A week ago, I asked engineering teams to help me check a hunch about something I keep seeing around AI-assisted work. I promised to share takeaways once I had enough responses. These are the takeaways.

AI adoption used to feel like the hard part.

Get developers to try the tools; convince the skeptics; prove the agent is not just a very confident intern with API access.

That phase is not over, but it is no longer the most interesting part. The more interesting part starts now, after we adopted AI a little too fast.

That is when the engineering floor starts to look like an airport without a control tower. Private chats are running in one place. Cursor sessions are happening somewhere else. Claude conversations contain useful decisions that nobody else can see. Then a founder, VP, or CTO asks a simple question:

Are we making our AI usage cheaper, faster, and more effective?

And the team has to reconstruct the answer from memory, scattered logs, individual conversations, and whatever screenshots people remembered to save.

The real "system of record" for a lot of AI work: dozens of private sessions nobody else can see.

I wanted to understand whether this was just my own bias from building in this space, or whether other teams were feeling the same thing. So I put the survey in front of people two ways: a paid SurveyMonkey audience, and by hand through a LinkedIn post, a few LinkedIn groups, Dev.to, a Discord I hang out in, and a lot of direct messages.

The final dataset had 78 usable responses from engineers, engineering managers, tech leads, founders, and product or technical people.

This is not a statistically definitive study, and I am clearly not a neutral party here. But for early market research, 78 usable responses were enough to make the pattern hard to ignore.

TL;DR

Nobody asked for more AI. The responses pointed somewhere more specific:

AI work is already happening, but it is scattered.
Teams repeat prompts, debugging steps, and context across sessions.
Leaders are starting to ask for proof of impact.
Engineers want successful AI workflows to become reusable, not disposable.
The missing layer looks less like another chatbot and more like observability, orchestration, and continuous improvement for AI-assisted work.

The chat box stops being enough once AI becomes part of the engineering system.

After AI Adoption, Teams Lack A System

AI work is happening. The operating layer around it is still catching up.

Plenty of usage, almost no visibility into it.

Can you tell what happens now that we adopted AI, and how we return to a less chaotic state?

This is the difference between talking about a tool and talking about an operating layer.

A tool helps one person finish one task. An operating layer lets a team see what happened, reuse what worked, improve the process, and explain the result afterward.

Right now, a lot of AI-assisted engineering work behaves like local state in a long-running script. Useful while the process is alive. Gone, or at least very hard to reconstruct, once the session ends.

The Pain Is Not "We Need More Agents"

Nobody was asking for a bigger magic button. They wanted basic engineering hygiene around a new kind of work.

When code became central to companies, we built version control, CI, reviews, logs, metrics, alerts, incident processes, and runbooks. Not because developers love process for its own sake. We built them because important work needs memory.

AI-assisted engineering is starting to hit the same wall.

The work is useful enough that teams care about it. But it is still often stored in places that are bad at becoming team memory: private chats, local sessions, screenshots, one-off prompts, and "ask Dana, she had a good Claude thread last Tuesday."

That is not a system. That is archaeology.

The Missing Loop

If you squint, the workflow teams seem to want is not complicated:

AI session ➡️ observe what happened ➡️ extract the useful pattern ➡️ turn it into a reusable workflow ➡️ measure cost, quality, and outcome ➡️ improve the next session.

The hard part is not drawing the loop.

The hard part is making it real without turning every engineer into a part-time reporting system.

The missing layer looks less like another chat window and more like an AI workflow control tower.

The teams in the survey were not asking for vague "AI governance." They were asking for very concrete answers:

Which workflows actually work?
Which prompts or agents are worth standardizing?
Where are we wasting tokens or retries?
Which sessions produced better tests, faster reviews, or fewer bugs?
What should we change next?

That is an engineering problem.

And engineering problems usually get better when we can observe them.

Leaders And Engineers Feel Different Versions Of The Same Problem

The role split was interesting because the pain shows up differently depending on where you sit.

Among engineering leaders in the responses:

75% agreed that AI work is scattered.
Just 28% could answer with clear measured data.
56% had already been asked to justify AI tooling cost, usage, or impact.
56% rated human-controlled AI coordination as very or extremely valuable.

Their problem is visibility and accountability.

They need to answer questions like:

What AI work happened?
Which tools are people using?
What is this costing?
What improved?
Which workflows should become standard?

Individual contributors and tech leads felt a more execution-shaped version of the same gap:

68% said context handoff between people is moderately to extremely painful.
55% rated reusable workflows or specialist roles as very or extremely useful.
52% rated human-controlled AI coordination as very or extremely valuable.

Their problem is continuity.

If a teammate finds a good debugging flow, creates a useful review prompt, or figures out how to get an agent through a tricky migration, that knowledge should not live only in one exhausted person's browser history.

Different symptoms. Same missing layer.

The Strongest Signal: Workflow Improvement

When asked which capabilities would be valuable, the highest-scoring answers clustered around improving and reusing AI workflows:

Turn successful AI sessions into reusable team playbooks.

Show which AI workflows improved quality or reduced cost.

Those two were almost tied at the top, which surprised me.

People want the useful parts of AI work to survive the session.

If someone discovers a good workflow, prompt sequence, model choice, test loop, or review pattern, the team should not have to rediscover it from scratch or search for it in a pile of conversation histories saved locally on every engineer's personal computer.

A successful session should graduate into a certified workflow the team can reuse.

The current shape of AI tooling makes this surprisingly hard.

Sessions are optimized for immediate interaction, not organizational learning. They are great at helping you right now. They are much weaker at answering:

Should the next person do it the same way?
Did this approach improve quality?
Was it cheaper or more expensive than the alternative?
Which context was actually necessary?
What should become part of our standard workflow?

One response summed it up perfectly:

"Everyone reinventing the wheel."

Another said:

"AI tools are scattered and there is no unified view, which makes it hard to share workflows or context."

What Teams Want To Measure

Today, most teams answer "is AI actually helping?" with hunches and manual logs, not KPIs or ROI. Only 23% said they could give leadership a clear, measured answer. The other 77% are running on gut feel, anecdotes, and whatever logs or screenshots they managed to keep.

That is the gap the next chart is really about. When teams were asked what they want to measure, they did not reach for vanity metrics. They asked for the boring engineering signals that would let them replace the hunch with a number.

If AI is part of engineering work, then AI workflows need the same kinds of feedback signals we expect elsewhere in engineering:

cost per unit of work
success and failure rates
repeated work
quality outcomes
review and rework impact
adoption by team or project
before/after changes when the workflow improves

None of these are magical metrics. They are boring in the best possible way.

Boring metrics are how systems grow up.

The Quotes That Stuck With Me

A few anonymized responses captured the pain better than any chart:

"Sharing workflows and configuration"

"Tracing complex workflows."

"I want to know exactly which prompts and AI workflows are saving the most time for our team."

"How can we improve our workflows in terms of cost/latency/success rate"

"A few, with no concrete data"

"I can only show some manual logs and individual developer feedback, as we lack clear before-and-after metrics."

Some teams already feel that AI is helping.

But feeling is not the same as instrumentation.

And anecdotes are not the same as a feedback loop.

The Layer That Makes Agents Matter

Teams have adopted AI, but the work around it has not caught up yet.

That is manageable while AI is only a personal productivity layer. It starts breaking down when AI becomes part of the team-level engineering system.

Once leadership asks about cost, usage, quality, and business impact, "people are using it" is not enough. Teams need to answer what actually worked, what keeps getting repeated, whether working with agents is getting them closer to the "10x engineer" promise, and what should become standard or be dropped.

The strongest signal was not demand for more model access. People wanted a system of record and a control layer for AI work: reuse, comparison, measurement, and coordination.

That is the part that pulled me into building something of my own.

The gap I keep seeing is not that agents are too weak. It is that their work does not build on itself. They produce output, but the output rarely turns into a reusable workflow, a better default, a measurable improvement, or shared team knowledge.

That is why I decided to call it Shepherd.

The name is not just branding. A shepherd does not do the work instead of the flock, and the herding dog does not replace the shepherd. The human sets the direction, goals, and constraints. The system keeps the work moving, visible, and within bounds.

That is how I want AI development to feel. Fast, but still something you can follow. Autonomous, but still under human control. Structured enough to scale without freezing into process for its own sake.

Everyone wants to supercharge their agents. The missing piece is the layer around them: the place where execution feeds knowledge, knowledge improves the next execution, and successful AI work stops disappearing into private sessions.

If your team is living this, using AI heavily but still unable to see what works, what repeats, and what should become standard, I am looking for a few design partners to build Shepherd with.

Thanks to everyone who answered the survey.

Every squad needs a Shepherd.