RoleModel started in 1997 as one of the first extreme programming (XP) studios, turning innovative concepts into reality. Pair programming, test-driven development, small iterations, all turned up as far as they would go. The tools have changed a lot since then, from Smalltalk to Java to Rails to JavaScript, and our proven approach carried through every one of them. In a lot of ways, it feels like we're on the ground floor again, this time of building software with AI agents.

Why do the old practices still apply to vibe coding?

AI made producing code cheap. Anyone can have an app running in an afternoon, and I build things that way all the time. The hard part moved. If fast is easy, then going fast sustainably is the hard part.

Kent Beck, one of the founders of XP, has a name for what makes it hard: features versus futures. Every feature spends some of your options for what the software could do next, and if you keep spending them, you end up with a system nobody can change. Agents speed that up. In an article earlier this year, Wes McKinney, the creator of the widely used data analysis library pandas, called it "technical debt on an unprecedented scale, accrued at machine speed."

In a professional kitchen, cleanup is part of the discipline of cooking, and software works the same way. Make some progress, then refactor and clean up. That's how you keep going fast, and a system you keep improving should get easier to work in over time, not harder.

Some people call this shift agentic engineering, building with agents the way an engineer would, and I think it's where vibe coding done well ends up. So I've been thinking about which of our practices still hold when an agent writes most of the code. Most of them do, because the principles underneath haven't changed, but they look a little different. Our approach of Explore, Craft, Ship, starting with a skateboard and building toward the car, applies to vibe coding just as much as it did to every set of tools before it.

Three practices keep coming up in my own builds.

Start with the problem and the research

Before you build anything, ask what problem the software is going to solve. Articulating it well means distilling it down to its real essence. A good thought partner session with AI helps you do that before you start looking for a solution.

Then do some research to figure out whether a solution even makes sense. Have your AI look for solutions that already exist, whether that's a paid product, an open source project, or just an idea worth borrowing. Then look at the assets you already have, like tools you've built before or other resources you can draw on. Sometimes the answer is a tool you've already built, or a different way of using AI that you hadn't thought of yet. When I wanted a better meeting transcription tool, I had AI evaluate the ones that already existed first. That narrowed the problem down to the one thing none of them did well: telling speakers apart when several people share one laptop mic.

None of this is new for us. It's process first, software second, the way we've always run projects, and the same experiments culture we use for selecting technology. AI makes it more tempting to skip, because building feels free. What you want to come out of it with is the smallest thing worth building.

Build in intervals

AI shortened the build loop. It did not shorten the time it takes to gather feedback.

One of the apps I've been vibe coding this fall helps me train for a 10K. A change to it takes minutes. Finding out whether the change was right takes a week, because the plan only meets the road on the days I run. You can't know what you want from software until you've used it, sometimes for weeks or months. Sometimes what's missing is a simple addition. Other times it changes how you think about the whole process.

So I build the way I train, in intervals: a short, hard burst of building, then time actually using what I built. In training, the recovery is where you get fitter. In building, it's where you learn what to build next. Fast changes are a budget for more loops, not a shorter calendar.

That's the skateboard to car idea from how we think about iterative value. Each step has to work, and real use gets a vote before the next one.

Craft the process: hands on the wheel

At Rails World, DHH, the creator of Ruby on Rails, said 37signals has gone pencils down on writing code by hand. I'd say hands on the wheel. If you're going to go fast, you don't hold the wheel loosely. You guide it with precision, so you hit the corner at exactly the right apex.

As a software developer, that means going from crafting the code to crafting the process. The same shift applies to anyone building with an agent. The agent writes most of the code, and what I craft is the structure it works inside: the instructions, the decision log, the checks it runs.

Retrospectives, pairing, and stepping back to improve the system have always been XP practices, and they matter more with an agent. Every time I have to redirect the agent, that correction goes into its instructions so I don't have to make it twice. Then I step back and review the process that produced the code, not just the code, and clean that up too.

The checks matter even more when you're crafting the process. Tests and other deterministic checks, the kind that give the same answer every time, form a verification harness the agent runs against on every change, so the system catches problems before a person has to. It's the same reason we've always written tests: confidence and documentation.

That changes where review happens. It's better to review a plan after you've broken it down and done a little spiking (a quick, throwaway build to test an idea) than a big change that went the wrong direction. By the time the code is done, review becomes two sets of eyes on the outcome.

What we're still working out

Beyond the checks we already know how to use, there are smarter parts of the process these tools can take on. QA is the one I'm thinking about most: an agent that probes the app the way an exploratory tester would, or a review harness that exercises the core workflows. Doing that efficiently is its own challenge, but it's a creative way to ensure higher quality in every software release.

Build slow

RoleModel was on the ground floor of XP, and what we learned from applying those practices, and from continuing to evolve them, still applies to vibe coding done well. We call it building slow: build fast in short bursts, then slow down long enough for real use to show you what to build next. The practice of writing code by hand is changing, but there's still value in taking what we've learned about creating great software systems and putting it in the hands of business users and their own teams. There's always been more software that could be created than we could ever build, and I want to see people doing it well.

If you've gotten partway through building something for your business and want a second set of eyes on the process and where to take it from here, we'd love to have that conversation and help guide you. You can see more about how we help on our AI services page.