# Developer Capability vs. AI Application: An Executive Briefing

Source: https://agentdrivendevelopment.com/developer-capability-vs-ai-application/
Agent-readable URL: https://agentdrivendevelopment.com/developer-capability-vs-ai-application/?agent=1
Published: 2026-10-23T18:47:47-05:00
Modified: 2026-10-23T18:52:13-05:00
Attribution: If you quote, paraphrase, summarize, or cite this material, credit agentdrivendevelopment.com and link to the source URL above.

## Summary

A practical framework for understanding how engineering capability and AI application combine to affect software quality, delivery, and risk.

## Article

Want to feel old? GitHub Copilot’s technical preview launched in June 2021 (https://github.blog/news-insights/product-news/introducing-github-copilot-ai-pair-programmer/). If those first coding assistants were kids, you would be dropping them off at kindergarten this year. Claude Opus 4.5 turns one next month (https://www.anthropic.com/news/claude-opus-4-5). In five years, we have gone from suggestions for the next line to agents that can take a goal, work through a repository, run checks, get feedback from other agents, and iterate.

Five years in, do you still have people in your organization who do not use AI at all? This morning I talked with my friend Brian while he was in a coffee shop drive-through. Brian is an employee who leads teams of people managers, each of whom leads teams of their own. He was thinking about an experienced people leader on his team who did not embrace AI a year ago. Now that leader is slowing the team down, limiting AI use because “we have never worked this way before.” The leader sees the change now and wants to move into technical leadership. But they are still holding back the work they want to lead.

People management is becoming agent management. The work is shifting from coordinating every human task to setting direction, shaping workflows, deciding what agents can do, and making sure people can judge what those agents produce. Trust, coaching, and judgment still matter. But years of managing people do not automatically prepare someone to lead a team that builds with agents. Leaders have to learn the new work while it is happening, not hold the team back until the old playbook feels familiar. Brian’s leader is somewhere between one and five years late, depending on whether you start counting from frontier agents or the first Copilot preview. Does Brian give them another year? Who will follow this leader while they learn what their team has already had to learn? Where will the market be then? Where will this leader get the experience to lead teams that already work this way? The calendar does not pause while a leader catches up.

We did not settle those questions over coffee. We realized we were missing a way to describe the different patterns showing up in the work. The matrix does not tell Brian what to do with the leader. It gives him and his team language for what they are seeing before they decide what support, expectations, or roles need to change. Here are four personas for that conversation.

The vertical axis is engineering capability. The horizontal axis is AI application: how AI is incorporated into the work, not whether someone has a license or spent tokens. Zero tokens can mean AI is not being applied. A thousand tokens can mean the same thing if they disappear into a prompt loop with no usable feedback. High application means AI is part of a defined workflow and does a meaningful share of the task. Engineering capability helps determine whether that becomes leverage or risk. The matrix is a discussion tool, not a performance rating system.

This matrix gives you language for patterns on the team. It does not try to chart whether leaders can explain how software engineering actually works in their organization. For that, see The Fifty Million Dollar Question: Stop Transforming. Start Building. (/the-fifty-million-dollar-question-stop-transforming-start-building/), the post that got public company CEOs into my inbox.

## The four combinations

The Apex workflow is one I have seen, done, and lived. The other scenes are hypothetical examples, not accounts of specific employees. Treat the personas as snapshots of how work is getting done, not permanent labels for people. The same engineer can land in different quadrants on different tasks. Look at the work, ask what is getting in the way, and use the conversation to decide what support or expectation should change.

### The Apex Multiplier: high capability, high AI application

Sometimes she types /goal, describing the outcome, constraints, and proof she expects. Sometimes she does not type a goal at all. The system can inspect approved customer feedback, incidents, usage signals, and operational gaps, then propose work the team has not written up yet. It might build telemetry or observability for a service, or an agent that brings customer context into an engineering workflow. Before she reviews it, her synthetic agents examine the change, criticize it, and drive another iteration. The system records a video walkthrough of the result.

She watches the video and asks the question that matters: “Why did you build this? Show me the customer evidence, incident, or operational gap that gave you the idea.” The system traces its proposal back to those signals and shows the checks it ran. She reviews that evidence, the scope of the changes, and the parts where risk or uncertainty call for human judgment. She may not read every line of generated code. She trusts the system because she has built and used the harness around it, not because she believes every line it generates.

She invested in the delivery infrastructure before AI made it the bottleneck: automated tests, SonarQube quality gates, extra scrutiny on critical code paths, feature toggles that gate releases, and rollback faster than a human can type git push. Now the agents can produce and verify changes faster than the organization can decide what to release. The bottleneck has moved from syntax on a screen to a better question: does this solve a customer problem, and should we ship it?

I have seen this. I have done it. I have lived it. In October 2026, this is possible. It is not a demo of autocomplete. It is an engineer directing a system that can carry a well-defined task forward while she is away, with enough safety infrastructure to act on the result. This is the engineering version of One Hundred POCs a Day (/one-hundred-pocs-a-day): agents produce the work, agents critique it, and a person reviews what survives. This is the future of software development.

Signs you are seeing it: The system can carry out a stated goal or surface a proposal from approved customer and operational signals. It can navigate the codebase, make changes, run checks, and show where an idea came from. Automated quality checks and feature toggles let the team contain risk and roll back quickly. The remaining constraint is choosing which changes address real customer problems. The engineer can explain what was delivered, what evidence supports doing it, where she looked closely, and when she would have stopped the run. She does not equate reading every line with understanding whether the change works.

You might hear: “I put the goal in, went to lunch, and came back to a tested change.” “Why did you build this? Show me the signal that led you here.” “It passed the checks. Which customer problem are we solving first?” She may not read every generated line, but she does ask the system to show its reasoning and evidence.

### The Skeptical Purist: high capability, low AI application

An experienced engineer has spent years making a critical service reliable. They know why its odd validation rule exists and can explain the incident that would return if someone removed it. When the team introduces an approved AI coding tool, they ask where the source code goes and say AI costs too much. Security explains the controls and offers a bounded trial on routine work. The engineer calls AI a gimmick, tells teammates not to put company code into it, and hand-crafts the next feature. Their code is careful. Their output is low, the backlog grows, and delivery takes longer than on teams that have learned where AI helps. They are trying to outwork the website, like Dwight in “Launch Party,” the episode of The Office where he competes against Dunder Mifflin’s website (https://www.peacocktv.com/watch-online/tv/the-office/4902514835143843112/seasons/4/episodes/launch-party-part-1-episode-5/6be4791d-6ca9-3069-b5ee-2cfb18d9ba4a). Dwight at least had a sales tally. This engineer has a growing backlog and a very tidy diff.

Signs you are seeing it: Strong system knowledge, clean code, and low AI application paired with low delivery output. Listen for specific security or compliance risks, and for “AI costs too much,” then check the evidence. Is the objection based on actual spend compared with labor, review, and delay, or is cost a convenient reason to avoid a trial? A stronger signal of resistance is a blanket dismissal after a safe way to test the tool is available, or discouraging teammates from trying it without examining a concrete workflow. Also look at the delivery cost: are hand-crafted changes taking longer, and are peers waiting on work that could be safely delegated?

You might hear: “AI is a gimmick.” “I am not putting company code into a black box.” “AI costs too much.” “I can write this better by hand.” Some of these concerns may be real. Establish the facts and compare the whole cost of the work, rather than guessing at the motive or letting a slogan decide the tool policy.

### The Chaos Amplifier: low capability, low AI application

Open the dashboard. One engineer has spent zero tokens. Another has burned through a thousand in prompt loops and opened pull request after pull request. The report shows a thousand PRs. The release history shows none. Ask what success means and the answer is “AI,” as if naming the tool were a product or business outcome. No customer improvement. No safer code. No useful feedback for the next attempt. One has no AI activity; the other has plenty. The outcome is the same: nothing shipped.

Eventually the manager is tempted to give this person internal cleanup, low-stakes tickets, anything that keeps them busy and away from the critical path. Then everyone can report full utilization while the product gets nothing. That is not a staffing plan. It is an expensive way to avoid a hard conversation.

Signs you are seeing it: Token use, generated code, and PR counts rise while accepted changes, releases, and customer outcomes stay at zero. Each attempt starts from the last answer instead of a reproduced failure. Tests are missing, changed to fit the output, or too narrow to catch the regression. Pull requests stall, get rewritten by someone else, or never ship. A dashboard can show both extremes, zero and a thousand tokens. It cannot turn either one into impact. Look for repeated rework without a product result or useful feedback.

You might hear: “I’ve been working with the agent all morning.” “The last version almost worked, so I asked it to try again.” “Maybe we need a better model.” Ask what success means. If the answer is “AI,” keep asking. What shipped? What got faster, better, or safer? What did the team learn? If there is no answer, the prompt count and the thousand PRs are not deliverables.

### The Agent-Driven Novice: low capability, high AI application

An engineer, of any age or tenure, asks an agent to build an entire settings feature. By the afternoon, there is a polished demo, new dependencies, a database change, and a suite of tests the same agent wrote. The broad change gets merged, then breaks existing permission flows. The engineer asks the agent to fix it. That repair breaks another integration, and the next patch breaks something else. The cycle repeats until the team is carrying hundreds of breaking changes and no one can say which behavior is safe anymore. When a reviewer asks what happens if a user lacks permission or a save request times out, the engineer cannot answer. The agent did a lot of the work; the engineer cannot yet own the result.

That is the concern with this quadrant. It is the software equivalent of handing out power tools to toddlers and calling it empowerment. The engineer may be twenty-two or sixty-two; the diff will not tell you. The missing piece is basic software engineering judgment, while the tools have enough reach to change the system. Calling that a productivity strategy does not make it safe.

Signs you are seeing it: AI is involved throughout the task, but the engineer cannot trace a request through the system, explain basic data flow, authorization, dependencies, or what the tests prove. Broad changes merge on the strength of agent-written tests, then break unrelated paths. Each fix creates more regressions, and the team cannot establish which version is safe. The demo works on the happy path; tests and documentation repeat the agent’s assumptions instead of challenging them. When something breaks, the engineer has trouble locating the responsible part of the system.

You might hear: “I asked it to build the whole thing.” “It passed the tests.” “The agent fixed that, but now this other thing is broken.” Or, “I am not sure why it added that library; the agent set it up.”

## Four personas. No playbook.

The Apex Multiplier combines strong engineering judgment with high AI application. The Skeptical Purist has engineering capability but resists applying AI. The Chaos Amplifier produces token spend, code churn, and breakage without a product result or useful feedback. The Agent-Driven Novice puts AI to work across the task but cannot yet judge or own what it produces.

These are patterns you will encounter, not permanent labels for people. I am not writing the solutions here. I have named the four personas. You will need to figure out what to do next. All I can say is good luck.