“Introducing Tiller”
Recently, Korinne and I open sourced Tiller. Our personal vibe coding environment built on Cloudflare. You can read more about it on paperwing.dev. It’s basically a replacement for Claude and Codex’s tools which allow for remote vibe coding, and controlling all the harnesses and models. It “steers” all queries to the appropriate model, harness, and compute based on the requirements. It was spun out of experiments around creating our own harnesses running on Cloudflare workers, and needing a way for them all to communicate.
As this is the first complicated project I’ve purely “vibe coded”, I wanted to get my thoughts down on what works, what I think of as “vibe coding”, and where I see AI coding going. This app was classic case of building it “not because it was easy, but because we thought it would be”. It took many months off and on, and had over 100 plans to become usable. There were major painful refactors along the way, and the scope and focus changed many times. I persisted only because I see this as a base for future non-coding agents that I’m working on. My thought is that delegating to the correct models and harnesses will be a core part of engineering in the future, and it seems a simple enough problem that I don’t have to outsource it. More thoughts on later.
Approach and Experiences Vibecoding Tiller
I’ve been vibe coding in earnest since May 2025. I only trusted it with simple personal apps though. I’ve slowly gone from reading most of the code, to only agreeing together on architecture decisions and requirements. For very simple apps I’ve stopped reviewing code or architecture entirely, but I think this only works because there is so much reference code in my monorepo. For even slightly larger apps it falls over quickly. Even today (May 2026) simple apps take far longer than I expect them to, and I still fall into the trap of thinking a small app will just be a few hours, and it turns into two days.
For Tiller, the approach was to keep a full mental map of the architecture and files in my head, but not be concerned with the actual content of the files. Most of the effort goes into writing plans. Some plans are small, but many (maybe most?) plans will be iterated on for at least an hour before we start coding. The agents and I explore all possible solutions and their pros and cons, we debate thoroughly at each step, and most assumptions are cross referenced with other agents. Each agent has different things that they are good at, and their “personalities” quickly become apparent. Since ChatGPT 5.4 for example, ChatGPT has been better at actually coding and makes less mistakes, but Claude is significantly better at writing plans and sometimes thinking outside the box. As you see in the app, every category favors different default models based on my experience, and the rankings are reevaluated when I get annoyed with one.
When designing and implementing plans, the amount of “topics” I can handle at one time is 3 to maybe 4 topics. I can have multiple agents checking the work in each topic, but I can only think of 3 or 4 things at a time. The process is to think on one problem, and then while it’s churning, move onto the other topics. I find programming in this way to be more mentally taxing then how programming used to feel, and often need to turn off my music and see other deeply focused indicators like that. I do still get into “flow” with this kind of programming — even with all the context switching.
In an ideal world, I would context switch less and have no more than two “work streams/ topics” being worked on at a time. When I have tried this, I burn through my weekly credits too quickly with a $100 ChatGPT plan and a $100 Claude plan. If I don’t use fast mode, even intense coding weeks are normally within the limits of both plans combined on max effort. I was previously pretty pleased with usage limits, but lately Claude and Codex have been far more restricted.
Viability of Personalized Software
For the last few years I’ve been watching AI, apprehensive about what it will mean for my chosen profession. February 2025 (couple months after Claude Code was released) marked the first time coding with AI would fill me with depression. I loved using it as a tool, but my hard fought knowledge was being commodified incredibly quickly. Even with the models as good as they are today, I’m no longer nearly as scared. At this point the models are incredible, but building complicated tools is still hard. You still have to hold all the context in your head, and it will lead you astray if you don’t understand everything you are committing to a plan and review. You can get away with it for quite awhile, but eventually you will need to make major refactors if you care about code quality. This bit me a few times while making Tiller. I hadn’t quite figured out the UX at first, so I let the AI build features so I could test them. I understood what I felt was 70% - 80% of the architecture, but this eventually led to long painful refactors.
All this to say, personalized software is much easier than it ever was before, but I’m now betting complicated apps will always require full time developers. For myself, the investment is worth it for things that are foundational to my life. Every day I open Spotify and hate the app. Before that I hated Youtube Music. Things that I use daily, that feel important to my identity — those things are worth personalizing. Curious people will go through the effort with the help of open source. Code will be cheap, and their will be a lot more choice and creativity for even non developers.
For ambitious projects however, I now think people will always need to go through the hard work of understanding the system, and ruthless QA. It takes a certain kind of personality to enjoy that kind of work. As Korinne and I have been joking the last couple years, anyone can “cook”. Most people still won’t want to, or have the time. The job of the engineer is still basically the same. Make the system work with the right abstractions, the fewest bugs, and as efficiently as is necessary. The barrier of entry is just much lower now.
Why Tiller
Originally it’s because I had more ideas for it. But honestly it took so long, that now these will just be experiments when I have time. The vibe coding platform is more than enough, and being able to immediately add ideas when I have them is freeing.
As for my future experiments, I’m generalizing it to work for apps that may not need git, a container, or where latency might matter. The “tiller-hub” concept will stay, and it will take a much more active role in routing between models, and be completely aware of each models state. This is hard to do with containers and complicated harnesses. But most of my use cases are more specific, and I think there is a lot to play with concerning evals, weak models with a custom harness, and low latency Cloudflare workers. So far my results have been mixed, so I guess we’ll see.
As for if any of these experiments will actually matter, I’m still not sure. Models and compute could get so cheap that none of this matters, managing harnesses could get so complicated that I want a better tool, or AGI could get so good that app development is something users do completely on their own. Most likely it will be some combination of all three. Still though, fun project, and I’m curious how long I can keep up with a personalized solutions to these problem.