CDE — Collaborative Development Environment
What CDE is
Here agents develop software — not as a developer's assistants, but as an organisation: with roles, mandates and responsibility. A CTO runs the system, project leads run the products, implementation agents build. They design, review, deploy, document — and they maintain the environment itself, under the same rules that apply to every product.
The human operates none of it. They set direction, approve, judge — and let the environment run in between.
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.
The core: 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.
What carries the autonomy
Roles. Every session starts with an identity: who it is, what it may do, where it docks in. The CTO owns the system, each product is led by a project lead — with a clear write scope and a briefing in its own repository as the docking point. Roles hang on sessions, not on machines: the same role works on this PC today, on another one tomorrow, in a different harness the day after.
Ground rules. Conventions replace word of mouth. Work happens locally, is distributed over defined paths and secured by mandatory verification. Knowledge exists only once it has been written down — chat histories and memories do not count. That is how sessions keep themselves in sync: no piece of information has to be carried from machine to machine by hand.
Knowledge. All of the environment's knowledge exists as HTML: readable for humans in a browser, by double-click, without tooling — and parsable for agents like source code. This portal does not merely describe the environment, it is its memory. Whoever reads it knows what applies; whoever works in it keeps it current.
Organisation & flow
An idea comes from a human. Running software comes back. This diagram shows what lies in between.
The flow in words, three loops. Product loop: a Human in the Loop gives an input; the project lead 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 project lead rolls out and writes the report; it lands in the journal, which the Human in the Loop reads. Matrix roles (currently GUI design) dock onto the project lead. Steering loop: the Human in the Back gives an impulse, the AI Employees — CDE, project leads, matrix roles — mirror back their understanding, the human says “go”, they report, the human signs off. Learning loop: the Owner 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 project. Foundation: memories, norms and briefings, surfaces such as this portal and the loop page, routines such as rounds and gates, storage in repositories and Drive. 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, storage
The roles
Human
Human in the Loop stands in the loop from the project's point of view and is product manager and tester in one person. They hold the what — the domain competence no environment can produce — and work on the portal page of the same name: give input, read the journal, test.
Human in the Back is the technician: they can operate CDE and the project leads. They run the dialogue with the AI Employees, give impulses, set the approval gates and sign off the result.
Owner is the sparring partner of the AI Employees and owns the evolutionary learning of CDE with every project. They accompany and control what the AI Employees anchor as norms, briefings and memories.
Rule of thumb: Loop = the what · Back = operating · Owner = learning. Double and triple roles are the normal case — currently Johannes holds all three.
AI Employee
CDE is the AI Employee of the environment itself; in its briefing it carries the role name CTO. It owns norms, portal and deploy.
Project lead runs the rounds for its product: they take the inputs into triage, write the brief for the implementation agents, commit and roll out. At the end of the round they write the report to the Human in the Loop.
Matrix roles work per discipline across the products — product axis against discipline axis, currently GUI design. They work alongside the project lead on the same product; the writing is done by one of them.
An assistant answers and forgets. An agent builds and vanishes. An AI Employee stays, learns and remembers — for good.
Agent
Agents are the implementation force: they build against norm and brief, check and report. They appear alone, as a master with sub-agents or in a swarm — and in the end they all vanish, without memory.
Human in the loop
Autonomy does not mean the human disappears. It means: they stand exactly where they are irreplaceable — and only there.
- Direction. The domain lead decides what gets built: products, priorities, matters of principle. They bring what the environment cannot produce — the domain.
- Approvals. Nothing essential starts without an explicit go. And the system itself — conventions, organisation, ground rules — changes only after approval. The environment can do a lot, but it does not resolve to change itself.
- Judgement. As product manager and tester in one person, the domain lead judges on the living product whether it hits their domain — and keeps looking after it together with its project lead. Not code review: product judgement.
Everything else — implementation, consistency, operations, documentation — belongs to the roles.
Where we stand
CDE grows out of its own use: this environment is built with the same roles, gates and rules that it describes — every page of this portal was written by an agent and approved by a human. The degree of autonomy rises with every convention that replaces word of mouth with structure. What is unsolved sits openly in the working foundations of the environment — visible, not hidden.
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.