VillaSlot and ShipSaaS: The Architecture That Lets AI Agents Ship Without Creating Spaghetti Code
Mike Codeur
Watch the full 50-minute masterclass
A nine-hour autonomous run raised a fair question
VillaSlot was built during a nine-hour autonomous run. The agent worked through twenty user stories in that sequence. The first video focused on execution speed: an agent can take on a substantial scope, work for several hours, and produce a functioning application.
Several developers responded with the same criticism: “This is vibe code.” That deserves more than a defensive answer. A working interface tells you little about the project structure, access security, or whether the product will still be easy to change six months later. The architecture has to be opened up and examined.
Speed is not evidence of quality
A fast agent can write good code or bad code. The duration of a run cannot settle that question. Quality shows up in architectural decisions, responsibility boundaries, tests, and the checks required before a story can be marked complete.
ShipSaaS provides an organized Full Stack foundation. The agent does not invent the application’s overall shape for every story. It works within known boundaries. Those boundaries reduce improvised decisions, make changes easier to review, and give tests stable places to exercise the system.
Multitenancy starts with the architecture
VillaSlot is a multitenant application. Multiple organizations use the same product while keeping their workspaces and data separate. That constraint affects almost every operation. A valid request must come from an authenticated user, but that is only the first condition. It must also run within the correct organization context.
Authentication, users, and organizations
Authentication establishes who is performing an action. That identity maps to an application user and an organization. The organization then becomes a functional boundary for reads and writes.
This distinction prevents a dangerous shortcut: assuming that a signed-in user can access any resource whose identifier they can submit. In a multitenant SaaS, the application must enforce organization context wherever access matters. A resource ID sent by the interface is never proof of authorization.
Data isolation is not a UI filter
Hiding an item in the interface does not protect its data. Isolation must be enforced on the server when an operation is validated and when persistence is queried. The organization context therefore travels with the request.
Three layers with separate jobs
ShipSaaS divides the system into Presentation, Services, and Persistence. The labels are familiar. Applying them consistently is what matters.
Presentation
The Presentation layer handles what the user sees and how actions begin. It collects input, displays useful states, and sends an intention to the server. It should not decide business rules by itself or open a direct route to the database.
Services
The Services layer owns use cases. It receives a request, checks the required conditions, applies business rules, and coordinates the operation. This is where the authenticated context and organization membership gain operational meaning.
Persistence
The Persistence layer reads and writes data. It encapsulates how storage is queried and returns results that services can use. It does not decide how the user experience should behave.
Following one use case from the interface to the database
Consider the generic path of an action in VillaSlot. A user triggers an operation in the interface. The Presentation layer gathers the necessary input and sends the request. The server identifies the authenticated user, resolves the organization context, and passes a structured command to the Services layer.
The service checks preconditions and business rules. It does not trust the submitted resource identifier as evidence of access. It combines the requested resource with the organization context, then calls Persistence. Persistence performs a read or write constrained to that scope. The result returns to the service, which turns it into a useful response. Presentation then updates the screen.
Agents need rules, not only tasks
A coding agent should not receive only a user story. It also needs project conventions, architectural limits, and a testable definition of done. Without them, it will naturally optimize for the most visible result: making the main scenario work.
The rules require the agent to respect the layers, reuse established paths, preserve multitenant context, and never bypass authentication. They also require error handling and verification of the change’s real effect. The goal is not to restrict useful initiative. The goal is to shrink the space in which a quick solution can conflict with the rest of the system.
The delivery loop around every story
Delivery does not stop when the code compiles or the screen looks correct. The loop begins with acceptance criteria. They turn the request into observable behavior and prevent an agent from declaring completion based on a vague interpretation.
TDD comes next: write or update tests, observe the unmet need, implement the expected behavior, and clean up without losing the proof. A separate review examines the change from another perspective. That separation matters because the author of a solution, whether human or agent, tends to see what they intended to write rather than only what is present.
The automated tests then run. The flow is also checked end to end in Chrome, which exercises the real integration between interface, server, and data. A visual inspection follows. A functional test can pass while the screen is clipped, unreadable, or inconsistent.
When a problem appears, the agent does more than report it. The auto-fix loop sends the issue back into implementation, and the checks run again. The complete path is therefore: criteria, TDD, separate review, tests, Chrome E2E, visual inspection, automatic correction, and renewed validation.
What this approach cannot guarantee
No architecture makes an agent infallible. Rules can be incomplete, tests can miss a case, and a review can overlook a defect. A structured foundation also needs maintenance as the product changes.
The nine-hour autonomous run does not replace technical ownership or product judgment. It shows that an agent can execute quickly when the system makes sound paths obvious and deviations detectable. Authorization boundaries still need attention, test coverage must keep improving, and decisions that no longer fit should be revised.
Inspect the architecture instead of debating a label
Calling VillaSlot “vibe code” does not evaluate the result. Useful questions are concrete. Are responsibilities separated? Does organization context follow every operation? Is each tenant’s data isolated? Does every story pass through a loop of evidence, review, and correction?
The first video demonstrated speed. This masterclass shows the mechanisms that keep that speed from producing a fragile pile of code. ShipSaaS provides the Full Stack structure, VillaSlot puts it to work in a real product, and agents operate under rules that can be inspected.