Campbell Yule’s recent competitive moat analysis in State of BIM 2026 prompted us to look at our own work.
If AI makes software much faster and cheaper to build, is the finished software still where most of the value sits?
Increasingly, we think it isn’t.
Software is part of an ongoing process
Over recent months, both of us have used AI coding tools to develop quite different systems.
The process is less structured than conventional software development. There is no fixed specification followed by a finished application. We start with a practical problem, build something, use it, correct it and continue.
Some corrections improve the immediate result. Others become new instructions, tests or validation rules. Occasionally, the correction changes the structure of the software itself.
We have started to think of this as elasticity: the software is allowed to change as our understanding of the problem develops.
It is not the finished asset. It is part of an ongoing process.
The model provides capability. The surrounding system accumulates experience.
The yellow trace and the red pen
Architecture already has two good analogies for this process.
The yellow trace captures design development. It contains the options tested, altered and discarded before a solution is reached. The final drawing records the answer. The trace records part of the search.
The red pen captures review. It identifies what is wrong, unclear or incomplete. But the markup alone is of limited value unless it remains connected to both the work being reviewed and the correction that resolved it.
The useful chain is:
input → review → correction → resolution
Most digital systems are good at retaining final outputs and file versions. They are less effective at recording why something changed and what was learned from the correction.
The same is true outside architecture. A resolved technical or operational issue usually records the outcome, but not always the evidence considered, the assumptions rejected or the experience used to reach the decision.
Much of the knowledge is in the process, not just the result.
The craftsman
Richard Sennett’s The Craftsman is relevant here.
Sennett does not limit craftsmanship to manual work. He applies it equally to programmers, doctors, musicians and other skilled practitioners. Craft develops through doing the work repeatedly, encountering resistance, making corrections and gradually improving both the result and the practitioner’s understanding.
AI does not remove that process.
It can produce an answer quickly, but it does not arrive with the practitioner’s accumulated experience of whether that answer is appropriate. That still comes from someone who understands the work and is prepared to stand behind it.
The difference is that a correction can now do more than fix one output. It can also alter how the system approaches similar work next time.
The model itself may not have learned from the mistake. The wider system can.
Two parallel experiments
One of our experiments began within the design of a real building project. An AI coding harness is being used to develop an architectural authoring environment alongside the design work. The project exposes what the software needs to do, while the software affects how the project can be explored.
The other began within the daily operation of a technology consultancy. It looks at how knowledge about clients, systems, alerts and previous decisions can provide better operational intelligence. The aim is to help experienced people interpret evidence and direct their attention, not to automate their judgement.
These are individual experiments in different fields. They are also direct results of our continuing collaboration and exchange.
Despite their different starting points, both have led us to similar conclusions:
- Software needs to remain elastic.
- General AI capability is not the same as professional experience.
- Corrections become more valuable when their context and resolution are retained.
- Human judgement shapes the system rather than simply approving its output.
- The knowledge accumulated through use may be more valuable than the software itself.
Where this leaves VKTRS
VKTRS has grown out of practical work in architecture, BIM management, content development and systems integration.
AI allows us to turn more of that experience into working software. It also forces us to be clearer about where the actual value sits.
It may not be in protecting a finished application. It may be in capturing how experienced practitioners explore a problem, recognise that something is wrong, correct it and apply that correction to the next attempt.
The yellow trace records the search. The red pen records the judgement. Elastic software allows both to shape what the system becomes next.