The economics of agentic software delivery

What changes in the client’s proposal?

Coding agents can reduce the effort needed to implement a feature. Whether the client benefits depends on the rest of the work: deciding what to build, integrating it into the product, verifying its behavior and correcting what fails. A proposal should account for that complete scope and explain where reduced effort changes the price or delivery date.

A useful comparison begins with accepted work: software that meets agreed requirements, passes the relevant checks and is ready for its intended use. For a membership cancellation, that includes the payment state, the access a member retains and the message they see when a request fails. Generating the cancellation endpoint completes only part of the task.

Experienced engineers and reusable software influence how much of that work must be done from scratch. A software factory gives coding agents a process around their implementation work, with specifications, project context and review findings carried between attempts. The cost of running that process includes human review and correction.

We will use Light Grid, our recent partner, as an example. Three full-stack, applied AI engineers built a platform spanning community operations, payments and AI-assisted discovery. Their collective experience includes startups and Fortune 100 companies operating at global scale. The engagement shows the range of work a small team can undertake with reusable foundations. It does not provide a controlled estimate of the savings attributable to AI.

For a founder or CTO comparing suppliers, the practical question is what each offer includes at acceptance. Put the required behavior and operating responsibilities beside the total price. Then compare the assumptions about effort and time. Later in this paper, a worked cost comparison shows how a fixed fee or retainer can be assessed against a conventional estimate.

The scope behind a small team

Light Grid combines member-facing web and mobile applications with administrative tools. Community boundaries, business rules and shared identities connect the features, so a change to one part can affect several others.

Independent communities. Each community has its own database, session identity, branding, administrators and feature configuration. Community administrators manage their community; grid administrators operate shared infrastructure. Wallets and payments can be disabled for a community. These boundaries implement the product’s requirements for community control while retaining shared operations.

Community activity and connections. Members join gatherings and recurring mastermind groups, publish posts and discover opportunities. Hosts collect registration answers, approve attendees and check them in. Recommendations help attendees find people to meet, request introductions and provide feedback. Paid memberships support the ongoing community around those interactions.

Tokenomics and the ledger. Members earn, spend and transfer tokens under configurable rules. A pending activity charge reduces the payer’s spendable balance while the recipient’s credit remains in escrow. Settlement releases the credit; reversal returns the reserved value. Stable charge keys and transaction-state checks protect supported retry paths from duplicate charges or repeated reversals. Refunding an activity charge releases its key so a later registration can create a new charge.

Applied AI. Light AI supports conversational discovery and presents results as usable cards. Mad Libs onboarding combines a deterministic workflow with generated suggestions. The matching agent explores a candidate pool through a Java REPL, using a repeatable search-coverage plan derived from profile fields. It considers what people offer and what they need in each direction. Application checks flag final candidate IDs missing from its working set; model-generated searches and final choices can vary.

Analytics and improvement. Authorized administrators can ask questions about business data through a schema-guided, read-only query path. The application validates the proposed presentation and renders tables and charts with existing components. Matchmaking evaluations, traces and member feedback give engineers evidence for changes to prompts, retrieval and scoring. A model-judge score is one input to that work; member feedback provides a different view of usefulness.

The delivery challenge lies in making these capabilities work together. A registration can touch authentication, attendee approval, a token charge and a confirmation screen. Scope and acceptance need to follow that journey across the system.

What experienced engineers make reusable

The Light team brought decades of collective experience to the engagement. That experience helps engineers recognize a product gap before it becomes an implementation assumption, and choose an architecture the team can maintain.

Full-stack work is useful when a requirement crosses several boundaries. An engineer handling membership cancellation needs to understand the provider’s state, the application’s access rules and the interface. Someone also needs to resolve differences between those interpretations with the product owner. Forward-deployed engineers stay close to those product decisions and the customer’s constraints.

As agents take on more implementation, engineers have to reason across a larger body of changes and verify that the parts still work together. That makes architectural knowledge and disciplined review central to the delivery process.

Some of that knowledge can become shared components and maintained agent skills. A team can give both people and coding agents concrete guidance on recurring work:

• Product judgment: connect the requested capability to a complete user journey. Resolve missing decisions before implementation. A useful analytics view may need a few queries and established charts before it needs a separate platform.
• Design systems: provide shared components and examples for responsive layouts, loading states and errors. Review how screens work together, including the transitions between them.
• Shareable skills and coding standards: capture implementation conventions, architectural decisions and verification procedures in versioned guidance. Explain when each skill applies and revise it as the project changes.
• Deterministic guardrails: enforce specific rules with type checks, dependency constraints, schema validation and business-rule tests. Written guidance tells an agent what is expected; executable checks can reject a change that violates a rule.
• Proportionate architecture: choose technology for the product’s needs, expected load and operating capacity. Require a concrete reason for another service or abstraction, including its maintenance cost.

A skill needs an owner and a defined scope. A shared component needs tests and a maintenance path. Their value comes from reducing repeated work while keeping the implementation understandable to the team that will operate it.

Reuse across the runtime and the interface

Light’s Java backend uses Helios, our agent libraries, for sessions and tool execution. Light supplies its own context, tools and matching behavior. The common runtime provides a foundation that can improve independently of the product’s matching logic.

The LEGO analogy applies when each component has a defined responsibility and a clear interface. Engineers still have to understand its constraints, configure it for the application and own its failure behavior. Reusing a runtime does not remove those decisions.

The same principle applies to the interface. Light uses shared typography, color tokens, forms, cards and dialogs. Recommendation cards and introduction flows appear in both gathering matches and the recommendations page. Generated presentations use a defined set of renderers, so a model’s structured output becomes familiar product components.

This gives coding agents an implementation contract. An agent building another screen can use the same action hierarchy and error treatment. Review still needs to check the resulting journey: using a shared component alone does not establish that the screen is coherent.

Pixel-perfect UX involves states as well as spacing. In Light’s dialogs, the body scrolls while the footer remains outside the scrolling region. The layout adapts between a sheet on smaller screens and a modal on larger ones. Long content, validation errors and loading states need inspection in each use. A correction in the shared component can improve several screens at once.

Sail and the engineering loop

We built Sail in Java as a software factory and a meta harness for coding agents. It coordinates harnesses such as Claude Code and Codex with project environments, specifications and review history.

A specification describes required behavior, constraints and verification commands. Sail prepares the project branch and supplies context to the implementing agent. Review examines code quality and functional behavior. Findings return for correction and another review; a passing review leaves the change awaiting human merge.

Loop engineering defines completion and escalation: what gets checked, which findings persist and when continued work stops. Addy Osmani’s Practical Loop Engineering discusses bounded goals and independent verification, with human attention where product judgment is needed.

Dependencies between tasks need the same care. Interface and backend work can proceed separately against an agreed API contract, then converge on integration checks. Preserve the state and evidence needed at each handoff, and return failed checks to the step responsible for correcting them.

Sail is our current delivery system. Light’s development spans the evolution of that tooling, so its delivery history cannot be attributed entirely to today’s harness.

Acceptance follows the user’s task

Light’s gathering registration illustrates why a feature list is insufficient for acceptance. Someone follows a link, decides to attend and selects the join action. If authentication is required, the application must remember why the member signed in and resume the registration.

The implementation preserves that intent. It waits for the host’s questions before deciding the next step, handles the appropriate invitation choice and avoids registering someone who is already going. A gathering with no additional requirements can take a simpler path.

The acceptance check should follow the same sequence, including the relevant alternatives. Testing sign-in and registration separately can leave the transition between them unexamined. A buyer should be able to inspect the complete journey and understand which cases were verified.

Membership cancellation needs a similarly explicit boundary. The member should see the correct access end date, understand what cancellation changes and receive an accurate message if the underlying request fails. Review of the code and verification of the running behavior answer different parts of that requirement.

A delivery proposal can capture these expectations in a short acceptance record:

The first examples come from Light’s implementation. The handover row is a purchasing requirement to agree with a supplier. Assign an owner to each check and record what happens when it fails. This makes acceptance a reviewable commitment and gives a fixed-fee estimate a clearer scope.

Compare total cost for the same accepted work

A conventional estimate provides a starting point: expected hours multiplied by a blended hourly rate, plus costs outside those hours. Compare that with the full proposed cost of delivering the same accepted scope.

For a fixed fee, include separately charged costs. For a retainer, include all months expected to reach acceptance. Treat model usage, infrastructure, support and taxes consistently across the offers, and count review and correction effort on both sides. Changes to client responsibilities also belong in the comparison.

• Baseline cost = conventional hours × blended hourly rate + comparable costs outside those hours.
• Proposed cost = fixed fee, or monthly retainer × delivery months, + comparable costs outside the fee.
• Cost reduction = (baseline cost − proposed cost) ÷ baseline cost.
• Equivalent cost per baseline hour = proposed cost ÷ conventional hours.

Consider a scope estimated at 1,000 hours and $100 per hour. The baseline is $100,000. These illustrative offers assume identical scope, acceptance standards and cost inclusions; they are separate from Light Grid’s commercial terms.

The $75 figure is a comparison measure: $75,000 divided by the baseline’s 1,000 hours. It says nothing about the engineers’ actual billing rate or hours worked. A lower total cost is possible when reduced effort covers the added tooling, verification and correction costs, and the commercial offer passes some of that benefit to the client.

Time matters to this calculation. In the retainer example, a fourth month raises the total to $100,000 and removes the saving. Earlier delivery under an unchanged fixed fee may still have business value, but it does not lower that fee. A 20–30% reduction is a scenario to evaluate against a credible baseline, rather than a forecast of the gains from a particular tool.

Put the comparison into the proposal

Ask a prospective team to explain its estimate through a complete capability, such as registration or membership cancellation. Identify the components already available, the product decisions still open and the evidence required for acceptance. That discussion reveals work an implementation-only estimate can miss.

Then request the assumptions behind the price. For a retainer, include the expected duration and what changes if acceptance takes longer. For a fixed fee, specify the included scope, change process and treatment of defects. In either case, make source access, deployment and maintenance responsibilities explicit.

Record the agreed scope, acceptance owner and total expected cost alongside the responsibilities that continue after release. Revisit those commitments when scope or dependencies change.

Further reading

• Addy Osmani, Practical Loop Engineering.
• Standard Applied Intelligence Labs.

AI expands what we can build. Building it well still demands judgment, mastery, and discipline.

Standard Applied Intelligence Labs