35 min read
The Software Factory
How we are building an in-house autonomous software delivery framework
Mario Jurić · Posted on September 1, 2026
I. Writing code stopped being the constraint. Holding one standard across a team is what replaced it
For seventy years the scarce resource in software was the writing of it. That constraint is gone. A competent model produces thousands of lines in minutes and the marginal cost of a line of code has fallen toward zero.
The question we wanted to answer is whether an agency of our size can encode its engineering judgement into something that then builds software autonomously, at the standard of quality a competent human team holds. The whole lifecycle, not only the code. A year in, the answer is mostly yes. The engine is called Nucleus, it is now the foundation for everything we deliver.
Writing code was never the hard part anyway. The hard part was producing software that is maintainable, accurate, secure and durable, at scale, with everyone involved holding to the same level of rigour. Every methodology we ever invented, waterfall, agile, pair programming, the 10X engineer, was a way of arranging distinct roles so that they produce one coherent result. Agencies like Upheave exist because we became good at that, on the operational side and the engineering side both.
That arrangement is coming apart too. Designers ship finished applications end to end. Engineers take on product ownership. Coordination layers that used to be structural are gone. Removing them does not make a team faster, it makes it inconsistent, and something has to hold the standard the old hierarchy held. It cannot be another document asking people to be careful.
Before the word harness was popular, and before Claude Code existed, we were building on top of AI automation to produce outcomes an agency of our size has no business producing. For the past year we have worked on an in-house delivery engine that leans fully into AI assisted code generation, infrastructure and project delivery.
II. Why we built Nucleus: one standard of software delivery across every live project
There are several reasons. The most durable one is curiosity: can we engineer a system that builds software autonomously at the level of a competent human team? The whole lifecycle, intent, prototype, development, maintenance, and around again.
The second is consistency. Every software agency lives with skill proliferation. We want every project executed to the highest standard, and that is genuinely hard, because software is long lived. Different people work on different things. Skill levels differ. Timelines and constraints differ. Technologies differ. Older projects carry maintenance requirements that newer ones do not. Available resources shift. Even a small change in team composition produces different results and new friction. The goal was to move as much of that as possible into one rigorous harness, so that every project we deliver carries the same level of delivery excellence. We believe this approach can scale to any number of projects in parallel.
The third is subjectivity, in the engineering work and in everything around it. Engineers hold strong opinions about how to build and what to build with. In principle that is a healthy mechanism for improvement. In practice it burns an enormous amount of time and energy on every single project. One of our goals was to institutionalise a set of decisions, axioms, and to make sure they propagate and are enforced across all of our work. This creates its own friction and its own margin of error. It also speeds up delivery while holding quality where we want it.
III. The software factory failed in 1968 and again in 2001 because the line had blueprints and no electricity
The phrase has a lot of historical baggage, and most of the people who use it as an insult are missing half the story.
Bob Bemer proposed the concept in 1968 while at General Electric, in a position paper on the economics of program production: apply industrial manufacturing principles to code. Hitachi took the name literally the following year and opened its Software Works in 1969, the first organisation to actually call itself one. System Development Corporation built its own in Santa Monica in 1975 and published the design in Computer. NEC, Toshiba and Fujitsu followed in 1976 and 1977. Michael Cusumano documented the whole arc, and what the Japanese factories achieved was real and bounded: reuse libraries, standardised tooling, measured defect rates, and a career structure that kept the expertise inside the organisation rather than inside individuals. They ran for roughly two decades. The American attempt did not last as long.
Then the industry chased the same ideal on worse terms. In the 1990s the factory meant offshore body shops, scaling output by treating large pools of human developers as an assembly line under rigid top down process control. By 2001 architects tried again with Model Driven Architecture, using complex diagrams to generate mounds of unmaintainable boilerplate Java. Those attempts stalled because they relied on rigid graphical models and lacked the cloud native infrastructure needed to automate the resulting deployments. They had blueprints for an assembly line and no electricity to power it.
A factory is not a building full of workers. A factory is an encoded process: an arrangement of jigs, tolerances, stations and inspections designed to guarantee that good output emerges regardless of who is on shift. The expertise lives in the machinery of the line, not only in the heads of the operators. You can hire a new worker and the line makes their output excellent, because the line refuses to let a bad part advance.
That vision is finally possible because we stopped trying to make humans work like machines. Translate the metaphor faithfully into software built by AI agents and you get four parts.
The workers are AI agents. They operate on a goal in, outcome out model. They are fast, tireless and highly capable, and completely indifferent to your architecture unless something forces the issue.
The jigs and tolerances are platform boundaries. The immutable rules of the environment: which module may import which, what vocabulary the core is allowed to speak, where a foreign key is permitted and where it is forbidden.
The inspection stations are deterministic gates. Not code review as a suggestion. Automated enforcement that blocks a defective or hallucinated component from moving to the next station.
The process knowledge is executable code. Architectural judgement that normally sits in a senior engineer's intuition, written down as rules and guardrails that travel with the line.
Nucleus is that line, rendered as a repository you can clone. It does not describe the factory. It is one, and it builds itself. The agents that build features in Nucleus are the same agents Nucleus distributes. The rules those agents obey are enforced by machinery that ships in the box.
IV. The more rules you write into CLAUDE.md, the less reliably the model follows any of them
Our rules lived in an AGENT.md and a CLAUDE.md file, the standing instructions a model reads at the start of every session. We kept adding to them and the agents kept breaking them, so we audited our own instruction file against the published research on how these models actually follow instructions.
The more rules you stuff into your instructions to make the AI reliable, the less reliable it becomes.
The mechanism is attention dilution, and it has been measured. Distyl AI's IFScale benchmark, published July 2025, tested twenty models across seven providers on between ten and five hundred simultaneous instructions. The strongest performer, gemini-2.5-pro, held 100% at ten instructions, 98.4% at a hundred, 84.8% at two hundred and fifty, and 68.9% at five hundred. That was the best result anyone posted at maximum density; every other model did worse. The paper also found that models favour instructions appearing earlier in the context, which is a polite way of saying the rules at the bottom of your file are decoration.
Anthropic says the same thing about its own product. From their June 2026 guidance on steering Claude Code: "Claude will follow the instruction most of the time, but when under pressure, in a long session or an ambiguous situation, or due to a prompt injection, the model can fail to follow a prompted rule." Their conclusion is the one we reached independently: "A real guardrail needs to be deterministic, and the enforcement methods are hooks and permissions."
A hook is different in kind. It is a shell script the harness executes at a fixed lifecycle event, and it blocks the action regardless of what the model decides. A rule like never run rm -rf, written as prose, is followed most of the time. The same rule implemented as a hook is followed every time, because compliance stops being the model's decision. Prose compliance sits in the worst possible place: high enough to feel safe, low enough to hurt you.
That gap is the difference between a suggestion and a guarantee, and it does not close by writing the rule more emphatically, in bold, three times. When we audited ourselves we found we had been doing exactly that: over a thousand lines of always on rules loading before a single conversation began, the same prohibitions restated four different ways, a pre-response checklist, a routing tree, an agent roster, a list of violations to catch, each repetition diluting the genuinely load bearing rules sitting next to it. The playbook meant to make the system reliable was the thing making it unreliable.
The fix was not more discipline. It was a theory of layers that assigns every rule to the mechanism that can actually enforce it, and forbids restating it anywhere else.
| Layer | Reliability | What it is for |
|---|---|---|
| Hooks | Deterministic, 100% | Safety rails and gates. Things that must happen every time, no exceptions. |
| CLAUDE.md | Probabilistic | Compact always on memory: identity, routing, the few conventions that touch nearly every task. |
| Path scoped rules | Probabilistic, lazy | Domain knowledge that loads only when a matching file is touched. Free until relevant. |
| Skills | On demand | Self contained workflows the model invokes when the task calls for them. |
| Subagents | Isolated context | Specialized focus, parallel work, protection of the main context window. |
The same five surfaces appear in Anthropic's own guidance.
From this falls a single decision procedure we apply to every rule we have.
Does the model follow it 100% of the time already? Leave it as prose. Done.
Less than 100%, but the consequences are bounded? Leave it and accept the drift.
Less than 100%, and the consequences matter? Make it a hook. Deterministic prevention or deterministic verification.
A workflow that only matters sometimes? Make it a skill.
Domain knowledge that only matters when touching certain files? Make it a path scoped rule.
The instruction file is not the whole game, and treating it as one produces a scroll of increasingly desperate commandments. We treat prose instructions as the least reliable layer available and push anything that actually matters down into machinery that does not care what the model feels like doing. The prose is reserved for what it is good at, orientation and memory, and stripped of everything a machine can guarantee instead.
Most of the time against every time is where production incidents live.
V. Eight named agents, eight deterministic gates, and a hook that stops the orchestrator when it reaches for the keyboard
Nucleus runs on an orchestrator pattern. The main conversation never writes code. It is a foreman: it reads the request, decides which specialist the work belongs to, and dispatches. If it forgets and reaches for the keyboard itself, a hook named orchestrator-guard blocks the edit and reminds it to delegate. The instruction never write code directly is not trusted to prose. It is a station on the line with a gate.
The specialists are a roster of named agents, each with a jealously guarded lane.
| Agent | Lane | Boundary |
|---|---|---|
| captain | Project manager. Roadmap, initiatives, cross cutting decisions | Consulted before substantial new work begins; a gateway hook checks the transcript to make sure it was |
| archie | Database. Schema and migrations | Never business logic |
| donnie | Backend domain logic: use cases, repositories, the pure core of a feature | Stays out of the web layer |
| nexus | Server side of the web app: data fetching, auth, server actions | Everything that must exist before a pixel is drawn |
| frankie | Frontend: components, JSX, styling | Forbidden from touching a route nexus has not already prepared |
| spec | The scribe. Maintains a SPEC.md per unit of work as living memory | Writes no code |
| auditor | The inspector. Reads every change against the rules and returns a verdict | Grades against the same file the implementer was handed |
| infra | The operator. Local stack, environments, deploys | Irreversible acts wait on a typed human string |
It is an assembly order enforced as architectural law. You cannot bolt on the door before the frame exists.
Every station ends in an inspection performed by a machine rather than by a person's goodwill. A partial catalogue of the gates that ship in the box:
| Hook | What it blocks |
|---|---|
orchestrator-guard | The foreman writing code instead of delegating |
architecture-guard | Architectural boundary violations, checked at write time |
frankie-scope-guard | The frontend agent touching files outside its assignment |
captain-gateway | Implementation beginning before the PM was consulted |
stack-commands-guard | Raw docker compose and next dev; routes to the uniform stack CLI |
schema-migration-guard | Destructive database migrations. The pipeline applies them under supervision |
auditor-trigger | Any attempt to end a coding session without the architectural review running |
build-check | A session ending with type errors. Runs the type checker on stop |
Every one of these hooks was added as a result of our agents and skills not following instructions as they were laid out. Adding more instructions, more bold "DO NOT REPEAT" text did not help.
Pragmatic advice here is don't try to assume where the problems will be and don't create hooks and deterministic guardrails in advance. Constantly monitor what your agents are doing and where they don't follow instructions. Then methodically and surgically add deterministic guardrails to mandate desired behaviour. You are then even free to remove the text instructions altogether.
Unfortunately, this does not always mean 100% compliance as AI is very good at finding ways to avoid deterministic instructions, like using different naming scheme, creating new layers of architecture to circumvent your restrictions. This means that hooks and other deterministic guardrails also need to be verified and constantly tightened.
It took us about six months to get to a point where we tamed all of the creative ways AI models were able to circumvent these guardrails and we're now seeing very reliable outcomes for the guardrails in place.
The deterministic gates and the final auditor that verifies if the gates are respected must have the same source of truth. We solved this by applying rules primitive in the agent, in the auditor and in the deterministic gates. This was not always easy as some instructions are abstract and can't easily be implemented as a deterministic check. That is the sole reason why these gates need to be audited and constantly refined.
The agents have personalities tuned to their jobs. The infrastructure operator is written as a grizzled site reliability veteran who thinks in blast radius, reversibility and time to detect. A persona is a compression of judgment, a fast way to load an entire posture of caution or rigour into an agent's behaviour, and we use it as one.
What these gates catch is structural. A change that violates a boundary, skips a station or breaks a type does not advance. A change that is structurally perfect and functionally wrong still can. That problem is not solved.
The underlying pattern never changes: for anything whose failure actually matters, do not ask the AI to remember. Build a gate that does not depend on memory. A model should never do arithmetic a script does perfectly, and a script should never make a call that needs taste.
VI. The core has no User, Organization or Role in it: an agent presents a key, it does not log in
Enforcement machinery only helps if there is something worth enforcing. The rules the gates check start with the nouns, and Nucleus begins by throwing out the ones the SaaS industry has used for thirty years.
The old vocabulary, User, Organization, Role, Login, encodes an assumption: that the thing acting on the system is a human, sitting at a screen, belonging to a company. That assumption is now false often enough to be dangerous. An AI agent provisioned to reconcile invoices at three in the morning presents a key rather than logging in, operates inside a boundary rather than belonging to an organization, and holds a precise and auditable set of permitted actions granted by a human who remains accountable for it. Not one of those four nouns describes it.
So the Nucleus core speaks in abstractions instead.
Principal is any entity capable of action: a human, an AI agent, a background worker. The core treats them as equal, because in the AI era they are.
Credential is proof of identity in whatever form it arrives: a password, an OAuth grant, an API key, an mTLS certificate.
Tenant is an isolated data boundary. Just the walls.
Context is short lived execution state. What used to be called a session, renamed to admit that it is ephemeral by design.
Policy and Entitlement are the exact permissions a Principal holds, expressed as a question the system can answer directly: can Principal X perform Action Y in Tenant Z? A computable grant rather than a rigid role.
Business meaning, this Tenant is a financial portfolio, this Principal is a doctor, is only allowed to exist at the outermost application layer. The core is kept aggressively ignorant of what it is being used for, because that ignorance is what makes it reusable across a thousand unknown future applications. A module that knows it handles doctors cannot be dropped into a logistics company. A module that knows only Principals and Tenants can be dropped anywhere.
VII. Seven axioms, every one trading convenience today for the ability to throw the code away tomorrow
To get reliable outcomes from an AI centric delivery system you have to become opinionated.
Terminology, architecture, design patterns, language, infrastructure and even core philosophy have to be ruthlessly selective. AI is perfectly capable of producing code in any language, architecture, pattern and style, and unless strictly confined it will do exactly that.
Years ago we decided Upheave would be centred on business outcomes and value rather than on technology. That meant optimising to be extremely efficient in one core stack instead of average in several. Nucleus reflects that completely. It is not a general purpose coding harness. It is a specialized set of protocols encoding the expertise we developed over years and across every project we delivered in our core stack.
On top of the stack itself, Nucleus enforces a handful of engineering axioms that make the foundation scale to any kind of software we produce.
| Axiom | The rule | What it trades |
|---|---|---|
| Isolation | A core module never imports another core module, or any application module | Verbose cross module features today, for a module you can rip out tomorrow |
| Orchestrator | Cross module work is coordinated only by the outer application layer, which opens a single shared transaction and passes it down. Modules never call each other | Indirection, for the absence of a dependency graph |
| Agnosticism | The core contains zero business terminology. Principals, not users | Readability in one domain, for reuse in any |
| Data sovereignty | Cross boundary references are plain text IDs, never hard foreign keys. Every module owns its own schema | Referential integrity at the database, for module disposability |
| Deferred deletion | User facing deletes stamp a deleted_at. Physical destruction is an asynchronous reconciliation job | Harder deletion today, for recoverability |
| Zombie shield | No read query is written raw. Every read passes through an interceptor that hides soft deleted rows | A layer of indirection, because a developer will eventually forget the WHERE |
| Edge verification | Authorization is a stateless JWT verified at the edge, not a database lookup per request | Revocation latency, because a fleet of high frequency agents would flatten a re-authenticating database |
Read together, these are really about time. Every axiom trades a little immediate convenience for the ability to change your mind later, cheaply. Soft links make deletion harder today so that a module is disposable tomorrow. Isolation makes cross module features more verbose today so that any single module can be ripped out and replaced tomorrow.
Nucleus is built to make throwing code away safe.
The whole architecture is engineered around the certainty that AI will generate an enormous volume of code, and the matching certainty that most of it will need to be thrown away. Nucleus is built to make throwing code away safe.
The last axiom is progressive extensibility. A project can adopt the full suite, or just the agents, or one core module, or all of them. Each piece operates in isolation and compounds when combined. Nucleus does the most when everything is used, but it enforces no adoption rules.
VIII. One nucleus update pushes a new rule to every project, and the projects now push rules back
Propagation is the fundamental capability of Nucleus. It was the primary primitive, in place before agents or core modules were ever considered.
Nucleus is three things:
A central repository with primitives for distributing across multiple projects progressively.
An AI delivery pipeline composed of agents, rules, skills and instructions.
A set of agnostic, pre-built core modules that compose functional foundations.
Without a means of easy propagation the best agents and the most advanced modules would be useless.
The mechanism is a command line tool, nucleus, which works as a source copy package manager. It copies actual source files out of a central registry into a receiving project. Nothing is locked.
Propagation matters most because Nucleus was always meant to be an iterative engine. Some of our agents have been rewritten several times. We constantly fine tune instructions and adapt to changes in the tools and primitives our agents have access to. Without an easy way to push all of that from a central repository it would be impossible to keep the same operating system across every project we run.
Any change in the core repository is applied to any project with a single nucleus update, and we encoded a process around it to keep delivery backward compatible.
Nucleus treats the way we build software as a versioned, distributable artifact with a release channel. When a new failure mode teaches us a new rule, that lesson can be pushed to ten projects or a thousand with the same command that pushes a bug fix. The methodology has a version number. That is the difference between industrialising software development and merely accelerating it.
It also enabled something we did not plan for. In-project agents now report issues upstream to the Nucleus repository when they recognise that the resolution should not be local but global, after which it is distributed to every other project sharing the same problem.
IX. Roadmap, decisions and specs live in the repo, and state.json is compiled by a script no human writes
One of the hardest problems in software delivery is keeping an honest historical record of what was done alongside a live view of the roadmap and priorities.
Historically this lived, for good reason, in a separate set of tools, processes and roles that organised knowledge, decisions, initiatives, specifications and the rest of the institutional memory that keeps everyone in sync. Ours sat in a project management tool disconnected from the code, tended by humans, perpetually out of date and quietly fictional. Nucleus folds it into the repository and puts a machine in charge of keeping it honest.
The structure has four layers, each with exactly one owner, and the fences between them are load bearing.
Leaves. A SPEC.md per unit of work, the living working memory of a single change, owned by the spec agent.
Spine. The committed plan of record: a roadmap, numbered INITIATIVES that group the leaves, and numbered DECISIONS that capture cross cutting architectural calls. Owned by the captain agent.
Index. A single file, state.json, that no human writes. It is compiled from the spine and the leaves by a zero dependency script that runs automatically after every file edit and at the start of every session.
Verdict. The auditor's architectural review, written into dedicated blocks inside each SPEC.
This defines more than a WHAT. It defines the HOW and the WHY. The DECISIONS ledger of every project records why things are the way they are, whether the reason is architectural, operational or functional.
There is no perfect way to structure this knowledge, but keeping it inside the source repository has clear advantages. Documentation evolves at the same time as the software. We made it very hard for the two to drift apart.
The cost is that it changes how a team operates. Either the PM becomes familiar with engineering tooling and learns the basics of git and the procedures around code delivery, or the engineering team becomes more product aware and drives the work from a higher level. Both work. We chose the second and pushed our engineers to become more product centric.
Agents are tireless, fallible and superhumanly fast, so they will drift. The only defence that scales is machinery that makes the drift visible.
X. Identity from the checkout path, not the branch: three weeks of orphaned containers taught us the difference
There is a category of project that gets the architecture beautiful and the operations feral: the code is a cathedral and running it locally is a knife fight with Docker. We refused the split. The environment, the database, the ports and the deploy are a product, held to the same standard as the code.
The instrument is a single command, stack. What it guarantees:
Uniformity. Every project on the machine exposes identical verbs: stack up, stack down, stack logs, stack psql, stack doctor. We run ten or more projects and switch between them hourly, so a bespoke incantation in any one of them compounds across all the rest. Raw docker compose and next dev are not discouraged, they are blocked by a hook and rewritten.
Isolation per worktree. Check out a second branch into a second directory, run stack up, and you get a separate volume, network and deterministic port range. No collisions, no configuration.
Identity from path, not branch. We computed instance identity from the branch name until we found stack down reporting success while orphaned containers kept running. Three weeks of them, on a branch nobody was watching. Identity now comes from the physical checkout, recorded as a DECISION.
A registry that is the truth. Ports are hashed into a range and probed until genuinely free, then claimed in a machine wide registry. A dashboard reconciles that registry against Docker continuously and distinguishes nothing is running from Docker did not answer. Treating indeterminate as empty is how a reconciler prunes the world.
A workbench for agents. An agent that wants to try something disruptive gets a sandbox: zero host ports by construction, time boxed to an hour, garbage collected. The human's primary stack is untouchable.
Verbatim gates on destruction. No agent wipes a volume, resets a tree or force pushes on its own recognizance. Each irreversible act waits on an exact string a human types: yes drop the database. Anything reversible, the machine may do. Nothing irreversible without a hand on the switch.
XI. What it costs: PR review became the bottleneck, and automated outcome verification is not solved
The change is drastic. Everything under us is moving fast and Nucleus is our attempt to capture the most value in the new paradigm, which requires rapid and dramatic adaptability. It enforces a mindset and prescribes protocols, and although it is built to be adaptable and extensible, some flexibility is lost. Much of the work a developer used to do has shifted to an agent, and with it a certain personal identity in the work. That takes getting used to. We have seen people move to other domains because they could not adapt, or because they no longer found the fulfilment they used to.
PR burnout. The volume of generated code makes the pull request process close to impossible. The human is now the bottleneck. There is no real solution at the industry level yet, but our bet is that the classic PR flow will have to change and that new ways of assessing quality will have to replace it.
Automated outcomes verification is not a solved problem. AI is excellent at producing hundreds of green unit tests that test nothing. Any approach where AI assesses itself yields limited reassurance, because the model optimises for success rather than for finding failure. We have tried several ways to automate outcome verification at scale and with high accuracy. It is not there yet.
Process eats tokens. A rigorous process means every change goes through several layers of delivery: planning, orchestration, development, then audit. Anything can fail at any layer or take multiple iterations. That costs time and tokens, and choosing the right model with the right constraints at each step is operational work we improve constantly.
Prototyping is not easy. The flow Nucleus enforces is rigorous, and rigour is not what free form exploration needs. For very early ideas we avoid Nucleus entirely until things crystallize enough to be worth formalising.
Keeping up with models and harness primitives. Parts of Nucleus predate Claude Code. The first code generation harness we used was aider. We moved to Claude Code early and have adapted through every change it introduced, from subagents to skills, rules and hooks. Our harness sits on top of a harness that keeps evolving.
Sticking to your decisions. With breakthroughs in models, tools and harnesses landing on a near daily basis, holding a course is difficult. Did we choose the right stack, the right model, the right harness? Are we missing something? Staying convinced that a long term choice was correct is a daily decision, not a settled one. We stay in the loop constantly, but steadfastness has a cost.
Code reuse. Generative AI is generative. It optimises heavily for producing code, not for reusing it. Getting the harness to make good decisions about when to reuse, when to extend and when to write something new is a constant struggle.
XII. Are you ready for a software factory?
The Factory becomes the job. In principle it becomes the most important job.
Building the Software Factory requires a constant, deliberate effort. Make a bad decision and it propagates at the speed of light. Leave it unattended and it can stall months of progress.
The Factory moves fast in whatever direction you point it, which means bad outcomes proliferate just as quickly as good ones. It requires deliberate care and at least one person to take the lead, coordinate efforts, listen to feedback, make tradeoffs and decisions and ultimately evangelise adoption.
This is not something that just happens, and it does not happen overnight.
If you encode processes that are unpolished or bad they will compound. That is the failure mode. Bad strategy, bad architecture, bad engineering, bad infrastructure. But at human execution speed there are ways around it, and in due time many projects finally land where they are supposed to.
A Factory will break as soon as it starts if you don't have good processes.
Understand that the factory will probably fundamentally change every six months due to rapid iteration, new primitives and constant advances in AI model capabilities.
But looking ahead, our bet is that there is little else left to compete on, and that the autonomous factory becomes the job.
XIII. Is it working? Every project in the past year is built on Nucleus, and the projects now force Nucleus to evolve
In the past year every project we have delivered, external and internal, has been built on Nucleus. As Nucleus evolved the projects evolved with it, and in practice the demands of the projects forced Nucleus to evolve. Every new capability was propagated to the projects that needed it.
At the time of writing we have five large projects that are either in production or in late development running on Nucleus, and a dozen internal tools and experiments that are early bets.
Nucleus has an average weekly release cycle where we tweak the agentic harness, add core modules or introduce new experimental use cases. Most of the projects are running latest Nucleus capabilities.
We've integrated Nucleus in our CI/CD pipeline and we have early signs of closed loop where trivial fixes are implemented with engineers doing only final review and acceptance. We are progressively letting Nucleus work on more complex problems autonomously.
The concrete version of that, from the one project we have written up in public: Mailoo, the drip campaign engine we built with no interface at all, took eight hours of human specification, and Nucleus built and delivered the working system from that spec in two to three days. Mailoo was internal R&D: not deployed, no customers, no production traffic. That is one project and one shape of problem, and an illustration of what the line does on a well specified brief.
The delivery engine makes sure all of these projects are held to the same standard of quality we want to enforce across our organisation, and for the first time ever it truly looks like all of our projects are the product of the same, cohesive team. Every engineer can easily swap projects and stay in the same familiar ecosystem.
Every project retains the ability to override anything Nucleus prescribes. In practice most of what Nucleus provides gets used, and when something is missing it is built in the project first and then delivered back into Nucleus if it has value for other cases.
The work is not done and probably never will be, but there are near term improvements we expect to change the way we work again.
Nucleus today is engineer first. We still use it primarily through a terminal. The direction showing the earliest signs of value is a conversational interface on top of the harness that lets non-developers collaborate on delivering software. In principle it is similar to what Lovable, Replit and other code generation tools provide. Our bet is that the process underneath ours is rigorous enough to keep delivery on par with, or better than, an expert human engineering process.
XIV. Our bet: when writing code is free, the advantage goes to whoever owns the line
When writing code is free, the advantage goes to whoever owns the best factory. Applications are cheap to generate and cheaper to clone. Everyone rents the same models. What compounds is the line itself: senior engineering judgment written down as something executable and distributable, improving from one upstream so that every project running it improves at once. We are not trying to build a product with Nucleus. We are trying to own the process the way a manufacturer owns a line rather than any item that rolls off it.
For seventy years the bottleneck was writing the code. The code writes itself now. The bottleneck is everything else: the structure it lands in, the boundaries it respects, the truth about whether it works. Nucleus is a partial answer, and the parts still missing from it are the ones nothing has broken badly enough yet to teach us. But it enforces its rules instead of stating them, and that is the difference we are betting on.
