On The Playground, a community platform built by The Spark, an architecture rule prohibited a practice that several dozen files nevertheless used. The instruction was confidently worded. When checked, it proved wrong: the prohibited practice was how the framework normally worked.
This episode raises a question that goes beyond prompt quality. When we delegate writing code to an agent, how do we know whether the rules we give it are right? And how do we check that it follows them?
Staying in control of the product depends on this too. It requires understanding choices, being able to discuss them and having ways to examine their consequences.
Understand the decisions that shape the product
We can start with the questions the team needs to be able to answer. Where is the data? Who can view or change it? Which part of the product implements a business rule? What happens if an external service stops responding? How can a change be reversed?
These questions connect architecture with use. The answer cannot always be found on a screen or in an agent’s general explanation. It may require examining a configuration, running a test or looking at a specific part of the code.
In building The Playground, we have delegated code writing and systematic code review to agents. Intent, trade-offs and validation of user journeys remain human responsibilities. This is an experience in a specific context, drawing on extensive technical and product experience. It does not make expertise in reading code redundant, particularly when investigating a defect or examining a sensitive issue.
The challenge is to choose what we need to understand and the level of evidence required, rather than equating the amount of code reviewed with the control achieved.
A convincing explanation still needs checking
An agent can explain why a solution should work. That explanation is useful for discussing a proposal. It does not, on its own, demonstrate how the system behaves.
The incorrect rule in The Playground is one example. We could have asked the agent to enforce the document, then made repeated corrections to the code. First, we needed to return to how the framework worked and examine the contradiction.
This means preserving the reasons behind decisions. A rule that includes its purpose is easier to reassess. If it aims to prevent direct data access from certain parts of the product, we can examine that specific risk. An absolute prohibition without an explanation leaves less room for discussion.
Official documentation, observed behaviour and product constraints provide ways to challenge a proposal. A second agent can help look for an error, but its agreement is not inherently independent evidence.
Turn some rules into checks
Once a rule is established, we can look for ways to check it automatically. A linter, for example, analyses code to flag certain prohibited or inconsistent constructs. It can make a deviation visible with every change, instead of relying on a reminder of an instruction.
The agent needs access to this check while it works. The message should explain what is wrong and, where possible, refer to the reason for the rule. The agent can then correct its proposal before submitting it.
An automated check is limited to what it examines. It may miss a case or block a legitimate exception. We therefore also need to check the check itself, define its scope and decide who can approve an exception. An agent free to change both the rule and its test could make the alert disappear without solving the problem.
Security rules in particular require permissions to be enforced technically. OWASP’s guidance on agent security highlights the importance of restricting permissions and controlling actions. An instruction alone does not constitute an access boundary.
Retain judgement where it is needed
Not everything can be reduced to an automated verdict. An architecture can follow conventions and still be unnecessarily complicated. A user journey can pass tests while demanding too much effort from the user. A feature can be correctly built and still not deserve its place in the product.
These choices require us to weigh the available evidence against the objective. Why add this abstraction? What change will it make easier? What does it cost now? The answer may lead us to keep the proposal, simplify it or seek specialist advice.
This is also what teams need to learn to pass on. Decisions and their rationale allow someone else to take over the product without depending entirely on the conversation that created it.
Building with AI shifts some of the effort towards organising understanding and verification in this way. Our Build digital products offer brings these requirements into design and delivery. They can also become a focus for training engineering teams.