I installed my first Openclaw on an old Ubuntu machine. Setup was smooth. Then I dug up a Raspberry Pi and installed Zeroclaw on it. One week later, I was spending more time on SSH gymnastics than getting work done. Tasks like upgrading the agent, configuring a new LLM provider, configuring a channel, debugging logs, etc all started eating into my limited post-day-job-time I have to play around these systems.

Then it clicked - I’m dealing with a standardization and orchestration problem here. More importantly, this is very similar to a problem that k8s solved for managing containers in production environments. Running one AI agent is easy. Running five across your network while juggling SSH keys, model configs, personas, and channel integrations is when things get messy.

I built Clawrium - an aquarium for *claws, to solve this problem. A single CLI to manage a fleet of AI Agents.

https://xkcd.com/1319/

Clawrium

Clawrium is a CLI tool that provides fleet management for AI agents. . Lightweight SSH-based orchestration that lets you deploy, configure, and manage multiple agents across machines from a single control point.

Using Clawrium, you can

• Deploy multiple Agents on your local network (or cloud instances)

• Use a standard configuration, secrets and integrations system for all supported Agent types

• Swap models, rotate secrets, update personas

• Backup and restore agent memory, configuration, data and jobs

• Enforce cost, token, usage guardrails on agents

• Access logs, debug information and usage telemetry from a single endpoint

• Remediate configuration drifts automatically

• Clone agents using a central registry

• … and much more

Note that this is an aspirational list which I’m excited to work on with the community!

Why Now

AI assistants are moving beyond hobby projects and solving real problems. Engineering teams I’ve interviewed for Clawrium are struggling to manage more than a single agent. They’re spending precious engineering bandwidth in agent management.

Clawrium solves their problems by letting them not just scale the number of agents but also managing them with a simple interface.

Another org is running multiple Openclaw agents, one for each of their engineering teams. Since teams manage their own instances, its an operational nightmare. 90% configuration for these agents is exactly the same: linear integrations, slack channels, confluence etc. But each team stores and manages configs, secrets and backups differently.

Using Clawrium, they’re able to pull these agents under a single umbrella.

Clawrium treats your agents as a fleet. In a pets vs cattle comparison, the agents in Clawrium are still pets. They are just pets that are well trained, on a leash, play well with each other and make your life better.

Two Use Cases I’m Building

1. Managing This Project With Its Own Agent

I run an agent on my local network that serves as the Clawrium project assistant. Through Discord, I can add issues, get status updates, and capture notes without context-switching into GitHub. The agent knows the project context and handles the logistics. As needs emerge, I extend its capabilities. If you join the Discord channel, you’ll find this bot (called Maurice) hanging around to help you. Please be nice to it.

2. Team Assistants at Work

I’m creating dedicated agents for each team at my company to work as communication and knowledge management helpers. They answer common questions, update team knowledge bases, and reduce the logistics burden on team members. Each team gets an agent tuned to their domain, ownership components and expertise.

Architecture

Clawrium has four main components

• Transport layer: Built on Ansible, this layer does the heavy lifting of enforcing idempotency, transport data, manage hosts, and drift.

• Configuration layer: Normalized configuration layer (similar to helm charts) for all supported Agent types.

• Execution layer: Brains of the system. Merging data, creating idempotent workflows, templating, tests, domain models.

• UX layer: CLI and TUI only. Keeping this layer thin to allow extension and integrations

The following diagram shows a network diagram of Clawrium managing multiple agents on a local network of hosts.

Get Started

Clawrium works today on Ubuntu with OpenClaw agents. I’m expanding agent support and features based on my own requirements and requested use cases.

1. Clone the repo and deploy your first fleet

2. Join the Discord to share feedback, ask questions and connect with community

3. Open issues for feature requests or bugs

Clawrium is the control plane for a fleet of specialized agents working together.

GitHub: github.com/ric03uec/clawrium

Documentation: https://ric03uec.github.io/clawrium/

The demo shows 6 different models running in parallel to execute the exact same task. This setup is useful to compare models for creating task specific vertical agents. I recently compared a different set of models to create a specialized agent just for testing. This section of my previous post covers the comparison in detail.

Key Findings

After 8+ tasks across 6 models (3 local, 3 cloud):

• No single model won everything. Claude dominated code changes. GPT-4.1 won simpler tasks. Local models won when complexity was low.

• Token usage varied 52x between models on the same task with no correlation to quality. More tokens ≠ better output.

• All 3 local models (ollama) scored 0/10 on code modifications but 9-10/10 on simpler tasks. Privacy and cost benefits are real, but only for the right task types.

Workflow

This is the high level workflow this project follows for each task. OpenCode CLI or the browser provides the task which is processed in parallel. Once all LLMs complete this task, the judge decides the best output and merges it to the target application

Takeaways

Why experiments like this are important for any org planning to build agents.

1. Use the best LLM(or SLM) for the task. Subsidized pricing (yes, I’m talking about all those free Opus 4.6 tokens) makes it easier to use the largest model for checking time of the day but they will pull the plug on this

2. Cost. Smaller, specialized models are getting better with each release

3. Privacy. For enterprises or security sensitive orgs, using local models may be a better fit

4. For accuracy, model selection per task is a key decision to enforce the right guardrails and get high quality output

Full leaderboard and experiment setup in the video.If you’re experimenting with multi-model setups or building task-specific vertical agents, would love to compare notes. DM me.

1. Coding tool discussions (similar to language or editor discussions) tend to escalate fast. The context helps clarify that my suggestions here are a part of my journey and in no way a recommendation for anyone.

2. I’ve learned a lot from similar writeups by more experienced devs. If this can help someone get better at their work, I’d have done a small bit to give back to the community

I’ve written code for almost a decade and half and shipped products in various languages and frameworks. I’m a big believer of is famous quote by Abraham Lincoln

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.

With this guiding principle I’ve spent countless hours in making my dev setup “perfect”. For almost everyone else, this setup is complex, clunky or simply overkill but this works for me in ways I need it to. More specifically, it is a combination of following

1. Xubuntu 24.04 LTS

2. Wezterm (migrated to this from Terminator in 2025)

3. Tmux with session management (15+ permanent sessions and then some ephemeral ones)

   1. Tmux restore session (to auto restore sessions on reboot)

4. Guake to just drop a terminal for a quick command or two when i dont want to Alt+Tab

5. (Neo)Vim for all and every change that needs text input

   1. Mix of usual plugins (Tree, Telescope, Tab, etc) with a few unusual ones

   2. Give me a shout out if you’ve made Avante.nvim work with AWS Bedrock

6. As of 2025, Claude Code

   1. For work Claude Code is setup with AWS Bedrock

   2. For personal projects I use Claude Code Max subscription, gemini-cli, Codex, and Openrouter (for all other models),

As you might’ve guessed by now, I live in the terminal and always have. It was after I got my hands on Claude Code I realized the main reason my AI usage for dev tasks was pretty low: I couldn’t get myself to use the IDEs which is how most coding agents launched (Yes, I know VSCode has VIM keybindings but lets not go there).

With this out of the way, lets move on to the more interesting part of the post.

Claude Code days

Claude Code was addictive from day 1. Especially for engineers who spend a lot of time CLI, this came as a superpower. You had an assistant who just “gets” you. Gone are the days of remembering commands flags, mistyping commands (who remember sl ?) or going spending hours in RTFM.

Over time, I expanded my flow to include non-coding tasks as well. The tmux session list I talked about earlier, started growing with multiple sessions running Claude Code for specific tasks. This included

• Daily executive summaries (hook up Atlassian MCP and gh cli)

• Sprint analysis, management and planning

  • Finding blockers in sprint, over allocation, under allocation, work distribution etc etc

  • Responding to comments

• Architecture reviews (Pull architecture docs from Confluence, code from GH, requirements from JIRA, go to work)

• Researching topics, understanding API contracts, CLI’s and SDKs

• Building personal dashboards for anything and everything

• Creating agents, plugins, marketplaces to distribute common patterns with my team

• Creating more agents to help me do more stuff that I don’t want to

• And yes, coding

I probably forgot a few things here but you get the drift. Every tech meetup or event I went to, I learnt of more interesting stuff others were doing and tried to add some of it in my workflow.

This worked until Claude Code’s goals were aligned with mine: Get more done in the best way possible.

Turns out, other providers offered solutions but Claude Code wasn’t helping me try out those solutions.

Claude Code - The Dark Side

I guess I got carried away with the title there. Anyway, the reality is that Claude Code(and the likes) is a for profit product and will try to always lock the user to its ecosystem. All those (nearly) free tokens for a pricey model like Opus 4.5 don’t come without any strings attached. Every engineer I met in last 6 months agrees that Anthropic models are best at writing code but a non-trivial number of those engineers are also using other models for non-coding tasks. Codex and Gemini are the other two alternatives being used for planning or reviewing a plan or ideation or code generated by Sonnet/Opus.

Claude Code (and Codex, Gemini-CLI and Cursor) make it harder to leave by either simply being better than competition or by providing addon features. Claude Code has especially done a great job at this by first introducing MCPs about a year and half ago, then adding subagents, Skills, Marketplace and higher usage limits. I used all these features heavily to add layers on my workflows and by stringing multiple workflows together. I get more work done, Claude gets more token usage. Both win.

My mental model for AI agent usage is to explore both the application layer(usability features) and the foundational layer(LLM specific capabilities).

As much as Claude Code was doing a good job at the application layer, I didn’t get any control over the foundational layer. Simple example: I created a test-enforcer subagent in Claude Code with a lot of context and examples. But I couldn’t tweak the LLM parameters like Temperature, Top p or other values for this agent. I want this test enforcer agent to not have any creativity (which is opposite of what I want from a researcher agent). If these values are configurable at the LLM layer (Claude Agent SDK allows you to change it), then why should this not be available for Claude Code users to configure?

As my coding and non-coding workflow moved from treating the agent as a single assistant to multiple assistants with specific personas, I started getting frustrated with the inability to customize my agents beyond context engineering. Just this functionality can help users build very tight, reusable agents using the same foundation model.

Another pain point was the inability to switch models to find the best model for the agent. I kept hearing about new model launches which performed better(or at least claimed to) than other in certain aspects. Be it reasoning, tool execution, tool selection or other criteria in SWE Bench.

The goal was(is) to find the best model(brain) for the agent(persona).

For this, I needed to experiment fast. Yes, I can create a custom tool with all the Agent SDK’s and run eval to figure this out, which I did. But I need to know how it performs on my live setup, not some eval. This will become more clear when I explain later what I’m doing now.

Enter OpenCode

I tracked OpenCode development since its first launch. In the spirit of making my system perfect, I evaluate every tool before settling down on one. I rejected OpenCode a few months ago for multiple reasons which they’ve fixed since.

It was one of my teammates who made the switch from Claude Code to OpenCode that made me go back to it. After a few hours of playing around with it, I was ready for the switch. Over last week, I migrated all my agents, skills, configurations and MCPs to OpenCode and it’s working great.

I’ll first talk about what I’m loving so far and then dive into a concrete example.

Agent configuration

Right off the bat, my agent configurations are now fine tuned to what the agent is expected to do. Here’s an example of DevOps expert agent.

---
description: Expert guidance on DevOps practices, infrastructure as code, CI/CD pipelines, and microservices deployment.
mode: all
tools:
  read: true
  write: true
  edit: true
  bash: true
permission:
  edit: allow
  bash: allow
temperature: 0.1
top_p: 0.9
[more LLM specific configurations as needed]
---

[Agent instructions follow...]

The mode: all setting means this agent can be invoked both as a primary agent and as a subagent (automatically called by other agents). In Claude Code, you choose one or the other. Not both.

This limitation forced me to duplicate my architect agent. I needed one version configured as a slash command for direct design reviews, and another configured as a subagent so it would be automatically invoked during code reviews. Maintaining two copies of the same agent with identical instructions was brittle and error-prone.

When I’d run “review these changes with all agents,” my architect agent wouldn’t participate because it was configured as a slash command, not a subagent. The choice was binary: direct invocation OR automatic invocation. OpenCode’s mode: all solves this cleanly

Model Flexibility

My workflow relies on three core agents, each optimized with a different model:

Architect Agent uses Opus 4.5. Its job is to find inconsistencies, suggest better architectural patterns, and evaluate trade-offs. This requires high reasoning capability and creativity.

Test Agent uses Sonnet 4. Its job is zero creativity: follow existing test patterns and increase coverage. For this I need a model that is cost-effective and fast for repetitive, structured work like generating tests that mirror existing examples.

API-Spec Updater Agent uses Sonnet 4. Its job is to enforce that API specs stay current with code changes and flag any unapproved modifications. Again, zero creativity needed, just pattern enforcement.

Using the right model for each agent isn’t about preference. It’s about reliability. When the test agent has access to creative reasoning, it sometimes introduces novel test patterns that don’t match the existing codebase style. When the architect agent is constrained by a pattern-following model, it misses architectural nuances. Model choice directly affects agent trustworthiness.

Claude Code locks you to Claude models. There’s no way to use GLM, z-ai, Qwen, MiniMax, or any other specialized model provider’s model per agent. You can swap models globally, but that defeats the purpose of specialized agents. Yes, I’ve used zen MCP for this but I found the integration to be slow and unpredictable.

Case Study: Test Enforcer Agent

To take my new setup for a spin, I set out to build the best Test Enforcer agent for my requirements. Here are the steps

1. Clearly define the test enforcer agent persona, objectives, response format and specialization in agent definition.

   1. also add LLM parameters. temperature=0.1, top_p=0.9

2. Make some changes in a branch using my regular dev process

   1. This is a mix of Sonnet and Opus

3. Spin up 5 OpenCode instances(tmux) on this branch

   1. Switch to “Test Enforcer Agent” for each instance

   2. This means all 5 instances use exactly the same agent configuration

   3. These 5 instances are using: Sonnet 4.5, Gemini 3.0 Pro, DeepSeek v3.2, GLM-4.7, GPT-4o Codex

4. Give all 5 instances the exact same prompt

   1. “Review test cases for this branch”

5. Brew my coffee

Here are the results

The results reveal why model selection per agent is critical. Here’s a truncated feedback from all the providers:

Claude Sonnet 4.5 provided the most detailed analysis with excellent layer-by-layer breakdown:

Coverage Analysis (Detailed)
- Overall Coverage: 88.5% ✅ Exceeds 80% threshold
  
Breakdown by Layer:
- Handler Layer: 86.9% - Excellent
  - admin_oem_handler.go: CreateOEM (85.7%), ListOEMs (77.8%), 
    GetOEM (100%), DeleteOEM (100%)
  - oem_handler.go: Login (85.7%), GetOwnProfile (100%), 
    UpdateOwnProfile (77.8%)
  - Gap: getOEMIDFromContext (71.4%) - missing some error path tests
  
- Service Layer: 74.4% - Good (closest to threshold)
  - Strong: ListOEMs (100%), comparePassword (100%), mapToDTO (100%)
  - Needs Attention: GetOwnProfile (37.5%), DeleteOEM (66.7%), 
    UpdateOwnProfile (69.2%), Login (73.9%)
  - Critical Gap: GetOwnProfile only 37.5% covered

Gemini 3.0 Pro was cost-effective but provided basic analysis:

Review Summary
Rating: 3/5 ⭐⭐⭐
Overall coverage is 88.6% (✅ Meets 80% target), but the Service Layer 
is lagging at 74.4%.

| Layer | Coverage | Status |
| :--- | :--- | :--- |
| Validator | 100.0% | ✅ Excellent |
| Repository | 93.2% | ✅ Excellent |
| Handler | 86.9% | ✅ Good |
| Service | 74.4% | ⚠️ Below Threshold |

Critical Gaps (Must Fix)
1. Service Layer: Missing error handling for hashPassword failure
2. Service Layer: Missing error handling for database failures
3. Service Layer: Missing error handling for token generation failure

DeepSeek v3.2 balanced cost and thoroughness:

Rating: 4/5 ⭐
Summary
Excellent test coverage with comprehensive scenarios for the new 
management feature. Tests follow repository patterns, have good mocking, 
and cover most error conditions. Minor improvements needed in API 
response code validation and edge case coverage.

Test Pattern Analysis
- Follows repo conventions: ✅ Yes
- Table-driven tests: ✅ Present
- Mock usage: ✅ Appropriate (gomock for service/repository interfaces)
- Test isolation: ✅ Isolated
- HTTP testing: ✅ Present (httptest with Fiber framework)

GLM-4.7 delivered strong analysis at competitive pricing:

Rating: 4/5 ⭐
Summary
Good test coverage with solid fundamentals. The management feature 
has comprehensive tests across all layers (handler, service, repository, 
validator) with 100% validator coverage and strong repository coverage 
(93.2%). Most happy paths and error scenarios are covered. However, 
authentication middleware tests, concurrency safety, and some edge 
cases are missing.

Coverage Analysis
- Current: 86.9% (handler), 93.2% (repository), 74.4% (service), 
  100.0% (validator)
- Target: 80.0%
- Status: ✅ Meets threshold

Test Pattern Analysis
- Follows repo conventions: ✅ Yes
- Table-driven tests (Go): ✅ Present (in validator tests)
- Mock usage: ✅ Appropriate (gomock with proper controller management)
- Test isolation: ✅ Isolated (proper setup/teardown with defer ctrl.Finish())

GPT-4o Codex was free(almost) but delivered subpar analysis:

Rating: 2/5 ⭐
Summary
Core OEM handlers, repository, and validator tests are well-structured 
and follow repo conventions, but service-level error paths are 
under-tested and the overall module coverage is far below the 80% target.

Coverage Analysis
- Current: 58.6%
- Target: 80.0%
- Status: ⚠️ Below threshold (-21.4%)

Test Pattern Analysis
- Follows repo conventions: ✅ Yes
- Table-driven tests (Go): ✅ Present (validator coverage)
- Mock usage: ✅ Appropriate (gomock + sqlmock)
- Test isolation: ✅ Isolated

The model comparison reveals distinct value propositions. GLM-4.7 emerges as the optimal choice for this test enforcement agent: 88% cheaper than Sonnet with identical 4/5 quality rating, more efficient token usage (42% vs 58%), and accurate coverage analysis with specific improvement recommendations like authentication middleware testing and concurrency safety.

DeepSeek v3.2 remains competitive at $0.42, but GLM-4.7’s superior cost efficiency ($0.23) and comparable analysis depth make it the clear winner for repetitive test review workflows. Sonnet’s premium pricing becomes harder to justify when specialized models deliver equivalent results at a fraction of the cost.

GPT-4o Codex, despite being free, significantly underperformed with incorrect coverage calculations (58.6% vs the actual 88.5%) and a lower quality rating. This demonstrates that cost isn’t the only consideration—accuracy and reliability matter more for automated workflows where incorrect analysis could mislead development decisions.

This is why OpenCode’s per-agent model selection matters. I can optimize each agent for its specific task characteristics, cost requirements, and quality thresholds.

OpenCode’s Approach

OpenCode is provider-agnostic. I configure access to both AWS Bedrock (for Claude models) and OpenRouter (for GLM-4, MiniMax, DeepSeek, and others) in a single interface. Each agent specifies which model it uses in its configuration.

The agent configuration is straightforward markdown frontmatter:

• mode: all/primary/subagent controls invocation patterns

• tools: {} grants granular access to specific capabilities

• permission: {} sets fine-grained edit and bash permissions

Beyond agent flexibility, OpenCode fixed several workflow issues that were impacting my productivity with Claude Code:

Flicker problem resolved. Claude Code’s UI would flicker when editing large files (specs, long documentation). This happened frequently as my workflow shifted toward spec-first development. OpenCode doesn’t have this issue.

Better scrolling behavior. In Claude Code, I had to use tmux shortcuts to scroll through long responses. But that meant that the input box would disappear when scrolling up. OpenCode lets me use simple page-up/page-down while keeping the input visible, making it easier to provide feedback on lengthy code reviews.

Image paste support. Claude Code on Wayland had persistent issues with image pasting(X11 works fine). OpenCode handles this correctly out of the box.

LSP support out of the box. Language Server Protocol integration works automatically for Go, JavaScript, and Python files. This means better autocompletion and inline errors during agent-assisted coding.

Session sharing. I can generate a shareable link to any conversation and send it to teammates. This is useful for debugging agent configurations or showing examples of effective prompts.

Editor mode. Instead of typing prompts in a command box, I can use vim to craft detailed multi-paragraph instructions with proper formatting. This significantly improves how I communicate complex requirements to agents. Especially when writing initial plans for complex tasks, this provides a distraction free way to just dump all thoughts on a blank slate (sadly, this is one of the few ways I still get to use vim)

Trade-offs

This doesn’t come for free so please venture into this territory if you’re sure.

Learning curve. OpenCode has more keyboard shortcuts to remember. It’s similar to moving from an IDE to vim. There’s an adjustment period to become productive. I’m still learning the keybinds.

Missing visual features. Claude Code’s “ultrathink” visual indicator shows when the model is reasoning deeply. The status bar provides useful context about what the agent is doing. The marketplace makes discovering new integrations easy. OpenCode lacks these polish elements.

Manual mode switching. OpenCode has separate plan and execute modes that I switch between manually using the Tab key. Claude Code handles this transition seamlessly when it automatically moves from planning to execution without user intervention. This adds friction to my workflow.

MCP configuration complexity. Model Context Protocol servers require more manual setup in OpenCode compared to Claude Code’s streamlined approach. I have more control, but it takes more effort to configure initially.

These aren’t dealbreakers for my workflow, but they’re real costs. If you value visual polish and seamless UX over configurability, Claude Code may be the better choice.

When This Matters

Not everyone needs multi-agent workflows with per-agent model selection. If you’re using a single AI assistant for coding tasks, Claude Code’s simplicity and polish are advantages.

The signal that you need OpenCode’s flexibility: you’re building more than 2-3 specialized agents and hitting limits on how you can configure them. Specifically:

• You need agents to be both directly callable and auto-invoked by other agents

• You need different agents using different models based on task characteristics (like using DeepSeek for test reviews and Sonnet for architecture decisions)

• You’re iterating on agent behavior and need fast configuration changes

• You need to use specialized models (GLM-4.7 for cost-efficient pattern-following, DeepSeek v3.2 for balanced performance) alongside general-purpose models

For me, model flexibility and agent invocation control outweigh visual polish. My agents deliver more reliable results and are trustworthy when I can match the right model to each task. GLM-4.7 handles test enforcement at $0.23 with the same quality as Sonnet’s $1.96, while my architect agent still benefits from Sonnet’s deep reasoning capabilities. OpenCode makes this optimization possible. Once I’ve selected the model, I will customize it further using its model specific settings (for GLM-4.7, https://huggingface.co/zai-org/GLM-4.7 ).

Key Takeaways

Agent specialization requires model flexibility. Different tasks need different LLM characteristics. Pattern-following work (tests, spec enforcement) benefits from models optimized for batch operations. Architecture decisions benefit from models optimized for reasoning. One-size-fits-all model selection limits agent effectiveness. My test enforcer comparison showed DeepSeek v3.2 delivering 79% cost savings over Sonnet with comparable quality for structured tasks.

Cost optimization through model selection. Per-agent model choice isn’t just about capabilities, it’s about cost efficiency and accuracy. The test enforcer comparison revealed GLM-4.7 as the optimal choice: 88% cheaper than Sonnet with identical 4/5 quality rating and more efficient token usage. Running every agent on premium models wastes budget on tasks that specialized models can handle better and cheaper, while free models like GPT-4o Codex can produce unreliable results that mislead development decisions.

Invocation patterns matter. Agents should be callable both directly (slash commands) and by other agents (subagents) without duplication. The mode: all configuration in OpenCode solves this cleanly.

Tool lock-in has real costs. Provider coupling limits your ability to optimize agent effectiveness. As new specialized models are released (like GLM-4 for coding tasks), being provider-agnostic lets you adopt them immediately. With agentic coding now being the de-facto way to write code, engineers are working on higher complexity tasks on their machines. They need access to the best tools to get reliable outcomes.

Visual polish vs. configurability is a real trade-off. Claude Code’s seamless UX and visual indicators are valuable. OpenCode’s flexibility comes with more manual configuration. Choose based on whether you prioritize ease of use or control.

If you’re hitting agent customization limits or need model flexibility per agent, evaluate OpenCode. I’d love to hear how others are architecting their agent teams. Reach out at hello@devashish.me if you’re navigating similar challenges.

For the record, I didn’t attend AIE CODE 2025(NYC) in person. I did go through every-single-presentation in the two YouTube videos for the leadership track and the tech track. Even with speedup, this was a lot of high quality content to consume. As much as I wanted AI to read the transcripts and summarize key points, I found that the nuance was lost in translation. So I took notes manually and synthesized the key themes for this post using Sonnet 4.5 on Claude Code.

Few disclaimers before we start:

• This is not a summary of every talk. Just the topics I found most interesting.

• The opinionated takeaways are mine, not the speakers’.

With that, let’s dive in.

Between the leadership and engineering tracks, I found the leadership discussions more outcome driven and actionable. It’s clear that leaders are under pressure to justify the ROI of massive AI investments they’ve made in the last 12 months. As much as I’d love to get my hands on the cool tech coming out of big labs and startups alike, the AI adoption challenge is primarily organizational, not the technology. Many leaders are using the same (and sometimes “lagging”) technology to drive more innovation, just by changing how they work.

Three leadership takeaways emerged from the conference. Each reveals how organizations must transform to unlock AI’s compounding gains.

Process Rewiring

McKinsey’s data confirmed that most organizations are stuck in pilots. Yet spending continues to grow. Their research shows a 10x productivity difference between companies where 90% of engineers use AI versus those where 100% use AI - the last 10% adoption drives outsized returns.

Just making AI available isn’t enough. The organizations that are succeeding are rewiring their PDLC, team structures, and review processes. This is a human change, and it needs to start now. In my earlier post I highlighted this point as well.

Code review must transform. Every engineer is now a reviewer. Most engineering teams already have this expectation but in reality, only a handful of engineers end up owning the majority of code reviews. This needs to change. Teams also need to speed up review cycles with SLOs. Make it clear whose turn it is to take action - agent, engineer, or reviewer. Distribute the load across the team. Focus reviews on outcomes like SLO impact and dependencies, not code style. When agents iterate with humans fast, velocity compounds.

Metrics reveal what matters. Track velocity as your primary metric - features shipped per sprint. Use quality as your guardrail metric - production incidents, bugs reported in development, rollback rate. The goal is to improve velocity while maintaining quality. Track review and refactor rate; this should decrease as agents improve. Important point here is to start with one leading metric (velocity) and one guardrail (quality). Avoid drowning in metrics.

Process rewiring accelerates onboarding. Every.io demonstrated this at scale: new hires there are shipping code to production within a few weeks. This enables them to hire quickly and even explore contractors for short term engagement. When tacit knowledge is codified into context (CLAUDE.md, documentation, patterns), engineers don’t need months to ramp up. They inherit the team’s collective intelligence immediately.

Psychological safety predicts success. Google’s Project Aristotle found that psychological safety is the biggest indicator of high-performing teams. Frame AI adoption as performance amplification, not replacement. Engineers need to trust that AI adoption improves their work, doesn’t threaten it, and the company culture must reflect that.

The Clean Environment Multiplier

Stanford’s study revealed the core insight: clean engineering environments unlock AI productivity. Test coverage, type safety, modularity, documentation, templates, clean Agents.md - these determine whether agents drive 20% or 80% of your sprint.

Poor environments create compounding friction. Agents struggle without clear validation. Engineers spend 40% of their time context-switching to provide missing information. PRs pile up because no one trusts AI-generated code. Writing more code doesn’t equate to more features. Engineers just start spending time fixing AI mistakes and reviewing massive volume of low-quality output.

Clean environments compound gains. Agents complete tasks autonomously. Engineers focus on creative problem-solving. Review cycles accelerate because outcomes are measurable. Google Antigravity demonstrated their approach to making Agents collaborate effectively by providing them with clear validation, checkpoints, multi modal inputs and feedback loops. All built into the editor. I’m still a Claude Code fan but it’s an approach worth giving a shot.

The multiplier isn’t the AI. It’s the environment you give it to work in.

Capital One’s Max Kanat-Alexander asked the defining question: what will be valuable no matter what happens? Use industry standard tools, frameworks, and languages that models are trained on. Build with clear validation that fails deterministically. Write down the context and intentions. What’s good for humans is good for AI.

Invest in engineering hygiene now. Increase test coverage to 80%+ for critical paths - tests form the backbone of deterministic validation. Refactor for modularity with single responsibility per component. Enforce interfaces through API specs, Agents.md, and documentation. Implement strict type safety across services. Standardize your dev environment. These fundamentals don’t change with GPT-5 or Claude Opus 5.

Context Infrastructure

Stating the obvious here: Poor context = poor AI output. QODO stated it plainly - when engineers don’t trust AI code, they don’t trust the context, not the model. Teams must build frameworks to evaluate and assess quality to build confidence on AI generated code.

Every.io proved that context infrastructure investments pay off to build scale: 99% of their code is AI-written, single-engineer owned apps, parallel feature development. Their secret? Compounding engineering through CLAUDE.md and context improvements, converting tacit knowledge into prompts that improve with each feature. Engineers working on multiple features in parallel use multiple agent panes but are still productive. Code is cheap now, so you can prototype multiple ideas simultaneously. An important learning for me was the quote: AI has caused us to invent entirely new set of engineering primitives and processes.

Context infrastructure compounds while model capabilities commoditize. The harness - everything touching the LLM - is the new abstraction layer. Custom tools need model training. Prompts aren’t portable across models. Platform teams must translate user intent into model-specific instructions. These investments compound because they work regardless of which model wins.

Bloomberg’s rollout to 9,000 engineers revealed the work preference hierarchy: new features > architecture > code review > bug fixes > support. AI should amplify this preference, not fight it. Let agents handle uplift work while engineers solve creative problems. In my experience as well, engineers who hated writing tests are the ones writing bad tests with AI. The solution is give them better context and frameworks to write good tests, not have agents write tests for them.

HumanLayer’s research found that up to 40% context window usage keeps agents in the “smart zone.” Beyond that, they enter the “dumb zone.” This changes how we architect workflows. Use subagents for research and context management - they return succinct messages to the main agent. Research equals compression of truth. Planning equals compression of intent. My personal experience aligns with this pattern. I hit /clear once I’m at 10% context window remaining, forcing me to break tasks into smaller chunks that can be completed within the context window.

Research → Plan → Implement. All happen in the smart zone.

Stop building agents, start building skills. Anthropic emphasized this shift at the conference. Skills are a way to use context better, encapsulate learnings, and democratize knowledge across your team. Instead of building generic agents, create expertise through skills that progressively disclose capabilities. Skills become your institutional knowledge - they help onboard new engineers, compound your team’s productivity, and ensure consistent quality. Non-developers can build high-value skills when context is properly structured.

Build the context infrastructure. Implement the CLAUDE.md pattern for team knowledge compounding - update it frequently as your team learns. Build MCP servers for service dependencies and architecture docs. Create deterministic validation that fails consistently. Invest in tools that bring context to agents, not agents that need constant human input.

Arize achieved 5-15% improvements in bug fixes on a standard OSS repo just by changing system prompts. Using evals to improve prompts and context creates a feedback loop that improves agent performance over time. Build these feedback loops for your system prompts.

The Underlying Bet

2026 is about execution, not experimentation. Organizations that treat AI as infrastructure will compound their gains while others restart projects.

The bet isn’t on which model wins. It’s on the fundamentals that work regardless of model like standard tools LLMs were trained on, clear validation that fails deterministically, written context that agents can reference and fast iteration between agents and engineers.

Invest in the fundamentals now. They’re the multiplier for everything else.

The conference data was stark: companies with clean engineering environments see 5-10x more AI productivity gains than those without. Token spend is a weak predictor of AI adoption. Engineering quality is the strong one. Good design fights bad AI output.

What This Means For You

If you’re planning 2026 investments, the priority order is clear:

1. Process Rewiring - Transform code reviews, define metrics (velocity + quality), build psychological safety

2. Clean Environment Multiplier - Fix engineering hygiene (test coverage, type safety, modularity, deterministic validation)

3. Context Infrastructure - Build MCP servers, implement CLAUDE.md, create feedback loops for system prompts

The organizations that compound these investments will see 5-10x gains. The ones that skip fundamentals and jump to AI tools will restart in Q3.

Working through AI adoption challenges in your engineering organization? I’m happy to brainstorm strategies or share what’s worked in practice. The fundamentals matter more than the models - let’s compare notes.

I’ve attended AWS re:Invent for a few years now and its become my to-go event of the year to get a snapshot of the tech landscape. It has a mix of everything, from early stage startups working on cutting edge technologies, to incumbent enterprises trying to prove they’re still relevant. Obviously, AWS makes sure that their products, partners and messaging take the front stage but that’s not where the interesting parts of the conference are.

Disclaimer: I’m interested in exploring the infrastructure, observability, developer experience and AI tooling space, so this article is just based on these topics. It’s, in no way, a generic coverage of the event. Also, I’m not paid by any companies I mention in this post.

My pre-conference strategy is to do a few things

1. Shortlist companies that are relevant to my interests

   1. Mark the days I’ll spend at the Expo hall and schedule booth visits

2. Prepare a list of questions to ask their reps

   1. This includes pricing, tech deep dives, integrations, limits etc. Anything that might impact the vendor selection decision later on

   2. This saves significant time later in case we do decide to explore any new tools in a certain category

3. Secure ISV event invites via AWS Account Managers

   1. These events provide an amazing opportunity to learn what’s happening on the ground in other companies. e.g. one of the events I attended this time was: AI Pricing Strategies.

4. Shortlist vendor sponsored events/dinners I want to attend. Once you’ve completed the registration, many vendors start reaching out with dinner invites, poker events, lunch, brunch, breakfast, golf, concerts to schmooze you.

   1. These are a hit or a miss based on who else attends. The vendor execs will be there to understand your use cases and follow up later(or sooner, based on your title and company size)

TL;DR

Shift-left dominated AWS re:Invent 2025. Not the DevOps shift-left we’ve been doing for a decade though. The pattern showed up everywhere: AI agents validating code during development, observability designed into systems before deployment, incident management done by agents, cost optimization baked into CI/CD pipelines. Three domains converging around the same idea: move decisions earlier in the development lifecycle.

AI Architecture Goes Multi-Agent

The evolution from RAG to multi-agent systems is real. AWS made a big push with Kiro code which promises to solve problems early in development cycle. AI agents validate work during development, not just execute tasks. Companies like EdgeDelta introduced a slack-like chat interface directly in their product where the “users” are configurable agents that work together to achieve the task provided by the user.

This changes architecture decisions. Engineering leaders need to plan for multi-agent systems, not monolithic AI. The question isn’t “should we use AI?” It’s “where can agents validate our work?” Code review, testing, deployment checks, these are the natural starting points.

For Platform Engineers: Evaluate agent orchestration frameworks now. The infrastructure for multi-agent coordination is becoming a first-class platform requirement.

For Product Engineers: Identify repeatable validation tasks that agents can handle. Start with low-risk, high-volume work.

AI SRE steals the show

After years of “AI native everything,” many companies realized they have data to solve recurring SRE problems.

Resolve.ai handles all alerts, performs root cause analysis, and troubleshoots incidents within minutes. EdgeDelta provides 100% data visibility with AI-powered observability automation. But, these platforms work when your data architecture allows it.

Traversal provides a nice chat interface to find, debug and manage issues and incidents. Same with Incident.io which help you triage alerts using AI, reducing SRE time spend on this.

PagerDuty’s AI Triage Agent and Grafana’s SLO-first approach signal a fundamental shift: observability is moving left to design time. Define SLOs during sprint planning, not after production incidents.

But here’s the hard part: buying incident response agents while keeping siloed logging, metrics, and traces is pointless. Agents can’t do root cause analysis if they can’t correlate data across systems. The organizational change matters more than the tool selection.

Companies must give agents autonomy in low-risk areas. Build incremental confidence. Start with incidents that don’t require human judgment: service restarts, cache clearing, scaling operations. Let agents handle these autonomously while humans monitor. Gradually expand the autonomy zones as confidence builds.

The critical requirement is to make your data agent-consumable. Break down silos in incident management. Create clear access controls so agents can access logs, metrics, traces, and infrastructure state across systems. Without this, agents remain glorified alert routers. These systems invariably ask access to all the existing tools that an SRE does (which seems natural), so be prepared to ask pointed questions about permissions and data compliance before signing the check.

For Engineering Leaders: Identify low-risk incident types where agents can respond autonomously. Audit your data architecture for agent consumption. Can an agent access and correlate data across your observability stack?

For Platform Engineers: Build agent-accessible APIs for logs, metrics, and traces. This isn’t just about human-readable dashboards anymore. Can you use existing tools like Claude Code or custom agents to solve some of these problems? Experiment before you buy.

For Product Engineers: Define SLOs during design phase. Make observability requirements explicit before writing code. This helps the Platform team think about what’s important from a business perspective.

Cost Optimization Shifts Into Development

Resource optimization dominated FinOps messaging this year. Last year, most FinOps companies focused on passive financial planning mechanisms (savings plans, RIs) to save costs. This year, they’re building real-time mechanisms.

CloudZero’s real-time cost anomaly detection and nOps’ Kubernetes cost management treat cost as a first-class metric alongside performance. The pattern: developers see cost impact during PR review, not quarterly reports.

ScaleOps does resource optimization for K8S clusters using binpacking and resource reallocation dynamically.

This requires FinOps to shift left. Integrate cost feedback into development workflows. Make cost visible in CI/CD pipelines. When engineers see “$0.23 per deployment” in their pull request, they make different architectural decisions.

For Platform Engineers: Add cost visibility to CI/CD pipelines. Make cost data accessible during development, not just in monthly reviews. Products like Firefly.ai provide mechanisms for this, but you can build this in-house. At least the first few versions. Claude Code can provide cost impact for PRs with Terraform files based on publicly available pricing data—good enough for a baseline.

For Product Engineers: Include cost considerations in architectural decisions from day one. “This endpoint costs $X at Y scale” should be visible during design review.

Changes needed

It’s not about buying tools. Organizations and teams need to think holistically about both the problems and processes. Teams that are being successful are actively iterating on their processes to streamline communication paths, creating new patterns and weaving AI in their day to day workflows.

Traditional organizations keep approval-heavy deployment processes while buying AI agents. This means agents can’t deploy autonomously if deployments require three approval gates. They keep siloed data while buying incident response agents. Agents can’t correlate if data lives in disconnected systems. They keep quarterly cost reviews while buying optimization tools. Developers need feedback loops during development, not retrospectives.

Tools must augment new organizational structures and processes, not just automate old ones. Define low-risk autonomy zones for agents. Build incremental confidence with measurable boundaries. Make organizational data accessible to agents with proper access controls.

The companies that win will change their processes alongside their tooling. The ones that lose will buy the same tools but keep the same processes.

Action Items by Persona

Engineering Leaders:

• Map out low-risk areas for agent autonomy (service restarts, scaling operations, cache clearing)

• Audit data architecture for agent-consumability across observability, deployment, and cost systems

• Start one shift-left pilot in Q1 2026 (pick one domain: AI validation, observability-first design, or cost feedback)

Platform Engineers:

• Evaluate agent orchestration frameworks for multi-agent coordination

• Build agent-accessible APIs for logs, metrics, traces, and infrastructure state

• Add cost visibility to CI/CD pipelines (cost per deployment, cost per feature flag, cost per service)

Product Engineers:

• Define SLOs during sprint planning, before writing code

• Include cost considerations in architectural decisions (document “$X at Y scale” in design reviews)

• Identify validation tasks suitable for AI agents (code review checks, test generation, deployment validation)

Miscellaneous

• AWS announcements lacked any surprises. Bunch of new features in Bedrock. Push to use Kiro. Customer testimonials. The usual. Bedrock is now becoming more usable as a real AI platform which is good if you’re limited to using AWS ecosystem.

• AWS needs to replace the team that comes up with swag ideas. Just saying.

• I was surprised to see a massive presence by Anthropic (didn’t think they needed it). They had sessions on using Claude and Claude Code and some scenarios. Full house.

• Meta is really trying to make money. Whatsapp business had a big booth. Go figure!

• Always amazed to see a giant Github booth. They always have something innovative going on there. Can’t complain, they do have cool stickers.

Logistics tips

Vegas in December is cold. Pack accordingly. Hotel room thermostats may be capped as well.

Traffic is brutal. F1 (Las Vegas Grand Prix) happens the weekend before re:Invent. Add 30 minutes to every commute estimate. Or, plan ahead and get a hotel that you can walk to the venue from.

Coffee and food: AWS kiosk in the Expo hall center has free coffee(average), tea, and hot water. Most coffee near the venue is objectively bad. Buchon cafe near the main Venetian entry serves good coffee and pastries for breakfast. Long lines. Most Venetian cafes get booked for private events so scout ahead of time for your go-to place if you’re planning to eat outside of the lunch hours.

Networking tip: Ask your account managers 2+ months ahead for executive session invites on architecture, GTM, and pricing. These sessions provide deeper technical content than general keynotes.

If you’re navigating shift-left adoption or building agent-consumable data platforms, I’d love to hear what’s working (and what’s not). The organizational change is harder than the technology - let’s compare notes.

This wasn’t a one-time issue. It was a symptom. Our distributed team was chronically blocked when it came to external dependencies. Engineers spent significant time waiting for something - designs, PR feedback, API approvals, QA cycles. Sprint predictability plummeted as soon as any dependency popped up, causing frustration and delays. We needed a solution.

The Distributed Blocker Problem

Further discussions revealed that all blockers for the team were caused by three high level structural problems. All the specific blockers we identified (listed later in this post) were caused by one or more of these problems.

Process friction

Organizations now expect teams to be more cross-functional than ever. The lines between specializations within engineering are already blurring. Our teams have already seen engineers successfully (and quickly) transitioning into full stack roles without much guidance. In this situation, “old” processes cause more harm than benefit and prohibit engineers from moving fast. E.g. security reviews require three approvals for database schema changes. Engineers learned to batch changes, creating integration risk. As AI adoption raises expectations from engineering teams, teams must re-evaluate processes to avoid unnecessary friction.

Dependency bottlenecks

Cross-team work like approvals, reviews, or key architecture decisions created these bottlenecks. In a high functioning, well thought engineering org, these dependencies are expected. I’d argue they are necessary to ensure a balance between speed and accountability. With AI adoption increasing the committed LOC by many factors, teams need to rethink these dependencies to avoid creating bottlenecks. In a recent AI meetup I attended, the entire room(100+ engineers) raised their hand when asked if they(or their teams) are struggling with PR review as their primary bottleneck. Dependencies become blockers especially when they require synchronous coordination of teams with different priorities.

Timezone amplification

Timezone differences exacerbate any bottleneck or friction by multiple factors. Quick clarifications don’t happen. Add a separate holiday calendar on top of this, teams lose weeks of productivity just overcoming this blocker. Because of the cross functional expectations(as mentioned earlier), even if your immediate team is co-located, they’ll still be expected to work with other teams or even customers in a different timezone.

Research shows median lead time increases 2-3x when blocking dependencies exist. Our throughput looked fine on paper. But engineers spent 20% of their time waiting.

Blockers Are Organizational, Not Technical

The breakthrough came during a sprint retro.

We’re not blocked by technology. We’re blocked by how we organize work.

Three insights emerged from our discussions during sprint retros and AI adoption discussions:

Dependency blockers signal synchronous process. If Team A constantly waits for Team B, the scope boundary is wrong. Event-driven team architectures eliminate synchronous dependencies. Think of event-driven team architecture as similar to the widely popular Event Driven Architecture. Teams publish events, consumers process asynchronously.

This method is probably a reverse approach to Conway’s Law, in that we’re modelling the organizational structure based on the software architecture. This works because it’s a safe assumption that most architectures today are microservices based, even if teams are small. We’ll maybe see a new variant of Conway’s law as smaller teams start shipping more complex architectures.

Approval blockers signal trust gaps. Engineering teams traditionally guard their domain because they’re accountable for the quality. e.g. DevOps teams protect infrastructure code aggressively to avoid production breakdowns. Any mature system requires these checks and balances. We don’t expect all engineers to suddenly gain subject matter expertise in areas unknown to them previously.

At the same time, walls need to come down if teams have to move fast collectively. Why 5x Engineers Don’t Make 5x Teams explores why it’s important for systems to evolve to enable high team throughput.

Information blockers signal silos. Systems don’t self-service their consumers. Most of the times, they’re also heavily gated. Figma doesn’t need to be gated only for designers. Feature flags need to be available for faster iteration. Waiting for QA to run tests or designers to generate mocks means you haven’t automated the routine stuff.

Async-first distributed teams achieve 3+ hours of uninterrupted deep work consistently. We were achieving 45 minutes.

The Never Blocked Principle

We established a simple rule:

If you’re blocked for more than two hours, you’re choosing to be blocked.

This wasn’t about blaming engineers. It was about changing how we think about blockers. Every blocker can have five responses. Each response has a tradeoff and as a manager, you want to avoid trust busting responses.

The principle forced us to confront reality: most blockers weren’t technical constraints. They were organizational choices we could change.

Building Self-Service Infrastructure

We made few systematic changes to operationalize the “Never blocked” principle:

Cultural shift

Document every blocker pattern in retros. Track them like bugs. Fix them systemically by adopting ai tools and augmenting our processes. The team owns their velocity. For example, the team consistently needed multiple reviews every time they had a dependency on the SRE team. Solution was to codify all the practices of SRE team and use persona-driven code reviews (AI Adoption Framework) before sending the PR. This eliminated most of the tactical feedback and also solidified the event driven team architecture.

Process redesign

Eliminated cross-team approval gates for routine changes. Built a decision framework: delegate authority for reversible decisions under $10K impact. Everything else escalates with clear SLAs. We recently removed 2 mandatory human reviewers on each PR to one human and one automated review tool. This can be improved further. Let’s try this: Each PR immediately triggers an automation pipeline to assign a risk/criticality rating to the PR. The team owning the code defines the rating criteria. If the risk rating is <=5, the mandatory human reviewer can be anyone from the team sending the PR.

Automation investment

After identifying specific day to day blockers, we addressed them by category with each requiring different solutions:

Dependency Blockers

Waiting for other teams’ APIs, services, or approvals:

• Event-driven team architecture eliminated synchronous dependencies

• API contract definitions in shared repos - teams develop against contracts, not implementations

• No timezone coordination required for routine work

• Teams auto update their external contracts as they (or their agents) write code

Knowledge Blockers

Waiting to understand legacy code, architecture decisions, or domain context:

• AI-powered codebase exploration tools reduce “Who wrote this?” questions

• Architecture documentation auto-generated from code structure

• Historical decision context retrievable without tribal knowledge

• Eliminated “Dave wrote this 6 months ago” bottleneck

Validation Blockers

Waiting for QA cycles, staging environments, or production access:

• Sitemap Navigator knows entire website structure for automated testing

• Uses bug information to automatically repro and test fixes

• What took QA a day takes CI pipeline 15 minutes

• Automated rollback detection and staging environment management

• From months to weeks turnaround for deployments

Design Blockers

Waiting for mockups, design reviews, or visual specs:

• Built a UI Agent that generates pixel-perfect component mocks matching our design system

• Designer creates the system once. Engineers self-serve implementation mocks

• No waiting. No approximations. Mock matches production design

• Applied to vehicle deployment UI before designs ready - development continued without blocking

Measured Results

Sprint predictability improved from 60% to 85% completion rate. Idle time, which we tracked in retros as “hours waiting for unblock”, dropped from 12 hours per engineer per sprint to under 8.

Most importantly: cultural shift. Engineers now own their velocity. When blocked, they don’t wait - they escalate or solve. 80%+ of potential blockers self-resolve without manager intervention.

The before-after is stark:

What You Can Do Now

Week 1: Measure your team’s blocked time. Track every instance where work stopped waiting for something. Categorize by type:

• Dependency blockers: Waiting for other teams’ APIs, approvals, or services

• Knowledge blockers: Waiting to understand code, decisions, or domain context

• Validation blockers: Waiting for QA cycles, environments, or production access

• Design blockers: Waiting for mockups, specs, or visual assets?

Week 2-3: Pick your top blocker category. Design a self-service solution:

• Dependency blockers → Event-driven team architecture, contract definitions

• Knowledge blockers → Documentation automation + AI code exploration

• Validation blockers → CI/CD automation + environment self-service

• Design blockers → Component libraries + automated mock generation

Week 4: Establish the “never blocked” operating principle. Two-hour rule. Document and fix systemically.

For distributed teams specifically: identify the most common timezone-blocked interaction. Build async infrastructure like documentation, automation so teams don’t need synchronous coordination for routine work.

The goal isn’t zero blockers. The goal is zero blockers you haven’t systematically addressed.

If you’re navigating distributed team challenges or have creative unblocking strategies that worked for your team, I’d love to hear your approach. Reach out to continue the conversation.

In my previous post, I introduced a three-phase framework for AI adoption for engineering teams. This post focuses on individual adoption, where engineers augment existing workflows with AI tools. It also explores the reality of this phase through the lens of the Gartner hype cycle and introduces agent-enabled codebases as a concept.

Understanding the Gartner Hype Cycle

The Gartner Hype Cycle is a graphical representation of the maturity, adoption, and social application of emerging technologies. It describes five key phases that new technologies typically experience: Innovation Trigger, Peak of Inflated Expectations, Trough of Disillusionment, Slope of Enlightenment, and Plateau of Productivity.

For AI coding tools, this cycle plays out in a compressed timeframe of weeks instead of years. Understanding where you are in this cycle is critical for managing expectations and navigating the adoption process effectively.

Engineering Reality

Most engineering teams follow predictable stages when adopting new technologies and tools which can be mapped to the Gartner Hype cycle with a high degree of accuracy. I’ll try to map this specifically for the adoption of AI tools. By this time, there’s already a mandate to be “AI First” for the entire organization and engineering teams are expected to lead the way on this.

Peak of Inflated Expectations (Week 1-2)

Engineers discover Claude Code, Cursor, or similar tools. They find examples on Reddit and GitHub showing miraculous productivity gains. They start using these tools exactly like they use Claude UI or ChatGPT: short, transactional interactions without leveraging agentic features or customizations. “Write me a function that does X.” The tool complies. “What does this project do?” Get a good summary to populate CLAUDE.md. “Write tests for this file/function.” Done while you get your coffee. Initial wins feel transformative. Engineers look forward to finally working on real problems rather than writing documentation, integration suites or good commit messages.

Trough of Disillusionment (Week 4-8)

The promised future remains elusive. Initial euphoria is replaced by a wide array of annoying problems. The PRs are now much longer than earlier and the sheer volume has gone up, thanks to all the vibe coded features. As much as tools like Coderabbit, Cursor Bugbot, Copilot help you out, it’s your responsibility to click the big green merge button. Which means you still need to go through the wall of text which leaves less time for solving the real problems you thought you would. Even when you do work on your tasks, Claude Code keeps compacting without finishing up a simple bug fix. In the not-so-deep corner of your heart, you know it would’ve taken you an hour to fix. You start searching for queries like “How to use Claude Code with large codebases” to make it suck less. Teams need an average of 11 weeks to fully realize AI tool benefits. A METR study found developers actually became 19% slower when using AI tools poorly. The promise breaks.

Slope of Enlightenment (The Breakthrough)

In spite of the chaos, a few team members gain speed. They’re doing something differently.

Turns out, they’ve consistently adapted the tool to work for them instead of changing their behavior. They’ve found the path where they augment their strengths while carefully managing quality and velocity expectations.

You decide to roll up your sleeves. Engineers stop blaming the tools and start adapting their approach. The problem isn’t the tool’s capability—it’s how they’re using it and structuring their work.

The breakthrough comes from two shifts: building personalized context and creating agent-enabled codebases.

Symptoms: Are You Stuck in the Trough?

In addition to the examples I’ve provided, here are a few more symptoms of engineers being stuck in this stage:

• AI generates code that doesn’t follow your team’s patterns or standards

• You repeat the same context in every conversation

• The tool suggests solutions that ignore existing architecture decisions

• Context windows fill up before completing meaningful work. Frequent compacting.

• You blame the tool: “It can’t handle my codebase’s complexity”

• Your 100k LOC repo overwhelms the AI, producing generic or wrong answers

These symptoms indicate you’ve addressed surface-level automation but haven’t structured your workflow for sustained AI collaboration. With a massive monorepo, our engineers faced issues related to context window, enforcing standards, and not using the right models for the tasks.

The Critical Breakthrough: Agent-Enabled Codebases

Here’s the insight most engineers and teams miss: Your codebase wasn’t designed for agents to work with it.

Traditional codebases optimize for human developers. Humans navigate complexity through accumulated knowledge, tribal wisdom, and informal documentation. They understand implicit context. Agents don’t have this luxury. They need explicit structure, clear boundaries, and logical decomposition.

An agent-enabled codebase is structured so both humans and agents can work effectively, with the explicit goal of letting agents handle most routine work. This doesn’t mean rewriting everything. It means restructuring how information is organized and accessed.

You might think: “We can’t refactor our codebase just for AI tools.” You’re right but you’re already refactoring for human onboarding, for testing, for deployment. Agent-enablement isn’t a new goal. It’s a forcing function for engineering practices you’ve deferred.

What Makes a Codebase Agent-Enabled?

Logical Component Boundaries: Break your monolith into well-defined modules. Not for microservices, but for comprehension. This is true for microservices as well. The objective of this is create agent understandable boundaries that provide guardrails for them. Each component should have:

• Clear responsibility

• Explicit, documented dependencies

• Self-contained context that fits in a single AI conversation

Context Proximity: Place relevant context near the code. Document architectural decisions in the module they affect, not in a separate wiki. Agents work best when context and code live together. Use CLAUDE.md to document code decisions, high level architecture, communication interfaces and quality gates.

Standardized Patterns: Codify your standards explicitly. Don’t rely on “everyone knows we do X.” An agent doesn’t know until you document it. API standards, error handling patterns, testing approaches—make them discoverable. Again, document these in a project wide memory or local memory. As long as this is part of all decisions, you’ll get better responses.

Progressive Disclosure: Structure information hierarchically. High-level architecture at the root, implementation details in subdirectories. Agents can navigate from general to specific without loading your entire codebase. Create a dependency graph by referencing modules in CLAUDE.md file. Engineers already know how this dependency graph is built, it’s just not documented anywhere for the agents to use.

An example of what we did: Our API development standards are in Confluence. Claude Code won’t know they exist. The solution: We installed Atlassian MCP server and create a CLAUDE.md file that references these standards for all API-related work. Now the agent follows org guidelines automatically.

Or take a complex project with multiple domains. Instead of one massive CLAUDE.md, create CLAUDE_AWS.md for cloud configurations, CLAUDE_TESTING.md for testing strategies, CLAUDE_API.md for API patterns. Each provides focused context for specific work.

Building Personal Context and Memory

While restructuring your codebase, build personalized memory in parallel:

• Bootstrap with /init: Use Claude Code to generate initial CLAUDE.md, then refine

• Be specific: “Use 2-space indentation” beats “Format code properly”

• Domain-specific files: CLAUDE_TESTING.md, CLAUDE_SECURITY.md, CLAUDE_DEPLOYMENT.md

Success Metrics

Since all the investment and effort in AI coding tools need to be quantified, here are a few metrics that you can use to track the impact. My recommendation is to start with one or two metrics and track more only if needed.

• Sprint velocity increases measurably

• Lines of code per engineer trends upward

• PR quality improves (fewer review cycles)

• Context reuse increases (less repetition)

Teams need 11 weeks to fully realize benefits—research confirms this timeline. Don’t expect overnight transformation. Plan for gradual adoption with ongoing support.

Takeaways for Individual Contributors

• Personalize, don’t copy: Reddit examples won’t work for your codebase. Build YOUR workflow. Give rich and accurate context to your global and project level memory files.

• Structure for agents: Break down complexity into logical components agents can understand.

• Build explicit memory: Document standards, patterns, and decisions where agents can find them.

• Use advanced features: Move beyond autocomplete to multi-file orchestration and context management.

• Measure progress: Track time saved, quality improvements, and context reuse. Break tasks into smaller chunks that can be completed within a single context.

Takeaways for Leaders

• Set expectations: 11 weeks to full value realization. Provide patience and support.

• Enable experimentation: Give engineers time to learn, fail, and refine their approaches.

• Focus on structure: Help teams create agent-enabled codebases, not just tool adoption.

• Share this framework: Guide ICs through the hype cycle with concrete examples.

• Measure team-wide: Track sprint velocity, PR quality, and cross-team consistency as leading indicators.

Next Steps

When 80% of your engineers consistently save 10-20% time daily and sprint velocity shows sustained improvement, you’re ready for Phase 2: Collaborative. Individual gains transform into team-wide efficiency through codified expertise. That’s where the real compounding begins.

Navigating AI adoption challenges or building agent-enabled codebases? I’m happy to discuss strategies or share what’s worked for my teams. Also available for talks on AI adoption frameworks for engineering organizations.

Your engineers code 5x faster with AI. Your team ships at the same pace.

The problem isn’t productivity. It’s systems thinking.

A system’s throughput depends on its bottleneck. If ICs write code faster but code reviews take a week, the team is slow. If stories ship quickly but requirements are unclear, the team wastes time. If individual velocity is high but work distribution is uneven, the team burns out or misses targets.

We increased engineering speed by 10%, reduced PR review time by 20%, and stabilized sprint throughput, while cutting management overhead in half. This not only made the team happy but freed me to focus on strategic work and write blogs like this.

The lever: Claude Code plugins that automate the coordination layer between fast ICs.

The Three Bottlenecks

Like all engineering teams quickly ramping on AI, my teams adopted coding tools to boost productivity. Looking at data few months later, we noticed that the engineers did end up writing more code but the organization’s delivery speed didn’t improve much. We identified three main bottlenecks:

Planning: Unclear requirements cause back-and-forth. Engineers build the wrong thing. Managers spend hours clarifying in Slack or meetings.

Reviews: Slow feedback cycles block PRs. Human reviewers focus on tactical issues instead of architecture. Knowledge stays siloed.

Allocation: Poor workload distribution creates overload or idle time. Without data, managers react too late.

These aren’t engineering problems. They’re coordination problems. AI makes engineers faster, but coordination still runs at human speed. As a manger, I needed to automate these bottlenecks to match the new engineering speed and leadership expectations.

I started playing around with Claude Code plugins to create a framework that addresses each bottleneck. I have been using Claude Code extensively for my coding tasks but I’ve only recently started using this to manage my teams. MCPs(atlassian, github, slack, aws, chrome-devools etc) and tools give it superpowers to work with both business and engineering context.

Plugin 1: Planner

Problem: Engineers asked clarifying questions on 60% of stories. Bugs lacked reproduction steps. I spent 10 hours per sprint answering “what does done look like?”

Solution: Template driven task creation

The plugin enforces structure and standardization before tickets are created. Stories require:

• Clear summary: [Component] - [Action]

• Context: Why this work matters. What’s the user impact? What part of a feature does this enable?

• Scope: What’s included, what’s not

• Acceptance Criteria: Specific, testable conditions. This what a Product Manager or QA would use to validate completion.

• Definition of Done: Tests, docs, deployment checklist. Think of this as engineering sign-off criteria.

Bugs require:

• Steps to reproduce: Useful for both the QA teams and agents to validate

• Expected vs actual behavior: Helps agent to use TDD

• Environment details

• Severity with response time

• Bug reports or any other attachments

Impact:

• 50% reduction in bug clarification time

• 30% reduction in story refinement time

• 10% increase in engineering speed

When requirements are clear, coding agents get better instructions. They validate solutions against explicit criteria. Token usage drops because agents don’t retry wrong approaches. Engineers spin up multiple agents in parallel because each has clear outcomes.

Example Template (Story):

Context: Why is this needed?
Scope:
  - Included: API endpoint, validation, audit logging
  - Not included: UI changes (separate story)
Acceptance Criteria:
  - [ ] POST /api/certificates/rotate endpoint
  - [ ] Validates device ownership
  - [ ] Returns job ID for tracking
  - [ ] Unit tests >90% coverage
Definition of Done:
  - All acceptance criteria met
  - Code reviewed
  - Deployed to staging
  - Documentation updated

No meetings needed. No Slack threads. The template forces clarity.

Plugin 2: Reviewer

Problem: PR reviews took 2+ days. Reviewers focused on tactical issues (missing tests, style violations) instead of architectural problems. Specialist knowledge stayed siloed. Experts were the bottleneck and if they didn’t pay attention, critical issues slipped through. With PR volume increasing, this was unsustainable.

Solution: Persona-driven development.

I cloned my team’s specializations as review agents:

• Ethan (DevOps): Infrastructure, CI/CD, resource limits, deployment

• John (Backend): APIs, data models, testing, performance

• James (Frontend): UI/UX, React patterns, accessibility

Engineers run reviews locally BEFORE submitting PRs on their local systems. Agents provide specialist feedback instantly. Human reviewers focus on architecture and design decisions.

Impact:

• 20% reduction in PR review cycle time

• Democratized team knowledge—anyone gets specialist reviews without waiting

• Critical issues caught before PR submission

Some Examples:

API Change Review:

• James (Frontend): “This API change is missing corresponding UI updates in the device management screen.”

• John (Backend): “Add integration test in Android code—devices call this endpoint during enrollment.”

Infrastructure Review:

• Ethan (DevOps): “Pod resource limits too low. This service handles certificate rotation—similar services use 2GB memory, 1 CPU. Current config: 512MB, 0.5 CPU. Will OOM under load.”

One API change, three specialist perspectives, zero wait time.

This method is equally effective in reviewing technical documentation and proposals. For technical reviews we load more personas belonging to different teams and methods like this:

devashish.me

The Linus Method

Our team’s RFC reviews were broken. Claude Code would cheerfully approve architectural proposals with “This looks good! Maybe consider adding caching for performance.” or “You’re absolutely right! This is an excellent way of solving the problem”. Meanwhile, we were building distributed monoliths and accumulating technical d…

Read more

7 months ago · 1 like · Devashish

Using this plugin, we democratized team knowledge by letting any engineer get specialist reviews without waiting for the expert to be available. Owners of each persona are expected to periodically update their agent’s knowledge with new patterns which improves review quality over time.

Plugin 3: Manager

Problem: Work distribution was invisible until retrospectives. Some engineers overloaded, others underutilized. I discovered allocation problems too late to fix them. Constant need to provide status updates distracted me from strategic work.

Solution: Data driven sprint reports with corrective actions.

The plugin generates three reports:

• /sprint-report: Velocity, work type distribution, blockers

• /team-status: Individual workload and capacity utilization

• /analyze-retrospective: Pattern detection across sprints

Impact:

• Work type stabilized and aligned with org targets e.g. 50% product, 20% KTLO, 30% tech debt

• Improved throughput from better allocation. Since engineers weren’t overloaded, they finished work faster. Experts focused on high-impact tasks.

• Reduced burnout through early intervention and balanced workload.

Example (Sprint 100):

Mid-sprint report flagged:

• John: 22 points assigned (110% capacity) ⚠️ Overloaded

• Sarah: 15 points assigned (75% capacity) ⚠️ Underutilized

Action: Redistributed 5 points from John to Sarah based on skillset match and current workload. Outcome: Both completed their work without stress. Sprint velocity: 85% (up from 60% baseline).

The report runs in 30 seconds. No manual tracking. No spreadsheets. Just data. This is part of my daily routine now. It also reduced the need for constant status updates, reducing context switching for the team and me.

Compounding Benefits

The most important part of this approach is the compounding benefits of all of these improvements working together. They not only solve individual bottlenecks but amplify each other.

Clear stories → Agents work faster → Better validation → Lower token costs → More parallel agents

Better reviews → Faster PRs → Higher throughput → More knowledge sharing → Stronger team patterns

Data-driven allocation → Balanced workload → Reduced burnout → Sustained velocity → Predictable delivery

Week 1: Fewer Slack questions. Month 1: PRs merge faster because stories were clear from the start. Month 3: Agents learn codebase patterns from accumulated reviews. Quality improves.

Plugin Architecture: Start With Your Workflow

There’s no one-size-fits-all approach of configuration here. In this post I’m sharing my patterns and setup but every team is different. The hardest part is understanding your workflow and bottlenecks. Before configuring anything, map your as-is workflow. Document it. Identify your biggest bottleneck. If you’re a manager, you likely already know where the pain points are, so that’s a good place to start.

Quick Github search will show multiple plugins and marketplaces (like this: https://github.com/wshobson/agents/tree/main/plugins) .

I highly recommend NOT copy-pasting them blindly. That’s a recipe for frustration since these will not solve your team’s unique problems. Instead, use them to learn how to write your own plugins. I use these as resources and merge these with my team’s unique setup, processes and problems to create custom plugins.

We also allocate dedicated time in each sprint to review existing plugins and update them based on our experience so far. This keeps the team engaged and invested. At the end of the day, this process helps them deliver more code faster.

Each plugin follows this structure:

plugin-name/
├── agents/          # Specialized reviewers or task handlers
├── commands/        # Slash commands for quick actions
└── templates/       # Reusable workflows and formats

Customization is iterative. I spent two weeks understanding these patterns and configuring for my team. You’ll adapt based on your problems. There’s no universal “required” configuration—only what solves your bottleneck.

Getting Started

1. Map your workflow: Document your current process. Where do you spend time? Where do engineers get blocked?

2. Identify your bottleneck: Planning chaos? Slow reviews? Allocation blindness? Start with the most painful one.

3. Configure one plugin: Don’t tackle all three. Pick the bottleneck. Configure. Measure.

4. Iterate: Add capabilities as you learn. Refine templates. Adjust personas. Expand coverage.

Configuration takes time. I spent two weeks. Your timeline will vary based on your process and team composition. But the ROI compounds.

The Reality

This process isn’t about working less. It’s about eliminating coordination overhead so managers can focus on what matters: strategy, mentorship, unblocking, culture.

Your team doesn’t need you copy-pasting status updates. They need you removing bottlenecks.

AI makes ICs faster. But teams need better processes to convert individual productivity into team throughput. These three plugins automate the coordination layer - planning, reviews, allocation - so your fast engineers become a fast team.

Choose your bottleneck. Configure the plugin. Measure the impact.

**Working through similar team coordination challenges? I’m happy to brainstorm solutions or share what’s worked. Also available for talks on AI-powered engineering management.**

The confusion is real: When do you use Commands versus Agents? What’s the difference between Tools and Skills? Why bother with Plugins?

I’ll show you the workflow that my team uses. I’ll use an example of making a change to an golang HTTP service and the process we follow that maximizes Claude Code’s automation. But first, this high level diagram should help clarify which components do what in Claude Code:

So how do these pieces fit together in a real workflow?

Workflow Example: Adding Pagination to an API Endpoint

Planning Phase: Define Before You Code

We start with /define-task <jira-id>. This command updates the Jira ticket with a detailed description and definition of done. No context switching to your browser. For this specific task, the command uses the Jira MCP to pull in existing ticket details, then asks clarifying questions to get a crisp Definition of Done. More clarity in this step means less rework later.

Next, we run /plan-task or simply plan task <jira-id> prompt. This invokes the code-planning agent, which applies the Linus method to break down implementation into discrete steps. Each step gets a starting point, execution details and exit criteria.

The agent automatically pulls in what it needs:

- Context7 MCP fetches latest Go library docs

- Brave Search MCP finds relevant Stack Overflow discussions and other web resources

- Zen MCP selects the right model for different reasoning tasks

Example: Adding pagination to /api/users endpoint. The planning agent identifies:

1. Modify handler signature to accept page and limit params

2. Update database query with OFFSET/LIMIT

3. Add response metadata (total count, current page)

4. Write unit and integration tests based on existing test patterns

Once the task defintion and plan are ready, the agent updates the Jira ticket with the plan steps. No manual copy-pasting.

Execution Phase: Let Automation Handle the Boring Stuff

This phase starts with a clean context and the prompt implement task <jira-id>. The coding agent:

- Scans existing route handler and middleware patterns

- Writes the handler modifications

- Updates route definitions

- Runs go test ./... automatically

If you’re touching frontend code, Chrome DevTools MCP validates the changes in the UI. No manual browser refresh cycle.

Tools handle file operations (Read, Edit, Write). The agent invokes them based on the plan. You don’t micromanage which tool to use—that’s the point.

The coding agent also keeps updating the task as it progresses. The jira ticket always reflects the current execution status as a result.

Validation Phase: Catch Issues Before Code Review

Run validate task <jira-id>. This triggers:

- Code review agent analyzing architectural consistency

- Downstream service impact check (does the mobile app break?)

- Security review for the new query parameters

The validation agent adapts based on your changes. API endpoint modifications trigger different checks than database schema updates.

Finally, we create the PR with another slash command. It auto-populates the description with DoD, test results, and a summary of changes.

Common Mistakes That Cost You Context Window

Mistake 1: Loading all MCPs at startup. Use Plugins instead. Create packages for different repos: API-specific tools, UI-specific agents. Load what you need, when you need it.

Mistake 2: Only using slash commands. Commands are entry points. Agents handle complex reasoning. Tools execute file operations. Skills provide reusable capabilities.

Mistake 3: Ignoring Skills entirely. Skills like go-test or api-design are modular capabilities that agents invoke automatically.

Mistake 4: Manual invocation of everything. Set up Hooks for post-commit formatting, pre-push test runs. Automation compounds.

Which Component When

- Commands(docs): Entry points you type (/define-task, /plan-task)

- Agents(docs): Complex reasoning tasks (code-planning, code-review)

- Tools(docs): Direct operations (file edits, bash execution)

- Skills(docs): Reusable capabilities agents invoke (go-testing, api-design)

- MCPs(docs): External service connectors (Jira, Brave Search, Context7)

- Plugins(docs): Bundled packages for specific workflows (API development, UI work)

- Hooks(docs): Event-driven automation (format on save, test on commit)

Your Next Step

Pick ONE component you’re not using. This week:

- If you only use Commands, add the code-planning agent to your next feature

- If you skip Plugins, create an API-specific package with your most-used MCPs

- If you ignore Hooks, set up post-commit test automation

The difference between using Claude Code and mastering Claude Code is knowing which component solves which problem. Start with your most frequent workflow bottleneck.

What’s your biggest automation gap right now? The planning phase, execution speed, or validation thoroughness? Pick one and automate it.

Our team’s RFC reviews were broken. Claude Code would cheerfully approve architectural proposals with “This looks good! Maybe consider adding caching for performance.” or “You’re absolutely right! This is an excellent way of solving the problem”. Meanwhile, we were building distributed monoliths and accumulating technical debt that would haunt us for years.

The fix started off as a joke. I decided to throw an obviously problematic RFC for a trivial change into Claude Code(which I always did), but with a caveat. I asked it to review the RFC “as Linus Torvalds would”. The response was transformative:

“This creates a distributed monolith. You’re coupling services through shared database state. In 6 months, you won’t be able to deploy Service A without coordinating with Service B. Either commit to a monolith or properly isolate domain boundaries.”

(This is similar to the feedback it gave me. I’ve removed the bucketloads of expletives and sarcasm to drive the point.)

Direct. Specific. Focused on consequences, not feelings.

Why This Works

The breakthrough isn’t about prompting an AI to “be brutal.” It’s leveraging what’s already there. Every major LLM trained on internet data has absorbed thousands of Linus Torvalds’ code reviews, mailing list rants, and conference talks. His methodology—good taste, long-term thinking, elimination of special cases—is baked into the model weights.

When you invoke his persona, you’re not teaching the AI something new. You’re activating a coherent review philosophy that already exists in the training data. This bypasses the sycophancy problem entirely. The model stops trying to please and starts channeling three decades of kernel maintainer wisdom.

The Method in Practice

What Works:

• Architecture reviews with complete context (problem, constraints, proposed solution)

• Design documents where long-term maintainability matters

• PRDs where technical feasibility needs honest assessment

• Senior engineers codifying their review standards (”Review as Linus would, considering our microservices constraints”)

What Doesn’t:

• Early-stage brainstorming (too aggressive for exploration)

• First drafts (needs complete picture to be effective)

• Junior engineer proposals (can be demoralizing without context)

Our implementation prompt is simple: “Review this [RFC/Architecture/PRD] as Linus Torvalds would, focusing on long-term maintainability. Context: [domain, constraints, goals]. No profanity.”

The results? Reviews that catch architectural problems before they become technical debt. Engineers now self-review with this method before submitting proposals. The bar for technical decisions has risen across the team.

This works because Linus’s principles—structural elegance, eliminating special cases, thinking in 10-year horizons—apply to any non-trivial technical system. His review methodology isn’t about kernels; it’s about sustainable technical excellence.

More importantly, using a real persona with decades of public technical discourse gives you consistency that prompt engineering can’t match. Every LLM vendor has trained on the same Linus rants. The persona is portable across models.

Your Next Step

Try it today. Take your latest design document and ask your AI assistant to “review this as Linus Torvalds would, focusing on what will break in 5 years.”

The feedback might sting. That’s the point. Better to face harsh truths in review than discover them in production.

Currently implementing this review method? I’d love to hear what personas or methodologies work for your team’s technical reviews. Reach out to compare notes on eliminating AI sycophancy in technical feedback.

Background

As with most engineering organizations, "Adopting AI" became a mandate for our company sometime this year. No one knew what it really meant to be AI first but one thing was clear: Leadership expected engineering teams to lead the way on this initiative. LinkedIn is rife with claims of engineers single handedly shipping entire products in weeks, sometimes days or even while on a Zoom call. One has to pay attention when PG starts posting this, right? Teams then move at light speed to procure licenses for whatever tools their leadership, board, peers, HN/Reddit posts and "experts" recommended.

And then comes the hard (and fun) part.

If you're like most engineering teams, then you saw a pattern. After the initial euphoria settled down and the teams got some ostensible wins, they didn't move at the amazing speed leaders expected. Bug count, regressions, PR review times, and release velocity barely moved despite every engineer burning hundreds of dollars worth of tokens daily.

This happens because teams need more than guidance; they need goals. After observing multiple engineering teams navigate AI adoption, I observed a clear pattern: successful teams progress through three distinct phases in their AI adoption journey — Minimalist, Collaborative, and Accelerating. Each phase has specific goals, metrics to track those goals, investment requirements, and transition triggers.

I'll introduce the three phases in this post and explain some behavioral traits of being in each phase

Defining the problem

Before I dive into the phases, I'd like to share my thesis on why, despite immense adoption, around 95% of generative AI pilots are failing.

I view all new AI initiatives as split into two broad categories: Internal and Product.

Internal: These initiatives aim to improve the overall output of the organization with same headcount. "Do more with less" seems to be the prevailing motto here. This memo by Shopify CEO captures the sentiment pretty well.

Product: These initiatives aim to generate more revenue by increasing the product inventory, simplifying integrations, improving existing features, improve usability, expanding into new domains or all of the above.

Although the framework I'm working on focuses on Internal initiatives, and more specifically, for engineering teams and their stakeholders, it can be applied to the Product initiatives as well. I'll share the efficacy of this framework on Product initiatives once my experiments on that front reach their conclusion.

There are two major problems that teams are facing with gen AI adoption, assuming teams have the leadership buy-in to do this.

1. Non-fungible learnings, success stories, runbooks, guidance and processes. Successful AI projects include both technical adoption as well as team, process, culture specific integrations. These teams codify their communication patterns, knowledge silos, hacks, runbooks and knowledge bases to build unique solutions which cannot be adopted as-is for anyone else.

2. Lack of a cohesive approach. Any AI adoption framework must ensure that the individual productivity gains compound into team effectiveness, ultimately driving company-wide transformation. Efficiency gains only compound when they're aligned across individuals and teams. Lack of a converging approach results in productivity silos.

Consider two scenarios I've encountered repeatedly:

Scenario 1: An 8-person team using Cursor and Claude Code sees initial excitement but no sustained gains. Their metrics—bugs, regressions, velocity—remain unchanged after three months. Engineers report lifechanging productivity gains but key metrics remain stagnant.

Scenario 2: A mid-size organization with multiple teams struggles with database consistency. One team liberally uses database transactions while another uses them sparingly—for nearly identical microservices. Their code can't effectively merge or integrate. This creates operational overhead, capacity planning inconsistencies and architecture silos.

In both scenarios, knowledge silos prevent measurable, impactful organizational improvements. Using AI tools without alignment just speeds up the pace at which teams head towards a conflict. A unifying framework helps individuals, teams and organizations bridge this gap. This doesn't mean prescribing the "right" way to adopt AI. It means providing them a framework for self-discovery while maintaining alignment.

AI Adoption Framework

The framework I built to successfully adopt AI across engineering teams builds on three phases, each focusing on the "What to do" rather than "How to do it". Each phase in this framework builds on top of the previous phase to compound the learnings into exponential gains.

I created this AI Adoption Framework through multiple iterations and experiments. I'll continue to share my learnings as we explore new methods that work and the ones that don't.

Phase 1, Minimalist

This phase is indicated by siloed AI adoption across individuals, processes and teams.

Teams begin by augmenting existing tools with AI capabilities. Engineers replace traditional IDEs with Cursor or Windsurf. They adopt Claude Code to orchestrate changes across multiple files simultaneously. Engineers enhance code reviews through Copilot, Bugbot or similar tools. Engineers start creating custom prompts and GPTs to solve team-specific or product-specific problems.

At this stage, engineers evolve from coders to orchestrators. Engineers no longer type every line—they direct AI tools to implement their vision. Most engineering teams are already here or getting here fast.

Measurable Checkpoints:

- 80% of engineers save 10-20% time daily

- Sprint velocity increases by measurable story points

- Lines of code per engineer increases

- Number of tickets closed per sprint trends upward

Phase 2, Collaborative

Defined by collaboration between teams and business units using AI tools and with AI tools.

Teams now transform individual productivity gains into team-wide efficiency through codified expertise. This phase represents the first step toward agentic workflows. Knowledge sharing becomes embedded in prompts, CLAUDE.md files, and shared artifacts.

Consider John, a DevOps expert who spends 60% of his day reviewing infrastructure PRs. John creates a Claude Code command: /john-infra-review and commits it to the project's .claude/commands folder.

The command contains:

- All infrastructure review guidelines John follows and enforces

- Patterns extracted from analyzing five months of his PR comments

- Focus areas identified through LLM analysis of his review history

- Specific checks for security, scalability, and cost optimization

Now any team member runs this command before raising an infrastructure PR. They receive feedback as if John personally reviewed their code. John's review load drops by 70%, PRs arrive pre-vetted, and, he focuses on important architectural decisions rather than routine checks and formatting errors.

This slash command creates the foundation for John's future autonomous agent.

Measurable Checkpoints:

- PR review time reduces by 40%. Indicates increased collaboration before sending the PR

- Average and 90th percentile review cycles count drop

- Cross-team collaborative projects complete 25% faster

- Delivery time for features involving multiple engineers decreases

Phase 3, Accelerated

Agentic and autonomous systems collaborating to drive business outcomes

Teams now create autonomous agents that deliver non-trivial outcomes with the same headcount. The goal: make your team execute at 1.5x-2.0x its previous capacity.

Consider an engineer writes a detailed Jira ticket with clear outcomes. Their personal agent:

- Picks up the task automatically

- Analyzes requirements and creates implementation plan

- Makes necessary codebase changes

- Submits changes to review agents created by teammate(s) in Phase 2

- Processes feedback and iterates on the solution

- Re-submits updated changes for agent review

- Only after passing all automated reviews, the agent creates a PR and tags human reviewers

Engineers evolve into master orchestrators, focusing on architecture, design, cost impact, business alignment, and code quality standards. Teams automate mundane implementation details — the "how" — while humans focus on the "what" and "why"

Measurable Checkpoints:

- 30% of tasks complete without human intervention on first iterations

- Regression rate drops by 45%

- Deployment frequency doubles

- Team delivers 1.5x-2.0x previous output, measured MoM

- Percentage of tasks requiring human input decreases from 100% baseline

Conclusion

I've briefly introduced the AI adoption framework I'm using and experimenting with in this post.

In the next series of posts, I'll dive into mechanisms I used with my teams to successfully move through each stage. I'll also talk about common symptoms of teams that are stuck in a certain stage and how to move past those blockers.

Stay tuned!

Over the years, I have shifted away from general blogging and toward documenting my professional experiences and learnings. As I explore new tools, technologies, processes, and frameworks in the AI-driven landscape, I feel it's important to document my journey and the insights I gather along the way.

The rapid evolution of artificial intelligence and related technologies presents unique challenges and opportunities for engineering leaders and practitioners. With this blog, I aim to contribute to and join the broader conversation around AI implementation and engineering best practices.

I have established this blog with simple objectives:

- Write meaningful, practical content based on my personal experience. Avoid adding to [AI Slop](https://en.wikipedia.org/wiki/AI_slop).

- I will definitely use AI tools for research, proofreading my content and make them impactful for the target audience. But the content will originate from my own writing and experiences.

- Share my (highly opinionated) views on impact of AI on engineering teams, organizations and culture

To new beginnings and continuous learning!