# AI Has Changed What Investors Should Ask About Software

> Why sophisticated product surface is weaker evidence of technical maturity than it used to be.

Canonical: https://schalginski.de/insight-ai-investors.html

A sophisticated product used to be a relatively strong signal. Building a broad interface, integrating multiple services and shipping a substantial workflow usually implied a meaningful amount of engineering capacity, time and organisational coordination.

That signal has weakened. AI-assisted development allows a small team to produce far more visible functionality, far more quickly. This is a genuine advantage. It also means that product surface and engineering maturity can now diverge much further than investors may expect.

The relevant response is not suspicion of AI-built software. It is a better evidence model.

## Product capability and technology-asset quality are different questions

A product demonstration answers questions about present capability. Can a user complete the workflow? Does the interface communicate the proposition? Can the company show traction around something that works?

An investment decision usually requires additional answers:

- Does the company understand and control the system it has assembled?
- Can the architecture support the operating and economic assumptions in the investment thesis?
- Which parts are durable foundations, and which remain disposable experiments?
- What happens when volume, regulation, customer expectations or the team itself changes?
- Which dependencies could materially alter cost, continuity or bargaining power?

AI does not create these questions. It changes how much confidence can be inferred from the visible product alone.

> A convincing product is evidence of product capability. It is no longer reliable evidence of a mature engineering organisation.

## Repository activity is also a weaker proxy

A large codebase, frequent commits and rapid feature delivery can look reassuring. Yet quantity says little about whether the system has coherent state ownership, explicit domain invariants, safe migration paths or controlled operational behaviour.

Generated code can be excellent, mediocre or dangerous, just like human-written code. The distinction is not authorship. The distinction is whether the organisation can evaluate, integrate and own what enters the system.

Useful diligence therefore looks beyond activity metrics. It asks whether important decisions are visible and understood:

- Can the team explain why critical boundaries exist?
- Are generated changes reviewed against system-level assumptions, or only against local acceptance criteria?
- Is there a stable model of the domain, or has functionality accumulated as a sequence of prompts and patches?
- Can a new senior engineer identify authoritative data and critical execution paths without relying on one individual?
- Does the organisation know which code, models, datasets and third-party components it is entitled to use and transfer?

These questions test control rather than output.

## The team’s ability to reason about the system is an asset

In traditional diligence, team quality is often evaluated through experience, hiring plans and development process. AI-assisted engineering adds another dimension: the organisation’s ability to maintain a coherent model while implementation accelerates.

A strong team should be able to connect business concepts to software behaviour. It should know where money, permissions, customer state or regulated data become authoritative. It should be able to describe failure and recovery paths, not only intended workflows. When uncertainty exists, it should be visible rather than disguised by confident documentation.

This does not require every engineer to understand every line. It requires clear ownership, reliable boundaries and enough shared reasoning that the company can make controlled changes.

The diligence question is therefore not “Did AI write this?” It is “Who can establish that this behaviour is correct, and from what evidence?”

## External intelligence can become structural dependence

Many AI-enabled products depend on model providers, vector services, hosted databases, workflow platforms or specialised APIs. These services can be the right commercial choice. They can also shape gross margin, product differentiation, data governance and continuity.

An investor should understand:

- how much of the customer proposition depends on a replaceable service versus proprietary capability;
- whether provider pricing can change the unit economics materially;
- which data crosses external boundaries and under what contractual controls;
- whether model or API changes can alter product behaviour without a corresponding code deployment;
- whether the company can evaluate output quality and regressions independently;
- how long a realistic substitution or migration would take in operational terms.

“Vendor lock-in” is too blunt a label. Dependence is not automatically bad. Unmeasured dependence is the problem.

## Technical diligence should test behaviour, not aesthetics

A clean repository can hide fragile operating assumptions. A messy repository can support a well-controlled business if critical paths are isolated, monitored and understood. Diligence should sample the evidence that matters to the investment thesis.

For a transaction platform, that may mean tracing a state-changing workflow through normal completion, retries, partial failure and reconciliation. For an AI product, it may mean examining evaluation practices, data boundaries, model substitution and cost behaviour. For an enterprise platform, it may mean validating tenancy, access control, migration capability and operational support.

The objective is not exhaustive code review. It is targeted falsification: looking for evidence that could materially weaken the assumptions on which the transaction depends.

## Questions that have become more important

AI-assisted development makes several questions more consequential:

1. **What is actually proprietary?** Product design, workflow knowledge, customer data, evaluation capability and operational integration may be more defensible than raw code volume.
2. **What does the organisation truly control?** Access, deployment, data, model behaviour, vendor accounts and critical knowledge should not depend on informal arrangements.
3. **Can the team change the system safely?** Velocity matters less if every change increases uncertainty or requires the original builder.
4. **Do the economics survive success?** API, inference, storage, support and human-review costs may behave non-linearly.
5. **What has not yet been tested by reality?** A product can have broad functionality while remaining lightly exercised under concurrency, failure, adversarial use or enterprise constraints.
6. **Which risks are reversible?** Some gaps are ordinary post-investment work. Others constrain the thesis because they become expensive only after customers, data and integrations accumulate.

## The decision that matters

AI has reduced the cost of producing convincing software. It has not reduced the importance of architecture, operational control or technical judgement. In some cases it has made them harder to infer from superficial evidence.

The updated diligence standard is simple: treat visible functionality as valuable but incomplete evidence. Establish what the company owns, what it understands, what it depends on and how the system behaves when conditions stop being ideal.

The goal is not to discount AI-enabled companies. It is to price technical reality into the investment decision rather than relying on signals whose meaning has changed.