Blog / English

AI Makes Code Cheaper. Building the Wrong Thing Still Costs.

October 31, 2026 — Luis Coimbra — Austin Tech Week · AI coding · software architecture · productivity · Digital Squad

Lessons from Austin Tech Week on software productivity, context, and the work worth doing.

By Luis Coimbra, Founder & CEO, DStrategy LLC · October 31, 2026

After a week of talks, demonstrations, and conversations at Austin Tech Week, including our booth at Startup Crawl, one question stayed with me: as building software becomes easier, are we getting better at deciding what deserves to be built?

AI coding tools can shorten the distance between an instruction and working code. That is valuable. But the distance between working code and a useful, maintainable business outcome includes much more than implementation.

My takeaway is simple: the cheaper execution becomes, the more important the decisions behind it become. This is our interpretation of the sessions and material we reviewed, not a consensus attributed to every speaker.

The same question appeared in different conversations

Business discussions brought us back to customer priorities. A problem can be real without being urgent enough to attract budget or change behavior. Investor questions returned to adoption, integration, recurring demand, and evidence of value.

The material on AI software factories raised a complementary issue. Agents can perform more work with less continuous supervision, but autonomy still requires context, permissions, review, and explicit controls. Knowledge that an experienced engineer takes for granted does not automatically become available to an agent.

Operational examples reinforced another distinction: a successful demonstration is a starting point. Production introduces dependencies, exceptions, maintenance, and responsibilities that a demo may never encounter.

Together, these ideas suggest that software productivity should be measured across the journey from problem to validated result, rather than only at the moment code is generated.

A two-day feature can still be expensive

Consider an illustrative example: a team uses AI to add a customer discount feature in two days instead of two weeks. The interface works, and the happy-path test passes.

Then questions arrive. Can discounts be combined? Does an existing pricing service already implement the rule? What happens to a refund? Which team owns the calculation? Does the mobile application use the same contract?

The implementation was fast. Yet unanswered questions can turn into duplicated logic, integration changes, repeated reviews, and support work. Some of those costs appear months later.

This is not an argument for writing a giant specification before every change. It is an argument for resolving the uncertainties that could invalidate the work, with effort proportional to the risk. A prototype may be the fastest way to answer a question. It simply should not be mistaken for evidence that every production concern has been resolved.

Productivity includes work that never needed to happen

Several small losses can accumulate throughout a delivery cycle:

  • Searching for context: rediscovering how a system works whenever someone new touches it.
  • Reopening decisions: revisiting choices because their rationale was not preserved.
  • Discovering rules late: implementing an interpretation that the business never intended.
  • Finding dependencies after the change: learning too late that another application consumes an interface.
  • Repeating correction loops: asking a coding agent to repair an output without resolving the ambiguity that caused it.
  • Maintaining unnecessary features: carrying operational complexity without a corresponding customer benefit.

An effective productivity conversation therefore includes both faster execution and avoided work. It also includes the effort required to obtain those benefits: analysis, verification, tools, and coordination have costs of their own.

Time recovered = context search avoided + unnecessary waiting avoided + rework avoided + unnecessary implementation avoided − added analysis and validation effort.

This is a conceptual accounting model, not a guaranteed financial formula. Categories must not overlap. The same hour cannot be counted as both waiting saved and rework saved, and available capacity does not automatically become cash savings.

More autonomy needs a clearer operating system

When agents can start multiple tasks, the backlog stops being a sufficient filter. A task that was previously too expensive to attempt may become easy to generate while still being costly to own.

Teams need to decide who authorizes work, which resources an agent may access, what constitutes acceptance, and when a person must intervene. Testing a behavior, checking permissions, and preserving an audit trail answer different questions; none replaces the others.

The objective is useful autonomy. Routine work should move efficiently, while consequential decisions remain visible and attributable. More checkpoints are not inherently better: controls should address actual failure modes, not merely add ceremony.

Where ArchGenerator fits

ArchGenerator's Digital Squad brings AI-based product, technology, data, and business perspectives to software analysis and preparation. It helps connect available evidence and business context to architectural decisions and structured specifications for a team's preferred coding AI.

In the discount example, that can mean investigating the existing system, surfacing an unresolved rule, recording the decision, and preparing acceptance criteria before implementation proceeds. A follow-up assessment can support verification of progress.

The squad supports the team; it is not a replacement for accountable people or the coding tools that implement changes. It cannot know information that has not been supplied or made available, and an assessment does not guarantee defect-free or secure software. Recommendations, assumptions, and open questions still require appropriate review.

The useful test is whether the work supports a better decision or a better change—not simply whether it produces another document.

A practical experiment for the next two weeks

Choose one real change with a clear business owner. Before implementation, record the intended outcome, current behavior, affected interfaces, unresolved rules, and acceptance criteria. Identify what can be reused and what may not need building at all.

Track time spent understanding, clarifying, implementing, reviewing, and correcting. Record questions reopened and changes required after acceptance. Compare with a reasonably similar task, while acknowledging differences in complexity and team experience.

Finally, ask whether someone used the output to make a decision or complete a change. Documents generated, tokens consumed, and lines of code are activity measures. They are not, by themselves, evidence of value.

The question worth bringing back to the team

AI creates a significant opportunity to build, learn, and iterate. Capturing that opportunity requires judgment as well as execution capacity.

Before asking, “How much more can we build with AI?”, ask: “How much of what we are building should exist at all?”

The next productivity improvement may begin with a better implementation. It may also begin with a clearer rule, a dependency discovered early, or the decision not to build a feature nobody needs.

Bring one real software challenge to ArchGenerator. Start with the decision you need to make and define what a useful result would look like.

Sources and further reading

The discount scenario and productivity model are illustrative. Product applications are our analysis, not endorsements by speakers or event organizers. No productivity percentage is claimed.

← All articles