With all of this fancy AI-assisted coding circus, there this presumption that everything should be moving fast. "I shipped $thing in a weekend," and other other assorted clickbait is definitely dominating the public consciousness.

It reminds me of a quote by Warren Buffet: "Be fearful when others are greedy and greedy when others are fearful." This is a particularly interesting koan because there are a lot of people on both sides right now armed with weapons-grade FUD. I believe that the trick is to try to walk the line as carefully as possible. Is the overwhelming majority of what most of us are reading on a daily basis a bunch of hype? Most likely. The potential is probably overvalued a bit and the so is the correlated fear of change.

This raises the question—what if I did the opposite? What if I spent some time building out some of the foundational pieces with the bet that by moving slowly and deliberatively up front, it would pay off in dividends later? The calculus here—of course—is that by moving methodically, I will end up with a deeper understanding of about how all of my tooling works and that it would be custom-tailored for my workflow and use cases. The counter-argument is that I am signing up to spend thousands of dollars in a grand display of yak-shaving.

For the last few weeks, I've been working on a few projects—among some others that I'll try to talk about later: A durable execution engine and a design system—two things the world definitely doesn't need more of. It's arguable that both of these endeavors are colossal wastes of time given that Temporal and about 3,000 other design systems both already exist.

On the other hand, they are both helping me keep sharp in terms of the latest developments in the field. And, both are allowing me to experiment with different design decisions than the prior art listed above.

I do have some unique takes (and no idea if these takes are actually any good). For the durable workflow engine, for example: I am trying to use the primitives built into the web platform whenever possible. I also gave myself the constraints that it needs to be able to run in the browser just as well as it does on the server. It uses a completely different mechanism for tracking the progress and resuming a durable execution; it uses checkpoints instead of replay, which eliminates the need for continueAsNew and—in my humble opinion—makes it a better fit for workflows that involve long conversation histories.

For the design system, I am has some components that would normally be deemed to complex for most other design systems out there today. For example, there are components for a chat interface and editor that let's you comment on and annotate a plan presented by an agent. As I begin to prototype bigger and better things, I don't want to have to wire up a bunch of libraries that were designed in isolation of each other. That's the bet: get this right early on and then leverage those pieces later.

I have this hypothesis that we're living in the Golden Era of subsidized tokens. Back in 2014, you could get an Uber in Denver for about $4. But, that venture capital doesn't last forever. Eventually, the major players emerge and wipe out the competition and then start charging what these services actually cost—and then some.

LLMs are good for taking unstructured data and turning it into structured data. A few years ago, if you wanted to build an application that had a list of every happy hour in your town and had some nice features like showing the ones currently going on sorted by which was closest to you, the hard part wasn't the code—it was getting a database all of the happy hours. And, then you'd a metric done of effort dealing with the edge cases if any of that data was malformed. An LLM is very good at taking the wall of text and synthesizing into a standardized format. This is as true as it is for happy hours as it is for parsing large logs of error messages when something goes wrong in the middle of the night.

The current zeitgeist is that we're all going to write skills and the agent is going to read some Markdown and figure out what to do. This mostly works, but it bakes in an implicit token cost everything single time for what could probably be turned into a deterministic set of steps—a workflow, if you will. This is what code is good at it. We should be prototyping with skills and then figuring out how to boil those skills down to deterministic workflows in a effort to push back the ballooning costs of tokens—both in terms of the sheer number of tokens as well as a potential rise in the cost of a given token.

Are both of the things I mentioned earlier that I am currently working on vibe-coded? Of course. But also, I've been working on both of them every day for the last six weeks and I wouldn't call either of them ready for prime time just yet. Working through each moving piece step-by-step, tweaking then experience and questioning my design choices along the way. I'm moving slowly at a time when everyone is taking about is showing off how fast they can generate code for the sake of generating code. The bet is that the old adage is true: slow is smooth and smooth is fast.

I've also built some personal tools along the way that have super-charged my workflow: a little task management CLI that allows me to organize work. The Goal: get to the point where I am designing, planning, and architecting ideas rapidly and balancing that with the ability to do that consistently and at scale and now have a set of differently crumbling foundations all at once. If I'm wrong and the next generation of frontier models can just manifest code with little-to-no human intervention, then we're all cooked anyway.

Maybe, I don't end up using either of these projects—in which case, I'll have at least learned something about both endeavors, which is knowledge that can't be taken away in the future. In a world where producing code is cheap, understanding patterns and concepts becomes the distinguishing factor.