By function
An engineering agent is useful when it completes a change the team can ship, not when it produces more code to review.
26%
measured productivity gain in software development studies. Employment for developers aged 22–25 has fallen nearly 20% since 2024.
Stanford HAI, AI Index 20261The bottleneck is often context, tests, review, and release, not typing. An agent that increases review load without increasing shipped work is negative leverage.
How I see it
Software engineering agents
Engineering agents can help with well-bounded work: tests, refactors with a spec, boilerplate, migrations, and documentation tied to a change. They create risk when they touch production paths without evaluation, permissions, and a human release gate.
Software engineering agents are sometimes the product and sometimes a supporting function. They should still pass the same economic test as any other agent.
SaasChing AI is relevant here as proof of production agent systems around design, build, test, and go-live, not as a reason to agent every repository on day one.
Common mistakes
What teams usually get wrong.
Lines of code as the metric
Generated volume that fails review is a tax on senior engineers.
Unsupervised production changes
Write access to production is a control point, not a default.
No evaluation on real repositories
A generic coding demo says little about your codebase.
A useful diagnostic
Five questions before you fund the work.
What engineering outcome is delayed by repetitive work?
Name the outcome: tests merged, tickets closed, releases cut.Will the agent increase or decrease review load?
If you cannot say, measure it in a small slice first.What may the agent never do unsupervised?
Secrets, production, and irreversible data changes belong on that list.Is there a more valuable business workflow first?
Internal engineering leverage is not always the COO’s first win.Can you baseline cycle time from ticket to production?
That is the number that matters.
Economic model
Engineering leveragecycle time and review hours on a bounded class of changes, before and after the agent
If review hours rise more than cycle time falls, the agent is not helping.
Three credible paths
How far should you go?
Do not force one solution. Choose the path the economics, the risk, and the organization can support.
Improve the work you already have
Keep the process mostly intact and use AI on the bottlenecks that create delay, rework, or follow-up.
The workflow is already sound and a few steps create most of the friction.
Gains are usually incremental. The operating economics do not change much.
Redesign the workflow around AI
Question every handoff, queue, and duplicate step, then rebuild the process around what AI can now do.
The process grew over years and coordination now costs more than the work itself.
Requires process change, clearer ownership, and a willingness to retire old steps.
Put an agent on a high-value outcome
Give an agent responsibility for one valuable result across systems, with humans at the control points that require judgment, authority, or risk acceptance.
The workflow is high-value, variable, multi-step, and worth engineering for production.
Needs stronger architecture, evaluation, controls, and monitoring. This is not a prompt project.
When this is the wrong next step
Do not fund an agent here.
- The team cannot describe a bounded class of changes.
- There is no test or review path.
- The COO is being asked to fund this while a much larger operations workflow sits untouched.
A useful next step
Bring one workflow. Get guided into production.
We guide the implementation, go deep on the technical path, and stay hands-on through operations — or tell you when a simpler answer is better.
Discuss an AI opportunity