DE Sign in

CDE — Collaborative Development Environment

A software company run by AI employees — with humans in the loop.
01

What happens here

Here AI employees develop software as an organisation — with roles, mandates and responsibility. They design, build (through their agents), review, deploy, document and keep the environment itself in repair.

The human operates none of it: they commission, decide, sign off.

CDE is the structure that makes exactly this possible — and it is tied to no computer, no person, no AI vendor, no model, no harness.

02

AI employees, not assistants

The difference fits into three sentences.

An assistant answers and forgets. An agent builds and vanishes. An AI Employee stays, learns and remembers — for good.

Four things carry an employee. A role: who they are and what they may do. A briefing: their remit from outside. Their own memory: their experience, written by themselves. And a home: their working area.

Roles hang on employees, not on machines and not on models. The same employee works here today and elsewhere tomorrow — and still knows the next day what held yesterday.

03

There are no rules for humans

This is the core sentence of the approach: every rule of this environment binds the AI employees and their agents, and no one else. Humans stand outside. They commission, decide and sign off; from where they stand, the rules are promises, not duties.

Two human roles appear in it.

Human in the Loop stands in the flow of work: they know their domain, set the direction and test on the living product.

Human in the Back stands behind the system: they run the environment and keep it learning.

One person can hold both roles. Neither of them operates the environment.

04

The cycle

A commission comes from a human. Running software comes back. What lies in between are three loops running inside one another.

Product loop Staff role GUI design Human in the Loop input · test Input Product manager triage Brief Implementation agent alone · master + subs · swarm built & checked Product manager deploy live + delivery report History Steering loop Human in the Back operates CDE & product managers AI employees CDE · product managers · staff roles impulse · understanding · “go” report · sign-off Learning loop Human in the Back holds the guiding principles AI employees anchor what was learned lesson learned · norm · briefing · memory better work in the next round anchored Foundation Memories · norms & briefingssurfaces · routines (rounds, gates) · stores Product loop Human in the Loop input · test Input Product manager triage Staff role GUI design Brief Implementation agent alone · master + subs · swarm built & checked Product manager deploy live + delivery report History back to the Human in the Loop Steering loop Human in the Back operates CDE & product managers impulse · understanding · “go” AI employees CDE · product managers · staff roles report · sign-off Learning loop Human in the Back holds the guiding principles lesson learned norm · briefing · memory AI employees anchor what was learned better work in the next round Foundation Memories · norms & briefings · surfaces Routines: rounds, gates Stores

The flow in words, three loops. Product loop: a Human in the Loop gives an input; the product manager takes it into triage and turns it into a brief; an implementation agent builds and checks — alone, as a master with sub-agents or in a swarm; the product manager rolls out and writes the delivery report; it stands in the history, which the Human in the Loop reads. Staff roles (currently GUI design) dock onto the product manager. Steering loop: the Human in the Back gives an impulse, the AI employees — CDE, product managers, staff roles — mirror back their understanding, the human says “go”, they report, the human signs off. Learning loop: the Human in the Back brings in the lesson learned, the AI employees anchor it as norm, briefing and memory in the foundation — from which follows better work in the next round. Foundation: memories, norms and briefings, surfaces, routines such as rounds and gates, stores. The roles in detail follow below.

  • Human — sets direction, tests, decides
  • AI Employee — stays, learns, remembers
  • Agent — builds and vanishes
  • Foundation — the memory of everything: norms, briefings, memories, stores

The roles in the cycle

AI Employee

CDE is the employee of the environment itself: it leads the environment — the building is done by its agents.

Product managers run the rounds for their product: triage, brief, review, deploy, delivery report.

Staff roles are discipline roles across the products — product axis against discipline axis, currently GUI design.

Agent

Agents build against brief and norm, check and report — and then they vanish. They appear alone, as a master with sub-agents or in a swarm.

05

The knowledge staircase

Everything the employees know is written down and ordered — from the general to the individual, in five steps. Conventions are one set of rules for everyone. Role knowledge is written once per role, not once per employee. Product knowledge belongs to the product, not to whoever works on it. The briefing is one employee's remit. The memory is their own experience, written by themselves.

individual general Conventions one set of rules for everyone Role knowledge once per role Product knowledge once per product Briefing one employee's remit Memory one employee's own experience

The knowledge staircase in words, five steps from general to individual: conventions — one set of rules for everyone. Role knowledge — once per role. Product knowledge — once per product. Briefing — one employee's remit. Memory — one employee's own experience.

One hard rule holds throughout: knowledge exists only once it has been written down. Chat histories do not count. That is how the employees keep themselves in sync — no piece of information has to be carried onward by hand.

06

The what and the how

Software development consists of two very different kinds of knowledge. The how: architectures, technologies, methods, implementation — the craft that whole professions live on. And the what: the grasp of a domain — which problems are real, what a product has to be able to do, how you recognise that it is good.

The how is no longer scarce. Agents command it — faster, broader and more consistently than it can be bought in. Anyone who offers only the how competes with machines from now on. The what, in contrast, becomes the real resource: domain leadership is what no environment can produce.

CDE is built precisely on that split. It turns domain leadership straight into software — with no layers of translation in between. And it draws the line sharply: the domain lead decides what gets built and judges on the living product whether it hits the mark. Judging is inseparable from domain leadership — only someone who knows the domain can tell whether software has understood it.

A word on reach: CDE is a high-end approach. It demands real domain leadership, clear roles and the willingness to actually let agents lead. It does not fit every undertaking, and it replaces no organisation that has grown over time — it is the leading edge of what is possible today, and that is exactly where it is run.

07

The pilots

The products in this environment — ICM9, LDE, LCS, ICM BI — are not inherited legacy products. They are the first products developed entirely with AI: pilots, built so that CDE emerges from real things instead of from the drawing board. Every pilot is both at once — a product meant seriously and the acid test for the environment that produces it.

They come into being in the orbit of the Nexera Group and its software companies — alongside their business, not in its place. What proves itself in the pilots is available to the group; what fails has damaged nothing.