DEV Community: Dr Hernani Costa

Managed Agents Over Copilots: The 12-Month Operating Model

Dr Hernani Costa — Sat, 09 May 2026 06:57:55 +0000

The shift from AI assistance to autonomous agent delegation is no longer optional—it's now a management and governance problem. Lean technical teams treating agents as upgraded autocomplete are building technical debt, not business equity.

From Copilots to Managed Agents: The 12-Month Roadmap for Lean Technical Teams

TL;DR: A 12-month roadmap for lean technical teams moving from ad hoc copilots to managed agents, shared context, and governed AI development.

A practical roadmap for teams that want to move beyond ad hoc AI assistance and build a governed, repeatable agent operating model over the next year.

A lot of lean technical teams are still using AI as a better autocomplete layer. That is not where the category is headed.

By April 2026, the leading products are pushing far beyond editor assistance. OpenAI's Codex app is designed to manage multiple agents in parallel, with built-in worktrees, reusable skills, and scheduled automations. GitHub Copilot coding agent works in the background and opens pull requests for review. Claude Code remains terminal-native and connects to external tools through MCP. Cursor now supports self-hosted cloud agents that keep code and tool execution inside your own infrastructure.

That means the real shift is no longer from "no AI" to "AI assistance." It is from copilots to managed agents.

For lean technical teams, that shift can be powerful or destructive. It becomes powerful when you treat it as an operating-model transition: who delegates work, where agents run, what context they can access, what requires review, and how shared patterns become team standards. It becomes destructive when teams keep layering new tools onto old habits without redesigning how work is supervised. The product direction across OpenAI, GitHub, Anthropic, Cursor, and the MCP ecosystem all points toward the same conclusion: more autonomous capability now exists, so management discipline matters more.

This is the roadmap I would use over 12 months for a lean team that wants to move from scattered copilot usage to a managed-agent system that actually holds together.

Months 1 to 3: Standardize the copilot baseline

The first quarter is not about scale. It is about visibility, consistency, and boundaries.

Most lean teams already have some AI usage by this point. Engineers are using chat tools, editor assistants, terminal agents, GitHub features, or remote background agents in fragmented ways. Before you try to expand, you need a shared baseline. GitHub Copilot coding agent, for example, can work independently in the background and then request review, while Claude Code can build, debug, navigate codebases, and connect to external systems through MCP. Those are meaningful capabilities, but they create different trust and review patterns.

In this first stage, I would do four things:

1. Inventory the current AI surface area

List which coding assistants, terminal tools, GitHub agents, background agents, and context connectors are already in use. In small teams, this often reveals more sprawl than expected because experimentation spreads faster than standards. That matters because GitHub, Anthropic, OpenAI, and Cursor are all now offering overlapping but non-identical forms of agentic work.

2. Choose the primary working surface

Decide whether your default control plane should be terminal-first, IDE-first, GitHub-first, or a supervisory desktop layer. That is now a meaningful architectural choice. Claude Code is terminal-native. GitHub Copilot coding agent is GitHub-native. Cursor cloud agents can be launched from multiple surfaces. Codex is explicitly framed as a command center for multiple agents.

3. Define what stays advisory versus executable

Not every AI workflow should be allowed to act. Some should stay suggestive. Some can edit code. Some can open pull requests. Some should never touch production-facing systems or sensitive internal tools. GitHub's own documentation says Copilot coding agent output should be thoroughly reviewed before merge, and OpenAI frames Codex around supervision and review rather than blind delegation.

4. Pick two repeatable copilot workflows

Good first workflows are narrow, frequent, and easy to review. Think internal tooling, test generation, documentation updates, pull-request assistance, or issue-to-PR support. The point is not to "adopt AI." The point is to establish two governed patterns the team can repeat.

Months 4 to 6: Introduce managed agent workflows

The second quarter is where the real transition starts. This is when the team moves from "AI helps me" to "AI can own bounded work under supervision."

That is now a credible step because the tools are built for it. OpenAI's Codex app supports parallel agents, isolated worktrees, reusable skills, and automations. GitHub Copilot coding agent can be assigned work and then request human review. Cursor cloud agents run in isolated remote environments and can keep working asynchronously. Claude Code GitHub Actions lets teams trigger implementation workflows with @claude inside issues and pull requests.

This is the stage where lean teams should introduce managed agents, not just better prompts.

What changes here

First, workflows become role-based. One agent may handle repo analysis. Another may draft documentation. Another may convert issues into implementation plans. Another may create reviewable pull requests. This mirrors how the leading tools themselves now think about the problem: coordinated or background agent work rather than isolated chat sessions.

Second, review moves from informal checking to explicit policy. If an agent can run commands, open PRs, or access external tools, someone needs to decide what is allowed automatically and what needs human approval. Claude Code GitHub Actions, GitHub Copilot coding agent review flows, and Cursor's remote agent model all reinforce that this is now part of the workflow design, not an afterthought.

Third, configuration becomes shared team infrastructure. OpenAI's Codex skills, Anthropic's CLAUDE.md and MCP support, and Cursor's self-hosted and plugin-oriented agent setup all point in the same direction: the compounding value comes from reusable instructions, shared constraints, and team-wide operating patterns, not private hacks.

Months 7 to 9: Build the shared context and control layer

This is where many teams stall. They manage to get one or two agents working, but the surrounding context layer stays improvised.

That becomes a problem because once agents can do real work, context access becomes an architectural decision. The MCP project now has an official registry in preview, and its 2026 roadmap prioritizes transport scalability, agent communication, governance maturation, and enterprise readiness. That is a strong signal that the ecosystem has moved beyond early experimentation into production concerns.

For lean teams, this quarter should focus on four design questions:

1. What should agents be allowed to access?

Repo access is not the same as issue-tracker access. Issue-tracker access is not the same as database or monitoring access. Anthropic's MCP examples show Claude Code pulling from issue trackers, monitoring systems, databases, design tools, and Gmail-like workflows. That kind of flexibility is powerful, but it makes exposure rules essential.

2. Which context should stay local versus remote?

Some teams should keep more work local or repo-close. Others may prefer remote or self-hosted cloud agents. Cursor's self-hosted cloud agents are specifically positioned for teams that need code, secrets, and tool execution to stay inside their own network. That is not just a hosting preference. It is part of the control model.

3. How should approval and review work across surfaces?

Once work flows across terminal agents, GitHub agents, remote cloud agents, and shared MCP-connected tools, review logic needs to stay consistent. Otherwise one part of the stack becomes much looser than the rest. GitHub's docs on coding-agent review and Copilot code review show that even vendor-native flows assume structured human review remains part of the process.

4. What deserves to become a team standard?

Not every successful experiment should scale. This quarter is about selecting the patterns that are safe, reusable, and genuinely valuable enough to standardize.

Months 10 to 12: Operationalize the managed-agent model

The final quarter is where lean teams decide whether they are building a durable system or just accumulating agent activity.

By this point, you should have enough evidence to know which workflows actually create leverage, which ones create hidden rework, and where review load or context sprawl is starting to hurt. The Codex app's emphasis on supervision, GitHub's review-first model, Anthropic's workflow automation support, and Cursor's isolated-agent environments all point to the same reality: the system gets stronger only when delegated work becomes measurable and governable.

This last stage has three jobs:

1. Formalize the operating model

Write down the agent roles, control surfaces, context rules, approval logic, and escalation paths. If that feels bureaucratic, remember that unmanaged capability is now a bigger risk than lack of capability.

2. Measure the right things

Do not just measure how much code or documentation agents produced. Measure rework, review load, merge quality, exception rates, workflow reuse, and how often agent output becomes team-standard output.

3. Decide the next shape of scale

At this point, a lean team usually chooses one of three paths:

Deepen the current managed-agent system
Expand into adjacent workflows
Redesign parts of the stack because the early control model was wrong

The key is that the decision should come from operating evidence, not from a vendor release cycle.

My take

The biggest strategic mistake I see coming is this:

Teams will think the shift from copilots to agents is mostly about buying more advanced tools.

It is not.

It is about taking on a management responsibility that did not exist at the same level before. Once agents can work in the background, open pull requests, run in isolated environments, connect through MCP, or be supervised in parallel, the real differentiator becomes operating design. The leading products are telling you that directly through their architecture and workflow choices.

Lean teams can absolutely win here.

In many ways, they are better positioned than larger organizations because they can standardize faster and avoid the inertia of big-platform committees.

But only if they stop treating agents like upgraded copilots.

Practical Framework

If you are a CTO, VP Engineering, or technical founder, this is the 12-month sequence I would use:

Quarter 1

Inventory current AI usage
Choose the primary control surface
Define advisory versus executable boundaries
Standardize two repeatable copilot workflows

Quarter 2

Introduce managed-agent workflows
Assign bounded agent roles
Move review from habit to policy
Create shared team configuration

Quarter 3

Design the context and tool-access layer
Decide what stays local, remote, or self-hosted
Align approval logic across surfaces
Standardize the best-performing workflows

Quarter 4

Formalize the operating model
Measure leverage and rework
Decide where to deepen, expand, or redesign

If you need to shape that roadmap before your tooling choices harden into the wrong system, start with AI Development Operations.

If your team already knows the design problem is bigger than internal experimentation, go directly to AI Consulting.

If you want a structured view of where you stand before redesigning anything, start with the AI Readiness Assessment.

Key Takeaways

The move from copilots to managed agents is already underway. Official product direction across OpenAI, GitHub, Anthropic, Cursor, and MCP shows a category moving toward background execution, multi-agent supervision, shared context layers, and more formal operational controls.

For lean technical teams, the right response is not to buy the most impressive tool and hope the rest sorts itself out. It is to build a 12-month transition plan: standardize the copilot baseline, introduce managed agents carefully, design the context layer, and operationalize what actually works. Teams that do that will build compounding capability. Teams that do not will collect expensive, inconsistent agent behavior.

AI Readiness vs. Consulting: Which Path Cuts Risk First

Dr Hernani Costa — Fri, 08 May 2026 06:57:22 +0000

When SME leaders choose the wrong diagnostic path, they waste 6-12 months and $50k+ in misaligned consulting spend. The difference between an AI readiness assessment and AI consulting isn't semantic—it's the difference between diagnosis and direction, and choosing wrong creates operational debt.

AI Readiness vs. AI Consulting

TL;DR: How SME leaders should decide between an AI readiness assessment and AI consulting, and when each path creates more value.

If you are choosing between AI readiness work and AI consulting, the core question is simple: do you need diagnosis first, or direction first?

These two paths are related, but they solve different problems.

An AI readiness assessment helps leadership understand whether the business, teams, workflows, and operating conditions are ready for AI adoption. AI consulting helps leadership decide where to focus, what to prioritize, and what the next practical move should be.

Choosing the wrong starting point slows progress and creates avoidable waste.

Start with readiness when the business is still operationally uncertain

Readiness work is usually the better first move when:

Teams are already experimenting without common standards.
Leadership does not trust current workflows, controls, or ownership.
The business lacks a clear view of operating risk.
Executives want a grounded baseline before they commit time or budget.

In that situation, a readiness assessment gives leadership a better foundation for action.

Start with consulting when leadership needs strategic direction

Consulting is usually the better first move when:

Leaders already see likely use cases.
The main problem is prioritization, not diagnosis.
The business needs help sequencing decisions.
Executives want an external view before committing resources.

Consulting is about direction. It should help narrow choices and clarify the path forward.

The simplest way to choose

Use this rule of thumb:

Choose readiness if the business is operationally uncertain.
Choose consulting if the business is strategically uncertain.

Operational uncertainty sounds like:

"We are not sure our workflows, controls, or ownership are ready."

Strategic uncertainty sounds like:

"We know AI matters, but we need help deciding where to focus."

When both are needed

Some companies need both. That is common when leadership wants to move quickly but the operating foundation is still weak.

In that case, the best sequence is often:

Run a focused readiness assessment.
Use the findings to narrow the consulting scope.
Move forward with clearer priorities and lower risk.

That sequence is usually faster than starting with a broad advisory engagement.

What leaders should receive from each path

From readiness work, leaders should receive:

A clear view of current-state gaps.
A view of operating risk.
Guidance on what should change before scale.

From consulting, leaders should receive:

Sharper business priorities.
Clearer ownership and sequencing.
A practical path forward.

If an offer cannot explain those outputs clearly, it will be hard to buy well.

Choose the Right Starting Point

Choosing the wrong entry point creates avoidable waste. If you're deciding between diagnosis and direction, these are your next steps:

For operational uncertainty: If you need a grounded baseline of your current state, workflows, and risks, start with our AI Readiness Assessment.
For strategic uncertainty: If you need to define priorities, sequence decisions, and build a practical roadmap, explore our AI Consulting services.

AI Consulting Scope Creep: Why Amsterdam SMEs Fail Before Starting

Dr Hernani Costa — Thu, 07 May 2026 06:57:23 +0000

Most Amsterdam-based SME leaders confuse AI visibility with AI readiness—and that confusion costs them months and budget before they've written a single line of code.

The real risk isn't choosing the wrong AI tool. It's choosing the wrong consulting engagement before you've answered the foundational questions that separate signal from noise.

AI Consulting in Amsterdam for European SMEs

TL;DR: A practical guide for Amsterdam-based SME leaders evaluating AI consulting, readiness, and the right first move.

Most Amsterdam-based SMEs do not need a grand AI transformation program. They need help deciding where AI can create real business value, what should be fixed before rollout, and how to move without creating unnecessary risk.

That is what practical AI consulting should do. It should improve decision quality, narrow scope, and help leadership move with discipline.

What AI Consulting Should Help You Decide

For most European SMEs, AI consulting is useful when leadership needs help answering questions like:

Which business problems are worth addressing first?
Which workflows are realistic candidates for AI support?
Do we need a readiness assessment before broader work begins?
Who should own adoption internally?

If a consulting engagement cannot help leadership answer those questions, it is probably too vague.

What Amsterdam Buyers Should Look For

Amsterdam has no shortage of AI messaging. That makes it easy to confuse visibility with fit.

Look for consulting that is:

Business-first rather than model-first
Clear about scope, outputs, and decisions
Realistic about governance, workflow constraints, and team capacity
Willing to tell you when not to scale yet

The right advisor should make the next decision clearer, not more abstract.

When AI Consulting Is the Right First Move

AI consulting is usually the right first move when leadership already believes AI matters but needs help with direction and sequencing.

That often means:

Narrowing use-case options
Aligning CEO, CTO, and operations leadership
Deciding where to invest first
Choosing whether to move into readiness, training, or implementation support

If the main issue is operational uncertainty rather than strategic uncertainty, start with an AI Readiness Assessment instead.

When You Should Not Buy Broad Consulting Yet

Do not buy a large consulting package just because AI is visible in your market.

You may not be ready yet if:

There is no clear executive owner
The business cannot name one or two workflows that matter
Teams are experimenting without shared boundaries
The real problem is weak process discipline rather than AI strategy

In those cases, a tighter assessment or scoping phase is usually more useful than a broad mandate.

A Practical Next Step for SME Leaders

For most SME leaders, the sensible sequence is:

Define the business problem
Confirm internal ownership
Identify the most credible first use case
Assess readiness and operating risk
Decide whether consulting should expand from there

That sequence keeps the work commercially useful and operationally realistic.

If your leadership team needs a practical view of where AI consulting can create value, review our AI Consulting path and decide whether your business needs consulting support or readiness work first.

GitHub's Coding Agent: The Workflow Restructuring Signal

Dr Hernani Costa — Wed, 06 May 2026 06:57:21 +0000

When AI coding agents enter your repository, they don't automate software delivery—they expose every gap in your operational structure. GitHub's new coding agent is forcing product and engineering teams to confront a hard truth: AI acceleration only works when your workflows are already clean.

What GitHub's Coding Agent Changes for Product Teams

TL;DR: A practical guide to what GitHub's new coding agent changes for product and engineering teams, and the workflow lessons leaders should learn from it.

For product and engineering leaders, the main lesson is not that software delivery becomes autonomous. The main lesson is that agent-based work is becoming more structured, reviewable, and workflow-bound.

GitHub's current documentation describes a coding agent that works in the background, opens one pull request per task, stays scoped to the repository where the task starts, and operates with explicit limitations and security considerations. That is not just a tooling detail. It is a workflow signal.

Why Leaders Should Pay Attention

This matters because it implies that AI-assisted development will increasingly depend on:

Cleaner task boundaries
Stronger repository hygiene
Better review discipline
Clearer access controls
Explicit human approval

In other words, the value does not come from "AI writes code now." It comes from how well the team can structure work around it.

What the Official Limitations Reveal

The official limitations are especially useful because they show where the operational friction really sits.

GitHub states that the coding agent:

Works within the repository where the task starts
Opens one pull request for each assigned task
Can be blocked by repository rules
Carries security and prompt-injection considerations

That is the opposite of magical thinking. It is a reminder that agent tooling still depends on clean workflows and clear controls.

What Product Teams Should Do with That Signal

Leaders should ask:

Are our repositories clean enough for agent-assisted work?
Can we define tasks clearly enough for background execution?
Do we have review discipline that can catch weak output?
Are we treating AI as an accelerant for a good workflow, or as a patch for a bad one?

Those questions matter even if the team does not adopt GitHub's coding agent immediately.

Why This Matters Beyond Engineering

Even non-software leaders should pay attention because repo-native agent tools are part of a broader shift: AI is moving inside normal systems of work, not sitting outside them as a chat layer.

That means adoption decisions increasingly depend on process quality, ownership, and controls. It also means leadership teams need better judgment about which AI signals are actionable and which are just noise.

From Signal to Strategy

Understanding developer AI signals is the first step. Translating them into a coherent AI automation consulting strategy is what drives real operational improvement. When teams implement workflow automation design aligned with agent capabilities, they unlock the real value: not faster code, but better-structured work.

If your team is ready to move from scattered AI experiments to a clear, practical adoption plan, our AI Readiness Assessment is designed to give you the operating clarity you need.

Sources

Written by Dr Hernani Costa | Powered by Core Ventures

Originally published at First AI Movers.

Technology is easy. Mapping it to P&L is hard. At First AI Movers, we don't just write code; we build the 'Executive Nervous System' for EU SMEs.

Is your architecture creating technical debt or business equity?

👉 Get your AI Readiness Score (Free Company Assessment)

AI Architecture Review: Control Before Scale

Dr Hernani Costa — Tue, 05 May 2026 06:57:50 +0000

Before you deploy more agents, ensure your architecture can enforce control, governance, and operational trust—or complexity will compound faster than capability.

A lot of teams think they need an AI stack review.

What they actually need is an AI architecture review.

By April 2026, the category has moved well beyond lightweight assistant usage. OpenAI's Codex app is built around supervising multiple agents, parallel work, and isolated worktrees. GitHub Copilot coding agent can work independently in the background and then request review. Claude Code can connect to external tools and systems through MCP. Cursor now supports self-hosted cloud agents that keep code and tool execution inside your own infrastructure. Those are not just feature upgrades. They are architectural consequences. (OpenAI)

An AI architecture review should answer one question: can this team scale AI-enabled delivery without losing control of quality, security, cost, and workflow coherence? If the answer is unclear, more tools will usually make the problem worse. The point of the review is not to admire the stack. It is to expose the design decisions that will determine whether AI becomes durable capability or accumulated complexity.

Why architecture review matters more now

In 2025, many teams were still testing whether AI tools were useful. In 2026, the harder problem is how to supervise and govern systems that can act. OpenAI explicitly frames the Codex app around directing and collaborating with multiple agents at scale. GitHub frames Copilot coding agent as a background worker that opens or updates pull requests for human review. MCP's official roadmap now prioritizes transport evolution, agent communication, governance maturation, and enterprise readiness. That is the market telling you the bottleneck has moved from access to operating design.

1. Use-case boundaries

The first thing an architecture review should cover is scope.

What exactly is AI allowed to do in this environment?

That sounds basic, but most teams are still too vague here. They say they want "AI for development" or "agents for engineering productivity" when what they actually need is a precise split between advisory work, bounded execution, background automation, and high-risk actions. GitHub's docs make the distinction visible by describing Copilot coding agent as working independently in the background but still requiring review. OpenAI's Codex framing does the same by emphasizing supervision rather than blind autonomy. (GitHub Docs)

A good architecture review names:

which workflows stay assistive
which workflows can be delegated
which workflows remain off-limits
which workflows deserve standardization first

Without that, the rest of the architecture becomes guesswork.

2. Control plane and working surface

The second thing to review is where the control plane should live.

That might be the terminal, the IDE, GitHub, a desktop agent supervisor, or a hybrid model. This matters because the leading products are no longer optimizing for the same shape of work. Claude Code is terminal-native. GitHub Copilot coding agent is GitHub-native. Codex is built as a multi-agent command center across app, CLI, IDE, and cloud contexts. Cursor's cloud agents emphasize isolated remote execution and can now run inside your own infrastructure. Those are not interchangeable patterns.

An architecture review should decide:

where agent work is initiated
where it is supervised
where it is reviewed
where it becomes team-standard behavior

That choice shapes everything else.

3. Context layer and tool access

This is one of the most important parts of the review, and one of the most ignored.

Once agents can reach repos, tickets, databases, docs, APIs, or monitoring systems, context access becomes architecture. Anthropic's Claude Code MCP docs show local, project, and user scopes for MCP servers, with explicit approval behavior for project-scoped servers. The official MCP roadmap now centers transport scalability, governance, and enterprise readiness. That means the context layer is no longer a convenience feature. It is part of the system boundary. (Claude API Docs)

A real review should ask:

what systems agents can reach
which access stays local
which access can be shared at project scope
which access can move to remote services
what must require approval
what should never be exposed at all

This is where many teams accidentally turn productivity tooling into a governance problem.

4. Execution and isolation model

If agents can act, then execution isolation matters.

OpenAI's earlier Codex launch described each task running in its own cloud sandbox environment, preloaded with the repository. The current Codex app emphasizes worktrees so multiple agents can work on the same repo without conflicts. GitHub describes Copilot coding agent as operating in a sandbox development environment with restricted permissions. Cursor's cloud agents run in isolated virtual machines, and its self-hosted option keeps code, build outputs, and tool execution inside the customer's own network. (OpenAI)

An architecture review should be explicit about:

local versus remote execution
sandbox versus developer-machine execution
how secrets are handled
how network access is controlled
how isolation changes the trust model

Too many teams still treat this as an implementation detail. It is not.

5. Review, approval, and human override

If the architecture review does not define review logic, it is incomplete.

GitHub's coding-agent documentation is clear that humans still need to review output. Anthropic's MCP setup prompts for approval when using project-scoped servers. OpenAI's Codex app is designed around reviewing changes, commenting on diffs, and collaborating with agents across long-running tasks. The market is already assuming that human oversight is part of the workflow. (GitHub Docs)

This review layer should specify:

what can be suggested
what can be executed
what can be submitted for review
what always requires explicit approval
what gets blocked automatically
how people override or stop agent behavior

If those rules are implicit, scale will expose the gaps quickly.

6. Shared configuration and team standards

An architecture review should also check whether the system can move from individual hacks to repeatable team practice.

Codex supports shared skills across surfaces. Claude Code supports project-level guidance and project-scoped MCP configuration. GitHub lets teams customize coding-agent behavior and apply organization-level controls. Those product directions all point to the same thing: the value compounds when behaviors become shared infrastructure rather than private tricks.

So the review should ask:

what is currently personal
what should become repo-level
what should become org-level
what must be documented before wider rollout

That is how teams stop relying on power users.

7. Evaluation, observability, and failure analysis

This is where many AI rollouts stay immature.

A strong architecture review should not just ask whether the system can act. It should ask whether the team can see what happened, evaluate output quality, and understand failure modes. GitHub's coding-agent docs now include sections on measuring pull request outcomes. OpenAI frames Codex around supervision across longer-running tasks, which only works if teams can track what agents are doing and what quality looks like. (GitHub Docs)

The review should cover:

output quality signals
rework rates
review burden
exception rates
agent activity visibility
failure categories
rollback and recovery paths

If you cannot observe the system, you cannot safely scale it.

8. Governance, security, and enterprise readiness

The architecture review also needs to confront the uncomfortable part early.

What happens when these workflows meet real policy, security, and audit requirements?

GitHub documents built-in protections and risks for Copilot coding agent, including repository permissions, branch restrictions, and sandbox behavior. MCP's official roadmap prioritizes governance maturation and enterprise readiness. Cursor's self-hosted cloud agents are explicitly positioned for teams that need tighter control over code, secrets, and tool execution. Those are not side notes. They are signals about what buyers now care about. (GitHub Docs)

A serious review should cover:

identity and permission boundaries
network and secret exposure
auditability
policy compliance
data-handling constraints
where self-hosting or customer-cloud execution is justified

This is especially important before agents touch production-adjacent systems, regulated data, or sensitive internal services.

9. Cost and deployment model

A final architecture review should examine whether the deployment model matches the business reality.

Some teams are fine with hosted convenience. Others need customer-cloud isolation, self-hosted execution, or stricter infrastructure control. Cursor's self-hosted cloud agents make that tradeoff more concrete. OpenAI and GitHub both tie agent workflows to broader product ecosystems and usage models. In practice, that means cost, vendor concentration, hosting, and control are part of the architecture review too. (Cursor)

This is where technical leaders should ask:

which parts of the system can be hosted
which parts should stay inside our infrastructure
which vendor dependencies are acceptable
what usage model creates durable economics

My take

The teams that scale AI well in 2026 are not the ones with the most agents.

They are the ones with the clearest architecture.

That architecture does not need to be huge. But it does need to answer the hard questions early: what gets delegated, where context lives, how execution is isolated, who approves actions, how quality is measured, and what governance boundary the system has to respect. The current product direction across Codex, GitHub Copilot coding agent, Claude Code, Cursor cloud agents, and MCP makes that clear. The tools are getting stronger. So the review discipline has to get stronger too.

Key takeaways

By April 2026, AI architecture review is no longer a niche enterprise exercise. It is becoming the practical checkpoint between experimentation and scale. The current product and protocol landscape already assumes stronger agent behavior, richer tool access, more formal governance needs, and more varied execution models.

That is why technical leaders should stop asking only whether a tool is impressive. The real question is whether the architecture can support repeatable, observable, governed use at scale. Teams that answer that before rollout will make better stack decisions and avoid a lot of expensive cleanup later.

Practical framework / decision lens

If you are preparing to scale AI-enabled development, this is the checklist I would use in an architecture review:

Use-case boundaries
Define what is advisory, delegated, and prohibited.
Control plane
Decide where agent work starts, runs, and is supervised.
Context layer
Review tool and data access, scopes, and approval logic.
Execution model
Choose local, sandboxed, remote, or self-hosted execution intentionally.
Review logic
Make approval, override, and blocking rules explicit.
Shared standards
Turn useful patterns into repo- or team-level configuration.
Observability
Track output quality, rework, exceptions, and failure modes.
Governance
Check permissions, auditability, policy alignment, and security boundaries.
Deployment and economics
Validate hosting, vendor concentration, and operating cost assumptions.

If you want a structured entry point before you redesign the full system, start with an AI Readiness Assessment. If you already know the issue is broader and need help designing the operating model behind it, go to AI Consulting. And if you want the broader framing behind this article, start with AI Development Operations.

Written by Dr Hernani Costa | Powered by Core Ventures

Originally published at First AI Movers.

Technology is easy. Mapping it to P&L is hard. At First AI Movers, we don't just review architectures; we build the 'Executive Nervous System' for EU SMEs scaling AI safely.

Is your AI architecture creating technical debt or business equity?

👉 Get your AI Readiness Score (Free Company Assessment)

Claude Code 2026: Terminal-First Control Over IDE Comfort

Dr Hernani Costa — Mon, 04 May 2026 06:57:56 +0000

When your coding agent sits in the terminal instead of the IDE, you're not choosing nostalgia—you're choosing architectural control. By 2026, that distinction separates teams that scale AI development from teams that struggle with agent governance.

Claude Code in 2026: When Terminal-First Still Beats IDE-First

TL;DR: Claude Code still wins in 2026 when teams need repo-close execution, MCP access, and tighter workflow control. Here's when terminal-first fits best.

The smartest choice is no longer just about model quality. It is about where your team wants control, context, and review to live.

A lot of teams are treating the coding-agent decision like a beauty contest between interfaces. That misses the real question.

By 2026, Claude Code is positioned as a terminal-native agentic coding tool, with direct repo work, command execution, GitHub Actions integration, and MCP-based access to external tools and data. At the same time, Anthropic offers a VS Code extension for teams that want a more visual interface. Even Anthropic acknowledges that interface choice matters. The mistake is assuming the IDE should win by default.

Terminal-first still beats IDE-first when the team needs tighter control over execution, faster access to the real state of the repo, easier composition with existing developer workflows, and a clearer path into automation. IDE-first has strong advantages for visual review, easier onboarding, and teams that want agent interaction to stay closer to the editor experience. The strategic question is not which interface feels nicer. It is which operating model fits the way your team builds.

Terminal-first is really about control, not nostalgia

Claude Code lives in the terminal by design. Anthropic describes it as an agentic coding tool that helps developers build features, fix bugs, navigate codebases, and automate work directly from the terminal. That matters because the terminal is already where many high-leverage engineering workflows live: git, tests, scripts, CI commands, environment tooling, deployment helpers, and local debugging.

This is the part many teams underestimate.

A terminal-native agent is not just an assistant in a different shell. It sits closer to the actual execution environment. That makes it stronger in teams where the real work is already command-driven and where engineers want the agent close to the same tools, scripts, and repo state they already trust. That is a very different design center from an IDE-first assistant that starts from the editing surface.

Where Claude Code still has the edge

1. Repo-close execution

Claude Code is strong when engineers want the agent close to the repository, local commands, and real project structure. Anthropic's docs position it around feature implementation, debugging, codebase navigation, and workflow automation from the terminal itself. That is a better fit when the repo is the system of work, not just one input into a broader desktop workflow. (Claude API Docs)

2. Workflow composability

Claude Code is not just a chat tool. Anthropic documents GitHub Actions support, where @claude can analyze code, implement changes, create pull requests, and follow project standards through repo-level guidance like CLAUDE.md. That makes terminal-first especially strong for teams that want coding agents to plug into existing repository and CI behavior rather than live only inside a local editor. (Claude API Docs)

3. MCP-based tool access

Claude Code can connect to external tools and data through MCP. Anthropic explicitly documents use cases like pulling from issue trackers, checking monitoring systems, querying databases, reading design inputs, and creating downstream workflow actions. That makes terminal-first stronger when your team needs a coding agent that can operate as part of a wider delivery workflow instead of just editing files in an IDE pane. (Claude API Docs)

4. Less abstraction between the engineer and the work

IDE-first tools can feel smoother, especially for review and inline suggestions. But terminal-first often wins for engineers who want fewer layers between themselves and the actual system. That is especially true when debugging involves scripts, build steps, environment inspection, log access, or command sequencing that already lives outside the editor. This is less about preference and more about where the truth of the workflow actually sits.

Why IDE-first still wins in some teams

This is not an anti-IDE argument.

Anthropic's own VS Code extension exists because many developers want a more visual way to work. The extension gives Claude Code a sidebar, plan-mode editing, auto-accept edits, file attachment, session management, and access to MCP servers configured through the CLI. For teams that want lower friction, visual review, and easier adoption for less terminal-heavy engineers, IDE-first can be the better choice. (Claude API Docs)

The broader market supports that too. Cursor's background agents run asynchronously in isolated Ubuntu-based machines, with internet access, package installation, and repo cloning from GitHub. Cursor also now supports self-hosted cloud agents that keep code, build outputs, and tool execution inside the customer's own infrastructure. That is a strong answer for teams that want IDE-centered control combined with remote execution and security boundaries. (Cursor Documentation)

OpenAI is pushing in a different direction again. Codex is positioned as a command center for multiple agents, parallel work, worktrees, and automations across app, CLI, IDE, and cloud. That makes it a stronger fit when the team wants a supervisory layer above individual editing workflows. (OpenAI)

So when does terminal-first still beat IDE-first?

Terminal-first usually wins under five conditions.

1. Your best engineers already work from the command line

If the real workflow runs through git, tests, package managers, shells, scripts, containers, and CI-related commands, then the terminal is not a side surface. It is the operating surface. Claude Code fits that well.

2. You want the agent close to the real environment

Terminal-first is often better when the problem is not just file editing but sequencing real commands and acting against the actual repo and runtime context.

3. You want easier automation beyond the editor

Claude Code GitHub Actions and MCP make terminal-first especially attractive when the agent needs to move into repo workflows, issue handling, CI, or tool-connected delivery tasks.

4. You want fewer abstraction layers

If the team values directness over polish, terminal-first often stays clearer under pressure. This is especially important in debugging-heavy or infra-adjacent work where the editor is only one part of the environment.

5. You need a stricter operating model

Terminal-first can be easier to standardize when you want consistent repo guidance, command boundaries, and explicit workflow control rather than open-ended assistant behavior distributed across multiple UI surfaces. Anthropic's docs on project guidance, GitHub Actions, and MCP support all reinforce this strength.

When IDE-first is the better choice

IDE-first usually wins when:

The team is less terminal-native
Visual review and low-friction onboarding matter more than direct command control
The agent is used more for assisted editing than full workflow ownership
You want remote isolated execution managed behind a friendlier interface
The team prefers a supervisory or editor-centered experience over command-line composition

Cursor's background agents and self-hosted cloud agents are especially relevant here because they combine visual workflow entry with isolated execution environments and stronger enterprise control options. Codex is relevant when the team wants multi-agent orchestration rather than a repo-close single-agent default.

My take

Claude Code still beats IDE-first in 2026 when the team's advantage comes from directness.

Not from aesthetics. Not from trendiness. From directness.

If your engineers already think in repos, shells, tests, scripts, and CI flows, the terminal is usually the shortest path between intent and action. In those environments, terminal-first often creates a better agent operating model because the tool sits close to where work is already real. The IDE can still be useful, and Anthropic's own VS Code extension shows that. But terminal-first remains the stronger default when you want control, composability, and repo-native execution to lead the workflow.

The mistake is thinking every team should make the same choice.

The real decision is architectural: where should the control plane live, where should execution happen, and how should review, context, and automation connect around it?

Practical Framework for Decision Making

Use this sequence before standardizing on a tool.

1. Map where your team's real work happens

Is the truth of the workflow in the terminal, the IDE, GitHub, or a remote execution lane?

2. Decide whether you need repo-close execution or supervisory coordination

Claude Code is stronger for the first case. Codex and remote-agent products are often stronger for the second.

3. Define how much tool access the agent needs

If the agent must interact with issue trackers, monitoring, databases, or APIs, MCP support becomes part of the decision.

4. Choose the review model

Will the agent suggest, execute, or submit work for review? GitHub and Cursor both make the review and isolation model a core part of the product story.

5. Start with one governed workflow

Do not standardize around a tool first. Standardize around one workflow that proves the operating model.

Key Takeaways

Claude Code remains a strong choice in 2026 because terminal-first still solves a real operating need: repo-close execution, command-line composability, GitHub workflow integration, and MCP-based access to external tools and data. Anthropic's own product surface shows that terminal-first is still central even as it expands into a VS Code extension for teams that want a more visual interface.

IDE-first is not wrong. It is often better for onboarding, visual review, and editor-centered work. But technical leaders should stop treating this as a simple UI preference. It is an operating-model decision about control, context, review, and automation. Teams that understand that will choose better stacks.

MCP Context Layer Design: The $2M Governance Gap

Dr Hernani Costa — Sun, 03 May 2026 06:57:47 +0000

When MCP becomes infrastructure, context access becomes a control-plane decision—and most technical leaders are still treating it like a plugin catalog.

MCP is becoming infrastructure. Learn how technical leaders should design context access, approval rules, and governance for AI agents in 2026.

The Model Context Protocol is no longer just a list of connectors. It is becoming part of the operating architecture for how agents reach tools, data, and systems.

A lot of teams still talk about MCP the way people talked about plugins a year ago, asking which servers are popular or which integrations look useful. That is already the wrong level of thinking. For MCP in 2026, the conversation has shifted. With an official registry in preview, a roadmap centered on scalability and enterprise readiness, and support from OpenAI and Anthropic, the protocol is now part of the core architecture for agentic systems. read

That shift changes the real question for technical leaders. The question is no longer, "Which MCP servers should we install?" The better question is, "What should our agents be allowed to see, touch, and trigger, through which transport, under which approval rules, and with what operational boundaries?" OpenAI's current MCP guidance explicitly distinguishes hosted MCP tools, Streamable HTTP servers, and stdio servers, while Anthropic positions MCP as the standard way Claude products connect to external tools and data. read

That is why MCP is now a context-layer design problem. And context-layer design is an operating-model problem.

Why MCP in 2026 Stopped Being Just a Discovery Story

The official MCP Registry is now the centralized metadata repository for publicly accessible MCP servers, with standardized metadata, namespace management through DNS verification, a REST API for discovery, and backing from major ecosystem contributors including Anthropic, GitHub, PulseMCP, and Microsoft. It is still in preview, which matters, but the direction is clear: the ecosystem is moving toward more formal discovery, metadata, and client interoperability. read

At the same time, the MCP maintainers say the protocol has moved well past its origins as a way to wire up local tools. The 2026 roadmap says MCP now runs in production, powers agent workflows, and is being shaped by formal governance, SEPs, and working groups. The roadmap's top priorities are transport evolution and scalability, agent communication, governance maturation, and enterprise readiness. read

That combination matters more than another server catalog. It means the real work has shifted from "What exists?" to "How should we expose capability safely and repeatably?"

The Transport Decision Is No Longer a Technical Footnote

One of the easiest ways to see MCP's maturity is in the transport story.

The current MCP transport specification defines two standard transports: stdio and Streamable HTTP. The March 2025 transport spec says Streamable HTTP replaces the older HTTP+SSE transport, and the OpenAI Agents SDK notes that SSE support remains only for legacy use and recommends Streamable HTTP or stdio for new integrations. The spec also makes clear that Streamable HTTP can optionally use SSE for server messages, which is different from treating standalone HTTP+SSE as the preferred integration pattern. read

That sounds like protocol detail, but it has direct operating consequences. Once you choose between stdio, Streamable HTTP, and hosted MCP access, you are not just choosing a transport. You are making decisions about latency, remote exposure, session behavior, scalability, approval flow, deployment model, and who controls the tool invocation path. OpenAI's MCP guidance also highlights tool filtering and caching considerations, which reinforces the fact that context access has become something teams actively manage, not just enable. read

Hosted, Remote, and Local MCP Are Different Operating Choices

OpenAI's current SDK breaks MCP integration into three main patterns: hosted MCP server tools, Streamable HTTP MCP servers, and stdio MCP servers. Hosted MCP tools push the round-trip into the Responses API, while Streamable HTTP and stdio keep more of the invocation flow on the local or application side. Anthropic's Claude Code docs, by contrast, emphasize connecting Claude Code to external tools and data through MCP, with configuration scopes for local, project, and user contexts. read

That distinction is strategic. A local stdio server, a remote Streamable HTTP server, and a hosted MCP tool may all appear to solve the same user need. They do not create the same governance, observability, or operational profile.

If your team treats them as interchangeable, you will make context-exposure decisions by accident.

Security and Authorization Are Now Part of the Architecture

The MCP transport and authorization documentation makes the security direction explicit. The transport spec warns that Streamable HTTP servers must validate Origin, should bind locally to localhost when appropriate, and should implement proper authentication. The authorization guidance recommends OAuth 2.1 public-client patterns for local clients, metadata discovery, token handling best practices, and dynamic client registration. read

That means "installing a server" is no longer an innocent productivity tweak. It can mean exposing internal systems, token flows, or action surfaces into agent workflows that were never designed with those trust boundaries in mind.

For technical leaders, this is the real shift. MCP is not just a better integration pattern. It is a growing control plane for how models and agents reach business systems, where expert AI Governance & Risk Advisory becomes critical to operational AI implementation and reducing technical debt.

Claude Code Makes This Visible

Anthropic's Claude Code docs are useful because they show MCP in its most operational form.

Claude Code can use MCP to connect to external tools, databases, and APIs, and Anthropic documents scope-aware configuration, OAuth flows for remote servers, output warnings for very large MCP results, and even the ability to expose Claude Code itself as an MCP server. That is not "assistant with plugins." That is an agentic interface sitting close to code, tools, and systems. read

This is why the old MCP content pattern is aging fast. A list of interesting servers can still attract readers. It does not help a CTO decide:

which servers should be available only locally
which ones can be shared at project scope
which ones deserve remote OAuth-backed access
which ones should never be exposed to general agent use at all

Those are management questions hiding inside technical configuration.

A Practical Decision Lens for the Context Layer

Here is the framework I would use.

1. Classify servers by business role

Start by grouping MCP servers into roles, not vendors:

Local development context: repo tools, file access, local testing
Internal system access: databases, tickets, dashboards, internal APIs
External SaaS actions: Slack, GitHub, Figma, Gmail, CRM
High-risk action surfaces: production changes, finance, regulated data, destructive actions

Once you do that, the evaluation gets cleaner. You stop asking, "Is this server cool?" and start asking, "Should agents in this environment have this capability at all?" This is a core question in any AI Readiness Assessment for EU SMEs and technical teams designing workflow automation for business process optimization.

2. Choose transport by trust boundary

Use stdio when the tool belongs close to the local environment. Use Streamable HTTP when remote service access is justified and operationally manageable. Use hosted MCP only when pushing the invocation path into the model-side infrastructure is acceptable for the use case and review model. Those distinctions are built directly into OpenAI's MCP guidance and the MCP transport spec. read

3. Define approval and filtering rules early

OpenAI's Agents SDK includes optional approval flows for hosted MCP tools and tool filtering for MCP servers. That is a signal worth noticing. The ecosystem is moving toward selective exposure and explicit permission models, not blanket tool enablement. read

If every available tool is exposed to every relevant agent, you are not building flexibility. You are building avoidable risk.

4. Treat metadata and registry maturity as selection inputs

The official registry's standardized server.json, namespace management, and discovery API are useful not because they make discovery easier, but because they make trust evaluation easier. Servers with clearer metadata, install instructions, naming, and provenance are easier to govern than ad hoc connectors copied from scattered lists. read

5. Design for enterprise readiness before scale

The MCP roadmap's explicit enterprise-readiness focus calls out audit trails, SSO-integrated auth, gateway behavior, and configuration portability. Those are exactly the issues that appear when an MCP experiment becomes a team workflow or a business-critical interface. read

That is why MCP adoption should be treated like architecture work, not just tool enablement.

My Take

The most common MCP mistake in 2026 is thinking the protocol solved the hard part. It did not.

MCP is solving standardization. That is valuable. But standardization increases the speed at which teams can expose tools and context to agents. It does not decide what should be exposed, who should approve it, how it should be audited, or when the workflow is safe enough to scale.

That is your job. And that is why MCP is now a context-layer design problem, a key component of a modern Digital Transformation Strategy and AI Tool Integration for business leaders managing Operational AI Implementation.

Coding-Agent Stack 2026: Control Model Over Tool Selection

Dr Hernani Costa — Sat, 02 May 2026 06:57:44 +0000

Your coding-agent buying decision is now a governance problem, not a tool problem. Most technical leaders are still evaluating AI coding assistants as 2025-era IDE add-ons, but the market has fundamentally shifted to supervised multi-agent workflows—and your team's ability to control, isolate, and review delegated work determines success or failure.

The Coding-Agent Stack Changed in 2026. Most Teams Are Still Buying Like It's 2025

TL;DR: The coding-agent stack has evolved beyond simple tools. Learn how technical leaders should evaluate control, isolation, and review models in 2026.

The market moved from single assistants to supervised agent workflows. Technical leaders now need to choose an operating model, not just a tool.

Many technical teams still evaluate AI coding tools as though they are simple IDE add-ons with better autocomplete, but this thinking is outdated. The coding-agent stack of 2026 has evolved dramatically. The strongest products from OpenAI, Cursor, GitHub, and Anthropic are no longer just inline assistants; they are command centers for multiple supervised agents, parallel work, and scheduled automations. This shift means the buying decision has changed from selecting a tool to choosing a scalable operating model for your team.

The question is no longer, "Which AI coding tool should we standardize on?"

The better question is, "What kind of agent stack can our team actually supervise, govern, and scale?"

The category moved from assistance to delegation

In 2025, many teams were still deciding whether AI could be trusted to help.

In 2026, the stronger products assume you are ready to delegate real work.

OpenAI's framing is explicit. The core challenge has shifted from what agents can do to how people direct, supervise, and collaborate with them at scale. The Codex app is built around multiple agents, separate threads, parallel work, isolated worktrees, reusable skills, and background automations. read

GitHub's framing is similar in a different environment. Copilot coding agent can work independently in the background on issues and pull requests, while Copilot code review can review pull requests across GitHub, mobile, VS Code, Visual Studio, Xcode, and JetBrains environments. GitHub also notes that human validation is still required because Copilot can miss issues or make mistakes. read

This is not a small product update.

It is a change in how software work gets organized.

The real buying decision is now about execution shape

When technical leaders compare coding tools today, they often flatten four different decisions into one.

1. Where the agent works

Claude Code is terminal-first and repo-close. Cursor background agents run in isolated remote environments. Copilot coding agent works through GitHub-native workflows. Codex spans app, CLI, IDE, and cloud usage with shared configuration and sessions. read

That is not just interface preference.

It changes how context is loaded, how access is controlled, how fast work can start, and how easily activity can be supervised.

2. How work is isolated

Codex emphasizes built-in worktrees so multiple agents can work on the same repository without conflicts. Cursor says background agents run in isolated Ubuntu-based machines. GitHub Copilot describes a restricted sandbox development environment for its coding agent. read

Isolation is not a convenience feature.

It is part of your review and risk model.

3. How context is exposed

Anthropic's Claude Code documentation highlights MCP support and repository workflows. GitHub documents MCP support in agentic coding tools and IDEs for Copilot coding agent workflows. OpenAI positions Codex skills as a way to bundle instructions, resources, and scripts so the system can reliably connect to tools and workflows. read

That means your coding stack decision increasingly overlaps with your context architecture decision.

4. How review happens

GitHub's coding agent works in the background and then requests review. OpenAI says Codex lets you review changes, comment on diffs, and open them in your editor. GitHub's own responsible-use guidance says Copilot reviews still need human validation. read

So the real issue is not whether the tool can generate code.

It is whether your team has a credible review model for delegated work.

Why most teams are still buying like it is 2025

Most evaluation processes are still too shallow.

They ask:

Which model feels smartest?
Which UI is nicest?
Which vendor is getting the most attention?
Which one has the best demos?

Those are not useless questions.

They are just no longer sufficient.

In 2026, a coding-agent evaluation should ask:

Do we need terminal-native control or a supervisory control plane?
Do we want local execution, remote isolated environments, GitHub-native delegation, or a blended model?
Which workflows deserve agent delegation first?
What needs explicit approval?
What belongs in shared team configuration?
How will we measure rework, review burden, and governance exceptions?

That is an operating-model conversation that a proper AI Readiness Assessment can clarify, not a shopping conversation.

The strongest teams will not standardize on one tool for everything

This is the mistake I see coming.

Teams are going to search for one winner and then try to force every workflow into it.

That is probably the wrong design for many technical organizations.

A more mature pattern is emerging:

terminal-first agent for deep repo work and direct technical execution
supervisory agent workspace for parallel tasks, long-running work, and orchestration
GitHub-native agent layer for issue-to-PR flow and review handoff
remote background agent lane for async experiments, heavier setup, or sandboxed execution
shared context and tool layer for controlled access to systems and workflows

Not every team needs all five.

But almost no serious team will succeed by pretending these are all the same product choice.

A Practical Decision Lens for Your Coding-Agent Stack

If you are choosing your coding-agent stack now, this is the lens I would use.

Agent role design

Decide what kinds of work you want agents to own:

repo navigation
debugging
incremental feature work
pull request generation
code review
documentation
recurring background tasks

Do not buy tools first and invent roles later.

Control model

Define where the highest-trust control point should live:

terminal
IDE
desktop command center
GitHub workflow
remote background environment

That one choice shapes the rest of the stack.

Isolation model

Choose how separated the work should be from developer machines, production secrets, and live systems.

If you skip this step, you will confuse productivity with safe delegation.

Review model

Be explicit about what requires:

human review
approval before execution
automatic blocking
read-only access
auditability

This is where trust gets built.

Rollout model

Start with one or two repeatable workflows, not broad mandates.

The goal is not to "adopt AI coding."

The goal is to build one governed, useful, repeatable delivery pattern at a time. This is the core of effective Operational AI Implementation.

My take

The coding-agent stack changed because the products changed shape.

OpenAI is betting on multi-agent supervision. Anthropic is still strong where terminal-native execution and repo intimacy matter. GitHub is turning delegation and review into GitHub-native workflow. Cursor is making remote asynchronous agents part of the everyday IDE workflow. read

That does not mean one vendor won.

It means the category matured.

And once the category matures, buying discipline matters more than hype.

Most teams do not need a prettier comparison table.

They need a serious answer to this question:

How should our engineers, agents, repos, tools, and review loops work together?

That is the real stack decision now.

Practical framework / decision lens

If your team is already experimenting, use this sequence:

Map the current agent surface area
List every coding assistant, background agent, repo-connected workflow, and AI review path already in use.
Choose the primary control plane
Decide whether your team should center work in the terminal, IDE, desktop supervisor, GitHub, or a hybrid pattern.
Define the first governed workflows
Pick a narrow set such as bug fixing, documentation, internal tooling, or pull request support.
Set review and approval thresholds
Make it clear what agents can suggest, execute, or submit for human review.
Measure the real tradeoff
Track speed, rework, review load, failure modes, and tool overlap.

Agentic Dev Ops: The $2M Governance Gap in 90 Days

Dr Hernani Costa — Fri, 01 May 2026 06:57:52 +0000

Uncontrolled agent rollouts cost EU tech teams 40% of productivity gains in rework and security debt. Here's the operating model that prevents it.

The First 90 Days of Agentic Development Operations

TL;DR: Discover a practical 90-day plan for agentic development operations. Learn to move from AI experiments to governed, repeatable delivery systems.

A practical rollout path for technical leaders who want to move from scattered AI experiments to governed, repeatable delivery systems.

The first mistake teams make with agentic development operations is trying to scale too early.

They buy a few strong tools, run a handful of impressive demos, and assume the next step is wider rollout.

In April 2026, that is exactly where the real risk begins. OpenAI's Codex app is built around supervising multiple agents, parallel work, built-in worktrees, and scheduled automations. Claude Code remains a terminal-first agentic tool with MCP access to external systems and CI workflows. GitHub Copilot coding agent works in the background on issues and pull requests, then asks for review. Cursor now supports background agents in isolated remote environments and, as of late March 2026, also supports self-hosted cloud agents that keep code and execution inside your own network. read

That means the constraint is no longer whether agentic development is possible.

The constraint is whether your team has a rollout model that can control it.

The first 90 days matter because this is when technical leaders decide whether AI becomes a governed capability or a messy layer of unmanaged delegation. The teams that get value out of agentic development do not start by asking for the "best" tool. They start by defining where agents can work, what systems they can reach, what requires review, and which workflows are safe enough to standardize first. That matters even more now that MCP has an official registry in preview, a 2026 roadmap centered on transport scalability, agent communication, governance, and enterprise readiness, and mainstream vendor support across OpenAI and Anthropic surfaces. read

That is why the right 90-day plan is not a transformation slogan.

It is an operating design sequence.

Why the first 90 days are different in 2026

A year ago, many teams were still piloting assistants.

Now they are dealing with agents.

That sounds like a language shift, but it is actually a management shift. Codex is positioned as a command center for multiple agents. Cursor's agents can run asynchronously in remote isolated environments with internet access and repo cloning. GitHub Copilot coding agent can work independently in the background and then request review. Claude Code can edit files, run commands, create commits, and connect through MCP to external tools and data sources. read

Once agents can act, not just suggest, your rollout sequence becomes more important than your benchmark scores.

Phase 1, days 1 to 30: establish the control model

The first month is about visibility and boundaries.

Do not start by scaling usage. Start by understanding what is already happening and where agents are likely to create leverage or risk.

1. Map the current agent surface area

List every assistant, coding agent, background workflow, MCP server, repo integration, and AI-enabled review path already in use.

Most teams underestimate this badly. The point is not just inventory; a proper AI Readiness Assessment aims to see where work is already being delegated informally across terminal tools, IDE tools, GitHub workflows, and remote agent environments. That distinction matters because each surface carries a different supervision and trust profile. read

2. Choose the primary control plane

Pick where your team will center agent work first.

For some teams, that is the terminal. For others, it is GitHub-native issue-to-PR flow. For others, it is a desktop control layer built for multi-agent supervision. OpenAI, Anthropic, GitHub, and Cursor are now clearly optimizing for different control patterns, which means technical leaders need to choose intentionally rather than drift into whatever an individual engineer prefers. read

3. Define trust boundaries early

This is where most teams try to save time and end up creating chaos.

Decide what stays read-only, what can generate changes, what can run commands, what can open pull requests, and what always requires human approval. GitHub explicitly says Copilot coding agent still requires human validation because it can miss issues or make mistakes. Cursor's background-agent docs warn that auto-running terminal commands and internet access introduce prompt-injection and exfiltration risk. OpenAI's Codex framing also emphasizes supervision and review over blind delegation. read

4. Set the context-access rules

If your team is using MCP or planning to, decide which systems agents should be allowed to access and through what route.

This matters more now because MCP is maturing into infrastructure. The current MCP transport model centers stdio and Streamable HTTP, while OpenAI's Agents SDK recommends Streamable HTTP or stdio for new MCP integrations and notes that standalone SSE is deprecated for new work. That means context access is now something you architect, not just enable. read

Phase 2, days 31 to 60: standardize one or two repeatable workflows

The second month is about proving one governed pattern at a time.

This is where many teams get impatient and try to spread agents across too many workflows. That usually creates tool sprawl, inconsistent review behavior, and weak learning.

1. Pick narrow workflows with real operating value

Good candidates usually share three traits:

they happen often
they already have some structure
mistakes are visible before they become expensive

Typical examples include internal tooling, documentation updates, issue triage, test generation, controlled bug fixing, and pull-request support. Those workflows fit well with the actual capabilities current products emphasize: background coding tasks, repo analysis, pull request generation, CI-oriented automation, and controlled review handoff. read

2. Standardize the workflow, not just the prompt

This is where Workflow Automation Design and AI Automation Consulting start to separate serious teams from experimental ones.

Define:

where the task starts
which agent or surface owns it
what context is available
what commands or tools are allowed
what the review step looks like
how completion gets measured

If that sounds too procedural, good. Agentic systems need operating rules. Otherwise you are not scaling capability. You are scaling variability.

3. Create shared team configuration

One of the strongest 2026 shifts is that the products now support reusable team behavior more directly. Codex uses shared skills across the app, CLI, and IDE. Claude Code supports settings and MCP scopes at different levels. Cursor background agents can use committed environment configuration. Those product directions all point toward the same lesson: individual hacks do not compound. Shared configuration does. read

4. Measure rework, not just output

If you only track how much faster agents produce code or documentation, you will overstate success.

The better questions are:

how much human cleanup is required
how much review burden increased
how often work has to be redone
where policy or security exceptions appear
whether the workflow is actually reusable by the wider team

That is the difference between productivity theater and operational leverage.

Phase 3, days 61 to 90: make the model scalable

The third month is about deciding whether you have a real operating pattern or just a promising experiment.

1. Audit the first workflows honestly

By this point, you should know where agents are helping and where they are adding hidden cost.

Look for:

duplicated tool roles
messy handoffs
unclear ownership
excess permissions
review bottlenecks
workflows that only work for one power user

This is where many teams discover that their best demo is not yet their best operating pattern.

2. Tighten the context layer before expanding

If MCP or other context-exposure layers are in play, this is the point to lock down what should actually be standardized.

The official MCP roadmap's enterprise-readiness focus includes governance maturation, transport evolution, and enterprise needs such as more robust operational patterns. That is a signal worth taking seriously. If you expand context access faster than you mature review and governance, you are likely to increase organizational risk faster than delivery quality. read

3. Decide what belongs in the team standard

Not every successful workflow should become a standard.

Some should remain narrow. Some should be paused. Some deserve investment. The goal after 90 days is not "company-wide AI adoption." The goal is a small number of governed, measured, repeatable workflows that the team can actually trust.

4. Choose the next lane based on operating fit

After the first 90 days, most teams are ready for one of three paths:

deepen the current model
expand into adjacent workflows
redesign the architecture because early assumptions were wrong

That decision should come from operating evidence, not vendor excitement.

What technical leaders should avoid

There are four rollout mistakes I would avoid right now.

Mistake 1: treating every agent surface as interchangeable

A terminal-native agent, a GitHub-native coding agent, a remote background agent, and a desktop multi-agent supervisor are not the same thing. They create different review, isolation, and context patterns. read

Mistake 2: expanding permissions before review logic

This is especially risky once agents can access external systems or auto-run commands. Cursor's own docs call out exfiltration risk for background agents with auto-run terminal behavior and internet access. read

Mistake 3: measuring speed without measuring cleanup

Fast output can hide expensive rework.

Mistake 4: rolling out agents before the team has a shared operating model

That is how you end up with impressive activity and weak organizational leverage.

My take

The first 90 days of agentic development operations should feel more like control design than technology rollout.

That may sound slow.

It is usually faster.

The current generation of tools is already good enough to create a mess quickly. Multi-agent supervision, background execution, shared context layers, and repo-connected review flows are here now. The teams that win will not be the ones with the most agent activity. They will be the ones that standardize a small number of high-value patterns, enforce trust boundaries early, and expand only after the system becomes legible. This is the core philosophy behind Operational AI Implementation and AI Governance & Risk Advisory. read

Practical Framework for Agentic Development Operations

If you want a usable 90-day rollout sequence, use this:

Days 1 to 30

map current agent usage
choose the primary control plane
define trust boundaries
set context-access rules

Days 31 to 60

choose one or two repeatable workflows
standardize the workflow design
create shared configuration
measure rework and review load

Days 61 to 90

audit what actually worked
tighten the context layer
formalize the team standard
decide the next expansion lane

AI DevOps in 2026: When Tool Choice Becomes Governance

Dr Hernani Costa — Thu, 30 Apr 2026 06:57:44 +0000

The $2M mistake: Treating AI agent adoption as a procurement problem instead of an operating model redesign.

A year ago, technical leaders asked: which AI coding tool should we adopt? That question is obsolete. By April 2026, the constraint has shifted from capability access to operational design. The real problem is now governance, supervision, and rollout architecture—not tool selection. This is why AI development operations matters. It is the operating model behind AI-enabled delivery.

Coding agents got better. Protocols got real. The hard part now is deciding how your team should supervise, govern, and scale AI-enabled delivery.

Once teams start using coding agents, MCP servers, automation layers, and agent-to-agent workflows, the bottleneck moves. The issue is no longer access to capability. The issue is operating design: who can delegate what, which systems agents can reach, how work gets reviewed, how context is governed, and how teams move from isolated wins to repeatable practice.

By April 2026, the market has shifted from single-assistant experimentation toward multi-agent workflows, shared context layers, standardized tool access, and early agent interoperability. OpenAI's Codex app now positions itself as a command center for multiple agents working in parallel with built-in worktrees and automations. Anthropic still positions Claude Code as a terminal-first coding agent with MCP-based access to external tools and systems. The MCP ecosystem now has an official registry, official transport guidance has moved toward stdio and Streamable HTTP, and Google's A2A surfaces in Gemini Enterprise still carry preview status.

That changes the real buying question. It is not just "Which tool is best?" It is "How should our team work with agents?"

The market moved from assistance to supervision

OpenAI's own framing makes the shift clear. The Codex app is built for managing multiple agents, parallel work, long-running tasks, and isolated worktrees. OpenAI explicitly describes the challenge as how people direct, supervise, and collaborate with agents at scale, not whether agents can do useful work.

Anthropicâ€™s positioning points to the same reality from a different angle. Claude Code remains terminal-first, composable, and close to the repo, with direct actions, command execution, CI workflows, and MCP support for external tools and data sources. In other words, it is not just a chat assistant. It is a working agent that can act inside a real delivery environment.

That is why tool comparisons alone are becoming less valuable. A CTO does not need another vague ranking. A CTO needs to know:

when an agent should operate inside the terminal versus inside a desktop control layer
when context access should stay local versus move to remote servers
when a team needs a shared protocol layer
when governance should block scale until the workflow is redesigned

MCP stopped being a novelty

A lot of 2025 content treated MCP like a growing list of cool servers. That is too shallow for 2026. The MCP project now has an official registry, formal governance, and a roadmap that explicitly calls out transport scalability, agent communication, governance maturation, and enterprise readiness. Its transport specification now centers stdio and Streamable HTTP, and the newer spec explicitly says Streamable HTTP replaces the older HTTP+SSE transport. OpenAI's Agents SDK reflects the same shift by recommending hosted MCP tools, Streamable HTTP, and stdio, while noting that SSE is deprecated for new integrations.

That matters because MCP is no longer just a discovery story. It is becoming part of the context and tool-access architecture. The question is no longer "Which servers exist?" The better question is "What should agents be allowed to touch, through which transport, under which approval rules, and with what review path?" That is an operating decision, not a shopping decision.

A2A is promising, but most teams are not ready to treat it as default infrastructure

Google has made A2A more concrete across Cloud Run, Vertex AI Agent Builder, and Gemini Enterprise. At the same time, some Gemini Enterprise A2A surfaces are still explicitly marked as Preview, and Google notes that model armor does not protect conversations with registered A2A agents in the Gemini Enterprise web app.

That does not make A2A unimportant. It means technical leaders should treat it as an architectural option with uneven enterprise maturity, not as a universal default. This is a good example of why AI development operations matters so much right now. The technology layer is moving quickly, but the operating assumptions around trust, review, security, and control are still uneven across vendors and surfaces.

If you adopt the protocol story without redesigning the operating model, you increase complexity faster than you create leverage.

Tool choice is now a management problem

When teams say they are "choosing an AI stack," they often mean one of four different decisions without realizing it.

1. Work delegation

What kinds of tasks can agents own end to end, and which tasks must stay advisory?

2. Context exposure

Which systems, documents, repos, and services should be reachable by agents, and through which mechanism?

3. Review logic

Who checks output, at what stage, with what thresholds, and what gets blocked automatically?

4. Rollout sequence

Which teams, workflows, and environments should adopt first, and what has to be standardized before expansion?

Those are management decisions because they shape behavior across people, process, risk, and delivery quality. A tool can make those decisions more visible. It cannot make them for you.

The new failure mode is not weak models. It is unmanaged capability.

In 2024 and 2025, the common fear was that models were not reliable enough. That is still part of the story, but it is not the main bottleneck anymore for many technical teams. The bigger risk in 2026 is unmanaged capability.

Teams now have access to:

agents that can work for longer
agents that can run in parallel
agents that can act through connected tools
protocols that standardize context and delegation across systems

That is useful. It is also dangerous when the surrounding operating model stays informal. The new failure mode looks like this:

one team standardizes on a useful workflow while the rest of the company improvises
MCP access expands faster than review and approval logic
coding agents accelerate output but increase hidden architectural debt
governance shows up after tool adoption instead of shaping it
leaders think they bought productivity when they actually bought complexity

A practical framework for AI development operations

Here is the decision lens I would use with a technical leadership team right now.

Layer 1: Agent role design

Define what each agent is for. Not "AI for coding." More like:

code generation agent
repo analysis agent
documentation agent
workflow automation agent
retrieval and context agent

If every tool does everything, nobody knows what should be trusted.

Layer 2: Context architecture

Decide how agents reach systems and information. This includes:

local repo access
MCP via stdio
MCP via Streamable HTTP
hosted tool access
early A2A interoperability where justified

The goal is not maximum connectivity. The goal is controlled connectivity.

Layer 3: Review and approval logic

Set the thresholds. What can be suggested? What can be executed? What needs human approval? What requires auditability? What must stay read-only? This is where trust is built—a core component of any robust AI Governance & Risk Advisory framework for technical teams.

Layer 4: Rollout design

Start where leverage is real and risk is manageable. Good early candidates often include:

internal tooling
documentation workflows
test generation
issue triage
controlled support workflows
structured knowledge access

Do not start with the most impressive demo. Start with the clearest operating value.

Layer 5: Measurement

Track more than speed. Measure:

rework
review burden
quality drift
tool overlap
governance exceptions
workflow adoption
delivery throughput

If you only measure output volume, you will overestimate success.

My take

Most teams do not have an AI tooling problem anymore. They have an AI management problem. The market made that easy to miss because the interfaces still look like tools. But under the surface, the shape of work has changed. When one product is built around supervising multiple agents, another is built around terminal-native action, a shared protocol is standardizing context access, and agent interoperability is entering enterprise surfaces in preview, the question is no longer "Should we use AI in development?"

The question is whether your team has a serious operating model for using it. That is the new gap between experimentation and advantage.

What technical leaders should do next

If you are leading engineering, platform, or technical operations, here is the sequence I would recommend.

1. Audit current agent behavior

Map which tools, assistants, automations, and protocols are already in use.

2. Define the control model

Set boundaries for access, review, execution, and escalation.

3. Standardize one or two high-value patterns

Turn individual wins into shared team workflows.

4. Delay broader scale until governance is real

Do not expand agent reach faster than approval logic and ownership.

5. Design the operating model before the stack calcifies

This is where most teams wait too long, and where expert AI Strategy Consulting can prevent costly mistakes in your workflow automation design and operational AI implementation.

AI Coding Stack ROI: Why Tool Choice Drives $500K+ Delivery Risk

Dr Hernani Costa — Wed, 29 Apr 2026 06:57:54 +0000

Most engineering leaders are optimizing for the wrong metric. They compare AI coding tools by feature checklist, not by how each tool reshapes your delivery velocity, code review burden, and technical debt trajectory—the three factors that actually move P&L.

Choosing the wrong AI coding stack doesn't just waste tool budget. It creates rollout friction, weak review loops, duplicated workflows, and a growing pile of AI-generated code nobody fully trusts. For CTOs managing AI Governance & Risk Advisory across distributed teams, this decision is as much about operational risk as it is about productivity.

Best AI Coding Stack for Engineering Teams in 2026

TL;DR: Choosing the best AI coding stack for 2026? This CTO framework helps you compare Cursor, Codex, Claude Code, and Copilot to avoid costly errors.

How CTOs should choose between Cursor, Codex, Claude Code, and Copilot without wasting budget, slowing delivery, or creating a governance mess

Most teams are asking the wrong question. They ask, "Which AI coding tool is best?" The real question is: which AI coding stack gives your engineers the right mix of speed, control, delegation, and review quality for the way your company actually builds software?

That is why this decision matters. A bad choice does not just waste tool budget. It creates rollout friction, weak review loops, duplicated workflows, and a growing pile of AI-generated code nobody fully trusts.

As of April 3, 2026, the strongest default answer for most teams is Cursor + OpenAI Codex. Cursor remains the strongest editor-centric daily driver for many engineers, while Codex now gives teams a stronger cloud and background agent lane through ChatGPT plans, Codex Cloud, IDE integration, and flexible business pricing. read

The Best AI Coding Stack for Most Engineering Teams Is Cursor Plus Codex

If I were advising a typical product or platform team today, I would not build the stack around one monolithic agent.

I would split it into two lanes:

A fast editor lane
A heavier delegation lane

That is why Cursor + Codex is the strongest overall answer right now.

Cursor remains strong because it combines the local editing experience teams want with team controls, cloud agents, and MCP-based extension paths. Cursor's current public team pricing is $40 per user per month, and its cloud agent documentation explicitly supports MCP for team-configured tools. read

Codex is strong because OpenAI has moved beyond a simple coding assistant model. The current product surface includes IDE support, Codex Cloud, background execution, reusable skills, and agent workflows, while ChatGPT Business now includes both standard seats and new Codex-only seat options under flexible pricing. OpenAI also updated Business pricing on April 2, 2026, lowering standard seat costs and changing the Codex billing model. read

That combination gives most teams the cleanest split:

Cursor for immediate editing, refactoring, and codebase navigation
Codex for deeper planning, background tasks, and parallel execution

For most companies, that is the best balance of developer happiness, stack flexibility, and commercial value.

Claude Code Wins When the Real Problem Is Not Editing but Orchestration

A lot of teams confuse coding speed with engineering maturity.

Those are not the same thing.

If your biggest issue is not "how do we write code faster?" but instead:

repo hardening
migration planning
standards enforcement
repeatable engineering workflows
tool orchestration across terminal, IDE, and desktop

then Claude Code becomes much more compelling.

Anthropicís public product and pricing surfaces show that Claude Pro includes Claude Code, while Claude's broader pricing stack now also includes Max and team plans. Anthropic also positions Claude Code as an agentic coding system that can read the codebase, make changes across files, run tests, and deliver committed code. read

That is why my recommendation for architecture-heavy teams is not Claude Code alone.

It is Claude Code + Cursor.

Cursor stays the fast interface. Claude Code becomes the structured engineering worker.

That pairing is especially strong for companies that need to build repeatable AI development operations, not just generate code faster.

GitHub Copilot Is Still the Safest Budget Decision for a 5 to 20 Person Team

If a company wants the safest low-friction rollout with a recognizable vendor, predictable pricing, and decent breadth, GitHub Copilot Business is still hard to beat.

GitHub's official pricing and billing docs show Copilot Business at $19 per user per month, with access to cloud agent capabilities, code review, and premium-request based model usage. GitHub also makes it easier to centralize licensing and policy across organizations. read

This is why Copilot remains such a strong BOFU option for budget-conscious teams:

low seat friction
easier enterprise buy-in
broad ecosystem familiarity
good enough capability across most common workflows

Would I rank it above Cursor or Codex for power users? No.

Would I recommend it as the safest first rollout for many companies that need broad adoption without a complicated operating model? Yes.

Amazon Q Is the Right Specialist Pick for AWS-Heavy Engineering Teams

There is a difference between a general winner and a context-specific winner.

If your stack is deeply AWS-native, Amazon Q Developer Pro deserves serious attention.

AWS documentation confirms a Free tier and a Pro subscription, with Q positioned for professional development workflows and higher usage limits. AWS also has explicit documentation for MCP-related usage and broader natural-language infrastructure workflows through its agent ecosystem. read

That matters because AWS-heavy teams often do not just want code generation.

They want help across:

infrastructure understanding
permissions-heavy environments
cloud resource reasoning
AWS-native operational context

So I would not rank Amazon Q as the best universal stack.

I would rank it as the best low-cost specialist for AWS-centric teams.

The Buying Mistake Most CTOs Make

The most common mistake is treating this like a beauty contest between tools.

That is not the real decision.

The real decision is which of these four operating models fits your team:

1. Editor-first operating model

Best fit: Cursor

Choose this if your team wants speed inside the IDE, low friction, and strong local productivity before you add more structured orchestration. Cursor's current surface emphasizes editor speed, team plans, and cloud agents rather than a pure autonomous cloud-worker identity. read

2. Agent-first operating model

Best fit: Codex

Choose this if your team already thinks in terms of delegated tasks, background work, isolated worktrees, and reusable instructions. OpenAI's current Codex app and cloud direction clearly push in this direction. read

3. Workflow-first engineering model

Best fit: Claude Code

Choose this if your real need is stronger instructions, repeatable standards, and deeper engineering orchestration across environments. Anthropic's Claude Code positioning supports that use case clearly. read

4. Procurement-safe standardization model

Best fit: GitHub Copilot Business

Choose this if your leadership team wants a simpler procurement path, lower seat cost, and a default tool that is broadly understandable across engineering managers, finance, and IT. read

My Weighted Decision Matrix

This is my current weighted scorecard based on five factors:

day-to-day coding UX and speed
agent depth and parallel execution
extensibility and instruction surface
team economics and pricing clarity
governance, admin, and deployment control

Weighted scorecard

Tool	Total / 10	Confidence
OpenAI Codex	8.8	High
Cursor	8.6	High
Claude Code	8.5	High
GitHub Copilot	8.3	High
Windsurf	8.1	Medium
Kiro	7.9	Medium
Amazon Q Developer	7.8	High
Tabnine	7.6	Medium
Qodo	7.5	Medium
Google Antigravity	7.2	Low
Devin	7.1	Medium
JetBrains Junie / AI	7.0	Medium
Perplexity Computer	6.2	Medium

This is an editorial decision framework, not a lab benchmark. I score confidence lower when official public pricing, packaging, or rollout surfaces are still moving. That is the main reason Google Antigravity stays lower-confidence today: Google still describes it as available in public preview, even while broadening the surrounding developer-tool story. read

What I Would Recommend by Team Type

Solo builder

Cursor + ChatGPT Plus/Codex

This is the cleanest value stack for a solo technical operator who wants fast iteration and the option to hand off heavier work. Cursor and OpenAI both currently position these products to support that exact split. read

5 to 20 person product team

Cursor Teams + ChatGPT Business/Codex

This is my default answer for most modern product teams because it gives you a strong local interface plus a stronger background-agent lane without jumping immediately into the highest-cost autonomous products. read

Architecture-heavy platform team

Cursor + Claude Code

Use this when standards, migration safety, and repeatable engineering practices matter more than maximizing raw tool throughput. read

Budget-sensitive team

GitHub Copilot Business

This is still the cleanest default when leadership wants a fast, defensible, low-friction purchasing decision. read

AWS-heavy team

Amazon Q Developer Pro

Context matters. If your engineers live inside AWS, this is the right specialist bet. read

Regulated or sovereignty-sensitive team

Tabnine, optionally with Qodo

Tabnine's public positioning remains unusually strong on private deployment, including cloud, on-prem, and air-gapped options. Qodo is compelling when the bottleneck is not generation, but review quality and governance at scale. read

The Strategic Takeaway for CTOs

The winning stack is rarely the tool with the loudest product launch.

It is the stack that fits your engineering operating model.

If your team needs speed, optimize for the editor.

If your team needs delegation, optimize for the agent lane.

If your team needs repeatability, optimize for instructions, hooks, and review gates.

If your team needs governance, optimize for admin controls, deployment model, and quality enforcement.

That is why the best buying decision in 2026 is not "Which AI coding tool should we buy?"

It is:

What combination of editor, agent, review layer, and policy controls lets us ship faster without losing trust in the code? This is a question of AI Governance & Risk Advisory as much as it is about technology.

That is the decision worth paying for.

Practical framework: how to choose in 30 days

Week 1: Map the real bottleneck

Decide whether your main problem is:

coding speed
planning and delegation
review quality
standards and governance
cloud context

Week 2: Run two-lane pilots

Test one editor-first path and one agent-first path.

Example:

Cursor for local execution
Codex or Claude Code for heavier delegated work

Week 3: Add verification

Measure:

PR cycle time
review burden
defect leakage
onboarding speed
reuse of project instructions

Week 4: Decide on the operating model

Choose the stack that improves engineering throughput without increasing AI-generated chaos.

This is also the point where many companies realize they do not actually have a tooling problem.

They have an AI development operations problem. This realization often leads to seeking external expertise in Workflow Automation Design or a comprehensive AI Readiness Assessment to align technology with business processes.

AI Code Review: From Vibe to Verification

Dr Hernani Costa — Tue, 28 Apr 2026 06:57:40 +0000

When AI generates code faster than teams can review it, the real engineering job begins—not in writing, but in building the system that decides what ships.

Stop Calling It Vibe Coding

TL;DR: AI software engineering is not 'vibe coding.' Learn why the real job is building robust systems to test, gate, and ship AI-generated code.

Real software engineering starts when the model stops typing and your system starts proving

Large language models can generate code faster than most teams can responsibly review it. This shift is the foundation of modern AI software engineering. The real job is no longer typing more lines; it's building the system that decides what gets accepted, what gets tested, what gets rejected, and what gets promoted to production.

The problem is not AI-generated code. The problem is lazy process.

The phrase "vibe coding" took off after Andrej Karpathy used it to describe a style of building where you mostly prompt, accept changes, and stop caring much about the code itself. Simon Willison later made the distinction sharper: if you review, test, and understand what the model produced, that is not vibe coding. That is just using a better tool.

That distinction matters.

Because a lot of people now use "vibe coding" as a lazy insult for any team using AI to write software faster.

That is wrong.

The issue is not whether AI wrote the code.

The issue is whether your organization has a repeatable process for turning machine-generated output into reliable software.

If the answer is no, then yes, you are gambling.

If the answer is yes, then you are engineering.

Writing code is no longer the scarce skill

Here is the uncomfortable truth most teams have not fully absorbed yet:

Code generation is becoming abundant.

Judgment is not.

A junior engineer with a strong model can now produce more raw code in a day than multiple senior engineers could carefully review line by line. That changes the economics of the job immediately. The old mental model assumed that writing was expensive and review was manageable. The new reality is the opposite. Generation is cheap. Verification is expensive.

So the winning teams do not respond by demanding more manual review.

They respond by redesigning the system.

They ask better questions:

What should be checked by AI before a human ever sees it?
What should be tested automatically at unit, integration, and end-to-end level?
What should be deployed into a preview environment before it is considered real?
What should require approval gates before it touches production?

That is where the leverage is now.

Real AI software engineering is not "read every line"

A lot of teams still act as if professionalism means every meaningful change must be personally read, line by line, by increasingly overloaded humans.

That is not a scalable philosophy anymore.

It is nostalgia disguised as rigor.

GitHub's own documentation now makes clear that AI can review pull requests and provide suggested changes, but those reviews do not count as required approvals for merging. That is a useful design choice. It tells you exactly where AI review belongs: inside the process, not above it. AI review is one layer. Not the whole system.

So no, I do not think the answer is "let the model write code and hope for the best."

I also do not think the answer is "humans must read everything forever."

The answer is to build a review and release architecture—a core component of modern AI Architecture—where trust comes from the system, not from heroic attention.

What the New Discipline of AI Software Engineering Looks Like

If you want to know whether a team is doing software engineering or just playing with AI, stop looking at how the code was written.

Look at the pipeline.

Professional teams build constellations of checks around change:

multiple AI reviews
repository-specific instructions
unit tests
integration tests
end-to-end tests
UI validation
preview environments
deployment protections
staged promotion to production

That is not theory anymore.

GitHub supports repository-level instructions and path-specific instructions for AI review. Playwright is built specifically for end-to-end testing with assertions, isolation, parallelization, and CI support. GitHub environments support approval requirements and deployment protection rules. Vercel preview environments let teams test changes live without affecting production and create a preview deployment automatically for pull requests and non-production branches.

That stack is the point.

The software engineer of the next phase is not mainly a typist.

The software engineer is a designer of guardrails, evaluations, feedback loops, and release systems.

The job is shifting from authorship to assurance

This is the part many people still resist emotionally.

They built their identity around writing code.

I get it.

For years, the visible output of engineering talent was the code itself. That is changing. The more capable the models get, the less valuable raw authorship becomes and the more valuable assurance becomes.

That means the best engineers will increasingly be the ones who can:

define the architecture clearly
express the constraints precisely
create strong tests
specify quality bars
design the review pipeline
create safe rollout paths
and know when the system is lying

That is a higher bar, not a lower one.

It is also why a lot of the "AI will replace engineers" conversation misses the point. AI is not removing the need for engineering discipline. It is making weak engineering discipline impossible to hide.

DORA had the right instinct before this wave even arrived

This shift also lines up with how strong engineering organizations have measured performance for years.

DORA's software delivery metrics focus on whether teams can deliver software safely, quickly, and efficiently. The framework splits performance into throughput and instability, looking at factors like lead time, deployment frequency, failed deployment recovery time, failure rate, and reliability. That is a useful lens here because none of those outcomes care whether a human or a model typed the code. They care whether the system ships dependable software.

That is the right frame for leaders.

Not "How much code did we write?"

Not "Did a human type this function?"

But "Can we repeatedly move good changes into production with speed and control?"

That is the scoreboard.

My take

Vibe coding has no place in production software engineering.

But that does not mean humans need to go back to manually writing everything.

It means professionals need to stop confusing authorship with accountability.

You can let the models generate enormous amounts of code.

You can let them propose fixes.

You can let them review PRs.

You can let them test interfaces.

You can let them accelerate everything.

What you cannot do is confuse speed with discipline.

The teams that win from here will not be the ones bragging that AI wrote the whole app.

They will be the ones who built the best machine for deciding what deserves to ship.

That is software engineering.

And yes, I believe those teams are going to produce better software than a shocking number of organizations still arguing about whether using AI is somehow less "real."

What leaders should do next

If you lead an engineering organization, this is the moment to redesign your workflow around one new reality:

code generation is no longer the constraint. verification is.

Start there.

Audit your current path from prompt to production. An AI Readiness Assessment can provide a structured approach to identifying these bottlenecks and designing your Workflow Automation Design for maximum safety and velocity.

Look at where your process still assumes humans can manually absorb every meaningful change. Then replace that assumption with a layered quality system:

AI review before human review
Use AI to catch obvious problems early, but do not pretend that AI review alone is approval. GitHub's own system treats it as advisory, not decisive.
More than unit tests
Unit coverage is not enough when AI-generated code can create UI drift, workflow regressions, and cross-system breakage. Playwright exists for exactly this kind of browser-level validation.
Preview every meaningful change
If a change matters, stand it up somewhere real before it touches production. Preview deployments and protected environments make this operational, not aspirational.
Promote, do not pray
Treat production as a promotion target, not a leap of faith. The highest-confidence change should be the one that gets promoted after surviving the system.

That is how you turn AI speed into engineering advantage.

DEV Community: Dr Hernani Costa

Managed Agents Over Copilots: The 12-Month Operating Model

From Copilots to Managed Agents: The 12-Month Roadmap for Lean Technical Teams

Months 1 to 3: Standardize the copilot baseline

1. Inventory the current AI surface area

2. Choose the primary working surface

3. Define what stays advisory versus executable

4. Pick two repeatable copilot workflows

Months 4 to 6: Introduce managed agent workflows

What changes here

Months 7 to 9: Build the shared context and control layer

1. What should agents be allowed to access?

2. Which context should stay local versus remote?

3. How should approval and review work across surfaces?

4. What deserves to become a team standard?

Months 10 to 12: Operationalize the managed-agent model

1. Formalize the operating model

2. Measure the right things

3. Decide the next shape of scale

My take

Practical Framework

Quarter 1

Quarter 2

Quarter 3

Quarter 4

Key Takeaways

Further Reading

AI Readiness vs. Consulting: Which Path Cuts Risk First

AI Readiness vs. AI Consulting

Start with readiness when the business is still operationally uncertain

Start with consulting when leadership needs strategic direction

The simplest way to choose

When both are needed

What leaders should receive from each path

Choose the Right Starting Point

Further Reading

AI Consulting Scope Creep: Why Amsterdam SMEs Fail Before Starting

AI Consulting in Amsterdam for European SMEs

What AI Consulting Should Help You Decide

What Amsterdam Buyers Should Look For

When AI Consulting Is the Right First Move

When You Should Not Buy Broad Consulting Yet

A Practical Next Step for SME Leaders

Further Reading

GitHub's Coding Agent: The Workflow Restructuring Signal

What GitHub's Coding Agent Changes for Product Teams

Why Leaders Should Pay Attention

What the Official Limitations Reveal

What Product Teams Should Do with That Signal

Why This Matters Beyond Engineering

Further Reading

From Signal to Strategy

Sources

AI Architecture Review: Control Before Scale

Why architecture review matters more now

1. Use-case boundaries

2. Control plane and working surface

3. Context layer and tool access

4. Execution and isolation model

5. Review, approval, and human override

6. Shared configuration and team standards

7. Evaluation, observability, and failure analysis

8. Governance, security, and enterprise readiness

9. Cost and deployment model

My take

Key takeaways

Further Reading

Practical framework / decision lens

Claude Code 2026: Terminal-First Control Over IDE Comfort

Claude Code in 2026: When Terminal-First Still Beats IDE-First

Terminal-first is really about control, not nostalgia

Where Claude Code still has the edge

1. Repo-close execution

2. Workflow composability

3. MCP-based tool access

4. Less abstraction between the engineer and the work

Why IDE-first still wins in some teams

So when does terminal-first still beat IDE-first?

1. Your best engineers already work from the command line

2. You want the agent close to the real environment