AI gives a team another way to explore a software idea and produce an implementation. I would include it in a build-or-buy assessment by examining the work around that implementation: requirements, review, integration, security, support, and future change. A useful comparison follows the same workflow through each option and measures the effort needed to reach a result the firm can operate.
Source
The useful question is where effort moves
METR’s May 2026 task-substitution discussion shows why a changing mix of work complicates productivity claims. In a build decision, I would ask which activities become easier and which responsibilities become more prominent.
Compare requirements, implementation, review, integration, and operation across equivalent options. A faster prototype may make a custom approach worth testing; the solution still needs an owner who can maintain and verify the result.
Separate implementation from the complete job
A working prototype helps people see what is possible. The operating decision also needs requirements, permissions, validation, deployment, monitoring, support, and a way to correct failures.
AI assistance may change the effort required for some of those activities. Measure where it does. Avoid assuming that faster code generation reduces every part of delivery by the same amount.
DORA’s 2025 research describes AI as an amplifier of existing organizational capabilities. For a small team, clear requirements and disciplined review remain useful inputs to the experiment.
Proposal
Compare equivalent alternatives
Take one bounded workflow and define its acceptance conditions before building anything. Compare configuration of an available product, a conventional custom implementation, and an AI-assisted implementation where those options are feasible.
Include the same access model, data handling, export, recovery, and handover requirements. Otherwise the custom demo may appear cheaper simply because important work has been omitted.
A hypothetical internal request tracker could be quick to demonstrate. The comparison becomes more meaningful when it includes permission differences, change history, duplicate submissions, notifications, and the person who will support it. Those requirements should follow the actual need, rather than grow into an unnecessary product.
Measure the surrounding effort
Track time spent describing the task, generating or writing code, reviewing it, fixing defects, testing, and deploying. Record assistance used in every option. If AI also helps configure or integrate a purchased platform, include that benefit rather than reserving it for the build side.
METR’s February 2026 update discusses difficulties in measuring developer uplift, including selection effects. It does not supply a universal multiplier for a firm’s project. A local pilot is more useful when its scope, participants, and limitations are visible.
Review the resulting software with the same seriousness regardless of how it was produced. NIST’s Secure Software Development Framework addresses lifecycle practices that remain relevant to requirements, dependencies, vulnerabilities, and ongoing maintenance.
Ask someone else to own the result
Have a second person follow the deployment instructions, inspect a failure, and make a small change. Observe whether the implementation is understandable and whether its tests help catch a meaningful regression.
Document what the team can support itself and where it needs outside help. Easy regeneration is an incomplete recovery plan if no one can determine whether the regenerated behavior is correct.
Use the pilot to update the decision memo: observed effort, remaining work, operational limitations, and a realistic maintenance range. Revisit the choice as the workflow and available products change.
AI can make a custom option worth examining sooner. The decision should still rest on the capability the firm receives and the responsibility it can sustain. A lower cost to begin is valuable when the path to continued ownership is also clear.
Proposal
What I would test next
I would compare one bounded capability across available configuration and build options, including AI assistance wherever it is actually used. Choose from the observed effort, quality, and handover evidence, then record what would change the decision.