The demo looked incredible. Clean UI, smooth flows, everything wired up. He hit deploy.

Five minutes later, he rolled it back.

The tool didn’t fail him. The architecture did. Dependencies were tangled in ways that only surfaced under real conditions. The structure that looked solid in a demo environment collapsed the moment it touched production.

And here’s what stuck with me: no AI was going to tell him that. Because AI builds what you ask for. It doesn’t tell you what you should have asked for instead.

The Dangerous Illusion

The vibe coding wave is real, and I want to be honest: the tools are genuinely powerful. I use them every day. I’ve built entire products with AI in days that would have taken a team weeks.

But they’ve created a dangerous illusion for non-technical founders. The illusion is that building software is the hard part.

It’s not. Building is the easy part now. The hard part is knowing whether what you built will hold up under real users, real data, and real integrations. Whether your dependency chain will survive an update. Whether your architecture can handle the load when your first enterprise client goes live.

The numbers back this up. Fixing a broken AI-built product costs roughly 3x more than building it right the first time. Researchers found a 37.6% increase in critical vulnerabilities after just five rounds of AI-assisted iteration. And across enterprise AI projects broadly, 95% of pilots never make it to production.

AI gives you speed. It doesn’t give you judgment.

What the Tools Are Good At (And What They’re Not)

I’m not writing this to bash AI tools. That would be dishonest, I build with them constantly.

Here’s what they’re extraordinary at: prototyping, validation, moving from idea to working demo at a speed that was impossible three years ago. For testing whether an idea has legs, there’s nothing better.

Here’s what they’re not good at: knowing your business constraints. Designing for the scale you’ll actually need. Understanding how dependency chains interact across enterprise systems. Telling you “this architecture won’t survive your first 100 concurrent users.”

The gap isn’t capability. It’s judgment. The kind of judgment that comes from having shipped systems that broke, maintained codebases that rotted, and debugged failures at 2am enough times to recognize the warning signs before deployment, not after.

The Vibe Code Audit

When I look at an AI-built product, there are five things I check. I call it the Vibe Code Audit, because vibe coding deserves a vibe check before it goes live.

1. Dependencies. Is this built on a house of cards? AI tools pull in packages freely, often without checking if they’re maintained, if versions conflict, or if you’re three layers deep in a dependency that one maintainer abandoned last year. A single broken link in the chain takes everything down.

2. Architecture. Is there real separation of concerns, or is everything duct-taped together? Can a human developer read this code and understand what each piece does? AI-generated code often looks clean but has no consistent design philosophy underneath. Every file works, but nothing works together.

3. Data. Schema design, migration strategy, backup plan. AI-generated schemas are often structurally correct but operationally fragile. They’ll handle your demo data perfectly and fall apart when a real user enters something unexpected.

4. Security. Authentication, input validation, exposed secrets. One study found over 2,000 vulnerabilities and 400 exposed API keys in a sample of vibe-coded applications. AI “handles” security the way autocomplete “handles” grammar. It gets most of it right. The part it gets wrong can ruin you.

5. Scalability. Can this serve 10x your current users without a rewrite? AI optimizes for “working now,” not “working at scale.” That’s fine for a prototype. It’s a time bomb for a product you’re selling.

The Real Cost of Skipping the Review

The founder I watched didn’t save the cost of a technical review. He created a problem that now costs more to fix than the review would have cost.

That’s the pattern I keep seeing. The rebuild tax isn’t just a technical expense. It’s a business one. Delayed launches. Lost customer confidence. Developer hours spent untangling AI-generated spaghetti instead of building new features. Months of momentum, gone.

The most expensive technical decision a non-technical founder makes isn’t choosing the wrong stack. It’s shipping without anyone checking whether the foundation can hold what they’re building on top of it.

When to Bring Someone In

I’m not saying “hire a CTO.” I’m not saying “stop using AI tools.” The tools are incredible, and the founders using them to validate ideas quickly are doing exactly the right thing.

What I am saying: before you deploy anything that touches real users or real money, get a technical review from someone who doesn’t have a stake in your tech stack. Not the AI vendor. Not the agency that built it. Someone independent who can look at the five areas above and give you an honest answer.

One conversation. A few hours. It’s the cheapest insurance in tech.

Before you ship, ask yourself: has anyone who understands systems, not just tools, looked at what you built?

If the answer is no, that’s not a gap in your product. It’s a gap in your process. And it’s the easiest one to fix.

I write about technology decisions, building products, and the intersection of engineering and business every week at MacroStack. If this resonated, subscribe for more.

Last month, I realized I hadn’t done any of that in six months.

Not because the problems got easier. Because I stopped sitting with them long enough to solve them myself. I’d hit a wall, reach for AI, and the wall would disappear. Fifteen seconds. No friction. No frustration. No learning.

I love AI. I co-founded an AI company. I build with it every day. And I’m telling you: something is slipping. Not just for me. Probably for you too.

What the Research Actually Shows

This isn’t just a feeling. It’s being measured.

MIT Media Lab researchers hooked participants up to EEG monitors while they wrote essays, some with ChatGPT, some with a search engine, some with nothing. The AI group showed the weakest brain connectivity. Worse: when they tried to work independently afterward, their brains failed to reactivate to previous levels. The researchers coined a term for it: “cognitive debt.” Short-term efficiency creating long-term cognitive costs. Over four months, LLM users consistently underperformed at neural, linguistic, and behavioral levels.

A Microsoft and Carnegie Mellon study analyzed 936 real-world AI-assisted tasks across 319 knowledge workers. The finding that stuck with me: people who trusted AI the most engaged in the least critical thinking. Higher confidence in the tool, lower confidence in themselves.

But the study that stopped me cold came from The Lancet. Nineteen experienced doctors, each with over 2,000 colonoscopies, used AI-assisted polyp detection. When the AI was removed, their detection rate dropped from 28.4% to 22.4%. These weren’t beginners. They were experts who got measurably worse at their job after relying on AI. Researchers called it the “Google Maps effect.”

Paul Graham put it plainly in Writes and Write-Nots: “A world divided into writes and write-nots is more dangerous than it sounds. It will be a world of thinks and think-nots.”

This isn’t speculation. These are measured outcomes. The pattern is consistent: delegate the thinking, lose the capacity to think.

This Isn’t About Skill Decay. It’s About Identity.

Here’s the thing: those 2am debugging sessions didn’t just teach me debugging. They taught me patience. Systems thinking. The ability to hold a problem in my head for hours without reaching for a shortcut.

The terrible first drafts I wrote for years didn’t just make me a better writer. They taught me to think clearly, to know what I actually believe versus what sounds good.

The startups that failed didn’t just teach me product. They taught me who I am under pressure, and who I’m not.

Every skill you’re proud of was forged in something uncomfortable. Remove the discomfort and you don’t get the same person. You get someone with the output but without the understanding. Researchers call this “productive struggle”, the confusion that precedes understanding, the false starts that teach what doesn’t work, the repetition that builds fluency. It’s not an obstacle to learning. It IS learning.

And here’s the question I can’t stop asking myself: if I’d had AI when I was 22, would I be the same person?

I don’t think I would. And that’s the part that scares me.

My Children Will Never Know a World Without AI

My children are five and seven. They’re learning to read, to add numbers, to sound out words they don’t recognize. Last week, my oldest was stuck on a math problem. She sat there for ten minutes, frustrated, erasing, trying again. She eventually got it. You should have seen her face.

That moment, the frustration and the breakthrough, is where she’s becoming herself.

Psychology Today reported something in March that I haven’t been able to shake: “Adults lose skills to AI. Children never build them.”

Adults experience atrophy. We lose what we had. But children growing up surrounded by AI experience something worse: absence. They never build the neural pathways in the first place.

The World Economic Forum warned the same month that children risk “learning to be human from machines.” The tasks we automate, writing, reasoning, creating, struggling, are the building blocks they need to become thoughtful adults.

My children will never know a world without AI. The struggles that built me into who I am? They might never experience them. Not because anyone took those struggles away. Because nobody thought to protect them.

What I’m Actually Doing About It

I’m not deleting AI. That would be dishonest. It’s my livelihood. I co-founded an AI company. I write with AI, build with AI, think alongside AI. I love what it makes possible.

But some friction is sacred. Not all struggle is wasted time. Some of it is the whole point.

Here’s what that looks like in practice.

For Myself

First drafts without AI. Architecture decisions. Strategy docs. Emails that matter. The thinking happens in the drafting. The MIT study showed brains don’t activate the same way when AI does the initial pass. So the first pass is mine. AI refines later.

Debug before I ask. When something breaks, I give myself 15 minutes before reaching for help. That’s where the instinct forms, the pattern recognition that separates a senior engineer from someone who just has the title. The instinct only builds through repetition of the struggle.

The “why” check. One question before reaching for AI: am I delegating drudgework, or am I avoiding thinking? Formatting a document is drudgework. Structuring an argument is thinking. Generating boilerplate code is drudgework. Designing the architecture is thinking. The Microsoft/CMU study found the workers who trusted AI the most checked it the least. Know the difference.

Own the architecture. AI can write the code. I design the system. Architecture is judgment, and judgment is the sum of every wrong decision I made and learned from. You can’t outsource the formation of judgment. Only the output it already produced.

Unplugged reps. Once a week, I work without AI for an hour. Code a feature. Write a post. Solve a problem end to end. Addy Osmani calls this essential: “Keep honing your debugging instincts and system thinking even if an AI gives you a shortcut.” Think of it like a musician who still practices scales. The performance uses technology. The skill is built without it.

For My Children

Protect the struggle window. When they’re stuck on homework, I don’t reach for my phone. Ten minutes of confusion before any help. That confusion isn’t the obstacle to learning. It IS the learning.

Ask questions, not answers. “What have you tried?” and “What do you think?” before solving anything. The Psychology Today research showed that when children never form independent reasoning, AI’s reasoning becomes theirs. The antidote is showing them their own thinking matters.

Protect the analog. Drawing by hand. Building with blocks. Writing on paper. Playing outside with no screen. These aren’t nostalgic luxuries. They build neural pathways that screens can’t replicate. For a five and seven-year-old, these experiences are literally building their brains.

Co-use, never solo-use. When they eventually use AI, we’ll do it together. “Do you think the AI got this right? How would you check?” The habit of questioning is the habit of thinking.

Celebrate the effort, not just the result. Not just the correct answer. The 20 minutes they spent stuck on problem 3 before figuring it out. Make struggle feel valuable, not wasteful.

Because the research is clear, and honestly, so is my gut: the struggle was never the obstacle. The struggle was the point.

The things that built you weren’t efficient. They were hard and slow and frustrating.

And they were yours.

Don’t outsource that. Not from yourself. Not from the people you’re raising.

What’s one thing you’ve stopped struggling with that you wish you hadn’t? And if you’re raising kids, what struggle are you protecting for them?

Nobody asks the obvious question: what if you didn’t pay per token at all?

Most people only know one way to use AI. You sign up, you get an API key, and a meter starts running. Every prompt, every response, every agent loop, billed by the token. You’ve accepted this like it’s the only option.

It’s not.

Subscribe now

You’re Taking Taxis Everywhere

Think of per-token AI like a taxi. Meter running from the moment you get in. Surge pricing when demand is high. The driver profits from taking the long route, and you can’t really tell if the route is long because you’re in the back seat staring at your phone.

That’s the token economy. Every API call goes through someone else’s infrastructure, metered per mile. The more your agent thinks, the higher the fare. And you have no say in the route.

The alternative is owning a car. Upfront cost, sure. And yes, you still pay for petrol. But petrol costs the same per litre whether you’re driving to work or across the country. There’s no surge. No one profits from the longer route. You control the keys, the route, and the pace.

Most people don’t realize they can buy the car.

Why This Matters More Than You Think

Here’s the thing: the token model worked fine when AI was a toy. You asked ChatGPT a question, got an answer, moved on. A few cents here, a few cents there.

But we’re not in that world anymore. Agentic AI burns tokens autonomously. Your coding agent doesn’t ask one question, it asks fifty in a loop. It reads files, generates code, tests it, iterates, reads more files, generates more code. One task can consume thousands of tokens without you ever hitting enter.

The economics flip fast. Enterprise AI cloud spend tripled from $11.5B to $37B in a single year. Inference, the cost of actually running AI, now eats 55% of all AI infrastructure spending, surpassing training for the first time. And here’s the part nobody mentions: OpenAI currently spends $1.35 for every $1 it earns. Current API prices are subsidized. When those subsidies end, and they will, your bill goes up.

The provider has no incentive to make your agent think less. Token greed is baked into the model. The longer the route, the higher the fare.

The Car Nobody Told You About

Open-source models have gotten remarkably good. Qwen handles coding tasks. Llama covers general reasoning. Flux 2 generates images. These aren’t hobby projects or research demos. They’re production-grade models you can run yourself.

Where do you run them? On your own hardware, like an NVIDIA GB10 sitting on your desk. Or on cloud GPU instances, like an AWS g5. Either way, you’re paying for compute time, not tokens. No meter running. Your agent can think as long as it needs to, and the fare doesn’t change.

The numbers are real: open-source models achieve roughly 80% of proprietary model coverage at 86% lower cost. Once you cross about 100 million tokens per day with consistent utilization, self-hosting saves 40-60% compared to API pricing.

When to Hail a Cab, When to Buy the Car

I’m not saying delete your API keys. The smart play is both.

Keep hailing cabs when:

• You’re experimenting with a new use case

• Volume is low and unpredictable

• You need frontier intelligence (the absolute best reasoning)

Below 50 million tokens per day, APIs are almost always cheaper. The overhead of managing your own infrastructure isn’t worth it for the occasional ride.

Buy the car when:

• Your workload is stable and predictable

• Volume is high and growing

• Data sensitivity matters

• You want your agent to think without a cost ceiling

I run a hybrid setup. Frontier models for exploration and complex reasoning. Self-hosted models for the production workloads where the pattern is known and the volume is steady. The difference in my monthly costs isn’t marginal, it’s dramatic.

Who Is AI Actually Working For?

This is the question underneath all the token math.

When you pay per token, your AI works for the provider first and you second. Every efficiency improvement they make goes to their margin, not your savings. Your data flows through their systems. Your agent’s behavior is shaped by their rate limits, their policies, their pricing changes.

When you self-host, the AI works for you. No cost anxiety when your agent needs to think harder. No external dependency deciding what your models can and can’t do. No surprise pricing changes at the worst possible time.

Token-metered AI means renting intelligence. Self-hosted AI means owning it.

The Question Worth Asking

The inference market exceeds $50 billion in 2026. Most of that money flows from people who never stopped hailing cabs.

Next time someone at a meetup talks about token costs, ask them: have you considered not paying per token at all?

The car is parked outside. The keys are on the table. The only question is whether you’re ready to drive.

I run a hybrid setup across frontier APIs and self-hosted models. If you want the full breakdown, the exact models, the hardware, the real monthly costs, and when I use which, I share that with MacroStack subscribers. Subscribe if you want it.

That’s not a rounding error. That’s a signal.

The industry spent two years telling you AI would change everything. Billions in tool subscriptions. Every IDE has a copilot now. Every team has a ChatGPT tab open somewhere. And the aggregate result across 20 million PRs is... ten percent.

But here’s what makes the data interesting. The top-quartile AI adopters in the same study see 2x throughput. Same tools. Same models. Wildly different outcomes. So the question isn’t whether AI works. It clearly does, for some. The question is why most engineers aren’t getting there.

Subscribe now

The 39-Point Perception Gap

Here’s the uncomfortable part. A controlled study gave experienced open-source developers real tasks with and without AI assistance. The developers using AI were 19% slower. But when asked? They said they were 20% faster.

That’s a 39-point gap between perception and reality. It might be the most important number in this entire conversation.

It explains why nobody’s panicking. You feel faster. The autocomplete fires. The chat gives you answers. Code appears on screen. You’re moving. But the Faros AI data across 10,000 developers tells a different story: teams with high AI adoption merged 98% more pull requests, but review time increased 91% and bugs went up 9%. DORA metrics? Flat. More PRs, bigger PRs, slower reviews, more bugs, same throughput.

More code is not more output.

A 2026 Tool With a 2023 Workflow

Most engineers bolted AI onto an unchanged workflow. That’s the pattern behind the 10%.

Using AI as autocomplete, tab-completing lines of code slightly faster. Still reading every line. Still the bottleneck. Saved keystrokes, not hours. Copy-pasting code into a chat window and asking “what’s wrong with this?” No codebase context. No architecture awareness. The AI gives generic answers because it received a generic question.

And the biggest one: prompting without structure. No project conventions. No architectural constraints. No patterns to follow. It’s like handing a contractor a blank sheet of paper and expecting production-quality work on day one. You wouldn’t do that to a junior developer. But most engineers do it to AI every single session.

Gergely Orosz wrote about this two days ago. Uber built twelve internal systems just to deal with the quality problems from AI-generated code. When the tool generates more code without the right context, you don’t get productivity. You get cleanup.

The problem isn’t that AI doesn’t work. It’s that most teams are using a 2026 tool with a 2023 workflow.

What the Top Quartile Does Differently

The Jellyfish study has another finding that most coverage is ignoring: centralized codebases with structured context see 4x productivity gains. Distributed architectures with scattered context? Near zero.

Context is the multiplier. And the engineers getting 2x aren’t using different tools. They’re operating differently.

They treat context as infrastructure. Not a prompt you type each time, but an architecture document the AI reads every session. Project conventions, patterns, constraints, all front-loaded. The AI starts every conversation already knowing how the codebase works. Most engineers skip this entirely and wonder why the output feels generic.

They decompose before they delegate. Instead of handing AI one big task and getting one mediocre result, they break work into focused, parallelizable units. Four agents, four isolated branches, each with a clear scope. The decision of what to parallelize matters more than the parallelism itself. One vague task produces vague output. Four focused tasks produce four solid results.

They shift from coder to architect. They review outcomes, not keystrokes. They validate that the system behaves correctly instead of reading every line the AI wrote. This is the hardest mental shift for engineers. We built our identities around writing code. The top quartile is building their identity around designing systems that write code.

And they compound their workflows. Every solved problem becomes a reusable pattern. Templates, skills, conventions that the AI can reference next time. Most engineers start from zero each session. Top performers build institutional knowledge into their AI setup. The AI doesn’t get better because the model improves. It gets better because the context improves.

Anthropic’s own research found that 27% of AI-assisted work consists of tasks that wouldn’t have been done otherwise. The top quartile isn’t just doing old work faster. They’re doing new work that wasn’t possible before.

One Data Point

I’ve been operating this way for over a year now. 5.1 billion tokens processed in two months. 587 sessions. Three companies running on this operating model. I’ve written about the specific workflow before, the parallel agents, the skills system, the compounding context. If you want the tactical depth, it’s there.

This isn’t a pitch for my setup. It’s a recognition that the setup matters more than the subscription.

And it’s not perfect. Agents go in circles on complex architectural decisions. Long sessions drift as context degrades. Sometimes I spend more time correcting output than it would’ve taken to write it myself. Customer conversations, product strategy, the ground work, that’s still entirely human. Maybe always will be.

But the difference between my results and the industry average isn’t talent. It’s the operating model.

The AI Operating Model Gap

Here’s the takeaway. AI doesn’t make you faster. Your operating model makes AI faster.

Most engineers upgraded the tool and kept the workflow. The top quartile upgraded the workflow.

The 93% adoption rate isn’t the story. The 10% gain isn’t the story. The gap between 10% and 2x is the story. And that gap has a name: the AI Operating Model Gap.

If you’re getting 10% from AI right now, you’re not doing it wrong. You’re just running new hardware on old software.

Next week, I’m writing the operating model blueprint, how to audit your current AI workflow and upgrade it step by step. This piece was the why. That one’s the playbook.

The right time to start that side project. To have that hard conversation with your manager. To finally take the leap on the idea you’ve been sketching in your notes app for months. You’re waiting for the calendar to clear, the savings to hit a number, the kids to get a little older, the market to stabilize.

Here’s the truth: the right time doesn’t exist. It never has. And every week you spend waiting is a week someone less qualified, less prepared, and less talented than you is out there building the thing you keep postponing.

The only people who build anything meaningful are the ones who start before they’re ready.

Do it anyways. Three words. That’s the entire operating system.

Subscribe now

The Engineer’s Trap

You know why this hits engineers harder than anyone? We’re trained to optimize. We design systems for reliability. We refactor before shipping. We wait for the right architecture, the right stack, the right abstraction.

That instinct is brilliant for code. It’s devastating for life.

Because life doesn’t have a staging environment. There’s no dry run for starting a company, no rollback for the years you spent thinking about it instead of doing it. The optimization mindset that makes you a great engineer is the same mindset that keeps you stuck in a loop of “not yet.”

You’re not being careful. You’re being comfortable. And comfortable doesn’t build anything.

What “Anyways” Actually Looks Like

2021. I had a toddler, a newborn, an Executive MBA program at Quantic, and a full-time engineering leadership role at Criteo. My co-founder called and said, “Let’s build this.”

Every logical bone in my body said wait. The timing was objectively terrible.

I did it anyways.

We bootstrapped with personal capital, hired 5 developers on day one, made every first-time founder mistake in the book. By month three we’d scaled down to 2 developers and rebuilt from scratch around what customers actually needed. In roughly 18 months, we hit a seven-figure annual run rate. Eventually acquired.

But here’s the part people don’t talk about. That wasn’t a single moment of courage. It was a decision I had to make again every single morning. Ship the feature when you’re exhausted. Take the customer call at midnight. Choose the startup over sleep, over rest, over the easy path.

Do it anyways isn’t a one-time act. It’s a repeating operating principle.

The Pattern That Keeps Showing Up

That same principle followed me everywhere.

When my current startup needed to pivot, not once, not twice, but three times in six months, from an AI journal to a home collaboration tool to an AI calendar, every pivot meant admitting the previous version wasn’t working. Every pivot felt like starting over.

I did it anyways. Each time.

The people who build things aren’t braver than you. They’re not smarter, more connected, or more ready. They just decided that feeling uncertain doesn’t get a vote.

The Cost Is Real

I’m not going to romanticize this.

The TinyWhale years were brutal. I missed moments with my kids. I skipped dinners. I asked my family to carry weight they didn’t sign up for. The sacrifice wasn’t theoretical. It was bedtimes I wasn’t there for and weekends that disappeared into Slack threads.

If someone tells you this path is painless, they’re lying to you.

But here’s what I know: the alternative is worse. Not because waiting is lazy. Because waiting while knowing you should act is its own kind of suffering. It’s slow, it’s quiet, and it accumulates. That voice in the back of your head asking what if I had just started? never goes away.

The cost of action is real. The cost of inaction is invisible, but it compounds.

This Isn’t Hustle Culture

Let me be clear: “do it anyways” is not “grind until you break.” That’s a different conversation, and a toxic one.

This is about agency. The ability to decouple action from feeling.

You will feel scared. You will feel unprepared. You will look at your calendar, your bank account, your responsibilities, and think this is not the time.

Feel all of it. Then do it anyways.

Not because feelings don’t matter. Because feelings are terrible project managers. They’ll always find a reason to delay. They’ll always flag a risk that hasn’t materialized. They’ll always recommend waiting for more data.

You don’t need more data. You need a first commit.

The Question You Already Know the Answer To

What’s the thing you’ve been telling yourself you’ll start “when the time is right”?

The startup. The side project. The conversation. The career move. The thing that lives in your notes app, your late-night browser tabs, the shower thoughts you never act on.

You already know what it is.

The timing will never be perfect. The conditions will never align. The risk will never fully disappear.

Do it anyways.

None of it came from following trends. It came from solving problems I could already see.

Here’s the thing: engineers have an advantage most people don’t. You build things. You see how systems break. You understand which problems are worth solving. Your day job isn’t just a paycheck. It’s a research lab for your next income stream.

Subscribe now

It Doesn’t Have to Be a Leap

Most engineers I talk to think starting something on the side means eventually going all-in. Quitting the job, the whole founder arc. That thought alone is enough to kill the idea before it starts.

But that’s not how it worked for me. The real path looks more like this: you notice a problem, you build something small, it starts generating value, and then you decide how far to take it. Side project becomes side income. Side income becomes a side company. And if you want, the side company becomes the main thing. It’s not a cliff. It’s a drift. You choose where you stop.

Path 1: The Side Project That Becomes a Company

While I was still at Criteo, a colleague and I kept noticing the same gap in how educators, teachers, and coaches operate their education business. Teachers and students needed better tools, and nobody was building them well. We weren’t planning to start a company. We just started building something that solved it.

That became TinyWhale, an edtech platform. It started small, stayed small for a while, then grew into a real company with a seven-figure annual run rate. Eventually it was acquired. The whole thing began as two people solving a problem they understood because they were close enough to see it.

You don’t need to build an edtech company. But if you work in fintech, you probably see broken onboarding flows every day. If you’re in logistics, you know which manual processes are begging to be automated. The product idea isn’t somewhere out there. It’s in the Slack channel where your team keeps complaining about the same thing.

The pattern: domain knowledge + builder skills + someone from your network who sees the same problem. Most engineers already have all three. They’re just not looking at their day job as the source.

Path 2: Sell Your Expertise Before You Build Anything

FusionOne started as consulting. Technical strategy and cloud architecture for startups. No product, no platform, just me advising founders on decisions I’d already made dozens of times in my career. Straightforward. Bill for your expertise.

This is the most underrated path for engineers. You’ve spent years solving hard problems. Startups and smaller companies face those exact same problems right now, and they’ll pay someone who’s already been through it. Freelance technical audits, architecture reviews, migration planning, system design advisory. These aren’t hypothetical. Companies need them today.

The beauty of consulting is you start earning immediately. No product to build, no users to acquire. Just your experience, packaged as advice. Start with one client from your network. See where it goes.

For me, it evolved further. I started building products from the problems I’d seen firsthand. But that was a natural evolution, not the plan from day one.

The pattern: every job you take deepens the expertise that someone else will pay for. Consulting is the fastest path from engineer to side income, because you’re monetizing what you already know.

Path 3: Content and Audience

This one surprised me. MacroStack started as a way to share what I was learning, not as a business. But building an audience and writing consistently compounds. It opens doors to partnerships, mentorship, and credibility that feeds everything else.

You don’t need to be famous. You just need to be useful to a specific group of people. Engineers writing for engineers is one of the highest-trust content relationships out there.

This doesn’t have to be a newsletter. A niche technical blog, a YouTube channel walking through real architecture decisions, a paid community around a specific domain. The format matters less than the specificity. “DevOps tips” is noise. “Kubernetes cost optimization for mid-size SaaS companies” is a business.

The AI Multiplier

Here’s what changed everything: AI collapsed the barrier between “I have an idea” and “I have a product.” What used to require a team of three to five people, I now build alone in days. You don’t need to hire anyone to test an idea anymore. You just need a weekend and the right tools.

What Doesn’t Work

Building a SaaS with no domain knowledge. You’ll build something nobody wants. Dropshipping, crypto trading, anything that doesn’t leverage the fact that you’re an engineer. If you’re competing with non-engineers on a non-engineering idea, you’ve already lost your biggest advantage.

The generic advice is generic for a reason. It works for everyone a little. It works for no one a lot.

The Question

Every engineer I know complains about something at work. A broken process. A manual task that should be automated. A workflow that wastes hours every week.

That’s not a complaint. That’s a business.

What pain do you see every day that nobody’s solving?

If this resonated, I write about engineering, leverage, and building beyond code every week at MacroStack. Subscribe if you want more like this.

50% of all AI agents are deployed for software engineering.

Not 50% of tech companies. Not 50% of Silicon Valley. Half of all agents, everywhere. We built agents to write code, review code, test code, deploy code. And then we built more agents to write more code.

Meanwhile, doctors still fill out forms by hand. Lawyers still review contracts line by line. Supply chain managers still dig through thousands of emails looking for a rejected quotation worth six figures.

Here’s the thing: the biggest opportunity in AI isn’t making better coding agents. It’s everything else.

Subscribe now

Why Engineering Got There First

It makes sense when you think about it. Code is structured. Code is reversible. If an agent writes bad code, you delete it and try again. If an agent files the wrong legal brief, someone’s in real trouble.

Anthropic’s data confirms this: only 0.8% of agent actions in software engineering are irreversible. It’s the safest playground imaginable. Low stakes, high iteration speed, fast feedback loops.

And engineers build tools for themselves first. Always have. The cobbler’s children finally have shoes.

But safe doesn’t mean only.

The Agent Gap

Here’s what the research actually reveals when you look past the engineering cluster: healthcare, finance, legal, supply chain, cybersecurity, they’re all showing up in the data. Barely. Tiny clusters. Sparse activity.

Not because agents can’t work there. Because nobody’s built the bridges yet.

Think about what engineering agents actually do: read structured data, find patterns, take action, check results. That’s not a coding pattern. That’s a work pattern.

A healthcare scheduling agent reads patient data, finds open slots, books appointments, confirms with patients. A legal research agent reads case law, surfaces relevant precedents, flags conflicts. A supply chain agent reads thousands of procurement emails, spots rejected items worth re-quoting, surfaces revenue that was invisible before.

Same pattern. Different domain. The gap isn’t capability. It’s deployment.

The Guardrails Are Already Proven

This is the part most people miss. The safety infrastructure for agents in high-stakes environments isn’t hypothetical. It’s already been proven, in engineering, at scale.

Anthropic’s numbers:

• 80% of agent tool calls include safeguards like restricted permissions

• 73% have human-in-the-loop involvement

• Agents initiate clarification requests more often than humans interrupt them, especially on complex tasks

The research calls autonomy “co-constructed.” It emerges from three things: the model’s behavior, the user’s oversight strategy, and the product’s design. It’s not a dial you crank to “fully autonomous.” It’s a relationship you calibrate.

That’s exactly what high-stakes industries need. Not AI that replaces doctors or lawyers. Agents that work within guardrails, ask when they’re unsure, and keep humans in control of the decisions that matter.

Graduated permissions. Monitoring. Intervention points. Engineers built this playbook over the last two years. It’s sitting right there, ready to transfer.

Where the Real Value Lives

The next wave of AI companies won’t come from building a better Copilot. That market is crowded and getting more crowded by the day.

The next wave comes from people who understand two things at once: how agents work, and how a non-engineering industry works.

An engineer who spent five years in healthcare and understands agents will build something a pure AI researcher or a pure hospital administrator never could. A supply chain expert who’s seen how coding agents operate will recognize the exact same patterns in procurement workflows.

The intersection is where the value is.

And here’s the thing most engineers don’t realize: you already have this. Years of domain experience from previous jobs, consulting gigs, family businesses, side projects. That experience felt like career history. Now it looks like a competitive advantage.

The Window

Anthropic’s study is a snapshot of early 2026. The agent gap is wide open right now. Software engineering sitting at 50%, everything else barely registering. But gaps close. They always do. The question is who closes them.

If you’re an engineer, you already understand agents better than 95% of the working world. You’ve used them. You’ve calibrated trust with them. You know where they excel and where they break.

The question isn’t whether agents will expand beyond engineering. They will. The question is whether you’ll be the one building the bridges.

What industry do you understand deeply that agents haven’t touched yet?

That gap between your domain knowledge and agent capability isn’t a coincidence. It’s your opportunity.

I’m putting together a deeper breakdown of agent opportunity across 10 industries, with specific use cases, readiness signals, and the engineering patterns that transfer to each. If you want the full Agent Gap Playbook when it’s ready, subscribe and I’ll send it your way.

Subscribe now

That thing you’ve been putting off for two weeks? It would take 30 minutes. You know this. You’ve known it the entire time. Every morning you tell yourself: I’ll get to it today.

You won’t. Because “busy” is doing all the work of an excuse without feeling like one.

“I’m busy” is not a reason. It’s a confession. Every day you don’t schedule it, you’re choosing everything else over the thing you claim is important.

Subscribe now

The Identity Problem

Being busy feels productive. It feels like evidence that you’re in demand, that you’re doing important work, that the machine can’t run without you.

But busy and productive aren’t the same thing.

I’ve had weeks where I was in back-to-back calls from 9am to 6pm, managing teams across Singapore, Tokyo, and Seoul, and still accomplished nothing that actually moved things forward. Nine hours of coordination. Zero hours of progress. Everything felt urgent. Nothing was important.

I’ve also had days where I blocked two hours on my calendar, shut everything else out, and moved a project further than the entire previous week combined.

The difference wasn’t effort. It was decision.

What I Actually Do

I run multiple things right now. Toshi, FusionOne, MacroStack. Each one has a list of things that “need to get done.” If I tried to keep that in my head and just get to things when I could, nothing would move. Everything would be “soon.”

So here’s my system, and I’ll warn you, it’s embarrassingly simple: Everything goes on the calendar.

Not a to-do list. Not a sticky note. Not a “I’ll remember.” The calendar.

I block 30 to 60 minutes for the thing. I treat it like a meeting I can’t skip. When that block comes up, that’s the only thing I’m doing. No Slack, no email, no “let me just quickly check this.”

Writing this article? On the calendar. A customer call I’ve been putting off? On the calendar. Reviewing a product decision I’ve been sitting on? On the calendar.

If it doesn’t have a slot, it doesn’t exist in my day. And if it doesn’t exist in my day, I’ve already decided it doesn’t matter, whether I admit it or not.

Why This Works

It’s not a productivity hack. It’s a forcing function for honesty.

When you put something on the calendar, you have to face what you’re giving up. That 30-minute block means something else doesn’t get that time. You’re forced to make a real trade-off instead of pretending you can do everything.

And when you look at your calendar and there’s no slot for the thing you’ve been “meaning to do,” you can’t hide behind “I’m busy.” You can see, clearly, that you chose not to prioritize it. That’s uncomfortable. But it’s honest.

The Uncomfortable Truth

Here’s what nobody says out loud: most of the things you’re “too busy” for aren’t hard. They’re uncomfortable.

That feedback conversation with your co-founder? Fifteen minutes. That investor update you’ve been drafting in your head for a week? An hour, tops. That side project you keep saying you’ll start “when things calm down”? Things won’t calm down. They never do.

You’re not too busy. You’re avoiding a decision. And “busy” is the most socially acceptable excuse for not making one.

I’m not claiming I’ve got this figured out. I still catch myself saying “I’ll get to it” and realizing three days later that I never blocked the time. The difference is, now I recognize what that means. It means I chose not to.

Why I’m Building a Calendar

This is how deeply I believe the calendar is the operating system for getting things done.

I’m co-building Toshi, an AI calendar, because the same problem plays out at home. Parents drowning in coordination, school schedules, errands, activities, appointments, all floating in WhatsApp messages, emails, and screenshots. Everyone saying “I’ll remember” and nobody remembering.

Toshi turns that chaos into calendar entries in seconds. You share a photo of a school schedule, it creates the events. Forward a flight itinerary, it’s on your calendar. The idea is simple: if it’s not on the calendar, it won’t happen. Whether that’s your startup priorities or your kid’s spelling test.

So Here’s the Question

What’s the one thing you’ve been “meaning to do” for weeks?

Open your calendar. Block 30 minutes for it. Not tomorrow. Right now.

If you can’t find 30 minutes, that tells you something too.

Half your week isn’t building. It’s coordinating building.

I used to live in that world. Now I don’t.

I looked at my screen the other day. Four terminals open. Four Claude Code agents, each running Opus 4.6. One building a new API endpoint. Another refactoring authentication middleware. A third writing tests for a feature I’d shipped the day before. A fourth investigating a data issue, querying the database and surfacing patterns I’d have spent hours finding manually.

No Slack messages. No standups. No blocked PRs. Just work getting done, in parallel, simultaneously.

This is my engineering team now.

Subscribe now

The Bottleneck Was Never Talent

Here’s the thing nobody wants to say out loud: the bottleneck in most engineering teams isn’t skill. It’s coordination.

I co-founded a supply chain AI company a couple years back. You’ve lived the same version of this story: three people minimum for a single feature. Backend, frontend, product designer. PRs waiting on someone’s review schedule. One feature took over a month and still wasn’t complete.

That’s not a failure story. That’s just how software gets built with teams. And it’s the part that AI agents just eliminated.

How It Actually Works

Claude Code isn’t ChatGPT in a terminal. It’s an agentic coding tool that lives inside your codebase, reads your project structure, runs commands, writes and edits files, executes tests, and commits code. You talk to it like you’d talk to an engineer: “Build the subscription billing endpoint using the same patterns as the user service.” And it does.

I’m on the Claude Max plan, $200 a month. For context, that’s less than what a single engineer costs per day in most markets. And I’m running multiple agents simultaneously.

Here’s the workflow. I spin up multiple Claude Code sessions, each in its own git worktree, an isolated copy of the codebase on a separate branch. Agent one works on feature A. Agent two handles feature B. Agent three writes tests. Agent four investigates bugs. They don’t step on each other’s files.

Each project gets a CLAUDE.md file, a context document that tells every agent the architecture, conventions, and patterns to follow. Think of it as the onboarding doc you’d give a new engineer, except this one gets read every single session and never forgotten.

I also build custom skills, reusable workflows for common tasks: writing publications, planning articles, debugging, code review. When I type a command, the agent loads the skill and follows the workflow. It’s like having SOPs for your team, except the team actually follows them every time.

Review output. Approve, iterate, merge. The cycle that used to take a week with a team coordinating across calendars now takes hours.

It’s Not Just for Code

Here’s what I didn’t expect. Claude Code became my tool for everything.

This article you’re reading? Written with Claude Code. I have a skill system that guides the agent through planning, structuring, and drafting publications in my voice. It reads my previous articles, my personal resources, and follows a tone guide. I review and edit, but the heavy lifting is delegated.

Data investigation? I gave Claude Code access to query a database. Asked it to find patterns in customer behavior data. It wrote the SQL, ran the queries, analyzed the results, and summarized everything with specific numbers. What would’ve been half a day of manual querying took about ten minutes.

Research, competitive analysis, debugging production issues by reading logs, generating marketing copy. The use cases keep expanding beyond what I originally imagined.

The Honest Part

I’m not going to pretend this is flawless.

Agents sometimes go in circles on complex architectural decisions. They can miss edge cases that an experienced engineer would catch on instinct. Long sessions start to drift if context gets too heavy. And sometimes I spend more time correcting an agent’s approach than it would take to just write the code myself. Even with Opus 4.6, the most capable model available right now, these limitations are real.

The big one: you need to know what to build. The agents are exceptional at how. They don’t know why. Strategic thinking, customer conversations, product decisions, those are still entirely on me. If I give a bad brief, I get a beautifully built wrong thing.

I’m still the architect. The agents are the builders. That division matters, and I don’t think it’s going away anytime soon.

What This Means for You

Here’s the question I’d ask yourself: how much of your week is actually building?

Not coordinating. Not waiting on reviews. Not sitting in alignment meetings. Not holding dependency graphs in your head. Building.

The definition of “team” is shifting. I’m not arguing every company should replace their engineers. I’m saying the math has changed. The coordination cost, the standups, the Slack threads, the blocked PRs, the context-switching, that cost is real. And for certain types of work, AI agents just eliminated it.

How many features are sitting in your backlog right now, not because nobody knows how to build them, but because nobody has the bandwidth?

What would you build if your only bottleneck was your own thinking?

The barriers that used to exist... don’t.

I’ve been running experiments for the past year. Building products alone that would have required a team just two years ago. And I’m not special, I’m just paying attention to what’s now possible.

Subscribe now

The Old Reality

Building a company used to mean capital. Hiring. Burn rate. Office space. Payroll before revenue.

Going solo meant staying small. Lifestyle business. Maybe a freelance gig that paid the bills. The math didn’t work for anything bigger, you needed people to scale.

That math has changed.

What Changed

Lovable started as an open-source side project called GPT Engineer. Anton Osika built it while working at another startup. It gained 50,000 GitHub stars. He and co-founder Fabian Hedin turned it into a product in late 2023. By February 2025, they hit $17M ARR with about 15 people. Four months later, $50M. By year end, over $200M. No massive sales team. No billion-dollar marketing budget. Just a product that worked.

Cursor was built by four MIT friends who independently realized “the IDE is the thing to build” after playing with GPT-4. They launched in 2022, hit $100M ARR in 14 months, the fastest ever. By late 2025, they crossed $1 billion ARR. With a small team. No marketing spend. Word of mouth from developers who couldn’t stop using it.

BuiltWith is the extreme case. Gary Brewer built it as a side project in 2006, working on it every evening for four years while keeping his day job. Today it generates $14M a year. He’s the founder, the lead developer, and the customer support team. One person.

For context: Microsoft does $1.8M revenue per employee. Meta does $2.2M. These companies are doing $5M to $14M per person.

These aren’t outliers anymore. They’re signals.

What I’m Learning Firsthand

I co-founded a supply chain AI company a couple years back. Building features required a team, at minimum three people: backend, frontend, product designer. One feature took over a month and still wasn’t complete.

Now I’m running solo experiments. Same domain knowledge. Same type of problems. Different economics.

I hear a customer pain point. I build a solution. With a team, that cycle used to take a month minimum, multiple engineers coordinating, designs going back and forth.

Now? Two to three days. Sometimes less. AI handles the heavy lifting. I review, approve, iterate.

This isn’t about working harder. It’s about working differently.

The New Operating Model

Here’s how I think about it now: AI does most of the work. I’m the observer and the approver.

What AI handles:

• Building (code, interfaces, entire products)

• Marketing copy and campaigns

• Prospecting and outreach

• Analysis and reporting

What’s still me:

• Talking to customers

• Making strategic calls

• Ground work that requires presence

• Deciding what to build in the first place

The skills barrier collapsed. You used to need frontend, backend, design, and marketing expertise, or you needed to hire people who had them. Now you need an idea and an understanding of how to work with AI.

The Honest Part

I’m not claiming this is easy. Most of my experiments will fail. Customer conversations can’t be automated. Judgment calls are still judgment calls.

And the ground work, actually getting out there, understanding the problem firsthand, building relationships, that’s still human. Maybe always will be.

But the barrier to trying? That’s gone.

If you never try, you never know. And trying used to cost six figures and a year of your life. Now it costs a weekend.

The Window Is Open

A few years ago, “one-person company” meant freelancer or small-time. Now it means leveraged.

The question isn’t whether one-person companies will emerge. They already have. The question is what you would build if you knew you didn’t need a team to do it.

What idea have you been sitting on because you thought you couldn’t build it alone?

What would you start this weekend if the only thing stopping you was the decision to start?

If you’ve led a team, shipped a product, or made any decision that mattered, you’ve heard some version of this. The blunt assessment. The unsolicited opinion. The critique that hits harder than it should.

My natural reaction used to be defensive. Protect the idea. Protect the work. Protect my ego, if I’m being honest. But over the years, I’ve learned to do something harder: listen first, react later. Because if the feedback makes the product better, makes the team stronger, makes me sharper, why would I fight it?

The problem is, not all criticism deserves that kind of attention. Some feedback is gold. Some is noise. And the skill isn’t just in receiving criticism, it’s in knowing the difference.

Subscribe now

The Four Critics You’ll Meet

Not everyone who gives you feedback has the same intent. I’ve found it useful to recognize who’s actually talking.

The Vague Commenter. “It just doesn’t feel right.” “I’m not sure about this direction.” No specifics, no suggestions, no path forward. They might mean well, but there’s nothing to act on. If you can’t get them to clarify, move on.

The Attacker. This one makes it personal. “Classic mistake from someone who doesn’t get it.” It’s not about your work, it’s about you. Often, this is projection, their own fears, their own failures. Recognize it for what it is.

The Bad Actor. Rare, but real. Someone who wants to mislead you. A competitor seeding doubt. A toxic colleague undermining your credibility. Their goal isn’t your improvement. Don’t give them airtime.

The Seasoned Critic. This is the one you want. They’re direct, sometimes uncomfortably so. “Your onboarding drops people at step two. I almost left myself.” It stings, but it’s specific. It’s actionable. They’re not attacking you, they’re trying to make you better. These people are rare. When you find them, hold on tight.

Your Default Reaction is Probably Wrong

When criticism lands, most of us fall into one of these patterns:

Self-doubt. “Maybe I’m not cut out for this.” One piece of feedback spirals into questioning everything.

Dismissal. “They don’t have the full context.” You rationalize it away before even considering if it’s true.

Defensiveness. “Let me explain why you’re wrong.” You’re already composing counterarguments before they’ve finished talking.

I’ve been all three. Sometimes in the same conversation. The fourth option, openness, doesn’t come naturally. It has to be practiced.

The Framework: Listen, Wait, Ask, Act

Here’s what works for me now.

Listen. When someone gives you feedback, your only job is to absorb it. Don’t interrupt. Don’t explain. Don’t defend. Just take it in. This is harder than it sounds, especially when your brain is screaming to correct them.

Wait. Don’t respond in the moment. Sleep on it if you can. I’ve written replies I was glad I never sent. Emotion fades. What remains is usually the part worth paying attention to.

Ask. Before you decide whether the feedback is valid, ask questions. “Can you say more about that?” “What would you do differently?” This does two things: it gives you more information, and it turns a critic into a collaborator. Most people soften when they feel heard.

Act. Once you’ve filtered the noise, make a decision. Implement it, discard it, or park it for later. But don’t let it sit in limbo. Feedback that never gets processed is just noise you’re carrying around.

Don’t Sit On It

The worst thing you can do with useful criticism isn’t rejecting it. It’s acknowledging it and doing nothing.

You nod along. You say “good point.” And then you move on, unchanged. I’ve done this too. It feels safer than actually making the change, especially when the change is hard or threatens something you’re attached to.

But that’s the trap. Criticism isn’t a verdict. It’s data. And data is only useful if you do something with it.

The best engineers I know, the best founders, the best leaders, they’ve built feedback loops into everything. Their systems, their products, their teams. The ones who go furthest build that loop into themselves.

Got feedback? I’d love to hear it.

Alex Hormozi put it bluntly: "We are the result of our actions, not our aspirations."

I see it all the time. Engineers who want Staff titles but won’t take on the messy projects. Engineers who want leadership but avoid the hard conversations. Engineers who talk about ambition but scroll Instagram for two hours every night.

We are the result of our actions, not our aspirations.

Subscribe now

The Year Everything Stacked Up

In 2021, my life looked insane on paper. I had a 2-year-old running around the house. A newborn who didn’t believe in sleep. Classes for my Executive MBA. A full-time engineering leadership role. And a startup I was building on the side, a product called TinyWhale.

People asked me how I managed. Honestly? I didn’t do it alone. My wife held things together when I couldn’t. She picked up the slack, absorbed the chaos, and gave me the room to chase something most people would call crazy. Without her, none of it works.

But even with support, there were sacrifices. I stopped going out. Social events became rare. Family time shrunk to whatever margins I could find. My weekends weren’t weekends, they were just different kinds of workdays.

Was it sustainable? Probably not. Was it necessary? Absolutely.

Two years later, TinyWhale was acquired.

Uncomfortable Is The Job Description

Here’s what I’ve learned: growth never comes from the comfortable path. Not in startups, not in engineering, not in careers.

The work that accelerates your career is almost always the work you’re avoiding.

For engineers, “uncomfortable” doesn’t always mean working 16-hour days. Sometimes it looks like:

• Taking ownership of the legacy system nobody wants to touch

• Speaking up in a meeting full of senior engineers

• Volunteering for the migration everyone else dodged

• Giving honest feedback to your manager

• Writing publicly when you’re afraid of being judged

• Reaching out to someone two levels above you

These are small discomforts. But most engineers won’t do them. They’ll wait to be invited. They’ll wait until they feel ready. They’ll wait until it feels safe.

And they’ll keep waiting.

The Calendar Test

Want to know if you’re on the uncomfortable path? Look at your calendar from the last 30 days.

Not your goals. Not your intentions. Your actual time.

Did you spend time on things that scare you a little? Did you do work that stretched you? Did you make any moves that felt risky?

Or did you optimize for comfort?

Your calendar doesn’t lie. It shows exactly what you prioritize, not what you say you prioritize.

The Cost Is Real

I won’t pretend there’s no tradeoff. There is.

I missed moments with my kids. I skipped dinners. I said no to things I wanted to say yes to. The grind had a cost, and my family paid part of it too.

I’m not telling you to burn yourself out. I’m not glorifying 16-hour days.

But I am telling you this: if you want something beyond average, you have to do things beyond average. There’s no clean path. No life hack. No shortcut.

Just choices.

The Question

So here’s the uncomfortable question: What are you avoiding right now that, if you did it, would actually move your career forward?

You probably already know the answer. You’ve been putting it off because it’s hard, or awkward, or scary.

That’s exactly why you should do it.

The uncomfortable path isn’t a punishment. It’s a filter. It separates the people who want things from the people who are willing to do what it takes to get them.

Which one are you?

Back in 2010, I was building my first cloud-based distributed system. Cloud computing was just becoming mainstream, and I was responsible for global infrastructure that needed to work across regions. The moment everything clicked for me wasn’t when I wrote cleaner functions or optimized algorithms. It was when I deep-dived into the actual architecture of cloud systems and realized how much more accessible everything became once I understood the bigger picture.

Here’s what I wish I knew then: System design isn’t something you learn when you become a senior engineer. It’s something you should start learning from day one.

Today, I’m working on a startup. We’re not implementing most of these patterns yet. We don’t need Kafka streaming or multi-region replication or serverless at Meta’s scale. But understanding these systems still shapes every technical decision I make. It’s the difference between building something that works today and building something that can scale tomorrow without a complete rewrite.

The Mistakes I Made (So You Don’t Have To)

Early in my career, I wrote code without thinking about system design. I didn’t consider how data would be distributed across nodes. I didn’t plan for CI/CD pipelines. When we faced high I/O latency, I had no mental model for why a queue would solve the problem. I was coding in a vacuum, and it showed when things broke at scale.

The difference between a junior engineer who stays junior and one who grows fast? The latter learns to think in systems, not just in functions.

Subscribe now

What The World’s Biggest Systems Teach Us About Design

If you study how the world’s biggest platforms work, you’ll notice patterns. These aren’t random architectural decisions, they’re battle-tested solutions to universal problems. Here’s what 2026 should be about: learning these patterns so you can apply them before you hit the wall.

The Foundation: Event-Driven Architecture

Start with Kafka and Slack. These systems teach you how to handle real-time data and communication at scale. When I built an ad network system years later, Kafka became the backbone, streaming events to handle high I/O throughput without choking. Real-time chat features like Slack (which I later implemented in my recent project) only make sense once you understand event streams, message queues, and how to decouple services so they don’t all fail together.

The lesson: asynchronous communication is not optional at scale, it’s the only way systems survive.

The Scale Layer: When “Good Enough” becomes “Not Even Close”

Then you move up to systems like YouTube, Meta, and Uber, where the numbers stop making sense.

YouTube supports 2.49 billion users on MySQL. Not some fancy distributed database, MySQL. How? Sharding, caching layers, read replicas, and a refusal to over-engineer early. They scaled vertically first, then horizontally, and only switched databases when absolutely necessary.

Meta handled 11.5 million serverless function calls per second. Think about that, per second. They do it with aggressive caching, edge computing, and a system architecture that assumes failure and plans for it.

Uber processes 1 million geo-matching requests per second to find nearby drivers. The trick isn’t magic, it’s geospatial indexing, sharding by location, and reducing latency at every layer.

The lesson: scale isn’t about one clever trick, it’s about making smart tradeoffs at every level of the stack.

The Storage Layer: Durability, Cost, and Retrieval

Look at AWS S3 and Google Docs. S3 is the backbone of the internet’s storage, designed for 99.999999999% durability. That’s eleven nines. It achieves this through replication, erasure coding, and lifecycle policies that automatically move cold data to cheaper storage. When I implemented S3 for data storage with lifecycle management, it cut costs by 60% without sacrificing reliability.

Google Docs handles real-time collaboration for millions of users simultaneously. Operational transformation, conflict resolution, and sync engines that reconcile edits in milliseconds. It’s not just about storing documents, it’s about making the system feel instant even when users are editing from opposite sides of the planet.

The lesson: how you store data determines how you retrieve it, and both determine your cost and reliability.

The Intelligence Layer: LLMs and Modern Compute

Finally, LLMs like ChatGPT teach us about compute-intensive workloads. Inference at scale requires GPUs, batching, prompt caching, and model optimization. The architecture isn’t about databases or queues, it’s about managing compute as efficiently as possible while keeping latency low enough for users to not notice.

The lesson: the next decade of system design will be shaped by AI workloads, and engineers who understand this early will build better products.

Why This Matters for You Right Now

You might be thinking, “I’m not building YouTube. Why do I need to know this?”

Because every product eventually faces scale. And if you don’t understand how distributed systems work, you’ll make decisions that box you in. You’ll pick the wrong database. You’ll build APIs that can’t handle traffic. You’ll design features that work perfectly for 100 users and collapse at 10,000.

I’ve seen engineers who can build beautiful features but can’t explain why their service crashes under load. I’ve seen teams rewrite entire systems because no one thought about data consistency when they started. The cost of learning system design late is rebuilding what you already built.

The benefit of learning it early is that you make better decisions from the start. You ask better questions in design reviews. You propose solutions that scale. You stop being the engineer who just writes tickets and become the engineer who shapes the system.

Where to Start in 2026

Pick three of these case studies and go deep. Not surface-level, actually deep. Understand the tradeoffs. Draw the architecture. Explain it to someone. Then look at the system you’re currently building and ask: what patterns apply here?

For me, understanding Kafka’s event streaming unlocked ad networks. Understanding S3’s storage tiers unlocked cost efficiency. Understanding real-time sync unlocked better chat features. The systems you study today shape the systems you build tomorrow.

System design isn’t gatekept knowledge for staff engineers. It’s the mental model that separates engineers who see code from engineers who see systems. And 2026 is the year you start seeing systems.

If you're looking for guidance on navigating your engineering career or thinking through technical decisions, feel free to reach out. I work with engineers who want to level up their system thinking and career trajectory. You can contact me at irwan@macrostack.dev

MacroStack is where good engineers become great. If you want to think bigger and build better, this is where you belong.

I gave her the parent-approved answer about building something important, but the question stuck with me. Not because I felt guilty (though maybe I should), but because it made me realize something: I’m surrounded by brilliant engineers who could do exactly what I’m doing. But they don’t.

And I genuinely want to get some answers.

I’m Not The Only One

Here’s the thing: I work every waking hour, 16 hours a day, 7 days a week. People talk about 996 culture, I’m way past that. I’ve sacrificed personal time, family time, all of it. I’m building what I believe to be the next unicorn, from managing infrastructure, writing code, dealing with real users, fighting fires at 2am. The whole founder playbook.

But I’m not doing anything a great engineer couldn’t do. The engineers I work with, the ones I see in my network, many of them are smart, experienced, better at building. They have the skills, they understand the market, they could raise money if they wanted to.

They just… don’t want to?

The Question That Won’t Leave Me Alone

I need to be clear: I’m not saying my way is right. I’m not saying everyone should be grinding like this. Maybe they’re the smart ones and I’m the idiot. But I genuinely curious what they’re optimizing for.

So I’ve been thinking about this a lot. Here are my theories:

The Stability Arbitrage

Maybe the math just makes sense? If you’re a senior engineer at a decent company, you’re making above $100K, for senior engineers maybe even $200K-300K, FAANG engineers maybe $400K. You work 40 hours a week. You get healthcare, equity that might actually be worth something, and you go home at 6pm.

Why would you trade that for:

• Zero guaranteed income

• 80+ hours weeks

• A 90% chance of failure

• Explaining to investors why your metrics aren’t growing fast enough

When you put it that way, the engineer is being rational and I’m being insane.

Craft Over Outcome

Some engineers genuinely love the building more than the winning. They want to solve interesting technical problems, not deal with fundraising, hiring, firing, customer support, marketing, and all the other founder bullshit.

I get this. There are days when I miss just coding. But I want to win. I want to build something that matters at scale. Don’t they?

Or do they have a different definition of winning?

Time Leverage

Here’s one that keeps me up at night: what if they’re playing a smarter game?

They work 40 hours for someone else, make great money, then spend their remaining time on things that actually matter to them. Family, hobbies, side projects on their own terms. Learning new tech because it’s interesting, not because they need to ship a feature.

Meanwhile I’m working 100 hours week, have no personal time, stressed about burn rate and user retention.

Who’s actually winning here?

Risk-Adjusted Ambition

Maybe they’re just as ambitious as me, but they’re better at math. They can calculate expected value. They see that the founder path has:

• Higher upside (maybe)

• Much higher risk

• Guaranteed suffering

• Opportunity cost of stable comp

And they decide it’s not worth the gamble. Especially if they have family, mortgage, or other commitments to think about.

I’m Looking for Answers

I don’t actually know, that’s the truth. These are all just theories, I’m making assumptions.

So here’s what I’m going to do: Over the next 3-4 weeks, I’m going to interview engineers. Not to convince them they’re wrong. Not to tell them they should be founders. But to genuinely understand what they’re optimizing for.

I want to talk to:

• Senior engineers who could easily be founders but choose not to

• Technical cofounders who stepped back to IC roles

• Engineers running profitable side projects they won’t scale

• Anyone who’s thought deeply about this choice

If that’s you, I want to hear from you.

Reply to this, DM me, tell me:

• What does ambition mean to you?

• What would it take for you to go all-in on something of your own?

• What do you think I’m missing about the founder path?

I’ll share what I learn in a follow up post. And maybe, hopefully, I’ll understand something I don’t right now.

Because my kid’s question deserve a better answer than “Dad just likes to work a lot”.

Maybe the real answer is “Dad chose one path, and there are lots of other good ones“.

Let’s find out.

Not a feature. Not an AI demo. Not a big launch.

It was how many decisions the platform had already made for engineers.

At first I thought, maybe this is just AWS being more opinionated. But the more I watched, the more it reminded me of something much closer to home.

Personal Story: A Small Team, A Recurring Problem

A while back, I was working with a small team, a couple of engineers, moving fast, juggling product and infra at the same time.

At one point, we had this annoying pattern.

Every few weeks, something would go wrong in production. Nothing dramatic. But the first 30 minutes were always chaos. Logs were incomplete. Metrics existed, but not where we expected. Alerts fired, but didn’t really help.

We always ended up asking each other “Do you remember how this service works?”

We did the usual tings, talked about it in a retro, agreed it was important, and wrote a short guideline. Everyone nodded.

And then, the same thing happened again a few weeks later.

That’s when it clicked. This wasn’t a people problem. It was a system problem.

When the Same Problem Shows Up Again

What finally caught my attention wasn’t a big outage. It was how familiar everything felt.

Different week, different person, same questions:

• “Where do I see what’s actually happening?”

• “Do we even have logs for this?”

• “Which dashboard should I look at?”

The first time, I brushed it off. Stuff happens. The second time, I couldn’t unsee the pattern. That’s when I started using a very simple rule for myself:

If a problem shows up twice, stop fixing the incident. Look at the setup.

Not the architecture. Not the people.

The boring stuff everyone walks past.

In our case, the setup was a service template and a PR checklist. Observability was “recommended”, but nothing broke if you skipped it. And under pressure, guess what people did.

I probably would’ve done the same.

What I Pay Attention to Now

These days, when something keeps breaking, I don’t ask who owns it first.

I ask a different question:

What did our setup make easy?

If I have to explain the same thing twice, I look for where to bake it in.

If something is important but optional, I assume it’ll be skipped.

I’m not claiming this is the “right” way. I’m still learning. But fixing incidents feels busy. Fixing the setup actually changes behaviour.

If you’re designing systems or running a small team and this sounds familiar, I’d love to compare notes. Always curious how others shape their defaults.

It’s a great reminder. Most engineering decisions go sideways not because people are bad engineers, but because the team never agreed on the actual boundaries of the problem.

Good engineers ask: “What should we use?”

Great engineers ask: “What are we solving for?”

And founders? We ask a slightly different questions: “Will this actually make users happier?”

Because if the answer is “not really”, then why are we even talking about Redis cluster topologies at 10am?

Why This Matters

Most engineering rabbit holes start with curiosity + ambition + lack of constraints.

Without boundaries, everything feels important:

• Should we introduce event-driven architecture?

• Should we migrate to Rust for performance?

• Should we containerize every single thing?

The problem is… those aren’t business questions.

The real questions are:

• Does the user’s life change if we solve this perfectly?

• What breaks if we don’t solve it at all?

• What’s the minimum structure we need to ship of value?

• Are we solving a real bottleneck or just building because it feels clean?

This is where boundaries help. Boundaries create clarity, and clarity prevents smart engineers from overbuilding.

A Personal Lesson I’m still Embarrassed About

At one of my previous startup, we made this mistake hard.

We were early-stage. No scale. No heavy traffic. Barely enough users to call it “load”.

And yet, one of my senior engineers kept proposing a full-blown architecture setup: Docker everything, message queues, caching layers, full orchestration, rewrite the whole codebase into a more performant language. All before we even had users that needed any of that.

We also kept building stuff from scratch, things that had perfectly good, market-proven solutions. We burned weeks building custom components we could’ve replaced with a SaaS tool or an open-source library.

And to be fair, we’re seeing this everywhere. I learned this lesson the hard way too.

Why?

Because we didn’t start with boundaries. We didn’t ask the one simple question:

When you don’t define boundaries, every technical idea feels legitimate.

With boundaries, 80% of the ideas automatically fall away.

What Boundaries Look Like in Real Life

Before choosing tools, frameworks, or architectures, define constraints like:

• Timeline: “We need something working in 2 weeks.”

• User impact: “This feature must reduce a task from 10 mins to 2 mins.”

• Scale: “We expect 50 users, not 5 million.”

• Team reality: “We have one backend engineer, not seven.”

• Risk tolerance: “If it breaks, the blast radius is small.”

Once you frame the problem like this, engineering becomes way simpler.

Suddenly, the question isn’t “Should we use Kafka?”

It becomes “Will Kafka actually make a user happier this month?” (usually the answer is no)

The Mental Shift that Makes Engineering 10x Easier

Define the boundaries —> decide the approach —> pick the tools.
Most teams accidentally reverse this.

Great engineering isn’t about knowing every modern tool. It’s about knowing which part of the system actually matters right now.

When you approach decisions this way, you don’t just build faster, you build saner.

You stay focused on the part that makes users say, “Oh wow, this actually helps”.

Not the part that makes engineer say, “Oh wow, this architecture is beautiful.”

If You Take One Thing Away from This Post

Before you choose what to build, ask:

“What are we solving for, and what are the boundaries?”

Set constraints upfront. Then build the simplest thing that hits those constraints. Your engineers will move faster, your users will be happier. And your future-self will thank you for not rewriting everything in Rust at 100 users.

Not really. Leadership is a behaviour, not a job grade. You can start leading today by fixing a real pain, helping others win, and creating leverage, whether or not anyone promotes you.

Why Leading Without a Title Matters

Creating impact without authority isn’t just a side hustle, it’s a multiplier. You make other people’s work easier. You speed up processes. You unlock opportunities that might otherwise stay stuck.

The catch? It often means doing more than your role description, pushing past uncertainty, and putting yourself out there. You might feel uneasy at first, wondering if you’re stepping on toes or just wasting time. That’s normal. The people who grow influence learn to navigate that discomfort.

Inspiration: Small Tool, Big Impact at Spotify

At Spotify, one engineer noticed that multiple teams were spending hours every week tracking API errors across different services.

Instead of waiting for someone in management to notice it and tell them to fix it, they built a small internal tool on their own time. It wasn’t flashy, just a simple dashboard that automatically surfaced recurring errors and highlighted where fixes were needed.

The result? Teams across the company cut debugging time by roughly 30%. The engineer became the go-to person for efficiency improvements, not because of a title, but because they made everyone’s work easier.

It’s a small story, but it illustrates the point perfectly: leadership isn’t about a corner office. It’s about spotting friction, taking initiative, and shipping something that actually helps people.

My Personal Story

At one of my previous company, I noticed my team spent hours every week doing a repetitive task that could easily be automated. I thought “Maybe I’m overstepping, but maybe I can make this better”.

So I built a small tool on weekends. Yes, it meant sacrificing personal time. And yes, I doubted if anyone would even use it.

But once it rolled out, the team saved a few hours every week. Colleagues started coming to me with questions on process improvements. I become the person people trusted to find small wins that mattered.

It wasn’t glamorous. It wasn’t a promotion. But it changed how my role was perceived, and more importantly it made a real difference for my team.

How to Start Leading Without a Title

1. Find an obvious pain and fix it. Start with small, visible wins.

2. Ship outcomes, not just ideas.

3. Measure your impact. Time saved, errors reduced. Numbers make the impact more noticeable.

4. Build allies. Help peers and managers win. Influence is relational.

5. Speak in business terms. Talk value, revenue, cost savings.

6. Teach others. Multiple your influence.

7. Be consistent and humble. Show reliability, and don’t demand credit.

Start Small, Think Big

Influence doesn’t wait for a title. It’s built through action, consistency, and care for the people around you.

Tomorrow, ask yourself: what one thing I could improve or fix that would make a measurable difference for my time?

Small steps compound, start there.

If you want a bit of guidance on spotting high-leverage opportunities or figuring out where to focus your energy, I am open for a short mentorship chats to help people identify practical moves that can multiply their impact. Email me at irwan@macrostack.dev if you want to grab that 15 minutes.

It sounds dramatic, but many engineers feel the same. The hype is loud. The breakthroughs are fast. It is easy to think the train has already left.

Here is the truth. You are not late. You are only late if you do nothing.

The Hype Hides the Real Work

Andrew’s reply was simple. Yes, AI is powerful. But without custom engineering, it is surprisingly limited. He would not trust an LLM to handle basic tasks like scheduling or resume screening. Not without proper workflow design, context handling, and guardrails.

And that is part most people never see.

People see the demo. They do not see the scaffolding. The integrations. The context windows. The prompt shaping. The retrieval logic. The ten iterations needed before something behaves consistently.

AI is general enough to open new possibilities, not general enough to replace engineering.

This means there is still a huge amount of work ahead. Work only engineers can do.

Subscribe now

What I Learned Across My Own Startups

Across all my startup experiences, AI was never the main thing customers wanted. Customers never came to me saying “please add AI”. They came with painful problems. Slow operations. Chaos. Inefficiency. Confusion.

AI helped make the solution smoother. Sometimes it improved productivity. Sometimes it improved the user experience. But the real win was solving the customer problem, not dropping a model into the product.

Still, every time AI become part of the solution, I learned something new. Agents. Tooling. Memory. Retrieval. Evaluation. Vectors. ALl the small pieces that make AI actually useful in production.

You do not learn AI by reading. You learn it by building.

That is how Toshi, my latest startup, was born. A household productivity companion that uses every lesson I have gathered from years of shipping. Not because I planned it that way, but because all the small experiments added up.

And it reminded me, I am not late. And you are not either.

AI Does Not Replace Engineers, It Amplifies The One Who Build With It

When building Toshi, the hard part was not the model. Anyone can call an API. The hard part was everything around it. Designing context. Handling memory. Creating predictable behaviour. Making the system safe for real families.

This pattern repeats everywhere.

Models are engines. Engineers are the ones who turn them into vehicles people can actually use.

The engineers who thrive are the ones who know how to:

• Shape model behavior

• Design context flow

• Integrate retrieval

• Evaluate outputs

• Connect the model to real user value

You do not need to be a researcher, you just need to be someone who builds.

Start Small, But Start Now.

You do not need to build an agent with thirty tools, just pick one workflow in your life and upgrade it with AI.

Automate a test. Summarize your team’s daily standup. Build a small internal assistant. Add retrieval to customer support page. Create a simple coding helper for repetitive tasks.

Small projects teach you more than any course: where models fail, how context shapes accuracy, why retrieval matters, how to design a feedback loop, what makes an AI feature trustworthy.

This knowledge compounds. And compounding is your real advantage.

Subscribe now

You Are Not Late

If you start today, you are early.

The tooling is young. The patterns are still forming. The standards are not defined. This is the perfect time to build intuition.

AI will not replace engineers, But engineers who build with AI will outpace those who do not.

So if you have been waiting for a signal, here it is.

Start with one small workflow. Build something. Learn something. Let it grow.

And if you want guidance, I occasionally help engineers and teams think through AI systems, tool choices, and product strategy. Reach out at irwan@macrostack.dev if you need a sounding board.

The door is still wide open. You just need to walk through.

Here’s what it actually means for you, how to act on it now, and under the hood what’s going on (or at least what we know).

Why this matters

GPT‑5.1 brings more than incremental improvement. It gives you engineering levers you can pull in your stack:

• Instant vs Thinking modes – choose speed vs depth.

  • Instant: low latency, good for formatting, simple tasks.

  • Thinking: higher latency, more compute, better for tasks requiring deep reasoning or structured output.

  Impact: You can design a prompt‑router in your system to pick the right mode (thus controlling cost, speed, user experience) rather than one‑size‑fits‑all.

• Better instruction adherence – fewer mis‑interpretations of your constraints.

  Impact: Lower overhead in post‑processing or filtering, fewer “well I guessed what you meant” failures, especially important when building for production rather than toy prompts.

• Tone / persona control – built‑in presets such as Friendly, Professional, Quirky.

  Impact: You now have a more manageable way to control UX voice rather than heavy custom prompt engineering. Easier to standardise across your apps.

What engineers should do now

1. Prompt audit – go through your stack and find the prompts that fail to enforce constraints, get ambiguous tone, or require heavy manual filtering. Mark those as first‑class candidates for GPT‑5.1.

2. Build task‑based routing – in your service layer (Node.js / Go) add logic: if complexity high → Thinking mode; else → Instant. Track latency, cost, accuracy.

3. Upgrade voice/persona – rather than embedding tone hacks in system prompts, use GPT‑5.1’s tone presets. Clean it up, maintain style across flows.

4. Measure and compare – track before and after metrics: hallucination rate, user correction count, latency, cost per query. Use data to decide where the upgrade pays off.

5. Fallback & budget planning – since it’s new, you may encounter edge cases. Build fallback paths (e.g., legacy model) or degrade gracefully if error/rate‑limit occurs.

Subscribe now

Under the hood: what we do know about GPT‑5.1

OpenAI has not published a full architectural “whitepaper” for GPT‑5.1 (at least not fully public), but they have released system cards, model specs, and blog posts that hint at the mechanisms. As engineers, parsing what is public helps you infer how to design around it.

Key technical levers

• Adaptive reasoning: GPT‑5.1 Instant and Thinking modes use a mechanism where the model dynamically decides how much “thinking” (compute/time) to spend before producing output.

  • For example: GPT‑5.1 Thinking “varies its thinking time more dynamically than GPT‑5 Thinking” – on easier tasks it can be ~2× faster, on harder tasks deeper.

  • Implication: The system likely includes an internal signal (complexity estimate, prompt length/context signals) to route compute depth.

• Model routing: The “GPT‑5.1 Auto” route decides between Instant or Thinking for you, based on prompt/context/user‑preferences.

  • This means your architecture can treat “Auto” as default, but you can also force one mode if you know your task profile.

• Persona/tone presets: The system injects additional conditioning to alter “style” of output.

  • From an engineering view: You’re getting stylistic layers built in rather than only prompt engineering.

• Context‑window and token‑management improvements: Context sizes vary, e.g., Instant up to 32K (on paid tiers) vs Thinking up to 196K in certain tiers.

  • For your stack: If you have tasks involving long context (e.g., document summarisation, chat history, multi‑agent workflows) you can exploit the larger window.

• Instruction‑following improvements: The system card addendum highlights tighter adherence to user instructions and expanded evaluations (mental health, emotional reliance) as part of safety/behaviour training.

  • From design: fewer “creative but wrong” interpretations means your guardrail layers may become thinner, but you should still monitor.

Architecture & trade‑offs (simplified)

GPT‑5.1 likely runs in two modes: a fast one for quick answers and a heavier one for deeper reasoning, depending on the task. The model seems to have internal logic that estimates task complexity and picks the right mode automatically.

Tone presets are built into the system, making it easy to control style and personality without complicated prompt hacks, though this flexibility comes at a small cost. Handling very large inputs, like documents with up to 196K tokens, requires smart memory and compression techniques to work efficiently.

There are trade-offs. Thinking mode gives more detailed outputs but is slower and more expensive. Instant mode is fast but may struggle with harder reasoning tasks. Systems using GPT‑5.1 should plan for mode selection and fallback strategies.

From a system perspective, GPT‑5.1 is best seen as a family of models with different modes, not a single monolith. Each mode has its strengths and limits, and your system logic should reflect that.

Big picture

GPT‑5.1 emphasizes something we care about: AI isn’t just a drop‑in tool. It’s a layer in your engineering stack, complete with knobs, trade‑offs, routing logic, persona control. For engineers, this upgrade is real because it gives you more control, more precision, and more ways to architect systems.

Don’t get distracted by “new version hype”. The win comes from how you use it: you route, you measure, you design. You build systems that turn this upgrade into better user experience, lower cost, higher reliability.

Further Reading

For more details straight from the source, check out the official OpenAI GPT‑5.1 page.

Every professional, whether engineer, designer, or founder, is suddenly a manager. Not of humans, but of systems.

You don’t have to become an AI engineer. But you do have to learn to delegate.

Delegation: The Skill Nobody’s Teaching

Delegation used to be a management skill. Now, it’s a survival skill for individual contributors.

If you’re still doing every repetitive or procedural part of your job manually, you’re already behind someone who has automated or delegated it.

An engineer who let’s their coding agent fix bugs or review PRs will ship faster.

A marketer who delegates campaign generation to AI will test faster.

A founder who offloads analysis to a model will decide faster.

Delegation is the new speed. And speed compounds.

Subscribe now

From Flight Mode to Feature Shipped

Earlier this week, I boarded a flight. I closed my laptop and walked into the plane.

Before takeoff, I described a feature to my coding agent, hit submit, and switched to flight mode.

When I landed, the pull request was ready — implemented, tested, and reviewed. I triggered a second review using Gemini, merged it and the feature went live before I reached baggage claim.

This wasn’t AI productivity. This was AI delegation.

The Leverage Shift

In the old world, leverage meant hiring a bigger team. In this one, it means building systems that work for you.

This changes what good work looks like:

• You’re not rewarded for how much you do, but for how much gets done without you doing it.

• You’re not measured by effort, but by orchestration. How clearly you can define outcomes and direct systems toward them.

AI delegation turns every individual contributor into a one-person organization.

The better you are at describing what needs to happen, the more you can multiply yourself.

How to Start Delegating Today

1. Audit your work.
   List everything you do in a week. Circle what follows patterns: routine, data-driven, rule-based works. Those are your delegation candidates.

2. Design the brief, not the output.
   The skill isn’t prompting. It’s describing what success looks like. Think outcomes, not instructions.

3. Automate the loop.
   Treat AI like a team member: assign, review, improve. Each iteration compounds learning, for you and for the system.

4. Think in systems, no sessions.
   Don’t treat AI as a one-off assistant you chat with. Build workflows where AI works between your sessions: writing, reviewing, or analyzing while you’re doing something else.

Subscribe now

The Mindset Shift

Most people ask, “What can I do for me?”

But the better question is, “What can I stop doing because AI can handle it?”

That’s delegation. And that’s how you stay relevant.

If the last decade rewarded those who could automate,
the next one will reward those who can delegate.

The Real Question

The workplace is splitting into two groups: those who delegate to AI, and those who are delegated by it.

Which side are you on?

I’m building and experimenting with these delegation systems every week — for myself, my team, and the tools we’re creating. If this lens on AI and work resonates, follow along for more essays on building leverage, not just effort.