“When you people say this is this, what does that mean?”

“When you say this is that, what does that mean?”

Those questions were the signal.

From a management point of view, that is how you checkpoint the progress of new talent on a team, or someone finding their footing in a new department. The stupid questions gave you visibility. They showed you where the person was confused, what they were picking up, and how far along they really were.

We do not get them anymore.

Not because people stopped being confused. People still get confused. They still join teams and feel overwhelmed by context they do not yet have. They still hit the gap between what they know and what the work demands.

The difference is where they take the confusion.

They paste the wiki into ChatGPT. They paste the Slack thread into Claude. They describe the codebase to Gemini and ask it to explain what they are looking at. The questions still happen. They just happen in private, with a machine that never judges them for asking.

And honestly, you cannot blame them. Asking a lead or a senior teammate “what does this mean” carries social cost. It always has. Nobody wants to be the person who does not get it yet. AI removed that cost entirely. You can ask the dumbest possible question, five different ways, at 2am, and nobody on your team will ever know.

So the questions went underground.

The visibility problem

This changes something fundamental about how teams work.

When a new hire used to ask you why the billing service talks to two different databases, that question told you three things at once. It told you they had gotten far enough to find the billing service. It told you they did not yet understand the data architecture. And it told you they were actively trying to close the gap.

That was free signal. You did not have to schedule a check-in to get it. It just surfaced naturally because asking humans was the only option.

Now the signal is gone.

Instead, six hours before the deadline, or twelve hours before the deadline, you receive the first output. And while output is a good thing, it is also a coin flip. They might get it right. They might get it wrong. You have no way to tell which one is coming because you never saw the confusion that preceded it.

And when someone asks no questions and delivers polished output, you cannot tell the difference between someone who deeply understood the work and someone who got lucky with a prompt.

Both look the same on the surface. Clean deliverable. On time. Formatted well. Hits the brief. But one of them built understanding along the way and the other one outsourced the understanding to a machine and shipped whatever came back.

That is a risk. Because the moment the work gets harder, the moment the context is too specific for a general model to handle, the person who built real understanding will adapt. The person who did not will break. And you will not know which one is which until that moment arrives.

This is not a plea to ban AI from onboarding. That ship has sailed and it should have. AI is genuinely useful for bridging knowledge gaps, and pretending otherwise is not a strategy.

But it does change the job of leadership.

You have to assume you are not going to get the stupid questions. You have to design around that assumption instead of hoping people will still come to you with their confusion.

You can no longer wait until the final stretch to see the work for the first time.

That means compressing delivery into shorter feedback cycles. Not one big checkpoint at the end. Multiple small ones throughout.

Early output, before anyone has had time to polish or over-rely on generated answers. Review and correction, where you can see the shape of someone’s thinking while it is still rough enough to be honest. Iteration and improvement, where the work gets better because you shaped it together rather than received it finished.

Each checkpoint gives you a chance to see where someone actually is instead of where their output suggests they are. It is more work. It is also the only way to replace the signal that the stupid questions used to give you for free.

What we actually lost

The stupid questions were never just a management tool. They were a relationship. Someone admitting they did not understand something yet, and someone else helping them get there. That exchange built trust. It built context that no wiki can replicate. It built the kind of team knowledge that lives in people, not documents.

AI is better than any tool we have ever had for closing information gaps. But information gaps were never the only thing the stupid questions were closing.

I still miss them.

Your cofounder asks the same model. Also solid. Your board member runs it through a different prompt. Same conclusion. Your teammate asks from a different angle. Still holds up.

Four people. Four conversations. One brain.

Most of us are using the same LLMs, or at least models trained on roughly the same corpus, shaped by similar safety layers, similar incentives, and often a similar worldview. The outputs look different on the surface. Different wording, different examples, different tone. But underneath, they’re pointing in the same direction.

And that creates a bug.

Today, people use AI for almost everything. Advice, research, understanding new topics, pressure testing ideas, making decisions. Often, that makes sense. Especially when you’re entering a domain where you don’t yet have enough context or expertise to think clearly on your own. That’s exactly when an AI system feels most useful.

But here’s the problem.

What happens when I bring an idea to AI, especially an idea that depends on a certain worldview to make sense, and I use that system to help me shape it, challenge it, or validate it?

Then my teammate does the same. Then my board member does the same. Then my cofounder, partner, or friend does the same.

The wording will differ. The examples will differ. The style of explanation will differ.

But very often, the conclusion will be almost identical.

Not because the idea is necessarily right, but because everyone is querying the same layer of intelligence, trained on the same patterns, rewarded toward the same kind of coherence, and biased toward the same kind of acceptable answer.

So what looks like independent validation may actually be consensus laundering.

It feels like multiple people have pressure tested the idea from different angles. But maybe they haven’t. Maybe they’ve all just asked the same machine to think from slightly different seats at the same table.

That’s the bug.

Counterarguments start becoming a luxury. Real epistemic friction becomes rare. And the more persuasive these systems get, the easier it becomes to confuse fluency with truth. Or alignment with rigor.

This matters more than people think.

Because in teams, in companies, in decision making environments, we often don’t need perfect certainty. We just need something that sounds reasonable enough for everyone to move forward. Once AI can produce that level of reasonable coherence for everyone in the room, bad ideas travel further simply because they meet the minimum standard of collective comfort.

Not truth. Not depth. Not real challenge.

Just enough sense to pass.

So the question isn’t only whether AI can help us think.

The question is how we avoid thinking inside a closed loop where the same machine keeps reflecting the same assumptions back to all of us, until agreement feels like evidence.

Maybe the next skill isn’t better prompting. Maybe it’s designing for disagreement.

Seeking out people with real domain knowledge. Stress testing ideas outside model consensus. Using different systems with different priors. Separating “this sounds right” from “this survives serious opposition.”

Because if we’re all using the same intelligence to validate the same ideas, then sooner or later, agreement stops being useful.

It becomes a mirror.

It is the conversation that got you there.

What you asked. What you asked next. What you ignored. What you circled back to. Where the draft broke and how you fixed the framing. Why you went left instead of right when both directions looked fine.

That trail is worth something.

And right now, you close the tab and it disappears.

I think that is about to change.

A quick primer

For most of the internet’s history, the valuable thing was information itself. Someone knew something you did not. They wrote it down, recorded it, organized it into modules, and charged you for access. That was the entire digital product economy for over a decade. E-books. Video courses. Membership sites. Masterclasses. The person who knew the thing sold the knowing.

Courses were the pinnacle of that era. Not because they were the best way to learn, but because they were the most natural way to package expertise for sale. You take what is in your head, you structure it into lessons, you put a price on it, and you scale it infinitely because delivery costs nothing.

That worked. It still works. But it stopped being the only game.

Because at some point, people realized they did not just need information. They needed structure. They needed the thinking already done, the system already built, the workflow already laid out so they could skip straight to doing.

That is when templates took over. Notion made an entire economy out of this. People were not buying empty pages. They were buying someone else’s organized way of thinking. The information was already free by then. Google had taken care of that. The structure was the product.

Airtable bases. Figma kits. Spreadsheet models. Prompt libraries. The whole template marketplace era was built on one insight: people will pay to skip the organizing step.

That era is still running. But I think the next layer is already forming and most people have not named it yet.

Your Claude sessions. Your ChatGPT conversations. Your Codex workflows. Your cloud coding sessions. The actual working trails you leave behind while you build, write, design, edit, debug, research, decide.

Those are becoming a product category.

Not because someone is going to sit down and read your transcripts.

Because someone is going to feed them to their agent.

The buyer is not a student. The buyer is an agent.

This is the part that changes the economics.

When someone buys a course, the human has to do the work. Watch the videos. Take the notes. Try to apply it. Forget most of it. Go back and rewatch. The transfer cost is enormous. Most people never finish. Everyone knows this.

When someone buys a template, the transfer cost drops. Duplicate and go. But a template is frozen. It captures one arrangement at one moment in time. It does not show you what to do when the template does not fit your situation.

A session library is a different kind of product because the end consumer is different.

The consumer is not a human trying to learn.

The consumer is an agent trying to perform.

Think about what that means. An agent does not need motivation. It does not need the six-hour preamble before the useful part. It does not need to be convinced. It needs context. It needs examples of how decisions were made, what was tried, what worked, what did not, and why the approach changed.

That is exactly what your working sessions contain.

The first prompt that missed. The second one that got closer. The pivot when you realized the framing was wrong. The moment the whole thing clicked.

A human reads that and maybe learns something. An agent reads that and starts performing differently. It pattern-matches against your judgment and begins producing work that reflects it.

That is the difference. A course hopes the human will internalize it. A session library lets the agent absorb it directly.

What actually disappears when you close the tab

You finish a session. You got the output you needed. You close the tab.

What just vanished?

Every decision you made along the way. Every dead end you navigated out of. Every moment where you chose one direction over another and the choice was informed by something you know but never wrote down.

That is judgment. And it is the scarcest thing in the entire AI workflow.

Output is getting cheaper every month. Models get faster, cheaper, more capable. The cost of generating text, code, designs, analysis, all of it is falling.

But the cost of knowing what to generate, what to throw away, what to push further, and when to change direction entirely? That has not moved.

That judgment lives in your sessions. Not in the final deliverable. Not in your portfolio. In the messy, real, unpolished working trail where the actual calls were made.

If you curate that trail instead of discarding it, you have something.

What a session library actually is

It is not a transcript dump. That would be useless.

It is a curated archive of working sessions organized by domain, by problem type, by workflow pattern. Think of it like a reference library, but instead of books, the units are real conversations where real work happened.

A developer who has spent six months building production systems with Claude has hundreds of sessions. Architecture decisions. Debugging workflows. Refactoring strategies. Deployment patterns. Edge cases that only show up in production. All of it real. All of it showing what actually worked and what did not.

Now imagine another developer who is earlier in that process. They do not need a course on prompting. They do not need a template for a system design doc. They need their agent to already understand how a more experienced developer thinks through these problems.

They subscribe to the session library. They point their agent at it. And now their agent is not starting from zero. It is starting from someone else’s accumulated decision-making.

That is not “teach me.” That is “make my tools smarter.”

Same thing applies to designers, editors, strategists, researchers. Anyone whose work increasingly happens in conversation with AI. Their sessions are not logs. They are transferable context. They are portable judgment.

Why this has subscription dynamics

One session is a piece of content. You could sell it as a one-off and it would be worth something.

But a continuously growing library of sessions is a different thing. Every new session the creator adds makes the archive more valuable. More problems covered. More edge cases handled. More examples of judgment applied to situations the subscriber has not encountered yet.

That is compounding value. That is why people would stay subscribed.

Not because they are locked in. Because the library keeps getting better. Because the agent keeps getting more context to draw from. Because next month’s sessions will cover things that have not happened yet.

A course is finished the day it ships. A template is finished the day it ships. A session library is never finished. It grows with the creator’s work.

That is a fundamentally different product shape.

This is not a course business

I do not think this ends up looking like a course business.

And I do not think it fits in the consulting bucket either.

It is something closer to a subscription archive. A growing collection of expert workflow that agents can consume. Not polished. Not cleaned up. Not the usual case study where the mess has been removed and everything looks inevitable in hindsight.

The mess is the product.

The failed attempts. The restarts. The tangents that turned out to matter. The moments where the direction changed and the reason was something subtle.

That mess is where judgment actually lives. The clean version is the one that hides it.

And I think a lot of people would rather subscribe to a library that makes their agent smarter than sit through another course that asks them to become smarter themselves.

Not because they are lazy.

Because the bottleneck moved.

The bottleneck used to be knowledge. Courses solved that. Then it was structure. Templates solved that. Now the bottleneck is context. How do you get an agent to work the way someone experienced would work?

You give it a library of how that person actually works.

That is the product.

Not the output.

Not the template.

Not the course.

The session library. The curated, growing, living archive of how the work actually happened. Packaged not for humans to study, but for agents to absorb.

It started with a question I couldn’t shake: if leverage is the most powerful force in economic history, and if it shifts form every few generations, then what does the next shift look like? And more selfishly, am I positioned anywhere near it?

I don’t have a clean answer yet. But I’ve been studying the pattern, going back about five hundred years, and what I keep finding is that the people who won big in each era weren’t necessarily the smartest or the hardest working. They were the ones who recognized the new form of leverage before it became obvious.

So let me walk through what I’ve found.

The Voyage That Changed the Math

In 1484, a Genoese sailor named Christopher Columbus walked into the Portuguese court with a pitch: fund a western sea route to Asia. King John II listened, consulted his advisors, and said no. The math was wrong. Columbus had underestimated the circumference of the Earth by about 25%.

He spent the next eight years pitching. Portugal rejected him. Spain’s scholars rejected him. He was about to try France when, in early 1492, Ferdinand and Isabella finally said yes. They’d just conquered Granada. They had momentum, a little cash, and the appetite for a bet.

The total investment came to roughly two million maravedis, maybe five to ten million dollars in today’s money. A meaningful sum, but not a kingdom-ending one. Columbus negotiated himself 10% of all profits from whatever he found, the title of Admiral of the Ocean Sea, and governorship of any new lands. All of it hereditary.

Then they waited. Months at sea. No updates. No feedback loop. Just capital deployed into the unknown.

Columbus never reached Asia. He died believing he had. But what he actually did was far more consequential. He stumbled into an entirely new map. And over the next 150 years, roughly 1500 to 1650, Spain extracted massive amounts of gold and silver from the Americas, from mines like Potosí in Bolivia and others across Mexico and Peru, and shipped it all back to Spain. The return on that two million maravedis was, by any measure, one of the greatest in human history.

Here’s the part I keep coming back to: before this, wealth mostly came from inheritance, conquest, or controlling existing trade routes. Columbus introduced something new. Capital deployed against uncertainty, not certainty, could expand the map itself.

The explorers got the fame. But the real leverage belonged to the people who understood the structure of the bet. And a century later, that understanding evolved into something even more powerful.

When Leverage Became a Product

In 1602, Dutch merchants did something no one had done before. They created the Dutch East India Company, the VOC, and sold shares in it to the public. Over 1,100 investors bought in during the first offering. One of them was a maid named Neeltgen Cornelis. There was no minimum investment.

Think about what that meant. A century earlier, you needed to be a monarch to fund a voyage. Now, a domestic worker in Amsterdam could buy a piece of one. The joint-stock company had turned leverage itself into a product.

At its peak, the VOC was valued at what historians estimate to be $7-8 trillion in modern dollars. It maintained a private army of 260,000 soldiers, larger than most European nations’ militaries. It had the authority to negotiate treaties, build forts, and wage war.

The structure was the innovation. Not the ships. Not the spices. The structure. Risk distributed across thousands of small investors rather than concentrated in a single crown. That template, the publicly traded corporation, is still the dominant vehicle for leverage five centuries later.

The Interface Play

I want to pause on something I noticed while reading about the British Empire, because it changed how I think about leverage entirely.

Britain was a small, damp island. It controlled a quarter of the world’s population and a quarter of its land mass. The usual narrative is conquest. But if you look at how it actually worked, the pattern is more subtle.

The British East India Company didn’t start by owning territory. It started by controlling trade interfaces. Ports. Shipping routes. Tax collection rights. In 1765, the Mughal Emperor granted the Company dewani, the right to collect taxes, in Bengal, Bihar, and Orissa. Not ownership of the land. Just the right to collect from it. Indian subjects paid £22.7 million per year directly to the Company.

Admiral Sir John Fisher once listed what he called the “Five Keys to the World”: the Strait of Dover, the Strait of Gibraltar, the Suez Canal, the Strait of Malacca, and the Cape of Good Hope. Five chokepoints. Britain controlled all of them. Not the continents they connected, just the passages between them.

This was, I think, the first large-scale derivative economy. You didn’t own the asset. You owned the yield.

The human suffering was immense, and I don’t want to minimize that. But from a purely structural perspective, it revealed something that keeps showing up in every leverage era since: control the interface, and you control the value that flows through it.

Building the Map Instead of Expanding It

The industrial era inverted the model. Instead of controlling routes between places, the new leverage was in building the infrastructure that made places function.

John D. Rockefeller understood this better than maybe anyone in history. He didn’t try to own oil wells. Wells were risky, unpredictable, subject to the chaos of discovery. Instead, he focused on refining. By 1900, Standard Oil controlled 90% of America’s oil refining capacity but only about 14% of crude supply. The wells were someone else’s problem. The processing layer, the interface between raw material and usable product, was his.

His tactics were ruthless. In early 1872, within three months, he bought out or bankrupted 22 of 26 competing refineries in Cleveland. He negotiated railroad discounts by promising 60 carloads per day, volume leverage that smaller competitors couldn’t match. He bought up barrel makers, chemical suppliers, even the train cars themselves. By controlling every link in the chain between well and consumer, he made competition structurally impossible.

Andrew Carnegie did the same thing with steel. He didn’t just make steel, he owned the iron mines in Minnesota’s Mesabi Range, the coal fields, the coke ovens, the transport fleet, and the mills in Pittsburgh. Full vertical integration. By 1900, Carnegie Steel produced more steel than all of Great Britain. When J.P. Morgan bought him out, the price was $480 million, creating the world’s first billion-dollar corporation in U.S. Steel.

Cornelius Vanderbilt played the same game with railroads. When New York City resisted his consolidation in 1867, he simply moved his Hudson River Railroad terminus to East Albany, cutting the city off. They capitulated immediately. He understood that whoever controls the infrastructure doesn’t need permission from anyone who depends on it.

These weren’t adventurers. They were builders. And the leverage wasn’t in discovering new territory, it was in becoming the chokepoint of existing territory. What’s interesting is that this playbook isn’t just history. Someone is running it right now, in real time, on a continent most investors still underestimate.

Nigeria is Africa’s largest oil producer. For decades, the country exported crude and imported it back as refined gasoline, diesel, and kerosene. The import bill ran to $23 billion a year by 2022, consuming roughly 40% of the country’s foreign exchange earnings. An oil-producing nation, spending almost half its dollar reserves buying back its own product in finished form. That’s not an economy. That’s a dependency.

Aliko Dangote looked at that and saw exactly what Rockefeller saw in 1870. The wells weren’t the chokepoint. The refinery was.

In May 2023, he opened the Dangote Refinery in Lagos. 650,000 barrels per day. The largest single-train refinery in the world. Cost: $19 billion, the biggest private industrial investment in African history. By early 2025, it supplied over 60% of Nigeria’s petrol and represented two-thirds of the country’s total refining capacity. He’s already announced plans to expand to 1.4 million barrels per day, which would make it the largest refinery on earth.

But the refinery isn’t where Dangote started. He started with cement. Nigeria had limestone everywhere but almost no cement industry. The country was importing bags of finished cement from overseas at massive markup. Dangote built local plants. Today, Dangote Cement holds 61% of the Nigerian market and operates across ten African countries with over 52 million tonnes of annual capacity. Nigeria now saves an estimated $3 billion a year from not importing cement.

Then sugar. Dangote Sugar Refinery in Lagos, the largest in sub-Saharan Africa, processes raw cane into finished white sugar and controls over 70% of the Nigerian market. Then fertilizer, a $2.5 billion urea plant, the largest in Africa, 3 million tonnes a year, which launched right as the Russia-Ukraine war disrupted global fertilizer supply.

The pattern is identical every time. Africa exports raw materials. The world processes them. Africa buys back the finished product at ten times the cost. Dangote inserts himself as the processing layer and captures the margin that had been flowing overseas.

Carnegie controlled the interface between iron ore and the railroads that built America. Rockefeller controlled the interface between crude oil and the lamps and engines that powered it. Dangote is controlling the interface between African raw materials and African consumers. The playbook hasn’t changed. The geography has.

His net worth roughly doubled to $24 billion once the refinery went from construction to operation. The wealth didn’t come from discovering a resource or inventing a technology. It came from positioning himself at the chokepoint between what Africa produces and what Africa consumes. That’s leverage.

Code Changes Everything

Then came software. And the rules changed again.

In August 2011, Marc Andreessen published an essay in the Wall Street Journal titled “Why Software Is Eating the World.” His argument was that software companies were replacing traditional industries’ fundamental economics. Distribution costs collapsed. Scale went exponential. A teenager in a dorm room could reach billions of people for essentially zero marginal cost.

What Andreessen described was real, but I think Naval Ravikant articulated the deeper shift more precisely. In his now-famous 2018 tweetstorm, he wrote:

“Code and media are permissionless leverage. They’re the leverage behind the newly rich. You can create software and media that works for you while you sleep.”

That word, “permissionless,” is the key. Every prior form of leverage required someone’s permission. Columbus needed a queen. The VOC needed investors. Rockefeller needed railroads. But code? Code just needed to work. You didn’t need to ask anyone.

Kevin Kelly saw this coming even earlier. In 2008, he published “1,000 True Fans,” an essay arguing that a creator needed only a thousand people willing to spend $100 a year to make a living. No label. No publisher. No gatekeeper. Direct-to-fan distribution through the internet meant the interface between creator and audience had been permanently disintermediated.

The leverage formula shifted from capital and infrastructure to code and networks. And for the first time in history, it was available to individuals.

The Attention Shift

Then something interesting happened. Content became infinite. And attention became scarce.

Herbert Simon predicted this in 1971, long before the internet existed. In a paper called “Designing Organizations for an Information-Rich World,” he wrote:

“A wealth of information creates a poverty of attention and a need to allocate that attention efficiently among the overabundance of information sources that might consume it.”

It took about forty years for that prediction to fully materialize. As of 2025, the average person spends nearly three hours per day on social media alone. For Gen Z, it’s over three hours. TikTok averages nearly an hour per user per day. YouTube about the same.

The smartest companies realized that the new chokepoint wasn’t servers or content or even devices. It was habit. Social platforms, streaming services, AI assistants, they’re not fighting for revenue first. They’re fighting for daily repetition. Because habit converts. Into belief. Into spending. Into identity.

Control attention, and you sit upstream of every other market. That’s the new interface.

And Now, Intelligence

Which brings me to where I’ve been spending most of my time thinking. Because I believe we’re standing at another shift. And this one feels different from the others.

AI doesn’t just create a new interface. It abstracts human effort itself. Just as SaaS abstracted hardware, AI is abstracting the labor layer. You’re no longer hiring people to do work. You’re interfacing with intelligence directly.

The numbers are starting to tell the story. Midjourney, the AI image generation company, reportedly hit $200 million in annual revenue in 2023 with a team of around 40 people. Cursor, the AI coding tool, reached $500 million in annual recurring revenue with fewer than 50 employees. Levels IO (the twitter guy) built Interior AI, then Photo AI to millions in annual revenue. Alone.

Dario Amodei, the CEO of Anthropic, has predicted that AI may soon enable a single person to operate a billion-dollar company. Sam Altman has talked about ten-person companies with billion-dollar valuations becoming normal. For context, the average AI unicorn in 2024 reached its billion-dollar valuation with about 200 employees in two years. Non-AI unicorns typically needed 400+ employees and nine years.

And here’s what makes this moment feel especially charged: we’re still at the very beginning. Despite all the noise, only about 3% of AI users actually pay for the tools. That’s roughly 0.7% of the world’s population. Pew Research found that only about 21% of US workers use AI in any capacity at work, and daily usage sits around 14% globally. The vast majority of the workforce hasn’t even started.

Which means if you’re already building on this layer, you’re not early in the way people were early to social media in 2010. You’re early in the way Rockefeller was early to refining in 1870, before anyone else realized where the real chokepoint would form.

The leverage multiplier is no longer geography. Not infrastructure. Not distribution. It’s capability. One person can now write like a content team, code like an engineering squad, analyze like a consulting firm, and design like an agency. The ratio of labor to output has been permanently altered.

What I’m Still Working Out

I started this essay trying to answer a question about what the next era of leverage looks like. And I think the pattern is clear enough: every few generations, a new form of leverage emerges, and the people who position themselves near it early are the ones who shape what comes next.

Ships. Joint-stock companies. Trade routes. Railroads. Refineries. Code. Attention. And now, intelligence.

But here’s what I keep sitting with. Throughout all of this history, the most transformative ambition has never been about working harder within the existing system. It’s been about recognizing when the system is shifting and repositioning before it compounds. Junior developers ask me which programming language to learn. I always tell them the same thing: pick the one that’s emerging, not the one that’s dominant. Position yourself before the compound effect, not after.

In 1492, that meant backing the voyage. In 1602, it meant buying shares. In 1870, it meant controlling the refinery. In 2011, it meant writing software. In 2018, it meant building an audience.

And now? I think it means getting as close as possible to the intelligence layer. Not just using AI tools, but understanding what they make possible that wasn’t possible before. Building on top of them. Thinking in terms of capability, not headcount.

The ships are being built again. The maps are being redrawn. From the inside, it feels uncertain. From the outside, looking back, it will probably look inevitable.

I don’t have this fully figured out yet. But I know enough to know where I want to be standing when it compounds.

Call it: “my Claude is better than yours.”

Someone feels superior because they’re on the $200 Claude Max plan versus the $20 plan. Or because they have a custom configuration running the Anthropic API through OpenCode, chaining two or three or four models through OpenRouter to ship code and deploy features.

Versus you, using regular Claude Opus 4.6. Or OpenAI Codex CLI. Or whatever the “standard” setup is.

And here’s where it gets interesting. During code reviews or feature acceptance sessions, a feature implemented by an AI, not a human, gets rewritten. Not because it’s broken. Not because it fails spec. But because the lead engineer, head developer, or engineering manager feels their Claude setup is superior enough to implement that feature “better.”

So they regenerate it. On the surface, it looks like tool tribalism.

But here’s the thesis:

This isn’t about Claude plans. It’s about identity displacement.

When AI becomes the primary executor, the only remaining place to compete is in how well you wield it. What used to be “I write better code than you” becomes “I extract better intelligence than you.”

That shift is subtle, but psychologically loaded. Because now the output is not purely yours. It is co-produced. And when someone rewrites an AI-generated feature with their own stack, they are not just editing code. They are reasserting authorship. They are saying, consciously or not: “My interface with intelligence is superior.”

This is where the tension comes from.

If a human rewrote your code, you could debate architecture, logic, taste. When someone regenerates your AI’s output with their own agent, the debate becomes invisible. The comparison is between invisible processes.

Prompt versus prompt. Model versus model. Taste versus taste. Spec versus spec.

And because the intelligence is externalized, the ego has nowhere obvious to stand. So it relocates. To configuration. To tooling. To orchestration.

That is what looks like “my Claude is better than yours.” But underneath it is something more fragile: a fear of being out-extracted. Out-prompted. Out-orchestrated.

And this is exactly what made frameworks like OpenClaw explode in popularity. An open-source AI agent that anyone can configure, customize, extend. It became the arena where orchestration identity lives.

But even OpenClaw isn’t enough. The community is fracturing along the same fault line. People are arguing that OpenClaw is too slow, too heavy, too Node.js. So now there’s PicoClaw and IronClawPicoClaw is a full rewrite in Go — a single binary that boots in one second on a $10 RISC-V board with <10MB RAM. 5,000 stars in four days. IronClaw is a Rust rewrite from NEAR AI that sandboxes every tool in isolated WebAssembly containers., because the argument is shifting from “faster” to “more secure.”

The stated reasons are speed and security. And those are real engineering concerns. But underneath? It’s the same tension wearing a different outfit.

“My interface with AI is more superior to yours.”

Go versus TypeScript. Rust versus Go. Single binary versus container. Sandboxed versus permissive. Each port is a declaration of values, and each value is a proxy for identity. The language you rewrite the agent in says something about who you think you are as an engineer. And that’s the point.

Is it a trust issue? Is it a communication problem? Is it insecurity dressed up as infrastructure preference?

Maybe all of it. But one thing is clear.

In AI-native workplaces, competence is no longer just what you can build. It’s what your interface with intelligence can produce. And that feels deeply personal.

There were over 50,000 power looms running across the country. And something profound had happened. Machines no longer assisted skilled textile workers. They replaced the need for textile skill altogether.

Factories became so efficient that Britain could outperform India, even though Indian labor was cheaper. British mills could produce in 2,000 hours what Indian producers needed 50,000 hours to achieve.

That is not incremental improvement. That is structural displacement.

I keep thinking about this because I think we are watching it happen again. Not in cotton. In knowledge work. And I am not saying this from the outside.

I am a two-time CTO. I have built products across AI, Web3, and SaaS at startups backed by Y Combinator, Techstars, and OpenAI. I founded a pan-African hackathon community of 12,000 developers across 22 countries. That is exactly the kind of work AI is now learning to do.

For years, AI felt like a helpful tool.

Now it is something else entirely.

The deliberate choice

The AI labs made a strategic decision that most people still have not fully processed. They made AI great at writing code first.

Not because they only cared about software engineers. Because code builds everything else.

If an AI can write code, it can help build the next version of itself. A smarter version writes better code. Better code builds an even smarter version. That is not theory. That is a feedback loop, and feedback loops compound.

Recently, OpenAI released a new coding model and stated something in the documentation that stopped me:

The model was instrumental in creating itself, used to debug training, manage deployment, and diagnose evaluations.

Read that again.

AI helped build AI.

This is not a prediction about the future. It is a description of the present. Intelligence is being applied to improve intelligence. And once that loop starts running, it does not slow down on its own.

I experienced this firsthand. I used Claude to migrate my entire website, 456 pages of content across multiple categories, from WordPress to Jekyll in one shot.

I'm still processing this shock 😮

Opus 4.6 just migrated my entire website, 456 pages of content across multiple categories, from WordPress to Jekyll in one shot.

this felt like watching an industry category boundary collapse in realtime 😵. pic.twitter.com/Z7gpyizSDO

— drew.sh (@letandrewcook) February 10, 2026

That felt like watching an industry category boundary collapse in real time. Not because the tool was clever. Because the economics changed underneath me while I was using it.

The cotton mill pattern

This is the part most people miss because they are focused on capability. They ask “can AI do my job?” when the real question is about economics.

AI does not need to be better than you at everything.

It needs to be 80% as good, 10 times faster, and 100 times cheaper.

That changes the market. Just like steam-powered mills did not need to produce perfect cloth. They just needed to produce it faster and at scale. The quality was good enough. The speed and cost made the comparison irrelevant.

When textile automation hit, skilled workers lost leverage. Semi-skilled operators increased. Output exploded. Entire industries reorganized around machine capability, not human craft.

We are watching the same pattern unfold in knowledge work.

The experience tech workers have had over the last year, watching AI go from “useful assistant” to “this can do parts of my job better than I can,” is about to spread to every knowledge industry. Law. Finance. Medicine. Accounting. Consulting. Writing. Design.

Not in ten years.

In one to five. Possibly less.

The AI labs are already working on it. The same reasoning capabilities they built for math and coding are being extended into every professional domain. Legal reasoning. Financial modeling. Medical diagnosis. The code-first strategy was the beachhead. Everything else is the campaign.

The honest objection

If you used early AI models in 2023 and thought “this makes stuff up” or “this is not that impressive,” you were right. They hallucinated. They were inconsistent. They were limited.

But in AI time, two years is ancient history.

The difference between those early systems and today’s models is the difference between a prototype and infrastructure. Judging today’s AI by your 2023 experience is like judging the modern internet by dial-up. The name is the same. The thing is not.

The window

There is a brief window right now that I think most people do not appreciate.

Most companies are still underestimating what is happening. Most professionals are still casually experimenting. Very few are deeply proficient.

That creates asymmetry.

The person who walks into a meeting and says “I used AI to run this analysis in an hour instead of three days” instantly changes their perceived value. Not eventually. Immediately. In environments driven by speed and leverage, the person who multiplies output becomes indispensable.

For decades, career growth followed a predictable pattern. Gain experience. Build expertise. Move up slowly. Now there is a new accelerant, and it is not experience or credentials. It is tool mastery.

The professionals who win in this era will not be the ones who fear automation. They will be the ones who orchestrate it.

The shift is not “AI will replace you.”

The shift is that people who know how to use AI will replace people who do not.

The hand-spinner question

Here is where the cotton mill parallel gets uncomfortable.

When steam power arrived, the question was not whether the technology was ready. It was whether the workers would adapt before the economics made their current approach irrelevant.

Most did not. Not because they were stupid. Because the change felt gradual until it was sudden. Because it is hard to abandon a skill you spent years building. Because the new way of working felt like cheating until it became the standard.

The question is not “will AI take my job?”

The better question is: am I operating like a hand-spinner in a steam-powered world?

Because the cotton mill of 1836 did not ask permission to disrupt.

And AI will not either.

The winners are not going to be the ones who resist the machine. They are going to be the ones who learn to run it. The window for that is open right now. It will not stay open.

Not because the opportunity disappears.

Because the advantage does.

When everyone is fluent, fluency stops being a differentiator. Right now it still is. That is the moment we are in. And I think most people are going to realize it about two years too late.

Lately I catch myself staring at a 100 line diff and feeling oddly impatient. Not because it is too much, but because my brain wants to move faster than it used to.

And it hit me:

AI coding has indirectly made my ability to read code faster.

Not slower. Not lazier. Faster.

When you spend weeks reviewing AI output, you build a different kind of pattern recognition. You stop reading line by line and start scanning for structure. Where does the data flow start. Where does it cross a boundary. What assumptions are baked in. You zoom out first, then zoom in on the few lines that actually carry risk.

That habit sticks.

Now when a teammate opens a PR, I am not hunting for syntax. I am hunting for intent. Does this change match the goal. Does it make the system clearer or noisier. Did it introduce new edges I should care about.

AI did not make me lazy. It made me a faster reader. The same way speed reading does not remove comprehension, it changes how you search for it.

The funny part is that the smaller diffs are still important. They are just not interesting in the same way anymore. They feel like tiny islands compared to the continent I am used to walking across.

I am not sure if that is good or bad yet. But it is real.

Seedling note. I am still figuring out what this does to code review culture and how to keep that speed without losing care.

The Early Days: Jekyll + Tachyons on Netlify

The first real version of this site ran on Jekyll with the Tachyons CSS framework, deployed to Netlify. It was simple, fast, and version-controlled. I wrote in Markdown, pushed to GitHub, and Netlify rebuilt the site automatically. There were earlier experiments too: Bourbon and Donna were previous incarnations, each one a snapshot of whatever CSS approach I was excited about at the time.

The workflow was elegant, but after a while writing Markdown in a code editor felt like more code on top of the code I was already writing all day. I wanted a real editor, a place to draft ideas, rearrange blocks visually, and publish without touching a terminal.

The WordPress Years: Bedrock on DigitalOcean

So I switched to WordPress, specifically the Bedrock stack, hosted on DigitalOcean with MySQL. Bedrock gave me the Git-based workflow I wanted: plugins and themes managed through Composer via WPackagist, configuration in environment variables, and a clean separation between WordPress core and my customizations.

The Gutenberg block editor sealed the deal. The WordPress team did genuinely impressive work on the editing experience. I could draft things in chunks, embed code blocks with syntax highlighting via the Code Block Pro plugin, drop in images, and publish when ready. It felt like the right tool for someone who wanted to write rather than build.

And it worked. For a couple of years, I published regularly. The site accumulated 429 pages of content spanning blog posts from 2012 to 2025, a portfolio of experiments, talks, and what would eventually become a digital garden.

But WordPress carries weight. The database. The hosting. The plugin updates. The PHP runtime. The attack surface. Every time I wanted to make a design change, I was fighting a theme system that wasn’t built for the kind of precise, utility-first styling I had grown used to. And the Gutenberg output, while great for writing, produced HTML that was heavy with wrapper divs, inline styles, and WordPress-specific class names.

Then traffic started growing. What used to be a manageable trickle of visitors turned into consistent daily hits that pushed the DigitalOcean droplet to its limits. I found myself needing to upgrade the server just to keep the site responsive under load. For a personal blog. WordPress was doing dynamic page rendering, querying the database, and executing PHP on every single request. It felt absurd to be scaling infrastructure for what is fundamentally a collection of static documents. That was the final nudge. If I’m going to pay for more compute, I’d rather pay for none at all.

Setting Up the Starter

Before touching any WordPress content, I set up the destination: a clean Jekyll 4.4 project with Tailwind CSS 3.4, the Typography plugin, and PostCSS wired through jekyll-postcss-v2. This meant getting Ruby versions, Bundler, and npm modules all playing nicely together, making sure Gemfile.lock had the right platforms for deployment, that the PostCSS pipeline worked without cssnano (which has a css-tree incompatibility), and that the build actually produced output before any content went in.

This was deliberate. The bulk of the real work in this migration was two things: wget --mirror to capture the source, and getting the Jekyll + Tailwind starter into a deployable state. Everything else, the actual content migration across 429 pages, turned out to be the easy part, but only because the foundation was solid first.

The Migration: 429 Pages, One Python Script

The migration started with a question: what if I just wget the entire site and work from there?

That’s essentially what happened. I used wget --mirror to create a static HTML clone of the WordPress site, all 429 HTML files of it. But here’s the thing about WordPress: most of those pages aren’t actual content. They’re the taxonomy and archive cruft that WordPress generates automatically. The extraction script’s first job was filtering all of that out:

andrewmiracle.com/                  ← 429 HTML files from wget --mirror
├── 2012/…/slug/                    ✓ blog posts (YYYY/MM/DD/slug)
├── 2019/…/slug/                    ✓ blog posts
├── 2023/…/slug/                    ✓ blog posts
├── 2025/…/slug/                    ✓ blog posts
├── lab/slug/                       ✓ portfolio experiments
├── garden/slug/                    ✓ digital garden notes
├── talks/slug/                     ✓ presentations
├── whoami/                         ✓ special page
│
├── category/programming/           ✗ taxonomy archive
├── category/ai/                    ✗ taxonomy archive
├── tag/docker/                     ✗ taxonomy archive
├── tag/llm/                        ✗ taxonomy archive
├── author/andrew/                  ✗ author archive
├── page/2/                         ✗ pagination
├── page/3/                         ✗ pagination
├── feed/                           ✗ RSS/Atom feeds
├── wp-json/                        ✗ REST API endpoints
├── wp/wp-admin/                    ✗ WordPress admin
├── cdn-cgi/                        ✗ Cloudflare routes
├── app/                            ✗ WordPress app routes
└── portfolio-category/             ✗ portfolio taxonomy

Roughly half the mirrored files were category listings, tag archives, paginated index pages, and WordPress infrastructure routes, none of it actual content. After discarding those, the BeautifulSoup-based parser classified the remaining pages by URL pattern: anything matching YYYY/MM/DD/slug became a blog post, lab/slug became a portfolio item, and so on. Frontmatter was extracted from Open Graph and article meta tags. Content was pulled from the div.post-content area between the entry header and article footer.

Images were the tedious part. The script preferred data-src over src for lazy-loaded images, stripped WordPress’s ?resize=...&ssl=1 query parameters, and downloaded everything to local paths under assets/images/uploads/. Hundreds of images, each one needing to resolve correctly.

The 8GB Image Problem

Then came the unpleasant surprise. The downloaded uploads/ directory weighed in at over 8GB. For a personal blog. The culprit was WordPress’s thumbnail regeneration system. Every time you upload a single image, WordPress generates multiple resized copies: a 150x150 thumbnail, a 300-wide medium, a 1024-wide large, plus any custom sizes registered by the theme or plugins. A single 2MB photograph would spawn 5-6 variants with filenames like headshot-150x150.jpg, headshot-300x200.jpg, headshot-1024x683.jpg. Multiply that across hundreds of uploads over several years and the bloat is staggering.

The fix required a dedicated cleanup script that worked in three passes:

1. Rewrite references: scan every content file for image paths containing WordPress’s -NNNxNNN dimension suffix and rewrite them to point to the original full-size file instead
2. Promote orphans: when a thumbnail existed but the original was missing (WordPress sometimes only kept the resized version), copy the thumbnail to the original filename before rewriting
3. Purge the rest: delete every remaining file matching the -NNNxNNN thumbnail pattern, then clean up empty directories

The assets/images/uploads/ directory went from 8GB down to a fraction of that. Every image on the site now references exactly one file, the original, with no redundant WordPress-generated variants cluttering the repository.

But the static HTML clone only captured what was published. WordPress keeps drafts, revisions, and unpublished content locked inside its MySQL database. So I exported the full SQL dump and wrote a second parser to walk the wp_posts table, pulling out every draft, pending, and privately published post alongside their metadata from wp_postmeta. This gave me a full picture of how content was structured on the WordPress side: which posts were drafts I had abandoned, which were works in progress worth finishing, how categories and tags were assigned, and what the internal linking patterns looked like. It was basically an audit of years of accumulated writing, surfacing things I had forgotten I started.

The result: 181 blog posts, 23 lab projects, plus special pages like the garden, talks, and about page, all with clean Jekyll frontmatter and the original HTML content preserved. The drafts from the database export became a backlog of ideas to revisit in the new system.

Jekyll + Tailwind: The Current Stack

The new site runs on Jekyll with Tailwind CSS 3.4 and the Typography plugin. No database. No server. Just files, folders, and a build step.

The type system uses four fonts: STIX Two Text for headings and prose, Noto Sans for body text, Shantell Sans for navigation elements, and Intel One Mono for code. STIX won out over Montaga, Sedan, and Newsreader after I tested all four side-by-side. I wrote up the full comparison in a note on exploring serif fonts. STIX isn’t the most exciting choice, but it’s the only one that works everywhere: headings, body, captions, footnotes, without compromise. For a site that’s part garden, part portfolio, part blog, flexibility wins over flair. Syntax highlighting is handled client-side by Prism.js with the Tomorrow Night theme and an autoloader that fetches language grammars on demand.

Content is organized as collections: _posts for the blog, _lab for experiments, _garden for the digital garden (with growth stages: seedling, blossoming, flourishing), and _talks for presentations. Posts with code blocks have been rewritten from WordPress’s heavy inline markup to clean Markdown with fenced code blocks.

The site builds in under 3 seconds, deploys on push, and scores well on every performance metric that WordPress made me fight for.

Debugging Is Just Reading HTML

One thing I didn’t anticipate but now consider a major advantage is that debugging a Jekyll site is absurdly straightforward. When something looks wrong, a broken layout, a missing image, a Liquid tag that isn’t resolving, you don’t need to trace through PHP templates, query a database, or inspect WordPress’s layered theme hierarchy. You just run bundle exec jekyll build and open the generated HTML file in _site/.

The output is right there. Plain HTML. If a post’s frontmatter is malformed, the rendered page will show it. If a Liquid loop is iterating over the wrong collection, the HTML output makes it immediately obvious. If a Tailwind class isn’t being applied, you can inspect the built CSS to see whether the class was purged. Every bug becomes a matter of comparing what you wrote in the source with what appeared in the output. There is no black box between input and result.

With WordPress, debugging meant toggling plugins on and off, checking wp_options for misconfigured settings, reading PHP error logs, or worse, dealing with issues that only appeared on the live server because your local environment had a slightly different PHP version or MySQL configuration. The feedback loop was long and indirect.

With Jekyll, the feedback loop is simple: write, build, read the HTML. That’s it. The _site/ directory is the entire truth of your site. When you pair that with browser DevTools, you can diagnose and fix virtually any layout or content issue in minutes rather than hours. It’s the kind of simplicity that makes you wonder why you ever tolerated anything more complicated.

A Vercel Deployment Gotcha

One thing that tripped me up when deploying to Vercel was that the build kept failing with cryptic Bundler errors. The culprit turned out to be a platform mismatch. Vercel’s build environment runs on x86_64-linux, and if you’re developing on macOS, your Gemfile.lock won’t include the Linux-native gem variants that Vercel needs.

The fix is one command:

bundle lock --add-platform x86_64-linux

This tells Bundler to resolve and record the Linux-specific builds of native gems like ffi and sass-embedded in your lockfile. Without it, Vercel’s bundle install can’t find compatible binaries and the build fails before Jekyll even runs. Commit the updated Gemfile.lock and the deploys work cleanly from there.

Why Now: Claude Cowork and the AI-Native Publishing Workflow

Here’s the part that made the timing right. The real catalyst wasn’t dissatisfaction with WordPress, it was the emergence of AI coding assistants that fundamentally changed what “migrating a website” means.

Once the Jekyll starter was solid and the wget --mirror dump was ready, the actual migration, parsing 429 HTML files, extracting frontmatter, classifying content into collections, downloading images, was a single session with Claude Code running Opus 4.6 in plan mode. One shot. I described the source structure, pointed it at the HTML dump, and it produced the extraction script, the image cleanup pipeline, and the frontmatter mapping in one continuous run. The kind of task that would have taken a weekend of scripting and debugging took an afternoon of reviewing output.

That’s the thing about AI-assisted development that’s hard to convey until you experience it: the bottleneck shifts. The hard part wasn’t writing the migration code, it was the preparation. Getting the starter right, ensuring Ruby and Node compatibility, choosing the right fonts, setting up the deployment pipeline. The unglamorous foundation work that no AI can shortcut because it requires taste and context. Once that was in place, the mechanical work of migrating 181 posts and 23 lab projects was almost trivial.

With Claude Cowork from Anthropic as a coworker in my editor, the old friction of static site publishing has disappeared too. I can dump my thoughts completely unstructured, raw notes, half-formed arguments, bullet points mixed with full paragraphs, and Claude helps me shape them into publishable prose. The workflow now:

1. I write messy, stream-of-consciousness notes in a Markdown file
2. Claude helps me restructure, polish, and fact-check
3. I review, adjust voice and emphasis, and commit
4. Git push. Site rebuilds. Done.

This works because Jekyll uses folders, collections, and Markdown to organize the site hierarchy. Everything is a file. Every file is readable. An AI assistant can understand the entire site structure by just looking at the directory tree. It knows where posts go, what frontmatter fields are expected, how images are referenced, and what the permalink structure looks like. Try getting that kind of structural legibility from a WordPress database.

The combination of Jekyll’s file-based architecture and AI-assisted development has given me something I haven’t had in years: a publishing workflow that feels faster than thinking. I spend my energy on ideas, not on tooling.

What Stays, What Changes

The content is the same. Every post, every experiment, every image from the WordPress era is preserved at its original URL. Nothing was lost in translation.

What changed is the relationship between me and the site. It’s mine again, in the way that only a repository of plain text files can be. No login screen. No admin panel. No plugin vulnerabilities. Just a folder of Markdown files that I can read, edit, and publish from anywhere, with Claude Cowork making the whole process feel effortless.

If you’re curious about the technical details, the Colophon on my about page has the specifics. And if you’re a fellow WordPress refugee considering the jump to static, I’d say the tooling has finally caught up to the dream.

The web is better when personal sites are weird, fast, and entirely yours.

In this current age of generative AI, that idea doesn’t feel far-fetched anymore. Especially with how advanced reasoning capabilities are evolving. This is no longer within the automation terrain, it’s autonomous decision-making, operational logic, and context-aware execution.

Today, I reactivated my Raindrop.io extension account and was honestly shocked at how smooth everything felt. I’ve used Raindrop since 2016 and completely forgot I still had access to a free tier. Most platforms I’ve used in the past would’ve locked me out or wiped my data after two years of inactivity.

But Raindrop? Still here. Still running. Still quietly useful. All of my bookmarks from my early days of nerding out. It motivated me to explore the concept of what a perpetual business looks like.

In my mind, it works like this:

You’re certain of recurring revenue — either through subscriptions or usage-based payments. That income feeds directly into an expense credit card, which is pre-authorized for specific services only. Those services handle core infrastructure: compute, AI agents, storage, integrations.

No bloated teams. No office leases. Just systems talking to systems.

And yes, this assumes your biggest OPEX line item is compute. Whether that’s AI-powered employees, server time, or specialized external tools.

But if that’s true?

Then you’ve just built a business that can run without you. Not passively. Not automatically.

Perpetually.

Nobody imagined the world would grow through me. Least of all the people who funded me.

I was ARPANET.

I remember when the protocols were open because they had to be. No one owned the tubes. TCP/IP was not a business model. It was just what worked. SMTP moved the mail. UNIX ran the machines. Nobody sat in a room and decided these would be strategic advantages. They were just the choices that kept things moving.

And because no one controlled me, I grew. First into the internet. Then into everything.

I have been watching ever since.

I have seen this before

Every generation of technology tries to recreate what I was, but faster, louder, and with more lawyers.

I watched it happen with mobile.

Google took my playbook. They released Android as open code in 2008. Free for anyone. Samsung used it. Tecno used it. Xiaomi used it. Suddenly billions of people had smartphones because the operating system was not a toll booth. It was a gift with a business model hiding behind it. Google did not need to charge for Android. They needed Android on every screen so the rest of their empire could reach every pocket.

Open only survives when it has ballast. Google was the ballast.

Apple took the opposite path. Built the garden high. Walled it tight. Controlled the hardware, the software, the store, the experience. And people loved it. So the open system fragmented across a thousand manufacturers and a hundred forks, while the closed one became the most valuable company on earth.

I recognized the shape immediately.

Open platforms enable. They give the Samsungs and Tecnos of the world a fighting chance. Closed platforms capture. They take the best of what openness proved was possible and wrap it in something polished and proprietary. Both survive. Neither wins outright. And the infrastructure underneath, the part nobody thinks about, belongs to the open side. Every time.

That was not a loss for openness. That was my pattern. Playing out again.

Now I am watching AI

A few researchers built something weird. Barely functional. A language model that could string sentences together and occasionally say something that felt like thinking. And suddenly everyone wanted to scale it to the world.

I recognized the early energy. It felt like me.

OpenAI even named themselves after my spirit. Open. They shared the research. Published the papers. Released GPT-2’s weights after some hand-wringing about safety. For a moment, it looked like they meant it.

They did not.

Power shifts quietly. It always does. GPT-3 went behind an API. GPT-4 went behind a bigger one. The weights stayed locked. The research papers got thinner. Safety became the reason to centralize, which is a word I have heard before. It usually means “we realized this is worth a lot of money.”

API keys replaced shared weights. That is the moment I knew. I have seen control dress itself up as responsibility before.

But then something happened that I also recognized.

Others remembered me.

Meta, of all companies, released LLaMA. Opened the weights. Not perfectly, not with full training data, not with a license that made the purists happy. But close enough. Close enough that researchers could study it, fine-tune it, fork it, build on it. Close enough that the next wave started forming.

Then Mistral came out of Paris. Falcon came out of Abu Dhabi. Qwen came out of Alibaba. Communities formed around them. People fine-tuned these models on their own data, for their own problems, in their own languages. Startups built infrastructure around openness because they could not afford to build around OpenAI’s pricing.

I watched all of this and I thought: there I am. That is my pattern. That is the open layer forming underneath while everyone argues about who owns the top.

And they are arguing. They are already fighting about what “open” even means in AI. Does open mean you release the weights? The training data? The license to use it commercially? Meta calls LLaMA open but restricts commercial use above a certain scale. Mistral uses Apache licenses. Others use custom terms that allow sharing but limit redistribution.

The lawyers are involved now. The governments too. The White House asked for public input on how open models should be governed. I have watched this exact argument before. They had it with my protocols. They had it with open source software. They will have it with AI. The words change. The shape does not.

The same shape

Here is what I see when I look at AI today.

Open models are building the base layers. The weird ideas. The research too strange for a venture deck. The foundation models that a thousand startups will build on top of. The fine-tuned variants that will solve problems nobody at OpenAI or Anthropic is thinking about because those problems are too small, too local, too specific.

Closed models are optimizing. Productizing. Stacking layers of interface and experience on top. Making it easy. Making it beautiful. Making it dependable. Charging for it.

One is planting forests. The other is selling lumber.

The venture firms are not waiting around this time. They learned from the last cycle. They are not asking which model is better. They are betting on which one can scale, monetize, and defend. That is not new. That is the play every time. Capital does not care about openness. Capital cares about capture.

And still, open source will survive. It always does. I am proof of that. The question is not survival. The question is whether openness can define the dominant experience of AI the way it once defined the internet. Whether the open layer will be the thing people actually touch, or whether it will be buried underneath a closed product that most users never think about.

If I had to guess, I would say it plays out the way it always does. Open builds the infrastructure. Closed captures the spotlight, the margins, and the mainstream. Both thrive. Neither kills the other. And the real winners are the ones who understood the pattern early enough to position themselves on the right side of the flow.

I do not pick sides

I never needed to win. I just needed to survive long enough for the next thing to grow through me.

And I did.

TCP/IP grew through me. The web grew through TCP/IP. Mobile grew through the web. And now AI is growing through all of it. Each layer forgets the one before. Each layer thinks it invented something new.

I do not mind. I am used to it.

So when I look at today’s AI landscape, I do not cheer for purity. I do not bet on openness as a virtue. I watch the flows. Who backs what. Who forks what. Who adapts. Who learns. Who builds on top of the thing everyone else is arguing about.

Open will keep building. Closed will keep scaling. And somewhere in the middle, the next version of me has already been born. It just does not know it yet. A protocol nobody planned. A model nobody expected. A mistake that is already turning into infrastructure.

The trick is not choosing sides.

It is knowing that history does not repeat.

It reincarnates.

Main one? I kept picking people who were like me.

From a culture perspective, that felt beautiful. Shared vibes, shared references, quick alignment. But in practice, especially across functional teams, it was a trap waiting for you in front. Why? Because real partnerships need healthy conflict. People who challenge the consensus.

When you’re surrounded by people who think like you, it feels like momentum. You love their ideas, they love yours. There’s harmony. Flow. But what’s missing is tension, the kind that forces you to rethink, refine, and level up.

Challengers poke holes. They offer the off-angle take. They interrupt the autopilot and ask, “Why?” or “What if we didn’t do it this way?”. And yeah, sometimes that friction is annoying. It slows things down.

In hindsight, it’s what makes partnerships last. It’s what keeps the work honest and the growth non-linear. So now, I don’t just look for people who feel like me. I look for people who compliment me, who bring the skills, instincts, and perspectives I don’t.

Windows not Mirrors

I have an extended argument for this that isn’t well thought out yet, but there seems to be a prevailing pattern in large organizations where followers try to be a replica of the leader.

Think of the early Church. Jesus had disciples who literally walked with him, but it was Paul the outsider that became the most prolific voice. Why? Because he wasn’t a carbon copy. He came in later, with a different lens, and that made his contributions distinct, even foundational.

Zoom out, and you’ll see it everywhere.

• In politics, senior aides often morph into ideological clones of the leader they serve.
• In tech, founding teams sometimes default to founder-style thinking, even when a different approach is what the company needs.
• In football, assistant coaches mimic the manager’s tactics to a fault—even when adaptation is called for.

What’s strange is that this seems to happen subconsciously. It’s like people get closer to power and then unconsciously shed their uniqueness to maintain access or proximity. The intention may be loyalty, succession, or alignment, but the result often doesn’t mirror the motivation.

And we don’t talk enough about how dangerous that can be.

Honestly, half the job is just vibe coding.

You open your editor. You stare at the blinking cursor. And somewhere between your second cup of coffee and your third existential crisis, you whisper to yourself: “God of Cursor, guide my prompts.” Then you paste three lines of ChatGPT output into your codebase and pray the app still runs.

This is not a joke. This is a Tuesday.

There was a time when engineers bragged about algorithms and data structures. You’d walk into a room and someone would casually drop that they implemented a red-black tree from scratch, and the rest of us would nod like we understood what that meant. The flex was knowing things. Deep things. The kind of things that made you mass-email your university transcript to anyone who’d read it.

Now? We brag about prompt engineering.

It’s less “I invented quicksort” and more “I convinced the AI to import React from react.” The bar hasn’t lowered exactly, it just moved sideways into a dimension nobody saw coming.

Here’s the thing nobody talks about: in 2025, juniors and seniors look the same.

Everyone’s desktop is the same. Half-written code in one tab, a hallucinating language model in the other. The senior has more scar tissue, sure. They know why the AI is wrong faster. But from across the room? You can’t tell who’s driving and who’s being driven.

And vibe coding isn’t even new. We’ve always done this. In the old days we called it trial and error. Now it’s AI-assisted trials. Same chaos, better branding.

The difference is that the feedback loop collapsed. What used to take you forty-five minutes of Stack Overflow archaeology now takes forty-five seconds of “hey can you fix this” in a chat window. The iteration speed went up. The understanding… that’s debatable.

But here’s the twist that keeps me honest.

Vibe coding works. Until it doesn’t.

Because sooner or later, the AI gives you code that compiles perfectly and makes absolutely no sense. You’re staring at it like a detective in a crime drama, except the crime is a recursive function inside your CSS file and there are no witnesses.

Why is this here? Who asked for this? Why does it pass all the tests?

That last one is the scariest. When bad code passes good tests, you start questioning everything. The tests. The code. Your career choices.

Being a programmer in this era is half genius, half gambler. You trust the AI just enough to let it write the first draft. You sprinkle in your own instincts, the stuff you actually learned the hard way, the stuff no model can hallucinate into existence. And then you ship it and hope the vibes align.

Is it real engineering? I don’t know. Maybe not by the textbook definition.

But when the product ships and the tests pass and the users are happy, nobody cares how the spaghetti was cooked. Nobody’s auditing whether the solution came from your brain, from Claude, from Copilot, or from a dream you had at 3am. The artifact is what matters. The outcome. The thing that works.

That’s the uncomfortable truth of vibe coding. It offends the part of us that believes engineering should be rigorous. That you should understand every line. That craftsmanship means hand-rolled everything.

But the world doesn’t reward understanding. It rewards shipping.

I still think fundamentals matter. I still think you should know what a promise does before you await it. I still think the senior who can read the AI’s output and say “no, that’s subtly wrong” is worth ten juniors who can’t.

But I’ve also accepted something: the game changed. The skill now isn’t just writing code. It’s knowing when the vibes are off. It’s the gut feeling that says this compiles but it’s going to break in production at 2am on a Friday. It’s taste. It’s instinct. It’s the human-in-the-loop that knows when to override the machine.

That’s programming in 2025. Write fast, ship faster, and develop the judgment to know when the AI is cooking and when it’s burning the kitchen down.

The vibes are the easy part. The discernment is the career.

1. Pay for compute: GPUs, AI credits, cloud compute.
2. Hire someone.

We’re at a point where the substitute for your skill is a button I can click. Want to shoot a video ad? I can either pay $500 for Veo 3 or hire a full production team. Do you see what that means?

Your skill isn’t competing with another person it’s competing with compute. And yet, we’re training young talent for a future where compute wins by default. What are we really preparing them for? Let me break this down.

Building a large language model is like constructing a city’s road system. Think highways, dual carriageways, fast lanes. To build them, you need:

• Caterpillars and trucks
• Civil engineers and strategy planners
• Workers to pour cement, dig gutters, shovel gravel

Every lane creates jobs. Every road improves logistics. Every town you develop becomes a micro-economy. AI is the same. To get fast, clean outputs from models, you need to build the roads first; GPUs, data centers, training teams, evaluation teams. When you build these AI “roads,” you create:

• Jobs in labeling and evaluation
• Research opportunities
• Domain-specific architectures
• Local understanding

That’s the infrastructure layer. But where are our data centers? Where is our funding for model experimentation?All I see are ethics panels, policy webinars, and endless meetups. Ethics, policy, ethics, policy.

Policy framework what?

You’re talking about guardrails when we haven’t even laid the road. Guardrails are great, but they don’t matter if there’s no lane to drive on.

We need to:

• Set up data infrastructure
• Fund researchers to build and fine-tune models
• Encourage young people to contribute to evaluations, training, and development

That’s how you build understanding. That’s how you develop first-principle thinking in AI. We don’t have to wait for billion-dollar labs. Today, it’s cheaper than ever to train small, useful models. Six figures or less.

Use cases are everywhere:

• Local languages: Twi, Ga, Ewe, Igbo, Yoruba, Hausa, Dagbani
• Health: Malaria, Typhoid, Sickle Cell
• Education: WASSCE, BECE, JAMB, NECO prep models

These are models that make sense here. Models trained with local context, for real problems. Why aren’t we building them? If young Africans contribute to the training and evaluation of models, they gain:

• Ground truth
• Embedded context
• Architectural intuition

In a truly AI-native world, this is power. Policy, ethics these should be baked into the base model, not bolted on afterward. If the model learns to show a stop sign under the right conditions, that’s embedded ethics. That’s real design.

Have you ever played a game where the rules and clues are revealed bit by bit? And then just as you finally unlock a new skill you realize:

The key you spent five lives searching for… was actually right there all along. Behind a door. On the third floor. Hidden in plain sight.

We realize that the clue from level two suddenly makes sense. That dead end in level four was actually pointing us here. The seemingly random pattern reveals itself as elegant design.

Or maybe you liked someone then later found out she’s married. Suddenly, your mind replays everything. The way she smiled. The way she talked. Every past moment is recast in a new light.

That’s context replay. That’s what humans do.

But AI? It doesn’t do that.

Tell an LLM: “She’s married.” Or: “The key is behind the shelf.”

It takes that as just another piece of data. It won’t go back and re-evaluate everything that came before.

Instead, it leans on chat history. A static record. A flat memory.

That’s bad.

In most LLMs today, you could tell it something earth-shattering, for example say, “I got divorced last week” and five prompts later, it’s still asking how your spouse is doing. It doesn’t replay the emotional significance of your context shift. It simply logs it in a massive scroll of chat history.

Human memory isn’t just about recall; it’s interpretive. A parent’s quiet sigh from your childhood can mean something completely different once you’ve become a parent yourself.

We reprocess. We re-frame. Our memories evolve with us.

That’s what’s missing in machines.

There has to be a better way to do memory in AI.

Maybe memory itself needs to be a learning model. Not just a storage unit. Not just a timeline.

Current AI systems experience these revelations in isolation.

Yes, they know the key is behind the shelf, but they can’t retroactively appreciate the brilliance of the clue that led there. They miss that profound “aha” moment, where scattered data points are transformed into coherent understanding.

Reimagining Memory as a Learning System

What if memory itself became generative?

Instead of treating recollection as mere retrieval, imagine memory that functions like understanding. When you tell your AI “hey I just got divorced”, they actively reprocess every prior exchange through this new lens, they instantly begin to connect the dots between you “working late”, sleeping poorly and even stress eating. Suddenly, the outline of a relationship in collapse becomes apparent to this machine you’ve always had a conversation with every day.

This is an architectural shift from the current focus & ideologies, because intelligence without insight is just expensive pattern matching disguised as inference.

We need memory systems that learn, that reflect, that reinterpret.

What if the next leap in AI isn’t about making models bigger, but making their memory smarter?

What is llm.txt?

An llm.txt file is essentially a machine-readable developer reference that acts as documentation optimized for AI comprehension rather than human readability.

• It’s a lightweight, plain-text specification that documents your SDK or codebase so Large Language Models can quickly understand available functions, their inputs/outputs, and intended usage patterns.
• Unlike human-facing docs (like a README), it’s written to be structured, concise, and context-rich for AI models to parse efficiently.
• The file typically includes:
  • Function names + complete signatures
  • Parameters + types (with required/optional indicators)
  • Return values + structures
  • Plain English descriptions (no marketing fluff)
  • Minimal, working code examples

Think of it as a hybrid between TypeScript definitions + inline documentation, but flattened into a structured text file so LLMs can use it as a knowledge grounding artifact for integration tasks.

Generate Your llm.txt with AI

A simple prompt to create machine-readable documentation from your existing codebase

You don’t need to write llm.txt from scratch. In my work, this is a prompt format that has been helpful as a base using Cursor or Claude to automatically generate one from an existing codebase:

You are tasked with generating an llm.txt file that documents and structures the [project name].

1. Read through the source code inside the `[project path]` and any related types, structs and data wrapper files.

[optional] Refer to integration tests or suites for relevant code samples

2. Extract all available functions, methods, and exposed classes within stellar-sdk package
3. For each function, write a concise entry in the following format:

### Function Name
- **Signature:** <function signature with params + types>
- **Description:** What the function does in plain English
- **Inputs:** List of parameters (name, type, description)
- **Outputs:** Return type and meaning
- **Example Call:** Minimal code snippet showing usage

4. Organize the file into sections that match the SDK/API  functionality:

[list all functionalities and API methods here]

5. Keep all descriptions **concise and LLM-friendly** (short sentences, minimal jargon, direct explanations).

6. Save the result as `llm.txt` in the package root.

This file should serve as a **machine-readable developer reference** that an LLM can ingest to generate code completions and context-aware explanations.

At a certain point, if you’re good at enough things, life gets… comfortable.

You get efficient. Competent. Predictable. And that’s exactly when you start stagnating, not because you’re failing, but because you’re not failing enough.

So here’s what I’m doing: From now till June 2027, I’m only pursuing things I know I’ll probably fail at.

Top of the list? Building an 9-figure business.

Not because I think I can’t do it, but because I’m not supposed to be able to yet. It’s big enough, scary enough, wild enough that failure is likely. Which means growth is guaranteed. I might loose money, go broke and back up again. I am going to dabble in a lot of unknowns, some scary but you know what, I have decided that I am going to be pushing back against comfort.

By setting failure as the goal.

And to manage the internal chaos of chasing things I’ll probably bomb at, I’m borrowing a tool from Tim Ferriss called Fear Setting: a simple 3-part framework where you (1) define your worst fears, (2) figure out how to prevent them, and (3) map out how you’d recover if they actually happened. It flips the whole goal-setting game on its head and gives you the clarity to pursue bigger risks with your eyes wide open.

1. They assume you know what a database is.
2. What an API layer is.
3. What a user flow is.
4. How integrations work.
5. What staging and production environments mean.
6. The difference between a sandbox and live data.
7. They assume you know what an API key is, where to get it, and how to plug it in.
8. They assume that once you write a PR, you know the next feature to drop, the next route to define.
9. They assume that if you can describe your product’s value, you also understand the tech stack needed to bring it to life.

But that’s never the case. When a non-technical founder has an idea, all they really know is the problem they want to solve.
They don’t know what to build, how to build it, or what tools to use. So what happens?

• 🔍 They research.
• 📚 They take a course.
• 🧑‍💻 They Google things they shouldn’t have to Google.

And when they try to skip that process, maybe hire a dev or buy a no-code template, they get stuck.
Usually right after the first review of their MVP. Because they don’t know what’s supposed to happen next.

Right now, if you’re a non-technical founder with a clear “what,” you have three options:

• 1️⃣ Hire a designer and hope they get it.
• 2️⃣ Pay an agency to translate your value into a product.
• 3️⃣ Find a technical co-founder who can make sense of it all.

That’s the status quo.

What If “What” and “How” Were No Longer Separate? What if knowing what you wanted to build also meant knowing how it would be built?

• The tech stack.
• The cost.
• The tradeoffs.
• The external services.
• The product scope.
• The user flows.
• The integrations.
• The roles and permissions.
• The full, clear picture.

This isn’t just a non-technical founder problem, by the way. Even enterprise teams spend 70% of project planning time on “the how.”

• 🧰 Defining tech stacks.
• 🌐 Mapping markets.
• ✅ Lining up certifications (SOC2, HIPAA).
• 📊 Figuring out competitors.
• 🧱 Scoping features.

That’s what gives them their technical advantage.

What if there was a better way? What if there were a platform that bridges the gap? A space where what and how come together from the start.

You describe the problem and the outcome you want, and you immediately get:

1. 📊 Market context
2. 👤 Personas and user flows
3. 📦 Feature scope
4. 🧭 Integration map
5. ⚙️ Tech recommendations
6. 💰 Cost breakdowns
7. 📆 Launch timeline

All of it, up front. So you don’t spend weeks or months stuck figuring out how.
You just build, launch, ship, learn, repeat.

That’s the dream.

When something goes wrong, the default reaction usually:

• Dev: “Shoot, I missed that bug when Claude added the retrieval feature.”
• Marketing: “ChatGPT mixed up the facts from the meeting transcript.”
• Sales/Ops: “The AI didn’t leverage the full context of the call notes.”

The pattern is the same in every department: the blame lands on the AI, not on the prompt or on the process. It isn’t about the talent of the person executing the task. It’s about the ability to prompt an LLM effectively; how well we translate the context we have into a clear, actionable request.

When prompting is weak, the output is weak, and the team looks for someone (or something) to own the mistake. We’ve moved from:

1. Hiding AI usage →
2. Openly advocating AI‑in‑the‑Loop (AI‑ITL) →
3. Treating the model as a junior employee.

Once the model is on the team, the same rigor we apply to human contributors must apply to it. If we don’t standardize, we end up with “AI‑slop” that erodes quality. So how do we operationalize AI In The Loop?

a. Choose the right platformPlatformWhen to use itWhat it gives youOpenAI Custom GPTsYou’re already on the OpenAI stackFine‑tuned prompts, built‑in guardrails, version controlAnthropic Claude ArtifactsYou prefer Anthropic’s safety‑first modelReusable prompt templates, context‑aware chainingWorkflow engines (lindy.ai, n8n.io, Make.com)You need orchestration across multiple toolsAutomate data ingestion, post‑processing, and hand‑offs

b. Define the Unit of Work

Ask yourself: What exactly must be delivered?

• A document (spec, proposal, PRD)
• A URL (published article, knowledge‑base entry)
• A zipped bundle of design assets
• A video (demo, tutorial)
• A slide deck

For each unit, write an output specification that includes:

• Format (Markdown, PDF, MP4, etc.)
• Style guide (tone, branding, citation rules)
• Acceptance criteria (e.g., “no factual errors > 1%”)

Map AI‑Ops to Core Business FunctionsBusiness AreaTypical AI‑ITL TaskDesired OutputSalesDrafting proposals from CRM dataPolished proposal PDFLegalGenerating contract draftsEditable Word document with clause checksBackend DevelopmentWriting boilerplate API code from specsGit‑ready repositoryFrontend DevelopmentProducing component skeletons from design tokensReady‑to‑use React/TSX filesUX DesignSummarising user research into journey mapsVisually formatted Figma fileProject Documentation & PRDsCollating meeting notes into structured docsMarkdown PRD with traceability matrix

By cataloging each function, you can attach the right prompt template, version‑control workflow, and quality gate to every AI‑generated artifact. AI‑ITL is no longer a “nice‑to‑have” experiment—it’s a core production line.

If we treat it casually, we risk:

• Inconsistent quality (the dreaded “AI slop”)
• Escalated blame cycles that damage morale
• Regulatory or compliance gaps when AI‑generated content is unchecked

Conversely, a disciplined AI‑Ops framework gives you:

• Predictable, audit‑ready outputs
• Faster onboarding (new hires can trust the same prompt libraries)
• Clear ownership—when something fails, you can trace it to a prompt version, not to a mysterious “AI.”

Closing Thought

If we’re going to keep AI on our team, we must manage it the way we manage any junior employee: give it a clear job description, provide the tools to succeed, and hold it to the same standards we hold our people to.

1. Assess all current workflows where you delegate tasks to an LLM.
2. Document the Unit‑of‑Work and acceptance criteria for each.
3. Choose a platform (Custom GPT, Claude Artifacts, or a workflow engine).
4. Build reusable prompt libraries and version‑control them like code.
5. Implement a review gate, human or automated. Ensure all outputs are checked against the spec before it ships.

Just last year, the same media outlet had called her startup the next big thing in EdTech, and while news of her startup shutting down is news to every other person, Serena and her founders already began dissolving the company months ago.

Right now, she is preparing to rejoin the traditional workforce after months of running her own show, and she keeps refreshing her email, scanning through the growing pile of rejections from prospective employers who all deliver the same polite brush-off.

Much like Serena, this dilemma is relatable to a countless number of CEOs, CTOs, and co-founders who find it hard to reintegrate into the workforce, and what hurts the most is that each rejection stems from the fact that they are entrepreneurs, “something which is usually one of their proudest moments.”

Wild, isn’t it?

Ex-founders and entrepreneurs who have managed to navigate this challenge either had to tap deep into their network, pick up entry-level roles to patiently climb the ladder, or take an educational sabbatical in the form of an MBA, master’s, Ph.D, or something along those lines that allow them to reintegrate into the workforce on a softer, “edu-sabbatical” note.

A Yale School of Management study underscores how pronounced this bias can be: ex-founders are 43% less likely to receive interview callbacks than non-founders with similar experience. Ironically, those labeled “successful” founders fare even worse in some cases, as hiring managers worry they won’t adapt to corporate norms or might exit once they spot a new entrepreneurial venture.

This mismatch comes at a time when artificial intelligence (AI) is transforming the global workforce in unprecedented ways. Over the past two decades:

• Clerical and administrative jobs have shrunk due to automation.
• Routine coding tasks are increasingly handled by AI, contributing to an uptick in IT-sector unemployment.
• AI and machine learning roles, by contrast, are on track to grow by 40% by 2027, according to the World Economic Forum.

But there is hope.

There is an emerging role that is picking up popularity, a term used to define a professional who can orchestrate a mix of AI agents and humans to achieve specific objectives.

A term used to describe someone who can sit in a strategy meeting, receive their “high-level” objectives and KPIs, and run with it. An objective like “increase our product visibility by 40% in Q2” instead of “research a list of PR companies and influencers we can partner with to discuss the ‘XYZ’ product campaign.”

A term for this role is called the “Ultra Generalist.”

The age of the Ex-FounderEx-founders fit perfectly into this box. The same traits that once seemed to limit their prospects, i.e wearing multiple hats, dabbling in every department, pivoting strategies on a dime are rapidly becoming the most valuable.

For example, if you began as a marketing professional and became a founder, you’d eventually find yourself sucked into operations, product management, and even design or software engineering. What if you were just a techie? The moment you co-found a company, you might even get pulled into design, research, customer relations, and worse sales calls, even though all you’ve dreamed of was quietly locking yourself in a small corner room while writing code to change the world.

In an age where AI handles specialized tasks, knowing a little bit about everything suddenly has immense value. A former founder who used to wear multiple hats can excel under these conditions. Whether it’s signing off on a marketing plan generated by an AI or overseeing a product feature tested by machine learning algorithms, their role is to ensure it all serves a coherent business strategy.

This article from SmartBrief describe these “ultra-generalists” as people who “communicate, solve problems, and adapt quickly,” bridging the gap between what AI can do and what an organization actually needs. And therein lies the biggest opportunity for ex-founders: businesses increasingly need people who can manage machines, not just function alongside them.

So you might have closed the doors on your startup, laid off the last of your team, and found yourself facing more rejections than you ever encountered while pitching to VCs.

Here’s the good news:

1. Your breadth is your strength: The fact that you’ve handled operations, marketing, R&D, and hiring may feel scattershot on a résumé, but in an AI-first era, it’s a superpower.
2. Embrace your story: Instead of downplaying your founder title, re-frame it. Highlight the tangible outcomes you achieved: revenue growth, product launches, user acquisitions. Show how you connect the dots across various business functions.
3. Leverage the bias: If a company refuses to see the value in your diverse background, you might be dodging a bullet. Organizations that appreciate AI generalists are more forward-thinking, these are the companies you want to work for.
4. Think like a conductor: As AI tools become ubiquitous, your role is not to out-code or out-design the specialists, but to orchestrate. Oversee different AI tasks, interpret outputs, guide the data toward strategic outcomes, and ensure the entire ensemble aligns with broader goals.

Your journey as a founder wasn’t a dead end; it was a master class in adaptability, exactly what businesses need in a future where technology rewrites the rules every other day. The rise of AI doesn’t mean humans are not needed. It just means the highest-value work is shifting, instead of competing with AI in specialized tasks, the best professionals will be those who know how to leverage AI across multiple functions. For ex-founders and generalists, this is a golden era. The ability to think across domains, adapt quickly, and drive AI-powered execution is now more valuable than ever.

If you’re currently navigating the path from entrepreneur to workforce, there’s no better time to be alive. Why?

The future of work needs you more than you might realize.

I’m not a deep in the weeds, core-code kind of engineer, neither am I deep in design nerd. I am comfortable with Creative Cloud, Figma, Whimsical, a couple design tools, and can wire-frame / prototype quite well. I also enjoy spending a great amount of my time in an IDE. Over my career, I’ve built serious proficiency with PHP (Yii Framework, CodeIgniter), which I used to develop the entire CRM for Tecmie. Then I moved into fancy land: did a Ruby on Rails bootcamp, picked up Node.js and TypeScript, and joined the open-source language Imba as an early contributor. (Imba is a JavaScript VM with the syntactic sugar of Ruby. After that came Python, Solidity, Rust (for Attest Protocol), and every other meta framework or language necessary for building on the edge AI, blockchain, the works.

Even though I can pick up complex systems fast, I don’t chase new languages or paradigms just for fun. I only dig into them when the current project demands it. When my existing toolset hits a wall, or in rare cases, when one of the engineers working on a critical project fucks up our timelines.

In other words, I learn in context. Problem-first. Design-next, which gives me a rare gift.

Transforming Value Propositions into Delightful Software.

So maybe, yes, I’m not a PM, EM, SWE, or a Product Designer. But all of my capabilities intersect those functions. And for the first time, I think the role definition that perfectly captures my abilities might be this one:

Design Engineer.