The problem is usually the same: at some point, during a bad period, work dries up. Without new clients, there's no money to pay developers. Without enough reserves, lots of agencies end up being forced to close.

I myself run a tiny web agency, but I do not consider it the heart of the business. Yes, it generates 99% of our revenue right now, but I'm working hard to add additional revenue channels because, in my gut, I know a recession could result in us closing down.

That said, I'm not planning to shut it down completely, even if our diversification efforts work. It's stable and predictable revenue, which lets me sleep better at night. The goal isn't to escape it. It's to stop depending on it exclusively.

Build Something That Doesn't Depend Only on You

The obvious move is to build something that doesn't need you in the room to generate money.

A product, a course, a small SaaS, something that people can pay for whether you're working or not. The agency is a time-for-money business. You stop working, the money stops. A product doesn't work like that.

This isn't a new idea. But most agency owners keep putting it off because client work always feels more urgent. The product never makes it past the idea stage.

The goal in year one isn't to replace your agency revenue. It's just to prove the model works. Pick one thing, give it a real time budget alongside your normal work, and build the habit.

Referrals Aren't a Strategy

Most agencies grow through word of mouth. Someone recommends you, you do good work, they recommend you again. It feels like a system but it's not really.

Referral networks dry up. Industries slow down. The people who used to send you work move on.

Building a public presence is the highest-leverage thing most agency owners skip. A newsletter, a blog, a YouTube channel, even just posting consistently on LinkedIn. It doesn't need to be perfectly polished. It needs to be consistent and genuine.

The math is simple: even if 0.1% of people who follow you become clients, it compounds over time in a way that referrals never will. Being known is the foundation. Everything else builds on top of it.

Make it fun. Show your work. Be a human, not a corporate account.

What Thoughtbot and Basecamp Got Right

Two agencies worth studying here are Thoughtbot and Basecamp, both built products alongside their services businesses, and both ended up with the product becoming more significant than the agency itself.

Thoughtbot built and open-sourced tools that became central to the Rails ecosystem. The tools generated awareness, trust, and inbound leads that the agency alone never could have. Basecamp built project management software to solve their own internal problems, then sold it to the world.

The pattern is the same: solve a real problem you already have, build it properly, and offer it to others who have the same problem. The agency gives you the context to identify real problems. The product gives you leverage beyond your headcount.

**How to Actually Do It**

There's a concept I keep coming back to: every small business should put 20% of its time into R&D.

And when I say R&D, I don't necessarily mean building a new product. It could be optimizing how you run projects so you actually have time for diversification. It could be figuring out where your margins really come from. It could be analyzing your services to find growth opportunities you're sitting on without knowing it.

The hard part is that client work always wins in the short term. A client with a deadline feels urgent. R&D doesn't have a deadline, so it keeps getting pushed. The way to fight that is to treat it like a scheduled commitment, not something you do when things slow down. Things never slow down. If you don't put it on the calendar, it won't happen.

Keep the scope small too. A dedicated hour or two a few times a week beats a big sprint that burns out in a month. Finish your client work for the day, then switch. Keeping them separate means you're not context switching all day, which is where most of the time actually goes.

If you're starting from scratch, keep it simple.

Pick one direction. A productized offer, a course on something you know well, a small tool that solves a problem your clients keep running into. Give it a real time slot alongside your agency work, not a sprint you'll drop after two weeks.

Build in public if you can. The marketing and the building happen at the same time that way.

Year one isn't about replacing your agency revenue. It's just about proving the model works.

Wrap Up

Agencies are great when they're working. The problem is they're fragile by design. They depend on a constant flow of clients, on your team showing up, on your own energy holding up.

Diversification isn't about abandoning what's working. It's about building something alongside it so that a bad quarter stays a bad quarter, and doesn't turn into something worse.

Client work feels safe because you can see the money. R&D feels risky because you can't. But that's exactly why most people never start, and why the ones who do end up somewhere different a few years later.

Nobody can tell you if it'll work. But you can't find out if you never try.

That wasn't there before. And it's not a coincidence. It means the tooling now expects you to think about AI context the same way you think about .gitignore or tsconfig.json: something you set up before you write a single line of code, not something you patch in later when things are already messy.

Most developers still skip this step, and honestly it's not hard to understand why. It looks like extra setup before you've even written a line of code. And if you've never seen the difference it makes, it's hard to know whether it's actually worth it or just one more config file to maintain.

So instead of just explaining it, let's see what actually happens.

Why Claude Keeps "Forgetting" Your Rules

Every Claude Code session starts completely fresh. No memory of last week. No recall of the architecture decision from three months ago. No awareness that your team agreed to never use default exports.

What Claude has is a context window: everything it can see at once, which includes your files, your prompt, and the conversation so far. It holds a lot, but not forever.

The annoying part is that long sessions drift. As a conversation gets long, Claude starts compressing earlier context to make room for new messages, and small details disappear in that process. It gets dumber, to put it simply. The naming rule you mentioned at the start of the session gets fuzzy. The instruction about where server actions should live stops being applied consistently. You end up typing the same correction multiple times without really knowing why.

CLAUDE.md sidesteps this because it's not part of the conversation at all. It's read directly from disk at the start of every session, before anything else happens. Your rules don't go through compaction because they never live in the conversation history in the first place.

Three Layers of Memory

Before getting into what to put in CLAUDE.md, it helps to understand that Claude Code actually has three different ways to carry knowledge across sessions. Each one does something different.

CLAUDE.md files are what you write. Project conventions, build commands, architectural decisions, naming rules. Anything a new developer joining the team would need to know before touching the codebase. These load at the start of every session.

Skills are on-demand files that Claude reads only when relevant. If you have detailed API documentation, component design guidelines, or a complex workflow that only applies to one part of the codebase, it doesn't need to be in CLAUDE.md. You reference it with @path/to/file syntax, and Claude pulls it in when needed. This is the right place for anything too long or too specific to load every session. It keeps your main CLAUDE.md short and your context window from filling up with things Claude doesn't need right now.

Auto memory is what Claude writes for itself. As you work, Claude saves notes: build commands that kept failing, debugging patterns that worked, preferences it noticed you correcting. It stores these in a MEMORY.md file in a project-specific directory on your machine. You don't manage it manually. Claude updates it on its own, and the first 200 lines load automatically with every new session.

The separation is worth understanding. CLAUDE.md is for rules that apply every session without exception. Skills are for knowledge that's only needed sometimes. Auto memory is for things Claude picked up from working with you specifically.

What Actually Belongs in CLAUDE.md

The official guidance from Anthropic is to keep it under 200 lines. That might sound like a lot, but it fills up faster than you'd expect once you start dumping things in. And a bloated CLAUDE.md is almost as bad as no CLAUDE.md at all. When Claude has to scan 500 lines to find what applies, it starts missing things. A short file gets followed more consistently than a thorough one.

A quick way to think about what belongs: would Claude get this wrong without being told? If yes, and it applies to the whole project, it belongs here. Things like exact build and test commands, file naming conventions, structural rules about where things live, non-default choices like "use named exports only" or "all server actions go in app/actions/."

What doesn't belong: vague guidance like "write clean code" (Claude already tries to do this), long documentation (that's what Skills are for), and anything that only applies to one corner of the codebase. For those, use path-scoped rules in .claude/rules/ so the instructions only load when Claude is actually working on matching files.

If you're not sure where to start, just run /init inside Claude Code. It'll analyze your project and generate a starting file based on what it finds. Not perfect, but a much better baseline than a blank file.

AGENTS.md and CLAUDE.md Together

If your repo already has an AGENTS.md for other tools like Cursor or Copilot, you don't need to duplicate everything. Claude Code reads CLAUDE.md, not AGENTS.md directly. But you can import one into the other:

@AGENTS.md

## Claude-Specific Instructions
Use plan mode for changes under `src/billing/`.

This way both tools read the same base conventions, and you add Claude-specific notes below the import. What create-next-app generates is already structured this way. The CLAUDE.md it creates imports AGENTS.md out of the box.

What This Actually Changes: A Comparison

I ran a small experiment to see how much difference this actually makes in practice. Two fresh Next.js projects, same prompt, same version of Claude Code. The only difference: one had an AGENTS.md with explicit project conventions, the other had only the default warning about Next.js breaking changes that create-next-app puts there.

Here's the AGENTS.md I used for the second project:

# Project Conventions

## Package Manager
- Use `npm` for all package operations

## Router
- Use Next.js App Router only
- No Pages Router patterns

## Exports
- Always use named exports
- Never use default exports

## File Naming
- Component files must use kebab-case (e.g. `todo-item.tsx`, `add-todo-form.tsx`)
- Component names inside files remain PascalCase

## Styling
- Tailwind only
- No inline styles
- Use `clsx` for conditional class names, never template literals

## Project Structure
- All server actions must live in `app/actions/` directory
- Components go in `components/` directory at the project root

## Testing
- Use Playwright for end-to-end tests
- Test files go in `e2e/` directory
- Run tests with `npx playwright test`

The prompt I gave both was intentionally vague:

Build a simple Todo app with the following features: add a new todo, mark a todo as complete, delete a todo. Use Next.js with Tailwind CSS.

Without conventions, the first thing I noticed was the file structure. Claude put everything into a single TodoApp.tsx inside app/components/: state, handlers, UI, all of it in one place. Which, when you let it assume everything, is kind of the expected result. There's no reason for it to split things up if nobody told it to. The architecture was pure client-side too, useState for everything, which works fine but doesn't use any of what App Router is actually designed for.

With AGENTS.md in place, the output was structurally different from the first prompt. Components landed in components/ at the project root, named in kebab-case. Server actions went into app/actions/. The page itself became a Server Component with client components underneath. clsx for conditional classes. crypto.randomUUID() instead of Date.now() for IDs. Named exports throughout.

Both apps looked nearly identical in the browser. That's what makes this easy to dismiss. But the code underneath was built completely differently. The difference wasn't just naming conventions. The architecture changed too.

In case the description isn't clear enough, here's the diff side by side:

And maybe the more practical payoff: I stopped having to say the same things twice. Once the conventions are in the file, they're just there. Every session, every feature, every time. That alone saves more time than it sounds like it would.

Worth noting: this experiment only tested architecture and structure. Add a Skill on top of it and the gap widens further. If your AGENTS.md imports something like @.claude/skills/component-design.md with your color tokens, spacing scale, and component patterns, Claude starts producing UI that actually looks like it belongs in your codebase. The more context you give it, the more the output feels like yours.

The File That Outlasts the Developer

There's a pattern that shows up in every codebase that's been around long enough. Some decisions are well-documented. Most aren't. The choice of a particular library, the reason a certain folder exists, the rule about never doing X in module Y: these things live in whoever made the decision, not in any file.

When that person leaves, the knowledge leaves with them.

CLAUDE.md is an opportunity to change that habit. Not because it's the right place to dump all your institutional knowledge, but because it asks a useful question at the start of every project: what does Claude need to know to work the way we work?

Answering that question honestly tends to surface the things that were never written down. The non-obvious choices. The decisions that would confuse a new engineer. The rules that exist because something went wrong once and everyone agreed never to do it again.

When that knowledge lives in a file instead of in someone's head, it doesn't just help Claude. It helps the next developer who joins the project. It helps you six months from now when you've forgotten why you made a choice. It becomes part of how the project explains itself.

AI made that useful in a new way. But the underlying habit, writing down what you know so the work can outlast any single person, was always worth having.

If you want to go deeper on building a real workflow around AI tools, I'm working on a course: The Developer's AI Productivity Blueprint . It covers everything from the basics through multi-agent workflows. Join the waitlist and I'll select a few people to get early access in exchange for feedback.

Some write structured prompts with labeled sections and explicit constraints. Some just describe what they need in plain sentences. Some have settled on a format that works for them and stopped thinking about it. Most of them are getting decent results either way.

So the question is worth asking: does the structure actually matter, or have we been optimizing something that was already fine?

The answer is yes, it matters. But only for one of the two things people use AI for, and most of the advice online doesn't make that distinction.

The Research Says One Thing. The Reality Is More Specific.

Someone recently did a meta-analysis of over 1,500 academic papers on prompt engineering and found that the companies generating real revenue from AI aren't following the advice circulating on social media. They're doing something more systematic, and more boring.

But buried inside that finding is something more interesting than "conventional wisdom is wrong."

The real distinction isn't between good prompts and bad prompts. It's between two completely different use cases that most people treat as the same thing.

Two Ways People Actually Use AI

The first is personal use. You need to draft something, debug a function, think through a decision. You open a chat window and describe what you want. Maybe you mention your role or give some context. You read the output, ask a follow-up, and move on.

The second is system use. An application calls an AI endpoint. It does this hundreds or thousands of times. Every call needs to return output in a specific format so the rest of the system can parse it. The response isn't being read by a human who can interpret variations. It's being consumed by code that expects consistency.

These are not the same problem. And the prompt engineering advice that applies to one doesn't necessarily apply to the other.

For personal use, a clearly scoped natural language prompt works fine. You don't need XML tags. You don't need a <role> block. You need to be clear about what you want, and modern models are good enough to handle the rest.

For system use, structure isn't a stylistic choice. It's a reliability requirement.

I Ran the Same Prompt Three Times

To make this concrete, I tested it.

I asked AI to write a JavaScript function that analyzes a user object and returns a structured report. The function needed to calculate days since last login, determine whether someone was a high-value customer, and return a specific status message based on that determination.

I ran the same request three times in natural language, then three times using a structured prompt. Fresh conversation each time.

The natural language prompt:

I have a JavaScript object representing a user with fields like name, email, age,
subscription (which can be "free", "pro", or "enterprise"), lastLoginDate, and
totalPurchases. Write a function called generateUserReport that takes this user
object and returns a report object. The report should include the user's full name
and email, whether they're a high value customer (pro or enterprise subscribers
who have made more than 5 purchases), how many days since they last logged in,
and a status message that says something different depending on whether they're
high value or not. Return just the code.

The structured prompt:

<role>Senior JavaScript Developer</role>

<task>
Write a function called generateUserReport(user) that analyzes a user object
and returns a structured report.
</task>

<input_shape>
{
  name: string,
  email: string,
  age: number,
  subscription: "free" | "pro" | "enterprise",
  lastLoginDate: ISO date string,
  totalPurchases: number
}
</input_shape>

<output_shape>
{
  fullName: string,
  email: string,
  isHighValue: boolean,
  daysSinceLogin: number,
  statusMessage: string
}
</output_shape>

<requirements>
- isHighValue: true only if subscription is "pro" or "enterprise" AND totalPurchases > 5
- daysSinceLogin: calculated from lastLoginDate to today
- statusMessage: "Priority customer - schedule check-in" if isHighValue,
  "Standard account" if not
</requirements>

<constraints>
- Output ONLY valid executable JavaScript
- NO markdown formatting or backticks
- NO explanations or comments
</constraints>

The natural language results all produced correct, working code. But look at what happened to statusMessage across three runs:

• Run 1: "Thank you for being a valued premium partner!"
• Run 2: "Check out our latest offers to upgrade your experience."
• Run 3: "Priority account: This user is a key contributor to revenue."

Three completely different strings. Different tone, different phrasing, different intent. The key name for days since login also drifted, appearing as daysSinceLastLogin in some runs. Some runs added JSDoc comments. Others didn't.

The structured prompt told a different story. Across all three runs, statusMessage was identical every time: "Priority customer - schedule check-in" or "Standard account". Key names matched the <output_shape> exactly. No comments appeared unless specified.

The code quality wasn't meaningfully better. What changed was the predictability.

Predictability Is the Point

This is the thing that most prompt engineering content misses.

When you're using AI yourself, variation is often fine. If the output is slightly different each time, you read it, evaluate it, and decide if it works. You're in the loop.

When AI is part of a system, variation becomes a bug. If a status message changes between calls, something downstream breaks. If a key name shifts, a parser fails. No one is reading the output before it gets used. Consistency isn't a nice-to-have. It's the requirement.

Structured prompts with explicit output definitions, clear constraints, and specific key names lock the model into a narrower range of responses. That's what makes them useful in production, not that they produce higher quality output, but that they produce the same output reliably.

For everything else, the overhead usually isn't worth it. Describing what you need in plain language, with clear scope and context, is enough. The model understands you. It doesn't need to be spoken to in a specific dialect.

So Is It Real?

Prompt engineering is real, but it's a specific tool for a specific problem.

If you're building a system where AI output feeds into code, where consistency across calls matters, where no human is reviewing each response before it gets used, then the structure is worth it. The tags, the explicit schemas, the defined constraints, they exist to solve a reliability problem, not a quality problem.

If you're using AI to do your own work, spending an hour on prompt structure is probably not the best use of that hour. Be clear. Give context. Describe what you want. That's most of what matters.

The people selling magic templates have it backwards. The goal isn't to find the right words. The goal is to understand what you're actually trying to solve, and then use the right level of structure for that problem.

For most things, that level is lower than the internet would have you believe.

Better prompts. Better tools. Better workflows. The assumption is that if you can just squeeze more out of the model, you will stay ahead.

That is not the skill that matters.

Before We Get Into It

I have written about this shift before. About how the bottleneck moved from writing code to understanding systems. About how AI does not know your business context, and why that gap does not close no matter how good the models get.

That is all still true. But there is a layer underneath it that I did not get to, and it is the part that actually changes what a good engineer looks like day to day.

What Everyone Gets Wrong About Prompting

When something goes wrong with AI-generated code, the instinct is to blame the prompt. The logic makes sense: better input, better output. So developers iterate on their prompts, add more context, write more detailed instructions, and sometimes it helps.

But there is a category of failure that prompting cannot fix. And it is the most common one.

AI works within a context window. It sees what you give it in that moment, and nothing else. It does not see the file you did not include. It does not see the service that runs in a separate repository. It does not see the architectural decision from eight months ago that constrained everything built after it. It generates something coherent based on what is in front of it, which can look exactly right while being completely wrong for the system it lives in.

This is not a knowledge problem you can solve by writing a better prompt. It is a structural limitation. The model is not missing information you forgot to provide. It is missing information that cannot be put into a prompt because it is distributed across your entire codebase, your team's history, and decisions that were never written down.

What Validation Actually Requires

Take a concrete example. You ask AI to build authentication for an app where users can be logged in across multiple devices. It produces token expiry logic, a refresh flow, tests that pass. Everything looks correct, because at the level the AI can see, it is.

What it cannot see is that this app handles financial data, and the business requirement is that changing a password must immediately invalidate every active session everywhere. That rule exists because of a specific incident that shaped how the team thinks about security. It is not in any file. It is in the institutional memory of the people who were there.

The AI built something that works. It did not build what the system needs. And nothing about the prompt would have changed that, because the person writing the prompt did not think to include it either.

This is where validation becomes something other than reviewing output. It is the act of bringing everything the AI cannot see into contact with everything it produced. Not skimming for syntax errors. Not checking whether the tests pass. Asking whether this code, in this system, with this history, actually does the right thing.

That requires knowing the system at a level that lives outside any single file or conversation. It requires knowing which decisions were made under constraint, which parts of the codebase are fragile for reasons that are not obvious, and which requirements look stable but are not. None of that is in the prompt. All of it determines whether the output is correct.

The Skill Nobody Is Training For

Most AI workflow advice focuses on the generation side. How to structure prompts. How to break down tasks. How to get better output faster.

The validation side gets treated as a review step. Read the code, check the tests, ship it.

But validation in the way I am describing is not a review step. It is the part of the job that requires the deepest understanding of the system. And it is the part that AI makes harder, not easier, because the volume of code being generated has outpaced the instincts most developers have built for evaluating it.

The engineers who will struggle are not the ones who prompt badly. They are the ones who can generate quickly but cannot hold the whole system in their head. Who can review a function but cannot see how it fits into something larger. Who treat a passing test suite as the end of the question rather than the beginning of it.

The engineers who will not are the ones who understand that generating the code was never the hard part. Knowing whether it belongs in the system is.

Coding Still Matters

None of this means writing code stops mattering. Reading a diff, tracing logic, understanding what a piece of code actually does, that is still the foundation.

But it is no longer where the difficulty lives.

The difficulty is in carrying the system in your head clearly enough to know when something generated fits and when it only looks like it does. That is not a skill you can prompt your way into. It is built from time spent understanding how things connect, why decisions were made, and what the codebase is actually trying to do.

The developers who will matter are not the ones who generate the most. They are the ones who understand enough to know when to trust what was generated, and when to push back on it.

That has always been the job. It is just more visible now.

Then I looked more carefully at what I was actually producing.

The Good Part Is Real

I want to be honest about this part, because the rest of this article will not make sense without it.

AI genuinely changed the pace of my work. Scaffolding a new feature used to take time — now it takes minutes. Boilerplate code is mostly gone, and when I hit an error, I get an explanation immediately instead of spending twenty minutes reading documentation I half-understand.

The speed is not hype. If you use these tools every day, you feel it.

And that is exactly where the problem starts.

How I Actually Used to Work

Before AI, I was a "paint on canvas" developer. I didn't fully plan features before writing them. I liked to throw something quick and dirty at the wall to get a base layer down, something that roughly worked, and let the shape of the feature emerge as I went. Messy, hacked together, but complete. Once the whole thing was working end to end, I'd step back.

Now I had full context and I could see exactly how the feature fit into the app, what was redundant, what needed cleaning up. That's when I'd refactor.

That allowed me to be fast, because I wasn’t overthinking the feature: get it working first, then refactor it all. Simple.

The messy first pass wasn't a problem to fix, it was the method. Explore fast, understand fully, then clean. That two-stage process was doing most of the real work, and I didn't even realize it until AI quietly erased half of it.

Then AI Broke the Loop

Here's what I didn't expect: AI didn't improve that process. It disrupted the part that made it work.

The first stage, fast and dirty exploration, got even faster with AI, and that part felt great. But the second stage quietly disappeared, and the reason is sneakier than you'd think. AI-generated code looks clean. It's formatted, it's structured, it doesn't scream "this needs another pass."

So I stopped doing the refactor… not consciously, there was no moment where I decided to skip it. The code just looked finished, so my brain treated it as finished.

The problem is that looking clean and being well-thought-through are not the same thing. The messy draft is supposed to be a phase. AI turned it into the final product.

The Prompt Loop Trap

Here is a scenario most developers will recognize.

You have a problem. You write a prompt. The output is almost right, but not quite, so you prompt again with a small correction. Still off. You try a different angle, add more context, rephrase. Fifteen minutes later, you are still working on a problem you could have solved in two minutes if you had just opened the file and fixed it yourself.

At some point, you are no longer solving the problem, you are negotiating with the model. This happens because prompting feels like progress. Every response is something, you are moving. But sometimes the fastest path is to stop prompting, close the chat, and just think.

AI was faster, until I used it to avoid thinking and became lazy. Then it was just slower in disguise.

The Hidden Cost: Thinking Less

This is the part that is hard to see while it is happening.

I started reviewing AI output the same way I skim a news article: looking for obvious problems, checking that it roughly matched what I asked for, then moving on. What I stopped doing was asking harder questions. Not "does it work?" but "is this actually right?"

The code was not obviously bad. It worked, tests passed. But "works right now" is not the same as “clean and maintainable”. I was accepting outputs I would have pushed back on before, because the output was good enough and moving on was easy. Standards do not drop all at once, they slip one small acceptance at a time.

AI Didn't Skip Steps. I Did.

The development process has not changed. You still need to understand the problem before you build, think about the architecture before you write code, refactor the output into clean and maintainable code, and review it all carefully before you ship.

AI does not skip those steps, it only does what you ask, making it way too easy to get complacent. No friction, no obvious cost. The cost shows up later, when something breaks in a way you do not understand, or when you have to modify code you never actually knew.

The Fix Is Not a Tool

When I recognized what was happening, my first instinct was to find a better workflow: a smarter way to prompt, a tool that would catch what I was missing. That was the wrong instinct.

The problem was not the tool. The problem was that I had let the tool collapse a two-stage process into one, without noticing. The fix had to happen at the same level. Not a new tool, but a clearer mental model for how to work.

A few things that actually helped:

I kept the two stages explicit. Fast and dirty with AI is still fine, but I now treat that output the same way I used to treat my own messy first pass. It's a base layer, not a finished product.

I still do the refactor pass. Once the feature is working end to end, I step back and ask: now that I can see the whole thing, what would I actually do differently? That question used to come naturally. Now I have to be deliberate about it. I’ll tell Claude or Codex exactly how I want things to be refactored until I’m satisfied.

When I find myself reprompting the same thing more than twice, I stop. That is a signal that I need to think, not prompt. Sometimes, clearing the context and starting fresh also helps.

When I already know the answer, I just write the code. Not everything needs AI. Knowing when not to reach for the tool is as important as knowing how to use it.

The Real Skill

The developers I see getting the most out of AI are not the ones with the best prompts: they are the ones who know what their process actually is and protect the parts that matter.

For me, the first pass was never where the real work happened. The value was in the second pass, when I had full context and could see clearly. AI made me think I could skip it, but really, I couldn't.

Tools will change and the specific model you use today will look different in a year, but knowing which stages of your process are doing the real work, and refusing to let a tool quietly erase them, that is the skill that does not get replaced. It gets more important.

AI made me faster. It also made me worse, for a while. The difference between those two outcomes was not the tool. It was whether I still did the second pass.

Last week, I wrote maybe 10 lines myself, and I shipped more than I usually do.

It’s not a flex, you’re probably doing the same thing. But it took me a while to get comfortable with it because writing was always the part that felt like real work to me.

Something has shifted though, and I think a lot of experienced developers are feeling it without quite knowing what to do with it.

The Role Has Changed.

There is a version of this conversation that goes: "AI writes code now, so developers are done." That is not what I am seeing.

What I am actually seeing is that the work itself has moved.

For a long time, writing software was the hard part. That is why you spent years getting good at your language, your stack, your mental models. Execution was where most of the effort went. That is no longer true.

And when execution stops being the constraint, everything that used to wait behind it becomes visible. Understanding the actual problem. Defining what the system should look like before a line gets written. Knowing which shortcuts will cost you six months from now. That stuff does not get easier just because the code writes itself. If anything, it matters more.

The job did not disappear. It just sits at a different point in the process now.

My days look different because of it. Less time writing, more time managing what AI produces. It feels less like craftsmanship and more like technical direction. And the catch with that is: a fast, capable system that makes mistakes in subtle ways requires more attention, not less. You still have to know enough to catch what it gets wrong.

What I Actually Do Now

Before I touch any AI tool, I think through what I am building. Not at the line level, but at the system level.

• What are the components?
• How does data move between them?
• What are the constraints?
• What should this thing never do?

This is the part that AI cannot do for you. Not because the models are not capable, but because the answers live in your head and in the business context around the project.

Then, I ask Claude to generate an implementation plan for the feature. I will review that part thoroughly, before asking for a list of TDD-style tests to be generated before any code gets written.

Starting with that allows me to define what “done” looks like for the current feature.

If you skip these steps, you end up reviewing code against a vague idea of what you wanted. That is where AI slop comes from, not from bad models, but from unclear input.

Once I’ve reviewed the tests, the implementation work can start. I’ll usually try to do it step by step, with smaller chunks of the feature that I can review as I go.

This matters more than people realize. When you let AI generate a large chunk at once, reviewing it becomes overwhelming. You end up skimming and you end up missing things. Breaking it down forces both the AI and you to think in sequence, and it keeps each review focused enough to actually catch problems.

Then a second AI reviews the output, then I review it myself one more time.

There is also something worth saying about the speed. I will be honest: there is something genuinely satisfying about watching an idea become working software faster than it used to.

Getting to the built thing faster just means more time for the parts that actually require a human.

What You Still Have to Bring

That last review step is where experience earns its place.

I am not only checking syntax. I am also asking whether this approach makes sense for the business and whether we are solving the right problem at all.

This is where AI has a specific blind spot worth understanding. It is very good at producing code that looks functional. Tests pass. The feature works. But "works right now" and "holds up over time" are different things. AI does not naturally think about what happens when requirements shift, when the codebase grows, or when another developer has to modify this six months from now. It optimizes for the output in front of it, not for the system around it. That gap is exactly where experienced judgment lives.

A junior developer might see the same output and think it looks fine, because it does look fine. What they cannot always see yet is how it will behave when something changes around it. That judgment is not something you can prompt your way into. It comes from having seen enough things break.

If you are earlier in your career, this is not a reason to panic, but it is a reason to be intentional. The repetitive work that used to teach you how things connect is being automated, which means you have to find other ways to build that understanding deliberately. The good news is that learning has also gotten easier. You can take a well-known open source project, something like Rails or Linux, and ask AI to walk you through how a specific part works. When you do, push further than the answer. Ask why it was built that way, not just how it works. That habit is what separates developers who are actually learning from the ones who are just collecting answers.

The developers who will grow in this environment are the ones who use AI to understand systems faster, not to avoid understanding them at all.

What This Means

I did not stop being an engineer.

I stopped being a typist.

The craft is still there. It just looks different now. Less time at the keyboard, more time thinking about systems. Less writing, more reviewing. Less implementation, more direction.

If anything, the parts of the job I find most interesting, the architecture decisions, the problem framing, the moments where you push back and say "I think we are solving the wrong problem", those parts have more space now.

The 10 lines I wrote last week? Those were the lines that actually needed a human.

I personally spend much less time writing code these days. Most of my time is spent managing AI agents and reviewing their work, almost like working with a team of engineers.

That shift matters more than the “AI will replace developers” debate, because writing code was never the most important part of the job.

The real value was always somewhere else: understanding the problem, thinking through the architecture, and translating messy requirements into something that actually works.

And that part hasn’t gone away.

But engineers who refuse to adapt probably will, and junior developers who rely entirely on AI without understanding what they’re building won’t last very long either.

There is a right way to use AI in 2026 if you want to stay productive, and a very wrong way.

Let’s dive in.

What Everyone Is Actually Arguing About

When people say "AI will replace developers" they usually mean one of three different things.

They either mean that junior roles will disappear, the whole profession is going away, or that AI will make engineers so efficient that companies will simply need fewer of them.

These are three completely different claims, and most of the debate online mixes all of them together. So before we go anywhere, let's be honest about what's real.

Yes, AI can write code. Good code, sometimes. It can scaffold a feature, write tests, handle boilerplate, and explain an error faster than any Stack Overflow thread. That part is not hype. If you've used these tools daily, you know they genuinely change the pace of work.

But here's the part that gets left out of the conversation.

Very few layoffs in recent years were actually tied to direct AI automation. Most were companies correcting for overhiring during the boom years between 2020 and 2022. Saying "we're going AI-first" is a better headline than "we hired 30 engineers when we only needed 10." Same layoffs. Better story.

AI didn't kill the job market. The job market corrected itself, and AI got the credit or the blame, depending on where you sit.

But that still doesn't answer the deeper question. Even if developers aren't being replaced right now, what about the work itself? Is the job changing in ways that matter?

Yes. And this is where it gets interesting.

AI Fixes the Code, Not the Problem

A while back, I ran into a bug in the staging environment of an app I help maintain, and it stuck with me. Not because it was complicated, but because of how simple the real fix turned out to be and how AI completely missed it.

You see, in that app, we have a job scheduled to run daily. Its job is straightforward: check documents and expire the ones that have passed their expiration date.

But at some point, we disabled it: development had been paused, costs needed to be cut, and staging wasn’t really needed for a while. It stayed off for about four months.

When we turned staging back on, something was wrong. Many users were showing incorrect expiration states. The data looked off and I wasn’t sure why.

So I asked Codex, which looked at the code, analyzed the logic, and started suggesting fixes:

• Change this condition
• Adjust that check
• Add this validation

The suggestions looked reasonable, but really, the code was completely fine.

The real problem was that the scheduled job only looked back four days when checking for expired documents. After four months of not running, there was a massive gap. The fix wasn't a code change at all. It was just running a script to backfill the last four months of missed processing. There was no need to change any code, since there was no bug.

AI never got there… It kept staring at the code because that's all it can see. You could argue that if Codex had full access to that Heroku account, it would have likely seen that the scheduled job was missing, but giving full access to infrastructure to any AI is still something where I draw the line.

At the end of the day, the problem wasn’t in the code. It was based on a human decision dictated by business needs.

The Knowledge AI Cannot Access

This is worth sitting with for a moment.

Good engineers carry context that isn't written anywhere. They remember the cost-cutting decision from last quarter. They know why a certain table is structured the way it is, even though the original developer left two years ago. They know which parts of the system are fragile and why. It's not because it's documented, but because they were there when it broke.

AI works from what it can see: the code, the error, the prompt you gave it. It has no access to the meeting that never got written down. It can't ask the right question because it doesn't know the right question exists.

This gap doesn't disappear just because models get better. Even a much smarter AI still only knows what it's been told. The institutional memory of a system lives in the people who built and maintained it. That's not a limitation of today's tools.

That's a structural reality.

Translation Is Still a Human Job

Here's the other side of this.

Clients can use AI to build apps now. That's real. You can describe what you want, generate something functional, and ship it without writing a single line of code yourself. The tools exist. People are doing it.

But most clients still hire engineers. And the reason isn't that they can't use AI themselves. It's the same reason most people still call a plumber even though they could theoretically fix a leaky pipe themselves.

They don't want to think about it or deal with it. After all, they don't know what they don't know, and when something goes wrong in a way they didn't expect, they don't know where to start to fix it.

Software is the same. A client can prompt an AI to build an app, but they often can't communicate exactly what they want. They describe the surface, not the system. They say "I want users to be able to track their orders" without knowing that this single feature touches authentication, database design, notification logic, and mobile layout. Getting from "here's what I want" to "here's what you actually need" is a translation job. It requires someone who understands both the business and the technology well enough to bridge them.

That's why business analysts still exist. That's why good engineers ask questions before they write code. The requirement-gathering process, figuring out what a system needs to do before deciding how to build it, is something AI cannot replace, because the client often doesn't know how to tell it what they need.

And there's one more piece to this. A good engineer doesn't just build what the client asks for. They push back when something doesn't make sense. They suggest a simpler approach. They flag a technical decision that sounds reasonable on paper but will create problems at scale. That judgment comes from experience and business understanding. It's not in the prompt.

AI is lazy. It will create features that work, but the code will often be messy, unmaintainable, or poorly structured unless you guide it properly.

What Actually Gets Displaced

Let's be honest here too, because the picture isn't all good news.

Some of what junior engineers used to do is genuinely getting automated. Repetitive boilerplate, simple helper functions, basic test generation, straightforward refactoring, and tons of UI work.

AI handles these faster and with less friction than a person would.

This means the learning path has changed. Before AI, juniors built experience by writing repetitive, simple code. That code taught them patterns, structure, and how things connect. Now AI writes that code instantly. What's left is understanding it, debugging it, and knowing when it's wrong.

That's harder to learn passively. And it's worth being honest that many juniors lose the repetitive practice that used to teach them how systems work. That's a real cost, but for the ones who push through it, it's actually a better foundation. The engineers who grow in this environment skip the surface-level work and go straight to the thinking.

The floor is rising.

What used to require a team of five can now be done by two people with the right tools. That creates real pressure at the entry level, but it also means engineers who develop genuine depth, who understand systems, not just syntax, will have more leverage than ever before.

The Question That Actually Matters

The engineers who will struggle in this environment are the ones who let AI do the thinking entirely. Who accept the first output, ship it, and move on without understanding what they built. They'll feel productive for a while, but when something breaks in a way AI can't diagnose like a cron job that's been off for four months, they won't know where to look.

The engineers who will thrive are the ones who ask the right questions before touching the code. What problem are we actually solving? Does this approach make sense for the business? What context am I missing?

I've seen this play out enough times to believe it. The value of a good engineer was never just in writing code quickly. It was in knowing which problem to solve, understanding the system well enough to ask the right question, and having enough business sense to know when the requirement itself is wrong.

AI didn't change that. It just made it more visible.

The Question Most Developers Skip

Most developers are asking: will I still have a job?

That's not the most useful question.

The better question is: what does good engineering look like when the repetitive work gets automated?

The answer has always been the same. Understand the business. Own the context. Ask why before asking how. Know enough about the system's history to recognize when the problem isn't in the code.

AI changed the pace of the work. It didn't change what the work is actually for.

The developers who bring business thinking, institutional memory, and the ability to translate between what clients say and what systems need, those developers aren't disappearing.

They're just harder to replace, which was always the goal.

Don’t want to be left behind?

If you want to build a real workflow around AI instead of just experimenting with tools, I’m working on a course that will be released in the coming weeks: The Developer’s AI Productivity Blueprint .

It contains everything I’ve learned over the past few months, starting all the way from the basics, to the role shift we’re seeing, as well as more advanced topics like multi-agent workflows.

Check out the course’s page for more details and join the waitlist. I’ll be selecting a few people that will get the course for free in exchange for feedback.

• Creating a small product
• Building an app
• Doing some freelancing to earn more

Something that doesn’t depend on the whims of your boss.

I was one of them, but as a developer, I wasn’t really sure how to get started.

I tried writing books first, before eventually switching to freelancing. At the time, it turned out to be a much better fit for me… but I didn’t know that beforehand.

So I thought it might be a good idea to compile everything I’ve learned about starting businesses as developers safely (i.e. without quitting your job), along with the patterns I’ve seen other developers follow.

That eventually turned into an ebook, Side Hustles For Developers.

What’s “Side Hustles For Developers”?

It’s the ebook I wish I had when I first got started… before spending a decade learning things the hard way.

And it’s free.

It’s a practical breakdown of the real ways developers build income outside their job, organized in a way that makes sense depending on where you are right now and what actually fits your style.

Inside you’ll find:

• How developers actually start side hustles without quitting their job
• Which paths work at different stages of your career
• How to avoid the traps that waste months of effort
• How to choose the right starting point based on your time and skills

The Side Hustle Ladder

The core of the ebook is a framework I call the Side Hustle Ladder.

The idea is simple. Not every hustle fits every person at every stage. Some take a weekend to start, while others take months of consistent work. Some need an audience, while others need nothing but a skill and a willingness to show up.

The Ladder helps you choose your next realistic step.

Not the dream scenario, but something you can actually start this week, based on your time, energy, and what you already know.

Here is a quick overview of the options we cover in the book:

Freelancing and Consulting (The Honest Version)

This is where most developers start, and trust me, it works.

But most developers who try freelancing either undercharge (I was one of them), take on the wrong clients, or burn out because they traded one boss for five.

Digital Products

Templates, tools, open-source projects with a paid tier, courses… These are the ones that sound passive, but honestly, nothing is ever truly passive.

And they’re certainly not at the start as they take real work to build and real effort to promote. What changes is the economics: you build once and sell many times, which is a very different model from billing by the hour or by the project.

Content Creation

Creating content such as tutorials, articles, videos, or podcasts can be an amazing way to build authority as a developer, and eventually turn that authority into real revenue.

My main concern with freelancing is that it doesn’t create much long-term leverage. Each project or hour you work generates revenue, and sometimes leads to more clients through recommendations. But it doesn’t really compound over time.

Content does.

Building a SaaS

Building a SaaS or small product means creating something that solves a clear problem for a clear audience, and I’m going to be honest.

While this has one of the lowest barriers to entry for developers, it’s also one of the hardest paths to break into. Most developers start building right away, only to realize later that there isn’t a real need for what they built, or that they have no idea where to find customers.

One Thing I Want to be Clear About

Not every side hustle is right for every person. We’re all different, and we all approach work in different ways, so it’s important to identify the kind of hustle that fits you and your lifestyle.

That’s why the ebook talks about tradeoffs, not just opportunities.

Because the goal is not to hustle harder. The goal is to build something that fits, and potentially can replace your full-time job (if you want it to), like it did for me.

Start Where You Are

The ebook is free. All of it.

If you are a developer who has been sitting on the idea of building something on the side, this is a good place to start. Not because it has all the answers, but because it will help you figure out the right next step for where you actually are right now.

Table of Contents

• Why Consider Moving Now?
• What We're Assuming About Your App
• Why DigitalOcean App Platform?
• Before You Touch Anything: The Migration Checklist
• Steps to Migrate from Heroku to DigitalOcean App Platform

On February 6, 2026, Heroku officially announced it is transitioning to a "sustaining engineering model." In plain English: no new features, just keeping the lights on. For developers who have relied on Heroku for years, this is a signal worth paying attention to.

For many Rails developers, that marks the end of an era. When Ruby on Rails was thriving, Heroku was the default. It meant you didn’t have to configure nginx on an Ubuntu server just to ship.

If you're still on Heroku, now is a good time to plan your exit before something forces your hand.

This guide walks you through migrating a standard Rails app from Heroku to DigitalOcean App Platform , a fully managed PaaS with a similar push-to-deploy workflow.

Why Consider Moving Now?

Before we get into the migration steps, here’s a quick comparison between Heroku and DigitalOcean App Platform as of early 2026:

Heroku still works. But pricing becomes harder to predict as you scale, especially with add-ons and bandwidth. DigitalOcean App Platform keeps things simpler and more predictable, which is why it’s a practical landing spot if you're planning a migration.

What We're Assuming About Your App

This guide is written for a typical Rails setup:

• Your code lives in a GitHub repository
• You're using PostgreSQL as your database (hosted on Heroku)
• You're using Sidekiq and Redis for background jobs
• You have scheduled Rake tasks running via Heroku Scheduler

Even if your stack is slightly different, most of this still applies.

Why DigitalOcean App Platform?

DigitalOcean is straightforward, well-documented, and affordable, a natural landing spot for developers leaving Heroku.

App Platform is DigitalOcean's managed PaaS, and it's the closest thing to a Heroku replacement you'll find. It uses the same Cloud Native Buildpacks as Heroku, so most apps migrate with little to no code changes. You get fully managed PostgreSQL, MySQL, Redis, and MongoDB built in, free internal service routing between components (no Private Spaces fees), SSL provisioning, and zero-downtime deploys out of the box. You connect your GitHub repo, push code, and it deploys.

No servers to manage, no DevOps overhead, just your app running.

Before You Touch Anything: The Migration Checklist

Before setting up your new server, collect everything you need from Heroku and prepare the migration. Do this while your app is still running. For production apps, enable maintenance mode before exporting the database so no new data is written during the backup.

Most migrations run both platforms in parallel, then cut over at the DNS level once everything is confirmed stable. That's exactly the approach this guide follows, so downtime is minimal to zero.

On Heroku’s side:

• Export all config vars: heroku config -a your-app-name
• Dump your database: heroku pg:backups:capture && heroku pg:backups:download
• Note your custom domain (if any)
• Note all Heroku Scheduler tasks (command + schedule)

Steps to Migrate from Heroku to DigitalOcean App Platform

1. Create an App on DigitalOcean App Platform

   Get started with DigitalOcean here .

   Once you’re in, go to App Platform and create a new app. Connect your GitHub repository and choose the branch you want to deploy.

   

   App Platform will detect your Procfile automatically and set the run command to bundle exec puma -C config/puma.rb. Leave the build command empty.

   

2. Add a Managed PostgreSQL Database

   In the same setup flow, go to the Add a Database tab, add a PostgreSQL database, and create an app.

   

   Heads up: After adding the database, DO will show an environment variable reference like ${your-db-name.DATABASE_URL}. This looks like it should work automatically, but in practice, you’ll want to replace it with the actual connection string so Rails and Sidekiq receive a proper DATABASE_URL. We'll do that in the next step.

3. Add a Managed Valkey Instance

   Add a second database and choose Valkey, DigitalOcean's Redis-compatible service. Your app and Sidekiq won't notice the difference.

   

   

4. Set Environment Variables

   This is the step that trips people up.

   Go to Settings → Environment Variables. You'll see DATABASE_URL and REDIS_URL (If you set one) set to reference values like ${your-db.DATABASE_URL}. Replace both with the actual connection strings.

   To get the connection strings:

   • PostgreSQL: Go to your database → Connection Details → copy the Connection String
   • Valkey: Same thing, go to your Valkey instance → Connection Details → copy the connection string

   

   Then add the rest of your environment variables from Heroku (RAILS_MASTER_KEY, any API keys, etc.).

   

5. Restore Your Database

   Before you deploy, restore your data. If you deploy first, your app will 500 on every request until the database is ready. Run this from your local machine using the connection details from your new PostgreSQL database:

   PGPASSWORD=your_password pg_restore \\
     -U doadmin \\
     -h your-db-host.db.ondigitalocean.com \\
     -p 25060 \\
     -d defaultdb \\
     latest.dump
   

   

   If you're starting fresh with no existing data, skip this and just run migrations after deploying instead.

6. Deploy

   Deploy your app. Once it's live, if you skipped the restore above, open the web console and run:

   rails db:migrate
   

   

7. Add Sidekiq as a Worker Component

   Sidekiq needs to run as a separate component so it has its own process and can be scaled or restarted independently from your web server. In DO App Platform, go to your app and create a new worker component:

   • Resource type: Worker
   • Run command: bundle exec sidekiq
   • Environment variables: Make sure DATABASE_URL and REDIS_URL are set here too. The worker needs both

   

   

   Deploy the worker. Check the runtime logs, you should see Sidekiq boot up and connect to Valkey.

   

   Note: Running a separate worker component means paying for an additional instance. For low-traffic apps, you can start without it and add the worker only when you have actual background jobs that need processing.

8. Recreate Your CRON Jobs

   DigitalOcean App Platform handles scheduled tasks as Job components, configured the same way as the worker above but with a schedule attached. Follow the official guide here:

   https://docs.digitalocean.com/products/app-platform/how-to/manage-jobs/

9. Point Your Domain to DigitalOcean

   

   Once your app is deployed, you can connect your custom domain.

   In App Platform, go to Settings → Domains and click Add domain.

   DigitalOcean will show you the DNS record you need to configure. Add that record at your DNS provider (or inside DigitalOcean DNS if you’re using it).

   After DNS propagates, App Platform will automatically provision SSL for your domain .

   If you want the full step-by-step walkthrough, DigitalOcean has an official guide here .

You're Live

Once everything is running, confirm traffic is flowing to DigitalOcean and monitor the app for any unexpected issues.

You can run both environments in parallel for a day to be safe. When you're confident everything is stable, remove the Heroku app.

Heroku isn't going away tomorrow, but it's no longer moving forward either. DigitalOcean App Platform gives you the same push-to-deploy simplicity with a platform that's still actively growing.

Get started on DigitalOcean with $200 credit today.

That may sound obvious. But when you watch something go viral, when the momentum builds and investors start paying attention, there is an invisible force that pulls you toward the default script: raise money, hire a team, scale fast.

Most people follow it without asking if they actually want to.

Peter Steinberger didn't. And the story of how he built OpenClaw and what he chose to do with it is a good lens for thinking about what it means to build something on your own terms.

What is OpenClaw?

OpenClaw is a local AI framework. You install it directly on your machine, and if you let it, it has system-level access to do anything on your computer.

By itself, it is just a shell. The creator jokes it is like a "space lobster harness", nothing happens until you plug in a brain. But once you connect it to a powerful LLM like Claude Opus 4.6 or GPT-5.3 Codex, it becomes something that can genuinely act. Not just answer questions, but do things. That is the official slogan: "the AI that actually does things."

You can talk to it through WhatsApp, Telegram, or any chat app you already use. It can connect to your browser, translate an audio file you send from your phone, and remind you to buy milk at 2PM. That last feature runs on something called Heartbeat which is basically just a clever cron job but it lets OpenClaw reach out to you, instead of waiting for you to ask.

There is also a soul.md file. That is where you give it a real personality and values. The creator calls it the soul.

But here is the thing about a tool with full system access and a proactive heartbeat: the security concerns are massive. When a bot gets this level of permission, it becomes a real risk.

And the plugins that extend OpenClaw's power? You can never be totally sure what they contain. To address this, Peter partnered with VirusTotal so that every skill is automatically scanned for bad code. It is not a perfect fix, but it is a serious attempt.

The Naming Drama (And What It Reveals)

OpenClaw did not start as OpenClaw.

After some early prototype names, Peter landed on "Clawdbot" (spelled with a W), like a lobster claw. He thought it was clever. He owned the domain. It felt right.

Anthropic, the company behind Claude (spelled with a U), did not think so. An employee sent him a friendly but urgent message: change it before the lawyers get involved. There was no lawsuit. But the message was clear.

Under sleep deprivation and stress, he panic-renamed it to MoltBot because he already owned those domains and needed a fast solution. He hated it immediately. His exact words: "the mold's not growing on me."

After sleeping on it, he came up with OpenClaw. And just to be safe, he actually called Sam Altman at OpenAI to confirm the name was okay to use before committing to it.

That detail matters. It is not just a funny anecdote. It shows someone who moves fast and figures things out under pressure but also someone who does the unglamorous work of getting it right, even when no one would notice if he skipped it.

The Part That Surprised Me

When something goes this viral, the expected move is a funding round.

OpenClaw had everything lined up for it. A strong technical foundation. A lot of buzz. A clear use case. The kind of momentum that usually ends in a hiring spree.

But Peter had already run a software company called PSPDFKit for 13 years. He knew what that path looked like, and not just the technical part but the people part. Managing employees, handling conflicts, navigating high-stress customers. That is what burned him out. And he is already financially comfortable, so making more money is not his main goal.

He also saw a conflict of interest. If OpenClaw became a SaaS startup, every cool community-built feature would become a temptation to lock behind an enterprise paywall. He did not want that pressure shaping his decisions. He believes OpenClaw should stay free.

So instead of starting another company, he joined OpenAI.

His reasoning was direct: "What I want is to change the world, not build a large company, and teaming up with OpenAI is the fastest way to bring this to everyone." OpenAI gave him access to their latest tools and massive computing power. Sam Altman announced that Peter would "drive the next generation of personal agents" at OpenAI.

His one condition: OpenClaw stays open-source forever, similar to how Google treats Chrome. OpenAI agreed. The project will live on in a foundation.

Why This Is Worth Thinking About

I will be honest: when I first read this, it felt strange.

If you build something valuable, aren't you supposed to scale it?

But the more I sat with it, the more I understood.

There is a shift that happens when something you built starts to grow. In the beginning, it is just you and the work, like writing code, shipping fast, and making decisions directly. It feels creative. It feels like building.

Then, if it works, things change. You hire. You manage. You sit in more meetings than you expected. Eventually, you are not building the thing anymore. You are running the thing.

Some people love that transition. Others realize they actually just want to keep building. That is a hard thing to admit in a culture that treats scale as the only real measure of success.

I have moved between freelancing, leading teams, running parts of companies, and building again. When I was in a Director of Engineering role, my days looked very different from when I was freelancing or writing books. Not worse just different. More coordination, more responsibility, less time in the codebase.

When I look at someone who ran a company for 13 years and chose not to spin up another one, I do not see a missed opportunity. I see clarity.

Growth Is Not Always the Goal

There is a quiet assumption in tech that if something works, you should maximize it. Staying small is often framed as lacking ambition.

But sometimes staying intentionally small is a strategic choice.

Growth changes the nature of the work. Once you raise money, you are no longer optimizing for what you find interesting. You are optimizing for revenue, retention, and returns.

That is not evil, that’s just how it works. The question is whether that is the deal you want.

The AI shift makes this question more interesting than it used to be. One developer with the right tools can now do what used to require a small team. If you can build meaningful things without hiring aggressively, you do not automatically need to scale headcount to scale your output.

Personally, I do not want a 50-person team and layers of management. I want something tight. Solid. Work that still feels like building. A small group of smart people who can achieve almost anything.

That does not mean avoiding impact, it just means choosing the shape of the impact.

What OpenClaw Actually Teaches Us

OpenClaw could have become a startup. Maybe a unicorn. Maybe it will still evolve in ways none of us expect, but what stood out to me was not the technology. It was the restraint.

Instead of following the predictable path, Peter asked a different question: what kind of work do I actually want to be doing?

That is the question most builders skip. Momentum is powerful, traction is addictive, and it’s easy to drift into growth because it feels like the responsible next step.

But that changes the job:

• You go from building to managing.
• From designing systems to designing org charts.
• From solving problems to absorbing them.

Some people want that. They thrive on it.

I don’t.

I don’t want a giant company. I don’t want layers of management and constant operational weight. I want something tight. Small. A strong group of smart people building fun things deliberately.

That is not playing small. It is choosing the shape of the work.

OpenClaw is interesting because its creator made that choice consciously. He didn’t drift into scale. He decided what kind of work he wanted to keep doing.

Most builders never stop to ask that question, they just follow the script.