Hey everyone,
Picture a Monday planning meeting that should have been about an SSO renewal ticket and a broken finance export. Instead, half the room is arguing about which coding agent is “winning” this month. Someone screenshots a survey chart. Someone else drops a funding headline. A third person swears the new tool will cut sprint work in half if we just migrate by Friday.
I have sat in that meeting. The energy feels productive. It usually is not.
Adoption data is useful. Market noise is loud. Neither one is a strategy for shipping software you can still operate next quarter.
Hi, I’m Robert Massey, software engineer and computer science professor with twenty-plus years in the trenches. AI is a tool and an assistant. Programming is still a skill. Software engineering is still engineering solutions with software. Standards and review capacity beat leaderboards.
What changed, and what did not
As of mid-2026, AI coding agents are no longer a niche experiment for early adopters. JetBrains’ Developer Ecosystem Survey 2026 (May-July fieldwork, 15,000-plus professional developers) reports that about 90% of professional developers use AI coding agents at work at least weekly, and about 68% use them daily. In that same window, Claude Code sits near the top of workplace adoption (about 39% worldwide in the survey’s framing), while GitHub Copilot’s measured workplace use is lower than its earlier peak (about 21% in the same cut). Awareness for several tools remains high even when usage shifts.
That pattern matters more than any single brand name. Tools can climb and fall in popularity while your incident queue, merge queue, and on-call rotation stay exactly as hard as they were last year.
Around the same time, headlines about highly valued coding-agent companies keep reinforcing a simple story: pick the “winning” agent and your engineering org will suddenly move faster. Investors can bet on platforms. Your team still has to merge diffs, protect auth boundaries, and explain failures to customers.
Generation got cheaper. Delivery still requires judgment.
Why leaderboard chasing burns real teams
When a group standardizes on whichever tool topped last month’s chart, a few failure modes show up quickly.
First, migration cost hides in plain sight. Prompt libraries, IDE shortcuts, review habits, and “how we ask for a change” conventions are muscle memory. Throwing that away for a two-point adoption bump is an expensive hobby.
Second, review capacity does not scale with agent output. An agent can open a pull request for the SSO redirect bug, the CSV export for accounting, and a drive-by refactor of unrelated helpers before lunch. Your seniors still have finite attention. If generation outruns review, the queue is the product.
Third, architecture consistency suffers when every engineer is chasing a different “best” workflow. One person lets an agent rewrite the auth middleware. Another person only uses inline suggestions. A third person pastes stack traces into a chat window with no repo rules at all. You do not get a coherent system. You get three dialects of almost-right code.
Fourth, metrics lie when you celebrate the wrong ones. Lines generated, tickets “touched,” and pull requests opened can all rise while change failure rate, reopen rate, and time-to-first-meaningful-review stay flat or get worse. Feeling faster is not the same as delivering safer.
I am not anti-tool. I use these assistants constantly. I am anti-fashion when fashion replaces engineering standards.
A thin evaluation rubric that actually fits real work
If your team needs a shared AI coding assistant (or a small set of approved ones), run a short pilot against your messiest real work, not a greenfield demo app. Keep the rubric thin enough that people will use it.
1. Task fit on your actual backlog
Pick three tickets you already understand: a bug in login redirect behavior, a flaky integration test around file export, and a small feature with a clear acceptance check. Score the tool on whether the first useful draft survives senior review without a full rewrite. Fancy autonomous demos matter less than reliable help on your stack.
2. Diff discipline
Does the default behavior produce reviewable changes, or does it “helpfully” rewrite half the module? Can you constrain scope (“touch only these files,” “no dependency changes,” “no drive-by renames”)? If every session becomes a 1,000-line archaeology project, you did not buy speed. You bought a backlog of unread diffs.
3. Context and repo rules
Can the tool reliably honor project conventions once you write them down? Services should not reach into another domain’s tables. External calls need timeouts. Structured logging stays structured. If the agent ignores your AGENTS.md / project rules after you make them explicit, the tool is fighting your architecture.
4. Security and operational surface
Where does code go? What gets logged? Can you disable training on your repositories? How do secrets, licenses, and audit trails work for agent-opened pull requests? A tool that wins a popularity contest and fails procurement is not a win.
5. Cost against review load
Seat price is only part of the bill. Token burn, rework, and senior engineer hours spent untangling almost-right output are the rest. If daily use multiplies pull requests without shrinking cycle time for customer-visible work, pause and fix the workflow before you expand seats.
You do not need a 40-row spreadsheet. You need a written pass/fail bar and a 2-4 week pilot with the same tickets across candidate tools.
Stabilize the workflow, not the brand name
The teams that get value from coding agents tend to look boring in the best way.
They write short repo rules and treat recurring review comments as documentation updates, not as a chance to complain in Slack again. They keep pull requests small enough that a reviewer can hold the change in their head. They separate “prototype with an agent” from “land in production.” They require the author to explain the change in review, whether a human typed every line or an assistant drafted most of it. They measure outcomes that customers and operators feel: lead time for trusted changes, escaped defects, and on-call noise, not autocomplete acceptance rate alone.
Notice what is missing from that list: a mandate to chase whichever logo is currently at 39% adoption.
Standardize the layer that must be uniform (security expectations, review ownership, branch protection, “no merge if you cannot defend the logic”). Then let teams pick approved tools that clear that bar. A rigid one-tool religion often creates shadow installs. Shadow installs are how you lose the audit trail.
A practical default for this quarter
If you need something concrete for the next planning cycle, try this:
- Pick one primary assistant for day-to-day work and, at most, one secondary for tasks where the primary is weak.
- Freeze tool-shopping for 90 days unless security or clear pilot data forces a change.
- Add or refresh a short project rules file with the constraints your reviewers keep repeating.
- Cap default agent changes to a reviewable surface area; split larger work into sequenced pull requests instead of one giant “agent finished the epic” diff.
- In review, ask the same question you would ask a new teammate: can you explain why this is safe?
AI coding agents are tools. Good tools amplify clear standards. They also amplify messy ones.
The leaderboard will keep flipping. Your customers will not care which model drafted the change. They will care whether the export ran, whether login still works, and whether on-call stays quiet.
Loved it? Drop a comment with the last tool-migration argument that ate your planning meeting. Support the shenanigans on Patreon or buy me a coffee, and follow AttuneIT on YouTube, X, and Facebook. Let’s make tech less scary and more awesome.