Two years ago, if you’d told me I’d be writing a blog about AI coding agents, I’d have laughed. I was deep in application modernisation — helping financial services teams containerize legacy workloads, migrate to microservices, and adopt cloud-native patterns on AWS.
Then I watched a coding agent refactor an entire microservice in 12 minutes. Not generate boilerplate — understand the codebase, plan the migration, execute across 40 files, and open a clean PR. That’s when everything clicked.
The Container Parallel
I’ve seen this movie before. In 2016, modernisation went from “lift-and-shift” to “rearchitect everything.” Teams that treated containers as just a packaging tool fell behind. The ones that thought about orchestration, team workflows, and platform engineering early? They’re years ahead now.
Coding agents are at that same inflection point. Most teams are treating them as fancy autocomplete. A few are redesigning how they build software entirely.
What I Got Wrong at First
My first instinct was to evaluate agents like infrastructure: benchmark throughput, measure tokens per second, compare pricing. That’s useful — but it misses the point.
The real differentiator isn’t model quality. It’s workflow design:
- How does the agent understand your codebase context?
- How do multiple developers share agent configurations?
- What happens when the agent produces bad code — how do you catch it?
- Can you run it on your own infrastructure when compliance requires it?
These are team problems, not tool problems. And nobody was writing about them honestly.
What This Series Covers
Coding Agents in Teams — 7 posts, one agent deep-dive at a time:
- This post — why I’m writing, what lens I bring
- 2026: The Year Coding Went Agentic — what actually changed
- Kiro — spec-driven development, hooks, subagents
- Claude Code — multi-agent teams, CLAUDE.md, headless CI
- Codex — cloud-native sandboxed execution, GitHub-native
- OSS Agents: Pi-Agent & OpenCode — bring your own model, full control
- The Team Playbook — patterns for team-scale adoption
Each post follows the same structure: what it is → how it works → hands-on setup → team integration → honest opinion.
My Lens
I’m not a neutral reviewer. I have biases — here they are upfront:
- I care about infrastructure. If I can’t run it on my own terms, that’s a problem. Self-hosted models, Bedrock, or a mix — I want optionality.
- I think in teams, not solo. A tool that makes one developer 3x faster but creates chaos for the other 49 is a net negative.
- I come from regulated industries. Financial services has constraints. Data residency, audit trails, model governance — if the blog post doesn’t address these, it’s incomplete.
- I prefer fewer tools used well over many tools used poorly. You probably don’t need all five agents. You might need one, configured deeply.
Who This Is For
- Engineering leads evaluating coding agents for their team
- Platform engineers building internal developer platforms with agent capabilities
- Individual developers who want to go deeper than “it autocompletes my code”
- Anyone running ML/AI infra who wants to understand the agent layer above it
Let’s Go
Next up: 2026: The Year Coding Went Agentic — the landscape, the shift, and why this time it’s different from every other “AI will replace developers” cycle.
Follow along on X or grab the RSS feed.
— Jihed