Software on Demand
Software used to be scarce: every feature was a project, every project a queue. That era is ending. A few standard components keep regulating the common business — identity, storage, messaging, compliance — but beyond them, any amount of software can now be produced on the spot, exactly when a question or a workflow demands it.
The worked example below is the whole idea in miniature: a one-paragraph spec — a plain, precise statement of what you want the software to do — and running software seconds later, with no project, no pipeline, no ticket.
What This Does to the Profession
- From developer to manager. You spend less time typing code and more time directing agents that do: setting goals, judging results, deciding what done means. The scarce skill is no longer producing code — it is specifying and verifying it.
- From specialist to generalist. When production is cheap, the bottleneck moves to breadth: architecture, data, UX, operations, domain knowledge. The broader your grasp, the more software you can responsibly commission.
- But the basics are non-negotiable. You cannot judge what you do not understand. A manager of agents who cannot read a diff (the exact before/after of a change), sense when two things running at once might collide, or notice that a promised behaviour was never pinned down as a check is a manager in name only.
Recommended Foundations
| Classic | Why it matters more than ever |
|---|---|
| Extreme Programming Explained — Kent Beck | Short feedback loops are the native rhythm of agentic work |
| Refactoring — Martin Fowler | Behavior-preserving change is THE core move when agents touch legacy code (Module 4) |
| Domain-Driven Design — Eric Evans | The shared, precise language where you, your domain, and your agents meet |
| Designing Data-Intensive Applications — Martin Kleppmann | Data-driven systems: agents thrive on explicit, typed, queryable state |
| Data Mesh — Zhamak Dehghani | Decentralized data ownership — the shape agent-era platforms take |
| Reactive programming | Streams and subscriptions — the way live systems (and this platform) are built |
And a league-change warning: the moment you integrate agents into your application, you are building a distributed system — autonomous actors, message passing, eventual consistency, partial failure. That is a very different league from building monoliths, and it is exactly why these foundations are not optional.
What You Will Learn
The standard use cases of agentic engineering — designing something new, refactoring legacy tech, modern software design — each get their own module, and the capstone revisits them end-to-end. Along the way you build the habits that make agents effective: writing down the outcome you want in a form that runs and checks itself — that is what a test is, a very formalized, precise spec (Module 2) — a consistent knowledge base (Module 3), and plans with real end criteria.
Worked Example — Software on Demand, Literally
Press Run and watch a spec become running software. Then read the code — this is the level of fluency the whole course assumes you keep.
From a hardcoded list of order lines (product, quantity, unit price), compute revenue per product — group by product, sum units and revenue, sort highest first — and render the result as a data grid with a title showing the product count.
Worked Example 2 — Software on Demand, With a GUI
The same idea, one step further: the spec now asks for an interactive surface — a table of quarterly financials driven by a Year and a Quarter selector. The selection state lives in the mesh; change it and the table recomputes reactively, server-side. The data is a plain hardcoded array — the point is how little stands between the spec and a live, working GUI.
Build an interactive table of quarterly financials over a hardcoded array of three years of quarterly line items — revenue, COGS, OpEx, and a derived net income. Add a Year dropdown and a Quarter dropdown with an All option, and have the grid refilter reactively whenever the selection changes.
Worked Example 3 — The Same Idea at Full Size
The two cells above fit in a paragraph each. Module 1 · Demo — Reinsurance Data Cube is the same claim carried through four prompts against one dataset: build a seeded reinsurance cube, slice it by line of business and year, chart the year-on-year result, then hand the reader two dropdowns and let them slice it themselves. Four prompts, four pieces of working software, no project and no pipeline.
Go there for the part these two cells cannot show: what it looks like when an agent's output has to keep agreeing with itself across several deliveries. Every cell opens with an INPUTS block, and every figure is derived from it — so you can turn one knob and watch which of the four steps move.
(It is also the demo used live in training Slot 1.1, but it is written to be read alone.)
Your turn
Three coding drills, one per weight class — pick yours from Your exercises below and work in your own editable copy:
- 🟢 Easy · 10–15 min — Predict the Behaviour. Eight calls to
Math.Round; predict every output, then run — each ✗ is behaviour you just learned to pin. - 🟡 Medium · 30–45 min — Characterize, Then Tame. Exercise 4's ugly-but-working order calculator: pin six behaviours by running it, refactor, and prove the output byte-identical.
- 🔴 Hard · 60+ min — Spec First: The Promo Engine. A promo engine specified only in prose — three stacking rules, a rounding clause, two nasty interactions. Battery first, then the code.
Prefer writing over coding? The four artefact drills — a rules page, a data model, a testing strategy, a design record — live in Module 1 — Your Turn, a first taste of Module 3 — The Knowledge Base.
Check yourself
Six quick questions on this module — instant feedback, explanations, and a score. Aim for 70%.