An order dashboard can look finished while counting the wrong event. Settle what the business means by an order, give the agent a way to check that rule, and inspect what happens when the rule changes. Each step checks a different part of the software you are asking it to build.
In Nate Herk’s interview Matt Pocock: What to Learn Instead of AI Automation in 2027, developer and educator Matt Pocock connects clear requirements with the code and tools an agent works with. His account of a failed spec-driven workflow gives a useful limit: a detailed description of the desired software can coexist with code that gets harder to change.
Choose an initial task with a result you can inspect and mistakes you can correct. Pocock recommends ordinary, measurable work, including drafts of routine replies. For a software trial, a local dashboard using sample records gives you behavior to observe without changing real customer records.
01Ask for the missing decisions
Tell the agent which outcome matters and why. Brief the model like a brilliant new hire covers that starting point. For an unfamiliar feature, ask the agent to interview you about decisions you have left unstated.
Pocock’s Grill Me discussion describes repeated questions that expose missing requirements. Anthropic also recommends an interview before larger features. A useful answer may be that a decision needs another person’s input.
For the order dashboard, settle:
| Question | Decision to record |
|---|---|
| When does an order count? | The event that makes it an accepted order |
| Who may see the record? | The roles allowed to read customer details |
| What happens when a record is incomplete? | The visible error or review step |
| Where will this run? | A local trial or a specified deployment environment |
| What would prove it works? | Sample records with expected dashboard results |
Questions can expose omissions; building can expose more. Keep unresolved decisions visible and revise the requirements when a trial reveals one. Power start sessions with /enhance-prompt covers reading back the request before execution.
Use the agent to explain an unfamiliar term, then inspect the cited documentation. Pocock uses teaching sessions to prepare for reading primary sources. Learn a work skill with AI covers checking whether you can apply the explanation yourself.
02Use the business’s own terms
Give a business concept the same name in the conversation, requirements, interface, and code. Pocock borrows this practice from domain-driven design, an approach to designing software around the business it serves.
The practice is called ubiquitous language, meaning a vocabulary agreed by the people who know the work and the people building the software. Microsoft’s domain-analysis guidance limits that agreement to a defined part of the business. The same word can mean something different in another department. You can use this practice in a small application without adopting the microservices architecture discussed in that documentation.
A glossary for the dashboard might be:
| Term | Agreed meaning | Boundary case |
|---|---|---|
| Draft order | A saved request awaiting acceptance | Appears in the review queue, excluded from accepted-order totals |
| Accepted order | A request the business has agreed to fulfill | Counted once when accepted, even if payment is pending |
| Paid order | An accepted order whose payment has cleared | A separate payment status, rather than a replacement definition of accepted |
Ask the owner of the process to correct those definitions before using them. Then ask the agent to find places where the code or interface uses the terms differently. If departments use the same word differently, record which meaning applies in each department and agree how to translate between them.
03Keep the code easy to change
Pocock describes trying spec-driven development for months in his custom video editor. In his account, he kept and refined detailed specifications while agents produced code from them. He saw the code and subsequent results getting worse. He changed his focus to the implementation and how easily it could be modified.
“a good code base is a code base that's easy to make changes in.”
Matt Pocock, “Matt Pocock: What to Learn Instead of AI Automation in 2027” · 28:54That is one developer’s experience with one sustained workflow. Anthropic’s interview guidance still recommends writing a specification. Keep a record of agreed behavior, then check the implementation as it changes.
For the dashboard, ask the agent to show where the acceptance rule lives and which views depend on it. When the business changes that rule, have it explain the affected code and check both the changed behavior and nearby behavior that must stay the same. A small rule change requiring edits in many unrelated places is a reason to inspect the design.
Improve your Claude Code workflow covers checking current code against stale project notes. Update the relevant requirement, glossary, and behavior checks together when an accepted decision changes.
04Let the agent run the app
Give the agent access to the application and the evidence needed to judge its work. Pocock reports better results after making his video editor runnable by the agent. Dependencies, including a local recording application, had made browser interaction difficult. Once he resolved that setup, the agent could click through the editor and capture screenshots.
Anthropic’s verification guidance names runnable tests, builds, and screenshot comparisons. Choose evidence that covers the particular requirement:
| Requirement | Evidence to inspect |
|---|---|
| Drafts stay out of accepted-order totals | Known draft and accepted records, with the expected count |
| An invalid record gets a useful error | The invalid input and the message shown in the running interface |
| A rule change preserves other behavior | Checks for the new rule and the unaffected cases |
| The trial ran in the intended environment | The services used and any dependency or access failure |
Give your coding agent a finish line covers tying those checks to completion. Record checks the agent could not run.
Pocock uses Opus 5.5 at medium effort and reports faster replies and lower token use in his setup. He connects that preference to an environment with useful checks. This establishes his preference, without measuring the best setting for your task.
Anthropic’s effort documentation describes a tradeoff between token use and capability; effort scales differ by model. Compare settings on the same task and checks, including your correction time. Recheck your model choices each release covers that comparison. A higher effort setting still leaves missing browser evidence unverified.
05Show you understand the work
A prototype should demonstrate a requirement the stakeholder recognizes. Pocock suggests building something that reflects the client’s business, while acknowledging that his existing audience limits what he can claim about competing for client contracts. Treat the prototype as evidence of understanding; production readiness needs its own checks.
For this dashboard, show how the agreed order definitions change the totals. Report the behavior implemented, the checks completed, and what remains unresolved. That gives the stakeholder something specific to correct.
06Run a small trial
Learn how to interrupt the agent and inspect its changes before broadening the task. Delegate to your agent in stages covers adding tools and unattended work after checked results.
Use this original prompt for the first trial:
I want a local prototype of [one business task] using sample data. Before editing, inspect the existing project and ask about missing decisions that would change the design. Include the user's goal, key business terms, access rules, failure cases, and how we will check the result. Wait for my answers where needed.
Write a short glossary with definitions and boundary cases. Show unresolved decisions separately. Propose one behavior we can implement and inspect, with sample inputs and expected outputs. Return the plan for review.
After I approve implementation, build that version. Show where the business rule lives, run the relevant checks, and demonstrate the behavior in the running app. Report any check you could not run. When I change a requirement, update the affected code, glossary, and checks, then verify the changed and unchanged cases.
Keep this trial local, preserve unrelated files, and use sample records. Stop with the prototype and evidence ready for my review. Ask before connecting accounts, changing real records, or deploying.