The same 5 patterns appear at every customer#
Our customers build very different products. They range from highly regulated industries to e-commerce and everything in between.
Most of the lead time passes before anyone writes code#
Every company we assessed already writes code with AI. Every one of them is still slow.
A typical change takes 5 to 6 months to reach production. Getting to final requirements takes 1.5 to 2 months of that. The hands-on work inside those weeks is 2 to 3 days.
For another, it is about entering new markets, where a new market takes 9 to 14 months from idea to production. The last market built with AI help reached its test environments in about 6 weeks. At another customer, about half of an initiative's lead time passes before work on the code starts.
Industry data agrees. Faros measured 10,000 developers. Heavy AI users merged 98% more pull requests, with no change in lead time. Review time went up 91%.
What each team knows is written down nowhere an agent can read#
At one customer, a service is about 10,000 lines of Java. One engineer can read it in an afternoon. Still, no other team can change it without the team that built it. How the service works lives in that team's heads.
A vendor saw the same in its own trials. Agents delivered the features that had good documentation. For the rest, people first had to rebuild the intent by hand.
The usual fix fails. Some customers try to manually backfill this knowledge by creating an architecture repository and hope people would fill it in. They do not.
A team indexed Jira and Confluence every night. Asked about a feature, it returned a status that was 2 months old.
Everyone uses AI, but each team builds its own tools#
At the vendor, all 20 questionnaire respondents use AI tools. Several teams run agent setups ahead of most of the industry. We counted 5 separate sets of agent tooling. Each ran on developer laptops, and none was shared.
Some power users spend 1,500 to 3,000 euros a month on tokens. Colleagues next to them try and give up.
On our AI Adoption Ladder, all companies sit at Stage 2: most people use AI, each in their own way. Some teams work at Stage 4 or 5. Between them, shared context, one platform, an owner and measurement are missing.
Teams do not trust their tests enough to release without a manual check#
New code usually has good test coverage. Releases are the problem. Developers told us they do not trust the automated tests enough to deploy alone. So every sprint ends with a manual regression check, and every release waits for a slot.
At one customer, customers confirm most behaviour of the older core during acceptance testing. At one customer, the release train exists mainly because nobody fully relies on the tests.
When an agent gets stuck, a developer has to step in live#
The common answer to a stuck agent is to let a developer connect to it. One customer was adding hosted IDEs to its pipeline for this. It works, but the agent waits until someone is free. Few people can read an agent's work mid-run, and the system learns nothing from the fix.
Lore became a factory platform with memory, gates and an audit trail#
Lore looks different from the April post. These changes matter most for the patterns above.
Factory terms. The Factory is the whole platform. A Floor is the coordinator that hands out work, one per team, cluster or trust tier. An Assembly line is a versioned graph of Stations for one type of task.
A Station runs one piece of work: an agent, a service call or a person. An Agent is one short-lived model run with a prompt and context. Each run copies its assembly line at the start, so later edits do not change it. In October we moved the Floor into its own repository, re-cinq/floor.
People as stations. A person can be a station in the graph, with the page they act on. "An architect approves the spec" then becomes a gate the pipeline enforces. Before, it was a rule on a wiki page.
Memory that ages. Lore collects context from repository files, PR history, agent sessions and explicit writes. It stores chunks, facts and a knowledge graph in PostgreSQL with pgvector, one schema per team. Search combines vector and keyword (BM25) results. Facts have a validity window and a confidence score.
When new facts contradict old ones, the old ones expire. Context behind merged changes gains weight. Context behind rejected changes loses it.
Specs linked to code and tests. A separate graph links each specification to its code and to the test runs that check it. Drift detection uses this graph to show what a changed rule affects. Scheduled jobs find missing documentation and create tasks to fill the gaps.
Escalation that leaves a record. Sometimes an agent still fails validation after its automatic retry. It then stops, commits its state and sends a structured exception to the owning team. The exception holds the diff so far, what the agent tried and why it failed. People answer in their own tools, and Lore stores the answer in memory.
Independent review. A different model reviews every change an agent writes. It starts with fresh context and has a fixed number of fix attempts. After that, a person takes over.
Rules the platform enforces. Each repository has a trust level: documentation first, then tests, then code. A repository moves up after a run of successful merges. Every action records 2 identities: the person who delegated and the agent that acted.
Full autonomy exists, but it is off by default behind 2 switches. Turning it on needs 2 people: an administrator and a code owner.
Issue triage. A labelled issue goes to a sandboxed agent that tries to reproduce the bug. Next, an agent finds the root cause and checks it against the docs and specs. Lore closes issues that are already solved and splits large ones. Then it waits for a maintainer to start the work.
Operations. The laptop part is now a small MCP adapter with a short-lived cache. When the backend is down, it serves cached answers and marks them. That was on the "pending" list in April.
Agents run as short-lived Kubernetes jobs, in a container you can supply. Only 1 process in the cluster holds Kubernetes credentials. Everything installs from 1 Helm chart. The test suite has about 650 files and more than 4,000 assertions.
Lore covers the engineering side, and the customer builds the business side#
The table maps each pattern to what Lore does and what each customer still builds.
| Pattern | What Lore does | What the customer still builds |
|---|---|---|
| Lead time before code | Intake from issues, chat and a form; spec PRs; approval gates | Meeting transcripts, clickable previews, a business data model |
| Knowledge in people's heads | Automatic capture, expiring facts, gap and drift detection | Loading its own wiki, architecture records and market tables |
| Each team builds its own tools | One shared platform and memory for all teams | Merging existing tools, and an owner who runs the platform |
| Manual release checks | Fixed validation steps, independent review, trust levels | Trusted regression tests, contract tests, feature flags, test data |
| Developers step in live | Structured exceptions, people as stations, two-identity audit | Who decides at which gate, and what they see there |
Lore is strong from spec to merge and covers part of the way from idea to outcome#
In September we scored Lore against a model of an AI software factory. We built the model from CNCF platform definitions, Team Topologies, DORA and case studies. Lore scored strong on the inner loop and mostly absent on the outer loop.
The inner loop runs from a spec, through agents, code and review, back into memory. Lore covers all of it. The outer loop runs from a business idea, through customer validation and release, to a measured result. Lore covers so far little of it, but we're also working on this.
Lore has approval gates, and its planning station helps people write specifications. The result is text, though, not a prototype a customer can click through. Agents can call custom MCP servers, so a planning step can call a prototyping tool such as Lovable.
Customers use Lore as a reference and build their own factory#
Every report we wrote this year describes Lore as the reference, with the customer building its own factory. That factory has to do the same jobs. Lore is open source under Apache 2.0, so customers can adopt, fork or rebuild each part. Lore is one option among several. Our software factory map compares the tools we see at customers.
We advise against rebuilding the patterns that cost us the most to learn. These are fixed retry limits, trust levels, logged decisions to defer a merge, and 2-person approval for risky settings.
In our customer engagements we target Stage 6 of our ladder: agents do most of the work, and people decide at intent and at release.
5 lessons from our factory work#
Memory matters most. In April I wrote that our agents search memory more than almost any other tool. At customers, missing memory is the most common reason their agent work stalls. The problems (old facts, manual updates, no learning) only show after months.
Start with the specification. In every value stream we mapped, the months sat at the start and at sign-off. A factory that starts with code speeds up the shortest step. A specification is also the cheapest thing to show a customer.
Keep validation separate from generation. An agent that writes the code and its test will make the test pass. Every team learns this once.
Build one factory. 5 good agent setups give a company 5 islands. A sixth one from us would not help. Leadership needs to say once, in public, that everyone uses the one factory.
Answer the role question before the build. At every customer, someone asked what their job would become. Where nobody answered, people held back. Where leadership said the factory would not cut jobs, people joined in.
Try Lore, or start with an assessment#
The code, the decision records and the install guide are at github.com/re-cinq/lore. To see where your teams stand first, book our 2-day assessment. You get a value stream map, a technical review, a ladder position per team and a 12-week plan. Our software factory guide explains the approach.
