Yesterday in Da Nang we had Cafe Cursor. It is an AI meetup where people come to drink coffee and talk about building with AI. Cursor sponsors it, and they are an amazing sponsor: they pay for everybody's coffee. I handle these events in the city with Frontier Club.
One of our regulars is Rob Hallam. Rob has spoken at a previous event. He has successfully launched two apps that are making real money. Lately he has been working on his AI workflow: how to generate software without spewing out a load of slop he has to fix later, and how to cut the time from idea to software in the world.
He arrived quite late. He missed the conversation I had invited Joe Bellissimo on stage for. Joe runs an agency out of Australia. Because Rob missed it, and because what Joe said is exactly what Rob has been working on, I am putting it down here.
Rob is the one who had the insight. Why do people come to events like Cafe Cursor and Frontier Club to talk about AI? Because they are all searching for the perfect workflow. The perfect way to build fast, without error. They want to know what other people are doing to build their software factory.
Joe has a really custom setup. I think it is interesting for anyone in that search. He does not use Cursor. He uses a mix of Crush and Claude Code on a Linux machine that uses very little resource, runs 24/7, and runs multiple sub-agents on different models. He uses cheap models at times. The practices still apply if you build with Cursor, or with any other AI coding harness.
The point is not the tools. The point is the guardrails. With the guardrails in place, the AI has very few opportunities to spew out crazy stuff that is jank, broken, and expensive later.
Here are the top tips from Joe.
Settings live in the database. Code stays code.
Joe makes a hard split. Every setting, everything that can change, goes in the database. The code is only there to create that thing in the frontend. Unlike a lot of agent-written apps, he does not bury behaviour in the files. If he needs to change something, he changes the database. In some cases the code files are created fresh from those settings.
That gives him a small, clean codebase. It also gives the agents a single source of truth. They are not allowed to invent a new way to do a thing that already exists as a setting.
A caveat from older software design, and it still applies: not every value belongs in a database. If changing it would only break the program, it can stay in the code. Joe's rule is about the stuff that is meant to change. You still need a tiny boot config so the app can find the database in the first place.
Design the repo so an agent can follow it
This is the same idea, one layer up. When Joe designs a codebase he has instructions in mind: one file, one purpose. Create primitives and reuse them, do not hardcode behaviour. Generate code where you can, instead of hand-rolling it.
He writes those rules in a markdown file. That file is the job description for every agent that touches the repo.
The public version of this is an AGENTS.md or a CLAUDE.md at the root of the project. Those files are how most harnesses now take a briefing: what the stack is, which patterns to copy, which directories are off limits. Joe's version is stricter. The instructions are not style notes. They are the architecture that is reinforced, and violations are watched for by a second agent.
May 2026 research from EURECOM puts a number on why the file alone is not enough. In Constraint decay: The Fragility of LLM Agents in Backend Code Generation, Dente, Satriani, and Papotti showed that as architectural, database, and ORM rules pile up, capable agents lose about 30 points on assertion pass rates. The models still try to make the feature work but they treat the structure as optional. A markdown file helps but does not enforce.
That is why Joe does not stop at the file.
Package each piece so it can stand alone
He compiles each little piece into its own package and keeps them in his own repo. He is on Bun for that, which is a replacement for Node. Bun is one option but the important item is that everything is separate and can work independently.
One file, one purpose becomes one package, one job. An agent that wants to add a feature should pick up a primitive, not invent a new tangle of files that all know about each other.
Unify hosting so there is one connector
Joe had been using a different service for the database, a different service for hosting, and a different service for files. He collapsed that onto Railway so the app, database, and files are in one network. And this now requires just one API connector.
Railway's own pitch is the same shape: backends, databases, caches, queues, and private networking in one project, so you are not federating three vendors to ship an API with Postgres. That is useful when agents are the ones wiring the connectors. Every extra vendor is another place for the model to invent a one-off integration.
Caveat: unified hosting is an operations choice, not a law. Some teams still split a frontend host from a managed database because they want a specific SLA. Joe's point is fewer seams for the factory, not that Railway is the only factory.
Run the local factory on Rust. Ship the product as TypeScript.
He needs a lot of processes sitting on that Linux box, 24/7. For anything that runs locally he has AI convert it to Rust. Rust uses very little resource, so he can keep watchers and sub-agents alive without melting the machine. When the product gets compiled and sent, it is Bun and TypeScript.
I could not find a named method for "ask an agent to transpile your watchers into Rust." That part is Joe's. What does exist is the resource argument. Rust agent runtimes that have published numbers idle in the tens of megabytes. Typical Node or TypeScript agent stacks idle in the hundreds of megabytes, sometimes more. Those are other people's benches, not Joe's. They are why the split makes sense: Rust for the daemons that never sleep, TypeScript for the software he actually ships.
Treat agents and CLIs like teammates
Give them a job description, tools, and rules. Same as a human hire. The markdown file is the job description. The tools are what they are allowed to touch. The rules are what they are not allowed to invent.
Joe lets the agents talk to each other in two ways. At the end of a turn, a stop hook hands the work to another agent to analyse. And then there is the other idea: a cheap model that never writes product code. It only watches.
Claude Code documents this hook surface in public. A Stop hook fires when an agent finishes. A SubagentStop hook fires when a sub-agent finishes. You can log the transcript, block a bad finish, or start the next role. Joe is using that idea as an org chart, not as a logging trick.
Collapse the seams. Put a Sentinel on the chat feed.
This is the failure mode the whole setup is built against. Sometimes the AI goes crazy, goes off on a tangent, and writes a new item when it could have copied a principle, a code sample, or an existing way of doing the thing. That is how you get interlinked files where you wanted one source of truth in the database and one piece of code.
Joe calls that collapsing the seams. The counter is not a longer prompt. It is a second agent whose only job is to notice.
Call it a Sentinel. It is not a product. It is an idea. You can build it this afternoon.
Every sub-agent already talks. Instead of letting those chats die in a terminal, you write them into a database. One row per message, tagged with which agent said it, which job it was on, and which files it touched. The rules the factory is supposed to follow already live in a markdown file: one file one purpose, reuse the primitive, do not invent a second source of truth.
Then you run one more model against that table. A cheap one. Haiku-class, whatever is nearly free. It does not write features. It does not touch the repo. It reads the new rows as they land and compares the flow of conversation to the ruleset. That is the whole job. Is this going off script. Is it building something it does not need. Is it recreating something that will later couple two files that should have stayed separate.
It can be cheap because the job is narrow. You are not asking it to be clever. You are asking it to watch a stream and flag dumb stuff. If it sees a seam opening, it writes a flag back into the same database, or it trips the next stop hook so the writing agent has to stop and explain itself.
A cheap model will still miss things, and it will still false-flag things, because it is a model. That is fine. The stop hooks are the harder gate: they can actually block a turn. The Sentinel is the always-on lookout. One reads the feed while the others work. You do not need a smart lookout. You need a lookout that never gets bored.
This is the part that maps onto the research. The May paper says agents will satisfy the feature and skip the architecture. The Sentinel is how you watch for that in real time, without paying Opus prices to police Opus.
One gateway for the tools
Joe uses a gateway when he connects multiple MCP servers. I am going to keep this one humble, because I want him to elaborate on the exact box he runs. The shape he described is this: the agents do not each wire up their own pile of servers. They talk to one gateway. That gateway talks to the database, the tools, other parts of the code, and the other agents. Inter-software and inter-agent communication through one door.
The public version of that pattern is now a product category. Docker's MCP Gateway sits between clients and servers, starts isolated containers, injects credentials, and gives every agent one endpoint. Other gateways exist, including small Rust binaries that hide a hundred tools behind a short search-and-invoke surface so the model is not drowning in tool definitions. I am not saying Joe uses Docker's. I am saying the industry independently arrived at the same seam: one connector, many backends.
Put together, the problems do not get a chance
When all of these things are in place, they solve a number of problems before the problems are able to occur.
That is the factory people are looking for. Not a magic model. A repo an agent can follow, a database that owns the settings, packages that do not tangle, one host, cheap watchers that never sleep, teammates with job descriptions, and one cheap model whose only job is to watch the other agents talk and notice when someone starts inventing.
Rob walked in late asking how to go from idea to software without the slop. Joe had already been answering it. The practices work in Crush, in Claude Code, and they will work in Cursor. The harness is not the workflow.