AI writes the code.
Can you still design the system?
The job has changed. You deliver trust, not code. That takes knowledge nobody's teaching: how to steer agents, and how to design systems that keep working. That's why we're building it, in the open. You're early.
See what's coming
- No signup, no commitment
- Walk the gym, the lab, and the roadmap
- Meet the community already in the Discord
- See exactly what you'd be backing first
Get sudo
- Every RunHacks challenge, the day it drops
- Members-only Discord and the community
- Founder role for those who fund the build
- An early look at the gym and the Lab
Here's the part nobody teaches.
The Gym is coached practice on the exact decisions that set whether a system holds: where boundaries go, how the pieces talk, where state lives. You make a call on a real system, you find out what it cost, and a coach shows you what you missed. Then you do it again on something messier. That is how judgment gets built, the same way it always has.
When you add a feature, what changes isn't decided by the feature. It's decided by where the related concerns already live. The set of things a change forces you to touch has a name: the blast radius. Your boundaries set it, not the work itself.
Below is a checkout system, drawn as a map of who owns what. Each service owns a few concerns. Read it as responsibility rather than code, and look at where each piece sits.
- checkout
- order history
- card processing
- refunds
- pricing
- stock
- reservations
- order emails
- receipts reads pricing
- profiles
- sessions
Most of these boundaries are clean. One isn't. Payments owns pricing. Payments should be about moving money, charging a card and issuing a refund. Pricing is a separate concern, what things cost and how that cost gets adjusted. It landed in Payments because that was the easy place to put it, and now anything that touches pricing has to route through the service that moves money. Notify already reaches across that line, reading pricing to build its receipts.
That placement is what a feature pays for later. A boundary in the right place keeps a change local, so you touch one service and you are done. A boundary in the wrong place taxes everything that comes near it, because the change has to go through whatever owns the concern. The feature never set the cost. The boundary did.
That is the skill in miniature, reading a system well enough to spot the misplaced concern and price the change before you write a line. Now try it.
One idea at three scales:
how far a change travels through a system.
- Where to draw module and service lines
- What a part should and shouldn't own
- Reading a change's blast radius before you make it
- Designing a seam so either side can change
- Versioning an API without breaking its callers
- Knowing what each side is allowed to depend on
- Deciding where state belongs and who can change it
- Idempotency: safe to retry, safe to reorder
- Staying correct when something fails
This is the skill that outlasts the tools.
Languages and frameworks come and go, and the models turn over every few months. The ability to look at a system and know where it bends does not, and it's what makes you the person who can stand behind what ships. The "learn AI" wave skips that part entirely. You build it one rep at a time, and six months or five years from now it is still the job.
When the system is real.
The Gym builds judgment on prepared problems. The Lab is where you take it to a real one. Real systems, real agents doing the building, and feedback the moment something moves. It is guided experimentation: you make the architectural calls, the agent writes the code, and you watch what your decisions actually cost. You see the terminal, you see the agent chat, and you see exactly what you are there to do.
In a Lab exercise you'll browse the repo, read every diff, and walk the git log right here, alongside the agent. Coming when the Lab launches.
Where this is going.
We would rather underpromise and overdeliver, so this is deliberately short, and the Lab gets no date until we can run it well.
- The Resources agent that builds answers from the best material on the topic.
- The first RunHacks challenges, polishing before they go live.
- The Gym, starting with Boundaries, the course the Resources agent coaches.
- More RunHacks challenges.
- The rest of the Gym, Contracts and then State.
- The Lab, real agents on real systems, once we can run it well and not a day before.
Targeting real value, not features shipped.
Who this is for.
This is for anyone who wants to understand the systems we work in every day. We teach you to decide what gets built and how it fits, no code required. We don't pretend the tools are the skill.
One membership. Elevated permissions.
Get notified when it's ready.