What do we work on when AI tokens will allow us to do virtually anything and everything in the digital space given enough time?
Steve Yegge has previously talked about atoms versus electrons in a business, and that people who only have electrons in their business do not have a moat. The best example of a business having atoms in it is Amazon. Amazon moves probably the most atoms (and potentially electrons too with AWS) in the physical world at the lowest possible prices, at scale.
Combining this with The Bitter Lesson, where any specific, local optimizations to AI systems eventually get surpassed by the model becoming more powerful, I’ve been feeling stuck in analysis paralysis. I haven’t been able to decide or figure out what to work on.
I have seen first-hand the power of Agents and how they killed my original idea for a SaaS: git commits to social media content, Roxas. It is now a Claude skill combined with the paid social media posting service, Buffer.
I have also seen Claude absorb features from Beads and Gas Town. These were scaffolding around gaps in Claude Code. These were external agent orchestrator tools that filled a need that model companies didn’t see. Anthropic then proceeded to incorporate their own version into Claude in a matter of weeks to months. Guess which one I use more often nowadays?
I have been very intentional about what I even choose to work on. The “what” I work on is more important than the “how”. Execution is essentially free and arguably, now guaranteed given enough tokens.
Reliable and Valuable APIs

It turns out that Buffer is the shape of service that gets more useful with Agents, not less. Buffer integrates with all of my social media accounts and expose a set of reliable APIs that my Claude Code can interact with to schedule posts across them. I like to call these types of services “rails” as in the “Ruby on Rails” sense, not to be confused with “guardrails”.
The qualities for what code should be written are captured best by Gas City’s Primitive Test. It's written in terms of Gas City, but the principles still apply across all projects. I haven't even used Gas City that much, but this document has been the single most important shift in my thinking for trying to find the thing that I want to work on.
In the Buffer example, it is just a pass-through. It reliably pushes data from one source (Claude Code) to another (out to my social media accounts). It also has some limited analytics reporting on the posts so that my Claude Code can do a closed-loop evaluation and learn how to do better for next time.
Why I pay Buffer $8 per month per account is because it handles all the various constantly changing social media API connections, and I don't have to think about them to post my content. “It just works” like an old school Apple ad.
What we need to do is clearly separate what the models are going to be really good at vs what should deterministic code do? What are models going to "eat" vs. what is safe long-term to build? How do we collect, store, and represent data to make it available through the right APIs or tool calls to a model at the right times, which then can decide what to do and how to interpret that data?
We are now data collectors and aggregators for models. We're the ones with a direct interface to the physical (and digital) world that we can collect data from. Only somebody with deep domain expertise knows how data should be collected and structured to be maximally useful. This is still a very human creative aspect, as we have a Perspective based on our experiences about what data, brought and combined together in various ways, would be productive and value accretive.
It is the “Buffer” shape of a service that I believe will continue to thrive. Anything that deterministically takes data from an input and it gives an output that can be read by an Agent. Oh yeah, it also has to be a Hard Problem. Sorry, you're not going to out-model the model companies or out-scaffold them due to The Bitter Lesson. The time to start an AI lab was 5-10 years ago. The time to join one is either now or 2-3 years ago.
If you’re not interested in doing that, we're left with the question, “what do we do with these powerful models and agents that AI labs produce?”
Remember the forest of low-hanging fruit? Well, everyone and their mother can now just one-shot a custom app or service that meets their specific needs for any problem of low enough complexity.
Domain Expertise as Perspective

I have been talking with my brother about this. He’s been vibe coding up a storm since I got him a Claude gift card for his birthday in February. He’s solving his digital marketing domain problems with code that he previously couldn’t write 6 months ago. He knows what problems exist in his domain of digital marketing, I don’t, and vice versa with DevOps / enterprise software engineering. Since we both have separate domain expertise, we have different perspectives.
That's the main thing humans can add to AI tokens: Perspective.
LLMs don't run themselves; there has to be a first mover, sort of like existential philosophy or religion. These models are invoked for a reason. What can we invoke them to do that isn't a low-hanging fruit copycat app that everyone else and their mother is doing or can easily think of?
I've talked about this previously as a “personal grove of low-hanging fruit”. What are your sum total of experiences that you have deep domain knowledge in? What are problems that only you can see and solve?
What is the cross-functional intersection of your experiences? That is your Perspective.
Perspective is a much more operational, actionable word than "taste". Taste is very vague and intentionally hoity-toity artsy-fartsy (even though I used it myself initially a few months ago). How do you define it? How do you train or improve it?
I would rather define it as perspective in domain expertise. Deep “knowledge of” versus LLMs that only have “knowledge about”. “Knowledge about” a thing is:
all the facts of a domain
all the nouns and verbs associated with a domain
what has happened so far in a domain
the current state of the art solutions, and the history of them
what are the next set of problems to tackle
These are all things that are well-known on the public internet. What isn't on the public internet that LLMs can train on are all of the experiences between your ears. That is “knowledge of” a domain. Your direct experience with working on the most valuable problems day in and day out. This is why human reinforcement learning and labeling is a thing for machine learning. That is the process we have for taking a human’s “knowledge of” and putting it into new models.
This is where my ecological dynamics Jiu-Jitsu coach side questing is coming in handy. People are adaptable. We exist in an environment (tech sector, “the market”, capitalism broadly) where the most adaptable thrive. The person who is willing to engage with the ever-changing environment and adjust themselves accordingly will be successful.
What does this mean? People who are willing to “lose” and learn, will win. People who are willing to do hard work in order to adjust their internal model of the world to be closer to how the world actually is. This is a lot of trial and error and engaging directly with whatever domain you are a part of.
My Personal Perspective

As a concrete example, my domain that I have a dozen years of experience in is DevOps. DevOps is the process around how code goes from developer laptops to customers. I have seen a lot of weird shit with computers running 24/7 when they're not necessarily designed to do so (Macs, in particular), at scale.
There's a lot of processes and scar tissue that develop as a result of seeing a lot of bad things happen. When bad things happen, DevOps typically lead Root Cause Analyses (RCAs) to correct mistakes that things that go wrong. This is to ensure that things can't fail in that exact way again. All of this comes from actually doing the thing, not reading about the thing in a book or blog post, but actual human hands-on keyboard interacting with the invisible computer environment.
DevOps is my Hard Thing. I am a relative domain expert in that. Not the best, but also not the worst. I think my job moving forward is to help design the rails (mentioned previously “Reliable and Valuable APIs” section) that models can interact with.
Only humans have the Perspective to evaluate and pay for the monetary value of a given service, for now at least. In the future, I'm sure agents are going to evaluate for themselves the trade-offs of build versus buy any given software. The agent may evaluate the cost of tokens, the time value of money and taking on additional dependencies to complete a task, Agents may just default to buying reliable access to data sources vs. rolling their own.
I believe the most defensible current and future companies are going to be good, reliable connectors to data sources that tastefully (there’s that word again, read: opinionated perspective) and thoughtfully expose data to Agents so that they can act on it.
Guardrails Crash Out

Let me crash out here on how people love to say "guardrails" and throw it out there for anything that even comes close to telling an Agent what to do. It’s a very general term that is almost as meaningless as “taste”.

I want to differentiate between “soft” guardrails and “hard” guardrails. Soft guardrails are prompts or anything that feeds into one, like skills. Anything in a prompt is a mere suggestion. You cannot guarantee an agent will or will not respect a prompt that you give it.
Hard guardrails are, in fact, physical limitations. Things like user access controls, IAM roles, CI/CD processes, and file system permissions that agents can't get around and modify. Basically anything that restricts a user from doing something is an actual hard guardrail that an agent has no choice but to obey. I think this is where I still have some amount of moat left in my job because electrons are physically blocked by semiconductors to enforce these hard guard rails. you can think of Hard Guard Rails as the "alignment problem," but with systems external to the LLM.
When people mistakenly treat soft guardrails like hard guardrails, they get surprised when they drive straight through a Wile E. Coyote paper guardrail and off a cliff (or into a brick wall).

We're going through growing pains as an industry for how to best use AI generated code. I believe more answers to things like Claude’s one-nine reliability problem lie more in Hard Guard Rails than in Soft Guard Rails. Somehow we didn’t micromanage every single line of code ever written by human engineers for the previous 80 years of electronic coding and we got along fine. We had a "normal" amount of bugs that humans got used to.
Now we're experiencing a greater-than-human number of bugs with AI-generated code. We need to solve this problem to get it back down to the previous "normal" amount of bugs. But if we can decrease it by that much, I believe the momentum in solving this problem will carry us to decrease it much further than the previous norm. We may just need to add many, many more test processes and strategies like layers of swiss cheese like I’ve mentioned on my previous newsletter to catch bugs from going out to production.
Obligatory Jiu-Jitsu Connection

Similar to what we observed earlier with humans having the power of the purse, again for now; humans get to set goals, for now. Maybe that's what spending money has been all along: we're trying to solve a problem by exchanging currency for a solution.
For a problem to be solved, a human or Agent has to observe it first. If an Agent observes a problem, and given enough permissions, it can set a goal to solve it. It doesn’t need a human to tell it that there’s a problem. It has enough context to know what a “problem” looks like to set a goal to solve it.
My job as a Jiu-Jitsu coach is to show my students what the primary goals are from the major grappling positions and submissions from standing, guards, and pins. I need to show them what the most common problems are and encourage them via my class structure to gain experience with these specific problems. I developed this class structure from listening to coaches like Greg Souders break things down from a constraints led approach Perspective as well as from my own personal grappling Perspective. There’s that word again.
I believe you can lock two white belts in a room for a year, give them the prompt to “figure out how to control the other against their will”, and they will be able to develop some approximation of what we know as “Jiu-Jitsu” just by themselves. If you think about it, someone had to be the first to do so initially. Jiu-Jitsu is accessible to all of us because we all have bodies and can figure out how to control someone else's while they try to fight back and control you.
My job is to shortcut the “White Belts figuring out Jiu-Jitsu from first principles” process. I prioritize what I believe will be the highest ROI on class time for everyone. That only comes from my Perspective; my style of grappling that I have accumulated over time and have proven to work pretty well for me.
You could probably ask an LLM to make you a training program as if you were being coached by John Danaher, but ultimately, you still have to do the thing yourself and get feedback from somebody who also has experienced the thing itself. This is a dynamic and very human-centered interaction. It’s also not large enough of a market for an actual AI company to come in and automate the process of coaching. My ultimate hedge against my software engineering job being automated by being a Jiu-Jitsu Black Belt is safe… for now.
Why am I hyper-analyzing these basic things?

Humans give a literal and figurative vector to LLMs. The high school geometry definition of a vector: a starting point, and a direction to go. LLMs use hyper-dimensional vectors to more or less do the same thing.
Humans are the first mover of LLMs. We give it a prompt, which embeds a goal for it to accomplish. We can course correct the resultant Agent-created vector (conversation) over time.
If all of this is like, “duh Mike, why are you stating the obvious?” it’s because it is. I’m trying to fully understand our basic assumptions around these technologies.
I think the highest leverage work we can do is by tracing back our assumptions and overlaying our Perspective on how this part of the world works, and how it may be similar or different to other parts.
Just a programming note: the newsletter may come out every other week now, just because these have been real thinkers and I want to put out good quality ones, and not just hit an arbitrary self-imposed deadline. Thank you all for joining me on this!

