Chapter 10 of From Copilot to Colleague asks what survives when models and tools turn over. In my original note, I pointed to an idea from Al Harris and the Kiro team at AWS: use specifications to describe what a system should do, rather than prescribing every implementation detail.
The attraction is practical. A model can change. A framework can change. The behaviour people rely on should remain something the team can describe and check.
Make the intended behaviour inspectable
A request such as “improve the booking flow” leaves most of the important decisions unstated. It does not explain what is wrong, what success looks like, or which existing behaviours must be preserved.
A specification can make those decisions available to the implementer and the reviewer. It should explain the trigger, the expected result, and the conditions under which the result must hold. It should also say which questions are still open.
This does not require a large document. It requires enough precision that two people can discuss the same behaviour rather than imagine different versions of it.
An example: changing a meeting time
Consider a scheduling tool. “Handle timezones correctly” is a reasonable intention, but a poor acceptance criterion. An implementer needs to know what the user is changing and what should stay fixed.
An illustrative requirement could be: when a participant changes their display timezone, the meeting keeps the same instant, while its displayed local time changes. Changing the timezone must not silently reschedule the meeting.
That statement gives the team a behaviour to test. It leaves room to choose the date library and state-management approach. It also makes a review more concrete: did the implementation preserve the instant, or did it change the event?
Keep the specification close to the evidence
A specification is useful only while it describes the intended product. When a decision changes, the document and its checks should change with it. Otherwise, an assistant can follow the document accurately and still produce the wrong behaviour.
I find it helpful to think of the specification as part of the working system: a place where intent can be reviewed, disagreements can be resolved, and tests can be connected to a reason.
The goal is not to write enough prose to eliminate judgment. It is to give judgment something concrete to work with.
Why this belongs at the end of the book
A book about AI engineering can become dated if all its value rests on the names of current tools. I want readers to leave with ways to reason about the work after those names change.
Describing a desired outcome clearly is one of those habits. So is checking whether the delivered result matches it. Together, they make it easier to adopt a new assistant without handing it an undefined problem and hoping its interpretation is the right one.
Read From Copilot to Colleague for the source-backed discussion behind the book.