The Playground is a product built by The Spark: a platform for bringing communities together around their events. People can create a community, organise a gathering and keep participants connected. The product is in production. It has also led to a white-label version for a private club.
Building it with Claude Code, described in an earlier account of the experience, directly informs our work at The Spark. A live product gives us a way to test how we design with AI, delegate implementation and check the results.
Behind this product, one person makes the decisions and organises the agents’ work. This practice draws on product and technical experience. It cannot be transferred unchanged to every team. It does, however, provide a concrete example of what we call an agentic software factory: a system of agents, tools, knowledge and checks organised around building the product.
To understand how it works, we can follow a real request: allowing several communities to come together under a shared page.
An idea that still needs decisions
The Networks feature (“Réseaux”) grew out of a need to group communities together. At first, the idea could be expressed in a few words: something like a federation that would let them be presented together.
That description leaves many questions open. Who would this grouping serve? What connection should it retain with the existing communities? What should be visible at this new level? What would it mean for data and user journeys?
The conversation with the agent helps explore these questions. It can examine what already exists in the product, suggest options and explain their consequences. Knowledge of the organisers and the product intent guide the choices. An agent’s suggestion remains a suggestion: asking about a feature is not a decision to build it.
This distinction is written into the working rules. It lets us explore an idea without discovering, a few minutes later, that implementation has already begun and needs to be undone.
See the user flow before building it
An interactive mockup then makes the choices visible. We can move through the screens, examine where information sits and understand what the user will be able to do. Some ambiguities become obvious as soon as we try to navigate.
The lower cost of giving ideas this form makes alternatives accessible. We can compare several ways of organising a screen before choosing which one to develop. This still takes time and judgement: a convincing mockup can still be a poor answer to the need.
The agent then writes the specification based on the discussions. It describes the expected behaviour, the decisions made and the limits of the scope. The person responsible for the product reviews and corrects it. It gives later sessions a more stable reference than the memory of a conversation.
On The Playground, these documents live in the product repository alongside the code. The agent can find the mockup, specification and decisions where it works. This memory still needs maintenance: an old document can contradict a recent decision, and a written instruction can be forgotten or misunderstood.
An agentic software factory that retains context
The coding agent has access to architectural rules, project conventions and ways to check its changes. Commands group recurring operations, such as preparing a mockup or comparing a specification with what already exists. Specialist reviews examine different aspects of the implementation.
This organisation makes continuity between sessions possible. The model can produce code; its environment helps it place that code within a product, understand the constraints and find out what remains to be done.
In technical terms, part of this environment is called the harness. Our notion of an agentic software factory also includes the product work that feeds it: where the request comes from, the criteria for decisions and how we assess what has been delivered.
Anthropic’s work on long-running agents also describes the importance of retaining a usable state of work between sessions. This aligns with our experience, but does not prove that a particular architecture would suit every product.
Autonomy remains bounded. An agent can prepare a change and run checks. Decisions that affect the product, access rights or a deployment remain explicit. Instructions describe what is allowed; permissions and the technical environment must also enforce those limits.
Check what has been built
For Networks, as for other features, the work goes through several types of checks. Some detect technical inconsistencies. Others test a business rule or run a user flow in the browser. Reviews look for defects and side effects.
These checks answer different questions. A test can confirm that an operation works with the expected data without showing that the screen makes sense to users. A review can spot a risk in the code without finding that the sign-in flow fails on a particular device.
As the work continued, these limits became very concrete. Checks carried out with an administrator account concealed a problem encountered by an ordinary user. An interrupted user flow was worked around during a check, even though that interruption was precisely the defect that needed to be understood.
These incidents changed the practice: run the complete user flow, with the right permissions, under the conditions in which it will be used. They also show why adding more review agents does not guarantee a result. Several agents can share the same blind spot.
A review report also calls for decisions
Over the months, another difficulty emerged. Fixing every review finding can extend the work far beyond the original need. The additional changes create defects of their own, which the next review then asks us to fix.
We therefore need to examine a finding before turning it into a task. Is it valid? Does it relate to the current change? Does it block delivery? Should it be handled separately?
The same care applies to the factory’s rules. An instruction can be wrong from the outset. Automating it without comparing it with how the product actually works would make the error more systematic. Maintaining the agentic software factory is part of the work: removing a rule that is no longer useful, refining a check or limiting the scope of a fix.
Production opens a new feedback loop
After delivery, errors and usage provide new information. The Playground uses error and usage-event monitoring, complemented by feedback from organisers. These signals help distinguish what is missing, what is not working properly and what could be simplified.
The white-label version for a private club provided another test. The starting point included the software, but also its specifications, tests and working rules. Some of that could be reused. The uses and responsibilities specific to the new context required adaptations.
This experience illustrates the value of a platform accompanied by the means to understand and develop it further. It does not establish that taking over an older or very different system would have the same characteristics.
What this changes in how we work with clients
On this product, design, implementation and checks continually inform one another. An interface decision can reveal a data question. A test can expose a poorly defined need. Feedback from use can lead to removing a feature rather than adding one.
This is the continuity we seek to establish in our engagements. We start with the product to be built and the people who will keep it running and developing. We then organise the agents’ contribution, decisions and checks around that work.
An agentic software factory is judged by what it enables us to deliver, understand and maintain. On The Playground, it continues to evolve as the product and our practice develop.
To work on this continuity in your product, explore our Build digital products service. To organise this practice with your teams, Rethink your organisation also covers setting up an agentic software factory.