For software engineers
Software Shaped Objects
When an agent writes the implementation, what does the engineer design? In this keynote and workshop, we look at how to define what software should do, give an agent room to build it, and check the result.
The workshop’s starting point
Give it a shape.
POST /bills/calculate
- An interface that says what callers can ask for.
- A contract that defines the expected behaviour.
- Tests that compare the old system with its replacement.
- Keynote: 45 minutes + Q&A
- Workshop: 3–4 hours
- With Phil Bennett
A prepared PostgreSQL billing system, ten core exercise briefs, and tests that run against both the legacy code and its replacement.
What you take awayThe talk and the practice
Two ways to get into it.
We can start with a keynote for the wider engineering group, go into the workshop with a smaller team, or do both.
Keynote · 45 minutes + 10 minutes Q&A
Software Shaped Objects
I call the interfaces, contracts, observable behaviour and documentation the software’s “shape”. The talk looks at how engineers define that shape and check whether an agent’s implementation fits.
Workshop · 3-hour core, 4 hours with extensions
Taming a Legacy Beast
Our example billing system can produce a total, but can’t explain it. You’ll use agents to understand how it works and build a replacement that can show where the money went.
More code still needs engineering.
An agent can finish writing before you’ve finished deciding what you wanted.
You still need to know what callers can rely on, which behaviour must survive a change, and how you’ll notice when something goes wrong. That’s where I want us to spend more attention.
The keynote demonstrations
We compare two versions of a small webhook service: one built from a bare prompt, the other with contracts, tests and project instructions. We inspect status codes, rejected events and logs.
A longer agent task shows how the same approach works beyond a tiny example. We look at the instructions and checks around the run, as well as what it produced.
Inside the workshop
Follow the bill.
Then rebuild it.
Find out what’s there.
Ask agents to map the legacy system and trace a bill through its readings, tariffs and charges. Identify what the current response leaves unexplained.
Make the expectations testable.
Pin the existing calculations in tests. Define the HTTP contract and the explanation you want, then run the same expectations against the empty replacement.
Build against those tests.
Use specialist agents to write the TypeScript service. It must calculate from the underlying data; calling the old stored procedures would dodge the exercise.
Put the explanation to work.
Compare the totals and try answering a customer’s question about their bill. Longer sessions add unfamiliar scenarios and structured logs in OpenObserve.
After the session
Keep the work.
Something to try next week.
You keep the exercise briefs and your work on the system map, API contract, tests and bill explanation. We finish by choosing a small part of your own work where you could try the approach.
I’m Phil.
I’ll lead the session. Tell me what your engineers have already tried with coding agents and where they’re getting stuck. We’ll use that to decide what to spend time on.
A few things before we start.
What experience do people need?
The keynote is for engineers, tech leads and engineering managers. Workshop participants should be comfortable running terminal commands. You don’t need to know billing systems or be an expert in PostgreSQL or TypeScript. We work in small groups on a supplied project.
Which tools does the workshop use?
The current exercises use GitHub Copilot with /fleet for specialist agents, Node 20 or newer, and psql. I provide the repository and access to a prepared database. Windows users need WSL or an equivalent shell. We’ll check your team’s tools and access before the session.
How much of the legacy system do we replace?
One bill-calculation endpoint, with an explanation of how it reached the total. Payments, account balances and monthly billing runs stay outside the exercise. The tests cover the supplied scenarios; there will still be other cases to investigate before applying the approach to a production system.
Can we change the format, and what does it cost?
Yes. These are examples of sessions we can plan around your team. The keynote is 45 minutes plus 10 minutes for questions. The workshop has a three-hour core, with extensions for a longer session. I’ll quote once we’ve discussed the audience, format and preparation.
What’s your team working on?
Tell me who the session is for and what you’d like them to try afterwards. We’ll work out whether the keynote, workshop or a combination makes sense.
Plan a session