You can write Python
Run the supplied application and trace one request. Learn what belongs around generated code before you ask an agent to change it.
Begin with the baselineProf Rod’s lab · Build, test, inspect
Build your own dark software factory from scratch.
Turn feature requests and bug reports into tested software with coding agents. Build the workflow, run it on a small application, and learn where human decisions are still needed.
Free lessons and source code. No course account required.
- 01 · Define the change
- 02 · Build a candidate
- 03 · Check its behavior
- 04 · Release or reject
What is a dark software factory?
A dark software factory is a workflow in which coding agents implement software changes and automated checks decide whether a candidate can proceed. The aim is to reduce the human work needed for each change. Humans still choose the task, set the acceptance criteria and decide what the workflow is allowed to touch.
The software it produces can be an ordinary application. In this workshop, the application updates a synthetic customer’s contact details. There is no language model in its request path. The coding agent helps change the application; a separate checker judges what the resulting application does.
Start with a narrow question: can this workflow implement one specified change, show the evidence and refuse a bad result? A passing teaching exercise does not establish that it can maintain an arbitrary production system unattended.
Start with the work you already understand
You deliver integrations
Turn “don’t update the customer twice” into an acceptance contract. Check the receiving system’s ledger, not just the API response.
Write the change contractYou already operate AI systems
Investigate uncertain writes and test the release decision itself. A deliberately faulty candidate should fail even when it reports success.
Inspect the failure exerciseOne application · Five lessons
Build the workflow on your own machine
You’ll get a runnable Python project, change requests, acceptance checks and worked solutions. Run the reference application without a model account. To generate your own candidate, use the supplied bounded builder with a paid Claude Code account.
You need a terminal, Python 3.11 or later on the host, a running Docker engine and enough Python to follow a function that calls an API. The containers use the pinned Python 3.13 image. All customer records are synthetic. Deployment stays in disposable local containers.
The email edition is being prepared. You can start now: all five lessons and the project are available below.
-
Run the application before automating changes
Run a contact-update service against a synthetic dependency. Inspect the evidence for a confirmed write and a lost response.
-
Define a feature that a test can reject
Specify duplicate-request handling, account boundaries and restart behavior before asking a coding agent to change the application.
-
Give the coding agent one bounded change
Generate one candidate file, keep credentials outside its runtime and record every attempt without changing the acceptance checks.
-
Release the exact application you tested
Check the candidate against an independent effect ledger, then repeat the checks in a fresh disposable deployment.
-
Resolve an uncertain write and reject a faulty change
Add reconciliation, inject a false confirmation and verify that the factory refuses to release the faulty application.
Understand the decisions behind the factory
These existing articles explain the boundaries, evaluation choices and human effort that the workshop puts into practice.
Who owns the factory’s task?
Turn a customer request into a contract the builder cannot silently change.
Who can change the acceptance tests?
Inspect a test revision and challenge the checker with a faulty candidate.
When can you leave an agent working?
Choose a bounded task and decide what would make you stop it.
Who checks the builder’s work?
Give the reviewer evidence without inheriting the builder’s assumptions.
What does your test environment prove?
Design the environment around the behavior you need to observe.
Where does the human work go?
Count verification and recovery work when judging an automated workflow.
From one agent to a workflow that changes software
The always-on agent book develops tools, memory and recovery inside an agent. Here, we examine the process around a coding agent: task definition, isolated execution, independent acceptance and release. The book gives useful background; it is not a prerequisite.
