Cheaper implementation gives a deferred tooling idea a reason to be reconsidered. It does not automatically give it a business case.
A campaign measurement checker might take less effort to build with a coding agent. Someone still has to define what counts as an error, arrange data access, validate the output, and keep the checker useful when campaign conventions change.
Aaron Levie has argued that cheaper code could make previously uneconomic software applications viable. That is a useful hypothesis for growth teams: some recurring problems may finally be affordable to solve. The operating decision is whether the cost of delivering and owning a useful tool has fallen enough to change its priority.
Start with a deferred problem that still matters
Revisit work that was postponed because implementation effort looked too high relative to its value. Check whether the problem still exists before estimating a new build cost.
A good candidate has a recurring user, a clear input, an observable output, and a workflow where you can inspect correctness. Campaign measurement QA is one possible example: a tool could flag records that violate an agreed set of naming or tracking rules.
For each candidate, write down:
- Who encounters the problem and how often.
- How they handle it today.
- What time, delay, or rework the current process creates.
- What successful use of the tool would change.
- Who would own it after delivery.
Avoid starting with a feature list. “Check these campaign records before reporting” gives you a tighter boundary than “build a marketing intelligence platform.”
Also revisit the original reason for deferral. If unclear requirements or inaccessible data blocked the project, faster coding may leave the constraint intact.
Define acceptance before implementation
A demo can look convincing while leaving the difficult operational questions unresolved. Write acceptance criteria before anyone starts building.
For a hypothetical campaign measurement checker, the criteria might require it to detect agreed errors in a prepared test set, distinguish missing information from invalid information, and provide findings an analyst can inspect. The analyst would also need to complete the intended workflow without the builder standing beside them.
Set correctness thresholds based on the consequence of mistakes. A tool that produces too many false alarms can consume the attention it was supposed to save.
Define continued use separately from technical acceptance. Identify the intended user, the recurring occasion for use, and the existing step the tool should replace or shorten. Choose a review window that contains enough real occasions to assess adoption. Thirty days can be a starting point for frequent workflows; an infrequent process needs a longer window.
Keep an initial QA pilot limited to reporting findings. Automatic campaign changes add consequences and review work that make the first evaluation harder to interpret.
Count the work around the code
Track labor from the first specification through the follow-up period. Include:
- Requirements and acceptance criteria.
- Implementation and agent supervision.
- Review and correctness checks.
- Data access and integration.
- Rework, documentation, and user onboarding.
- Maintenance and support during the observation window.
Include everyone whose effort changes. A shorter build can still be a poor trade if it creates more analyst debugging or engineering review.
Record recurring infrastructure and software costs separately. If you convert labor into money, state the rates and assumptions. Keep observed time savings distinct from estimated future savings.
The value estimate deserves the same discipline. Time saved per completed workflow can support a capacity argument. It does not establish incremental revenue, and it may not reduce cash spending. Be explicit about the decision the released capacity would enable.
Choose the comparison that answers your question
There are two useful questions here: does this tool improve the current workflow, and does agent assistance improve the economics of delivering it?
For one candidate, compare the existing manual process with use of the accepted tool. Observe completion time, correction work, and whether people keep using it. This can inform the build decision, but it cannot isolate the contribution of the coding agent.
To evaluate the implementation method, use several reasonably comparable tasks if you have them. Match tasks on scope and integration difficulty, then randomly assign tasks within those groups to agent-assisted or existing implementation workflows. Apply equivalent acceptance and adoption criteria to both.
Keep the pilot small enough to inspect failures. With only a few tasks, differences in task difficulty or builder familiarity can dominate the result. Treat the comparison as local decision evidence, with uncertainty attached.
Measure accepted tools that survive use
A useful delivery metric is:
Total labor hours across all assigned tasks ÷ tools accepted and still in use at the end of the observation window.
Count time spent on abandoned and unsuccessful tasks in the numerator. Otherwise, the metric hides the cost of finding the successes.
If no tool qualifies, report that result and the hours spent; the ratio is undefined. Do not substitute completed prototypes for accepted tools.
Read this metric alongside defects, reviewer burden, unresolved tasks, recurring costs, and workflow time saved. Continued use alone does not prove sufficient value. A tool can become part of the process while adding little benefit.
Make a decision about the next tool
Before starting, define what evidence would justify continuing. The threshold should reflect local opportunity cost: what else could the same people accomplish?
Continue when a tool meets acceptance criteria, gets used on real work, and creates enough recurring benefit to justify ownership. Narrow the scope when the core function helps but integration or support absorbs the savings. Stop when the need is weak, correctness remains unreliable, or the maintenance burden outweighs the benefit.
Watch for three misleading signals. A fast prototype may leave review unfinished. Enthusiastic feedback may never become recurring use. A successful pilot may depend on one builder quietly providing support that nobody records.
The output of the pilot should be a better investment decision, including which kinds of tooling deserve another attempt and which constraints still need attention.
Evidence and limitations
Aaron Levie’s demand-expansion argument is a forecast. It does not establish implementation savings, adoption outcomes, or employment effects.
The evaluation method here develops that hypothesis into an operating recommendation. The campaign measurement checker is an illustrative candidate, not a reported implementation or success story.
A short pilot can reveal delivery effort and early use. It cannot establish long-term maintenance costs, incremental revenue, or market demand for selling similar tools. Those require separate evidence. Even a successful internal tool supports a bounded conclusion: this workflow appears worth serving under the observed conditions.
Source basis
- Supplied summary of Aaron Levie’s argument that lower coding costs could expand economically viable software demand; original post not independently verified for this review.
- Proposed evaluation method covering total labor, equivalent acceptance criteria, sustained use, and maintenance; no completed experiment or measured outcomes supplied.