For most of the software era, the product question was shaped by scarcity. Could I hire enough software engineers? Could I prioritize the right roadmap? Could I afford to build what we imagined?

Earlier in my career, working as a software product manager, the job often felt like saying no most of the time and occasionally getting to say yes. Every planning cycle became a negotiation between customer requests, roadmap commitments, technical debt and the engineering capacity available to make progress.

In my view, that dynamic is rapidly disappearing as agentic coding tools demonstrate their ability to create increasingly complicated software autonomously; a transition which shifts scarcity from the means to produce software to the user's ability to trust the software that is produced. In other words, the question becomes not whether the software can be built, but rather whether or not there is the confidence to connect that software to important data, customers and workflows.

Georgian's work on developer productivity frames this as a shift from software scarcity to software abundance, with constraints moving downstream to review, testing, deployment, security and reliability. This transition from software scarcity to abundance is being accelerated by the increasing role of AI in code creation. For example, it is being reported that the majority of code at Shopify, Google and OpenAI is now being written by AI. The trend also appears to be moving further toward automation rather than simple AI-assistance with Anthropic recently reporting that multiple Claude Code agents produced a Rust-based C compiler capable of building Linux 6.9.

In my view, with the advancements in AI coding tools such as Claude Code and OpenAI’s CODEX since December 2025, the interesting question isn’t whether a particular piece of software can be built or not, it is now: “Given I can build almost anything with enough time and tokens, what should I build, what should I reuse, and what should I trust to run?”

From capability to confidence

A piece of software that can be generated on demand may not yet be a system an organization can rely on. It may run in a demo, become a credible MVP and pass generated tests while still lacking evidence about edge cases, security boundaries, uptime, auditability, support, incident response and ownership.

That is the gap between capability and confidence. AI can help create code, tests and documentation. It can also help reason about failures. But before software is connected to important data, customers and workflows, buyers still need comfort that the system will behave predictably, fail safely and have someone accountable for the outcome.

Take a customer-support or revenue-operations agent. A startup might sell it, an internal team might build it, or a business user might assemble it with a workflow tool, a model API and access to CRM or ticketing data. In each case, the demo may look similar: the agent can read context, draft responses, update records, trigger refunds, escalate issues or summarize account history. The production question has two layers: can we trust how this agent was built, tested and deployed, and can we trust what it is allowed to do once it is live? What data can it access? What actions require approval? How are mistakes detected? Can the company audit what happened? Who owns the customer impact if it acts incorrectly?

Georgian's AI Applied 2025 work shows both momentum and friction: 83% of respondents viewed AI as a top-five strategic priority, while concerns such as AI reliability, hallucinations, data security, privacy and integration remained barriers to scale.

Georgian's trust lens for agentic software

This is why Georgian believes the trust lens is useful. Georgian has long taken the position that trust is not simply security or compliance. Trust comes from the balance between value and comfort: value gives customers a reason to adopt, while comfort gives them confidence that adoption will not create unacceptable risk.

I believe this framing of trust matters in software abundance because agentic software changes two related things. First, agents are becoming builders: agents can help generate code, tests and development artifacts, which creates a creation-time trust question - can we trust how the software was produced? OpenAI and Anthropic have both described systems that automate increasingly large parts of software development, from Codex workflows to parallel Claude Code agent teams.

Second, agents are becoming actors: agents can retrieve data, call tools, update systems and act toward goals set by humans, which creates a runtime trust question: can we trust what the software does once it is operating? That runtime question is where risks such as prompt injection, sensitive information disclosure and excessive agency become relevant: the issue is not just whether the software works, but what it is allowed to access, decide and do.

In Georgian's framing, comfort includes security, privacy, fairness, transparency, reliability and accountability. Comfort asks whether systems and data are protected, whether customers understand and control how their data is used, whether outcomes are fair, whether behavior is explainable, whether the product operates consistently, and whether the organization takes responsibility for the impact of its products and services.

Applied to agent-built software, those dimensions of comfort ask whether the code, dependencies, tests, configuration, deployment path and change history can be inspected and trusted. Applied to agent-run software, they ask whether the agent’s data access, memory, permissions, tool use, decisions, failures and handoffs can be constrained and observed.

I see the two agentic shifts converging. Agentic engineering increases the volume of software that can be created. Agents as actors increase the consequences of letting that software run. Together, these shifts make comfort harder to earn through assertion alone. Buyers need evidence.

Verifiability turns comfort into evidence

In my view, verifiability is what turns comfort from a feeling into evidence. While Georgian’s original trust thesis did not treat verifiability as a standalone principle, the idea was embedded throughout the framework: in reliability through monitoring and validation, in transparency through explainability, in accountability through measurement, and in security through audits and controls.

As agentic systems generate code, call tools, access data and act on behalf of users, I believe we will see buyers demand more than simple assurances. Software buyers are already being encouraged to ask for evidence such as logs, evals, audit trails, provenance, permissions, test results, bill of materials (e.g. listing open source libraries), performance metrics, product-security artifacts and third-party validation.

I believe reliability is especially important here. Georgian's 11 Principles of Trust include anticipating the unexpected, analyzing and responding to failures, monitoring product and system health, watching customer feedback channels and refining response plans over time. Generating a functional system is only part of the problem. Earning confidence that it should operate in production is the other part.

The companies that verify faster can harden faster

If verifiability turns comfort into evidence, verification loops determine how quickly that evidence compounds. Historically, battle-hardening came mostly from time in market: scaled deployments, customer implementations, edge cases, failures, support tickets and incident response. Those still matter. In my view, however, companies with faster verification loops may be able to compress part of that learning cycle.

The mechanism is not just a test. It is a loop. First, a company defines what "good" looks like for a narrow domain: the code compiles, the tests pass, the policy holds, the vulnerability is removed, the workflow completes correctly, the output matches a known standard, or the human reviewer accepts the result. Then agents can generate or modify the system, run against that verifier, observe the result, repair the failure and try again. OpenAI’s Codex launch materials make this pattern visible in software development: Codex can run tests, linters and type checkers, and OpenAI emphasizes citations, terminal logs and test results as ways for users to verify its outputs.

The compounding part comes from what happens next. Each pass through the loop can create evidence: which cases failed, which fixes worked, which edge cases appeared, which policies were ambiguous and which user interventions were needed. That evidence can improve the product, but it can also improve the verifier itself. Over time, the company is not only hardening the software. It is hardening the process by which the software gets evaluated.

Not every domain has clean objective functions. Many trust questions still require judgment, context, customer expectations or regulatory interpretation. But where a company can turn more of its domain into verifiable outcomes, it may be able to learn faster than competitors. A support agent might be verified against resolution accuracy, escalation quality, policy compliance, customer sentiment, refund thresholds and human review decisions. A security product might be verified against exploit reproduction, vulnerability remediation, false-positive rates and provenance checks.

In my view, this is one of the more interesting potential moats in software abundance. The advantage may not come simply from generating more code or shipping more agents. It may come from having proprietary verification loops that let a company test, repair, learn and harden faster than others. Better verifiers create better feedback. Better feedback improves the system. A better system creates more production evidence. More evidence can improve both customer trust and the next generation of verifiers.

Build, source or compose

If trust is understood this way, the build-versus-buy question becomes less binary. The cost of building is not only the time and tokens required to generate software. It is the cost to verify, monitor, harden, govern, support and stand behind the system. In my view, that is trust-adjusted TCO.

Practically, this points toward composition: build or generate where customization and speed matter, and source trusted components where the problem is horizontal, high-risk or operationally unforgiving.

Companies already compose systems from APIs, cloud services and open-source components. MuleSoft/Salesforce's 2024 Connectivity Benchmark Report found that 99% of organizations use APIs, with IT leaders reporting that APIs are used to build integrations, support new-project development and enable code reuse. Georgian also believes the API economy is a way for builders to assemble capabilities quickly while focusing on their core competency.

That is not just an efficiency pattern. At their best, trusted components carry accumulated evidence: edge cases, documentation, security reviews, uptime history, observability, support, customer feedback, product-security artifacts, provenance and remediation processes. CISA's Secure by Demand guidance similarly encourages software customers to look beyond enterprise security posture and evaluate how manufacturers approach product security itself.

The security bar may also be rising. Anthropic's Project Glasswing announcement described Claude Mythos Preview as an unreleased frontier model that identified thousands of zero-day vulnerabilities, including critical vulnerabilities across major operating systems and browsers, many of them autonomously.

That does not mean shared or open-source components are inherently unsafe. It does suggest that trust in a component cannot rest only on popularity, age or the assumption that many eyes have already found the important bugs. Trust increasingly depends on ongoing verification, active hardening and evidence that buyers can inspect. Synopsys has also reported that 74% of audited commercial codebases contained high-risk open-source vulnerabilities. In my view, that argues for disciplined selection, maintenance and governance of the components we choose to rely on. Trust should be earned and verified, not assumed.

Trust is not just an incumbent advantage

There is an obvious objection: if trust comes from battle-hardened systems, does software abundance simply make incumbents stronger? Not necessarily. Trust is not only inherited. In my view it can be designed, borrowed, priced and earned.

Startups can narrow the initial risk surface, keep humans in the loop, limit data access, make behavior observable, borrow trust from established infrastructure and underwrite risk through pricing, guarantees, SLAs, warranties or implementation commitments. CISA’s Secure by Demand and Secure-by-Design guidance points to the kind of evidence buyers can ask for and the kind of accountability software manufacturers can show.

The startup answer to incumbency is not simply "move faster." In my view, it is "learn faster by verifying faster." A startup that defines the right outcomes, instruments the right feedback loops and builds domain-specific verifiers may compress the time required to earn confidence. It still needs customers and real-world exposure, but each deployment, failure, support interaction and eval result can become fuel for the hardening loop.

Buying decisions are unlikely to become purely mechanical. Even if agents help evaluate vendors, organizations may still encode human preferences into those systems: security posture, procurement readiness, reputation, references, purpose, alignment and perceived career risk. Anthropic's public-sector packaging and GSA OneGov agreement are a useful reminder that procurement path, pricing and safety-oriented positioning can matter alongside technical capability.

Trust becomes the selection rule

Software abundance creates a selection problem. If more applications, agents, workflows and components can be created, buyers need a way to distinguish what merely works in a demo from what deserves to run in production. Trust becomes that selection rule.

In my opinion there are two implications to the concept of trust as a selection rule. First, existing software companies may need to make trust more visible and more operational. It may not be enough to say that a system is secure, reliable or well governed. Customers may increasingly expect evidence: permissions, logs, evals, provenance, audit trails, runtime controls, monitoring, incident response, third-party validation and clear accountability.

Second, and perhaps more interestingly, software abundance may create a new class of opportunities around delivering trust itself. If the bottleneck shifts from generating software to verifying, hardening and standing behind it, then the trust layer becomes a product surface. That could include companies building agent observability, domain-specific evals, software provenance, runtime policy enforcement, AI security, verified open-source infrastructure, synthetic testing environments, compliance automation, trust centers, warranties, insurance, or other mechanisms that help customers decide what can safely run.

In my view, this is the next extension of Georgian’s trust thesis. Trust is still about value plus comfort. But in a world where software can be generated more easily, comfort may depend on the systems that make trust verifiable. The companies most likely to matter may not simply be the ones that generate the most functionality. They may be the ones that help customers build, verify, harden and operate the systems they are willing to trust.

When anyone can build any software, trust becomes the moat, and the tools that create trust may become some of the most important companies to build.