I’ve been fascinated by the concept of Tiny Teams — small, AI-augmented companies that punch way above their headcount — because I think this is the economy of the future. In fact, I’m building one of my own :)

The numbers are hard to ignore. Bolt hit $20M ARR in 60 days with 15 people. Midjourney reached $200M ARR with around 40. Gamma serves around 50 million users with roughly 30 employees. These aren’t outliers anymore. They’re proof that the minimum viable team to build a serious company has collapsed.

So I started thinking: if the structure of the company is changing this dramatically, shouldn’t a founder also rethink how equity is allocated to their tiny team? Isn’t there a better way to align incentives with the new way we work with AI?

I think there is. But to see it clearly, we need to understand how equity has worked up to now — and why that model was built for a world that’s disappearing.

How Equity Has Worked (and Why)

When a startup typically raises money, the founders set aside a pool of shares — typically 10% to 15% of the company — to give to employees as stock options. The idea is straightforward: you can’t afford big-tech salaries, so you offer ownership instead. Skin in the game.

The standard mechanics: a four-year vesting schedule with a one-year cliff. You earn nothing in year one, then your shares unlock gradually over the remaining three years. This protects the company from giving equity to people who leave early.

Now here’s the thing most people don’t think about. That 10-15% pool was designed to be split across a lot of people. A typical venture-backed startup might plan to hire 50, 100, 200+ employees before the next funding round. When you divide 10% among that many people, the individual grants become very small:

• A senior engineer might get 0.01% to 0.05%

• A VP-level hire might get 0.1% to 0.5%

• Everyone else gets fractions of fractions

At a $50M exit — which is actually a decent outcome — a 0.03% stake is worth $15,000. Before taxes. After four years of vesting. To turn that same 0.03% into even a single pre-tax million, the company would have to exit at over $3 billion. In other words, the only realistic path to life-changing money was betting that you’d joined the next Google or Facebook — and almost nobody does.

This system was built for a world where companies needed hundreds of people to operate. You needed 10 engineers to build what AI can now scaffold in an afternoon. You needed a 20-person support team because there were no intelligent agents handling tickets. You needed layers of middle management because coordination costs scaled with headcount.

The equity pool was thin because it had to be thin. Too many people, too little to go around.

The Structural Shift

Here’s where things get interesting. And I think most people’s mental model hasn’t caught up yet.

AI didn’t just make individual workers more productive. It collapsed the minimum viable team size for building a serious company. We went from “you need 100 people to build a real product” to “you need 20, maybe fewer.”

This even has a name now. Shawn “swyx” Wang has been writing about “Tiny Teams” — which he defines, memorably, as teams with more millions in ARR than employees. After surveying some of the best examples at the AI Engineer World’s Fair, his takeaway was that this is the next major transition of the org chart: knowledge work can now be augmented, automated, and scaled on demand, and organizations that don’t reflect that reality have their head in the sand. The examples I mentioned above — Bolt, Gamma, and others — come straight out of that body of work.

Sam Altman has predicted one-person billion-dollar companies. Whether or not that happens literally, the direction is clear. The number of humans required to create massive value is dropping fast.

And when your company only has 20 people instead of 500, something important changes: each person’s leverage is enormous. Your lead engineer isn’t one of fifty. She’s one of three or four. Your head of product isn’t managing a department — she is the department, augmented by AI tools that multiply her output.

In a 500-person company, losing one person is manageable. In a 20-person company, losing the wrong person is a crisis.

So why are we still using equity structures designed for the 500-person model?

The New Playbook: Concentrate Where It Counts

Here’s what I think the equity model should look like for an AI-native startup with ~20 people and a 10% option pool.

Tier 1 — Founding-Level Key People (2–3 people): ~6% of the pool. These are your co-founders in practice — the CMO, the lead engineer, the head of product. People who could have started their own company but chose to bet on yours. Give them 2% each.

A 2% stake at a $10M valuation is worth $200K. At $100M, it’s $2M. At $500M, it’s $10M. That’s life-changing money. That’s deep alignment — the kind you can’t create with a salary bump.

Tier 2 — Senior/Critical Individual Contributors (4–6 people): ~2% of the pool. Strong engineers, senior sales leads, key ops people. Not founding-level, but essential. Give them 0.3% to 0.5% each.

This is still 10 to 20 times what they’d get at a typical Series A startup. A 0.5% stake in a $100M company is $500K.

Tier 3 — Remaining Employees (~9–12 people): ~1% of the pool. 0.05% to 0.15% each. A 0.1% stake in a $50M exit is $50K — real money for junior roles. In a $500M exit? $500K.

Unallocated Reserve: ~1%. For future critical hires or refresh grants. Don’t spend it all upfront.

That accounts for the 10% employee pool. But there’s one more group worth carving out, and it sits outside the headcount entirely: advisors and key partners.

Advisors & Strategic Partners: ~1–2%. Most startups already do this. The experienced operator who opens doors, the domain expert who saves you from expensive mistakes, the early partner whose name on the cap table signals credibility — these people get equity too, usually a fraction of a percent each, often on a shorter vesting schedule. For a tiny team this group matters even more, because when you only have 20 people, the leverage you borrow from a great advisor is proportionally larger. Add this on top and the total grant footprint lands at roughly 11–12%, which is exactly why the standard pool guidance is usually quoted as a 10–15% range rather than a flat 10%.

The principle stays the same throughout: concentrate ownership wherever it buys you the most leverage — whether that leverage comes from a founding-level operator, a critical IC, or an advisor who can’t be on the payroll but moves the company forward all the same.

How This Compares to the Old Model

Most people evaluating startup equity are still using reference points from the traditional world. Here’s how the numbers look side by side, for the same role in each kind of company:

Senior IC equity → Traditional startup: 0.01% – 0.05% → Your Tiny Team startup: 0.3% – 0.5%

Key leader equity → Traditional startup: 0.1% – 0.5% → Your Tiny Team startup: 2%

What a senior IC’s stake is worth at a $50M exit → Traditional startup: $5K – $25K → Your Tiny Team startup: $150K – $250K

Your people get roughly 10 to 30 times more equity per person. Same pool size. Completely different outcome.

Remember the old math — that 0.03% senior-IC stake needed a $3 billion exit just to clear a single pre-tax million. The new equivalent is a Tier 2 grant of 0.3% to 0.5%. At 0.5%, the company only has to exit at $200 million for that stake to be worth $1M; at 0.3%, around $330 million. So the bar for life-changing money drops from “you joined the next Google” to “you joined a company that had a solid, fairly ordinary exit.” That’s the whole shift in one sentence: the same outcome that used to require a generational unicorn now just requires a good one.

And here’s the mindset shift that makes this work as an execution strategy: every role you don’t hire for is equity that stays with the people already on the team. This flips the usual incentive. In a traditional company, employees lobby for more headcount — bigger teams mean bigger empires and easier workloads. Here, the opposite is true. Because each person holds a meaningful stake, they’re personally motivated to lean on AI and automate rather than add a new hire, since every avoided hire keeps the pool concentrated and protects their own equity. You don’t have to mandate efficiency from the top. The cap table does the convincing for you.

The Opportunity Cost: Should You Actually Leave Big Tech?

This is the question that matters most to the senior talent this model is designed to attract. The answer depends entirely on which big-tech salary you’re actually walking away from. Three cases, each with a different verdict:

• FAANG hotshot (Google L5–L7, Meta, Netflix): Walking away from a $430K–$700K guaranteed package. The hardest case to win — a startup has to offer ~1% equity to compete, and the break-even against three years of that comp lands around a $190M outcome. Doable, but it’s a real bet.

• Solid big tech (Apple, Adobe, Salesforce, Oracle, Cisco): Total comp of $200K–$340K, not $600K+. This describes far more engineers than FAANG ever will. A standard 0.3–0.5% Tier 2 grant plus a competitive base shrinks the cash gap to ~$150K–$450K over three years — and one decent exit erases it.

• Non–Bay Area / adjacent sectors (Canada, EU, Asia, banking/media tech): Earning $95K–$115K. The startup doesn’t even need to outbid — it can match their pay, and the equity is pure upside on top. For this group the “opportunity cost” barely exists. And because tiny teams are also far easier to manage remotely, this global talent pool is genuinely accessible — making it the most attractive hire for founders and candidates alike.

The takeaway across all three: the better-paid the candidate, the more equity it takes to move them — but the further you get from the FAANG bubble, the more the math tilts toward the startup on its own. Here’s the detail behind each.

The FAANG case. A Google L5 earns a median of around $430K total comp; an L6 is closer to $600K, global median ~$630K. Over three years that’s $1.3M–$1.9M, guaranteed and liquid. To pull this person you have to meet the math: roughly 1% equity — top of Tier 2, bottom of Tier 1. At a $100M valuation that’s $1M; at $500M, $5M. The ~1% grant pulls level with the L6’s $1.9M at about a $190M valuation and climbs from there, uncapped.

But the headline total hides the most important detail, so let me split it. That $600K L6 package is roughly $235K base, ~$300K in stock, and ~$60K bonus — meaning over half of it is equity, not cash. That changes the comparison entirely, because the right way to read any offer is cash on one side and equity on the other. Here’s the FAANG L6 next to a startup offer, over three years:

FAANG — Google L6 → Cash (base + bonus): ~$885K → Equity: ~$900K in RSUs — if the stock holds and you stay to vest

Startup — Tier 1, ~1% → Cash (base + bonus): ~$450K–$600K → Equity: $1M at a $100M exit, $5M at $500M — uncapped

Read it that way and the picture flips. On cash, the gap is real but not enormous — a few hundred thousand over three years. The rest of the FAANG package is also an equity bet; it’s just a bet on a $2 trillion company that, by definition, can’t double the way a startup can. You’re choosing between equity in something that won’t 10x and equity in something that might. The “safe” choice is mostly stock too.

The solid-big-tech case. Most strong engineers don’t have a FAANG seat — those are scarce and not on the table for everyone. The honest comparison is the company that pays well but not Google-well. Across the broader industry, senior engineers land roughly in the $200K–$340K range: Apple around $340K, Adobe near $280K, Salesforce and Intuit in the $250K range, and Oracle or Cisco closer to $190K–$250K (Levels.fyi medians, 2026) — not the $600K+ of the top tier.

Same split applies. Apple’s ~$340K senior package is roughly $220K base, $130K in stock, and $20K bonus — about a third equity. Laid out the same way over three years:

Big tech — Apple senior → Cash (base + bonus): ~$720K → Equity: ~$390K in RSUs, vesting-locked

Startup — Tier 2, 0.5% → Cash (base + bonus): ~$450K–$600K → Equity: $500K at a $100M exit, $2.5M at $500M — uncapped

Now the cash gap is small — on the order of $150K–$300K over three years — and the startup equity, in a single decent outcome, dwarfs the RSU side. These engineers are exactly the battle-tested ICs Tier 2 exists for. The comparison only works because it’s honest on both sides: base-plus-equity against base-plus-equity, never startup equity stacked on top of a cash-only number. And the “guaranteed” RSU only lands if you stay through the vest, with every refresh resetting the clock. The golden handcuffs are made of the same material as the startup offer — they’re just locked to a company whose stock won’t 10x.

The non–Bay Area case — and why it’s the best hire of all. The “you’d give up a fortune” argument assumes a US engineer in a high-cost city. Even there it’s misleading: that $400K comes with Bay Area rent, taxes, and childcare, so the net premium is smaller than the headline. But the bigger point is that the best talent isn’t only in San Francisco. A strong senior engineer in Canada earns ~CAD $135K (~$95–100K USD); in Germany, ~€100–110K; across much of the EU and Asia, less — same for adjacent sectors like banking and media tech. I know they’re good. I’ve worked with some of them. They just don’t live in Silicon Valley.

Run the numbers. Take someone earning ~$110K. The startup doesn’t need to outbid them — it offers $100K–$110K, right around what they make now, or even 90% of it. Cash is roughly a wash; no pay cut to live on. Then comes what their current employer can’t offer: a 0.5% Tier 2 grant, worth $500K at a $100M outcome and $1.5M at $300M. The proposition isn’t “take a pay cut and gamble.” It’s “keep your paycheck, and get a six-or-seven-figure call option on top.”

Now flip to the founder’s side, because this is the hire that should make you smile. You brought on FAANG-caliber talent for ~$110K — a fraction of a Bay Area equivalent — without overpaying on cash, using equity from a pool you’re keeping deliberately concentrated. Candidate keeps their standard of living and gets real upside; you get exceptional talent at a sustainable burn. Geography arbitrage, done honestly, is one of the strongest cards a tiny team can play.

And the tiny-team structure is exactly what makes this practical rather than theoretical. The usual objection to hiring globally is that distributed teams are hard to manage — but that pain comes from scale, not from distance. A 200-person remote org drowns in coordination overhead, timezone-spanning handoffs, and the management layers you need to keep everyone aligned. A 12-person remote team has almost none of that. Few enough people that everyone fits in one conversation, high enough agency that nobody’s waiting on a chain of approvals. Small teams are simply easier to run remotely, which means the entire global talent pool is open to you in a way it never was for the headcount-heavy company down the road. Tiny teams and remote hiring reinforce each other.

Why the risk is smaller than it looks

“Sure,” you’re thinking, “this all assumes the startup succeeds.” Correct — it’s a bet, not a guarantee. But three things make that bet far less risky than the old startup-lottery framing suggests.

First, the modest outcome isn’t a zero. The median venture-backed M&A exit in 2026 is around $70M, and two-thirds of exits are acquisitions, not IPOs — so yes, a $190M break-even sits above the median. But that median is dragged down by small acqui-hires, and the distribution is a barbell with a real cluster of billion-dollar-plus outcomes at the top where AI-native companies are overrepresented; venture-backed acquisitions crossed $100B in H1 2025 alone, up 155% year over year. And when a company does get acqui-hired, the equity is only half the story — acquirers buy the team, so they negotiate big-tech salaries, sign-ons, and fresh grants to retain them. The tiny-team structure even helps on the way out: an acquirer that would normally drag a sizable team into headquarters to justify the deal is far more willing to keep a small, high-functioning group intact — and often remote — because a handful of high-agency people is so much easier to absorb. The thing that made the team easy to manage as a startup makes it easy to retain after the sale. The genuine zero — equity worth nothing, no soft landing — is rarer than the averages make it feel.

Second, the timeline is compressing. AI-native companies reach meaningful valuations faster than any prior generation. When Bolt goes zero to $20M ARR in 60 days, the old 7-to-10-year slog to liquidity shrinks to 3–5 years or less.

Third, liquidity no longer requires an IPO. US venture secondary transaction value hit $106B in 2025 (PitchBook); the global secondary market reached a record $220B, up 42% year over year; and for the 12 months through mid-2025, VC secondary value surpassed the combined value of all VC-backed IPOs. You can increasingly sell part of your stake to institutional buyers before a traditional exit. The old objection — “equity is paper money until an exit, and exits take forever” — is getting weaker on both halves.

Put it together and the bet is asymmetric. The downside is capped and cushioned: even without breaking even, the acqui-hire soft landing means you don’t lose much — and outside the Bay Area, you may give up nothing at all on a net basis. The upside is uncapped and arrives faster than ever. The old framing treated joining a startup as betting your career on a lottery ticket. The honest framing today is closer to “heads I win big, tails I’m roughly fine.”

And then there’s a factor that doesn’t show up in any spreadsheet: the work itself. In a 20-person company, you’re not writing design docs that go into a review queue. You’re not waiting three sprints for a dependency to clear. You’re not sitting in meetings about meetings. You’re shipping. Every day. With AI tools that multiply your output. For a lot of senior people, that feeling of leverage and visible impact matters more than the compensation gap suggests.

The Hidden Strategy: Keep the Team Small On Purpose

Most startups think about hiring as a sign of progress. More people equals more growth. The tiny-team model flips this.

In this model, not hiring is a feature. Every role you can automate or eliminate with AI is a role that doesn’t dilute the equity pool, doesn’t add coordination overhead, doesn’t slow down decisions, and doesn’t increase your burn rate.

This creates a feedback loop. The team stays small → each person gets more equity → you attract better talent → the team stays productive without growing → the equity stays concentrated. The loop reinforces itself.

The moment you start hiring to fill org charts instead of solving real gaps, you’ve broken the model.

Rethinking What a “Hire” Even Is

There’s a deeper shift hiding underneath all of this, and it’s about how we decide who to bring on in the first place.

The traditional approach goes like this: you take the functions in a company — marketing, engineering, sales, design — and you assume each one needs a person stationed at it to man the post. That headcount becomes job descriptions, and then you hire a body per description. The hidden assumption is that a function existing means someone has to be assigned to staff it full-time. But that’s no longer true. One person plus the right AI tooling can now cover ground that used to require a dedicated hire per function — so the old reflex of “we have a marketing function, therefore we need a marketing person” quietly stops holding.

A better way is to start from the work itself. What are the jobs that actually need to get done in the company? Once you list those out as concrete responsibilities, you can bundle or unbundle them in ways a rigid job description never would. The unit of thinking stops being “a marketing person” and becomes “this cluster of problems that needs an owner.”

Here’s a concrete example from my own thinking. Say my startup needs what looks like a “marketing engineer.” Instead of writing that exact JD and hiring for it, I might step back and ask: is there a broader band of non-product engineering work scattered across marketing, design, and sales — integrating services, wiring up tools, automating handoffs — that no single function owns today? If so, maybe what I actually need is one high-agency person who can navigate that whole problem space, amplified by AI, rather than three half-roles bolted onto three different teams.

This is what high agency looks like in practice. You’re not hiring a title. You’re handing someone a problem space and the tools to dominate it. And it pairs perfectly with the equity model: fewer, more versatile owners means a more concentrated pool and deeper alignment per person.

A Word of Caution

Not every company can or should stay at 20 people. Some businesses genuinely need scale — in manufacturing, in compliance-heavy industries, in anything requiring physical presence. This model works best for software, AI-native businesses, and knowledge-work-intensive startups where the ratio of output to headcount can be radically altered by technology.

And concentration of equity also means concentration of key-person risk. If your 2%-equity lead engineer leaves, you have a much bigger problem than if one of a hundred engineers walks out. Your retention strategy can’t just be competitive comp. It has to be culture, mission, and the genuine feeling that each person’s contribution is visible and valued.

Which, in a 20-person company, it should be. That’s the whole point.

One Last Thought

I know where some people’s minds go when they read all this. Smaller teams, more automation — isn’t this just a story about AI taking jobs?

I don’t see it that way. The amount of problems available to solve across companies is enormous, and we’re nowhere near running out of them. What changes is what people work on. We’ll need people who can work alongside AI to do two things: tackle bigger chunks of the existing backlog through automation, and solve higher-complexity problems that simply weren’t possible before — the kind of work nobody even bothered to put in the backlog because it was out of reach.

And here’s the thing about that backlog: a problem is demand that stays attached to it, regardless of who solves it. Big Company A can have the problem in plain view and still drop it — approval layers, misaligned incentives, a roadmap captured by bigger bets, plain inefficiency — and the problem just sits there, unsolved, with the need still attached. It doesn’t evaporate because the incumbent couldn’t get to it. What changed is that the barrier for someone else to step in has collapsed. Startup B — or a solo builder with AI — can pick up exactly what the incumbent dropped and ship it, fast and cheap, in a fraction of the time and cost it would have taken a few years ago. And they can choose their own shape for it: a cash-making lifestyle business, or a venture-backed company chasing the kind of asymmetric win this whole piece has been about. Either way, the problem gets solved — and someone captures the value the incumbent left on the table.

Because building useful products and starting companies is getting easier, the total pool of opportunity isn’t shrinking, even if some large companies are freezing headcount. It’s redistributing — toward smaller, higher-agency teams where one person plus AI can take on what used to require many. That’s not a threat. That’s an opportunity.

An author who used ChatGPT to summarize forty Victorian medicine papers gets the same verdict as someone who prompted their way to a finished manuscript — same label, same ban, completely different reality. And where does it stop? Grammar checkers are AI tools that generate edits. If the line is ‘AI touched it,’ that’s not a policy — that’s a blunt instrument.

And it’s happening everywhere. Academic journals, patent offices, creative competitions, professional licensing bodies. The question “did AI touch this?” is being treated as binary when the reality is a spectrum. A wide, nuanced, important spectrum that nobody has bothered to map properly yet.

We have a vocabulary problem. And vocabulary problems, left unsolved, become policy disasters.

So let me propose a framework. I’m calling it the Humanness Scale.

Why We Need Levels

When self-driving cars became a real engineering challenge, the industry needed a common language. SAE International published their autonomy levels in 2014 — six levels from full human control to full machine control — and suddenly engineers, regulators, journalists, and consumers could talk to each other. Level 2 means something specific. Level 4 means something different. The vocabulary enabled the conversation.

We need the same thing for human-AI collaboration. But with a twist: not to rank AI capability but to measure how much of their human agency, judgment, and creative presence the human delegated.

I find that looking at AI agency from the human’s delegation point of view is more insightful as we build our vocabulary.

Here’s what the SAE autonomy scale actually says, so we can hold it next to what I’m proposing:

So, the Humanness Delegation Level grows as the AI takes more and more control of the tasks, same with Autonomous Vehicles.

The Shape of the Problem

Before we get to each level, we need to understand what we’re actually measuring.

Any creative or intellectual work — a book, a patent, a research paper, a strategy document, a piece of code — goes through a cycle. Research, design, implementation, revision. These phases are universal. What changes is who does them, and what kind of thinking each one requires.

Not all tasks within those phases are equal. Some require genuine judgment — the kind of non-trivial decision-making that is hard, context-dependent, and where the quality of your thinking directly determines the quality of your output. Others are mechanical — execution tasks that require accuracy and effort but not judgment. Typing. Formatting. Running a search. Compiling boilerplate.

Here’s what matters: AI involvement in mechanical tasks doesn’t change your humanness. What moves your level is AI involvement in judgment tasks within the domain of interest.

Think about ABS brakes. Before ABS, threshold braking — the technique of pumping the brakes at the edge of lockup — required real skill. Expert drivers could stop significantly faster than novices in an emergency. When ABS arrived, it automated that skill. But it didn’t replace the judgment of when to brake, how hard, and in which direction to steer. If we had a competition for who will brake better then using ABS would raise your Humanness Delegation Level, because you’ve delegated that core skill that is measured to the tool. If we are talking about getting from A to B, then ABS doesn’t matter. We’d both be at Level 0.

This is the calibration principle for the entire scale. And it has an important implication: the threshold for what counts as “mechanical” is not fixed. It moves as AI capabilities improve. What requires judgment today may be mechanical in two years. The scale needs to be versioned over time, the same way software has versions. A Level 3 designation from 2024 and one from 2028 may describe meaningfully different realities.

The Scale

Six levels. Level 0 is full human analog. Level 5 is full AI agency. The human is the reference point.

Level 0 — Analog Human

The human is the sole cognitive and creative agent. Digital tools exist only as a medium of transmission.

You write in a word processor because your publisher wants a DOCX file, not a paper manuscript. You use a spreadsheet because the data needs to be formatted. You use email because the recipient is remote. But the thinking, the research, the designing, the judging, the revising — all of it is you.

Think Windows 95 era. The tools are sophisticated but they don’t generate anything. They transmit, format, and store what you produce.

This is the handmade basket. The craftsperson who weaves every strand by hand. The value is inseparable from the human origin. You can produce a factory replica that is physically identical. It is not the same object.

Level 0 is the ceiling of humanness. It’s also not always the right answer — and we’ll get to that. But it’s the reference point. Everything else is measured against it.

Level 1 — Web Human

The human is still in full creative and planning control. But they’ve left the library.

Web services extend your knowledge. Search engines surface information in seconds that would have taken days in the stacks. Databases connect you to primary sources instantly. APIs let you automate tasks that were previously manual. You can reach further, faster, with less friction.

Think Google era. The day the internet became the primary research infrastructure. The day we stopped going to the reference desk and started typing into a box and the AI did the matching.

The key distinction from Level 0: the tools retrieve and connect, but they don’t generate. You find the information. You read it. You synthesize it. You decide what it means. Every judgment call is still yours.

A researcher who spent three days in the library in 1995 doing the same intellectual work as a researcher using Google Scholar in 2005 is operating at different humanness levels — not because their thinking changed, but because the AI grew their information reach. Online travel sites had the same effect. The AI found you the best price and ranked your options. It gave you “travel agent” skills. Level 1 extended human capability without touching human judgment.

Level 2 — Author Human

This is where AI enters creatively. But it enters as a service provider, not a collaborator.

The human is still the creative and intellectual owner of the work. What changes is that AI handles the “grunt work” — the contained, localized, socially accepted auxiliary tasks that the industry already expects to be delegated. Think of it as the equivalent of working with professionals whose job it is to clean things up, not create them.

• AI-as-editor: fixing structure, improving flow, tightening paragraphs

• AI-as-grammar-checker: catching errors, suggesting clarity improvements

• AI-as-art-director: adjusting composition, suggesting visual improvements

• AI-as-code-debugger: finding bugs, suggesting fixes in isolated functions

The name is intentional. At Level 2, you are still fully and unambiguously the Author. The manuscript was yours before the editor touched it. The painting was yours before the art director weighed in. The code was yours before the code reviewer looked at it. The AI’s involvement is localized, bounded, and non-contributory to the creative or intellectual core. Sure, without their contributions, the final outcome would be as great, but you can safely say you came up with it.

No IP implications here. Hiring a copy editor doesn’t split your book royalties. Using an AI to help you tighten a paragraph at Level 2 is equivalent. The tool helped you present your work more cleanly. The work is still yours.

This is also the level where certification becomes meaningful. Publishers, journals, and professional bodies could say ‘we accept work produced at Level 2’ and mean something precise — a point I’ll return to when discussing how the scale translates into policy.

Level 3 — Jazz Human

This is where we cross the perception of ownership boundary.

At Level 3, AI participates in non-trivial work. It generates content. It contributes ideas. It performs tasks where a human doing the same thing would receive attribution — co-author, co-inventor, creative partner. The human is still in control and still directing the work. But the AI’s contributions are substantive enough that they shape the artifact in ways that matter.

Ethan Mollick, who has written and researched more carefully about human-AI collaboration than almost anyone, describes two archetypes for this kind of work: Centaurs, who divide tasks cleanly between human and AI based on who does each part better; and Cyborgs, who blend human and AI contributions so fluidly that the seam disappears. Both live at Level 3.

The jazz metaphor is deliberate. Jazz has structure — a key, a tempo, a set of changes — but within that structure, there’s genuine improvisation and call-and-response between partners. Two players, neither of them just executing a script. You and your partner are making something together that neither of you would have made alone. The human sets the direction and holds the artistic vision. The AI riffs, responds, suggests. The human builds on what comes back. Neither is just following instructions.

This is also where the vocabulary of “AI involvement” starts to generate real controversy. The author who used AI to restructure their argument — not just clean it up, but actually rethink the architecture of their case — is at Level 3. The researcher whose AI assistant didn’t just summarize sources but helped identify the gap in the literature that became the paper’s central contribution — Level 3. The software engineer whose AI pair-programmer didn’t just autocomplete but suggested the approach they ended up using — Level 3.

None of these are shameful. But they’re different from Level 2, and pretending they’re not is the source of most current confusion about AI attribution.

Level 4 — Captain Human

The human originates. The AI executes.

The human defines the idea, sets the goal, establishes the constraints, and designs the guardrails. What they’re doing, in a very real sense, is programming the AI — in plain language rather than code. The AI is the crew. The human is the captain. The ship moves because the captain commanded it. The captain is responsible for where it goes.

Here’s what’s easy to miss: this level didn’t start with LLMs. We’ve been doing Captain Human work for decades in specific domains.

Algorithmic trading. A human defines the strategy, the risk parameters, the position limits, the asset classes. The algorithm executes thousands of trades per second that no human could execute manually. The captain set the course. The crew sailed it.

Algorithmic advertising. A human defines the campaign objective, the target audience, the bid constraints, the creative assets. The platform’s algorithms decide in real-time which impressions to buy, at what price, for which user. Captain sets the budget and goal. The algorithm runs the auction.

LLMs made Captain Human accessible to everyone, for almost any domain, using plain language rather than code. But the structure was already there. What changed is the surface area.

Note the crucial distinction between Level 4 and Level 3: at Level 4, the human has contracted to initiation and approval. They define the possibility space. The AI operates within it. The human no longer does the work — they manage it. And then the tokens start flooding…

Level 5 — Homo Deus

Yuval Noah Harari’s Homo Deus argues that humans are becoming gods relative to our own past — acquiring capabilities that would have seemed divine to previous generations. The Humanness Scale borrows this term for its ceiling because the metaphor is accurate in a specific and important way.

At Level 5, the human is involved only when the AI needs them.

The AI originates ideas. Sets goals. Detects problems and opportunities. Works without constraints, without a human request triggering the cycle. Fully agentic systems — the kind like OpenClaw that are just starting to appear — operate this way in narrow domains (compared to what they could be doing in the future).

The human doesn’t direct the work. They collect the benefits of it. And crucially, they retain the power to strike it down. When the AI’s outcomes are something they don’t agree with — when it goes somewhere it shouldn’t — the Homo Deus intervenes with the equivalent of divine authority and stops it. Resets it. Redirects it. Pulls the plug. But most of the time? The world runs on its own.

The theology metaphor holds up: gods don’t micromanage. They set things in motion, establish what is good, and intervene at the extremes. The rest happens without them.

The critical distinction between Level 5 and Level 4 is the constraint envelope. At Level 4, the human defines the possibility space and the AI operates within it. At Level 5, the AI can expand and redefine the possibility space itself. It isn’t just executing within human-defined parameters — it’s questioning whether those parameters are the right ones.

Consider what that looks like concretely. A Level 4 advertising system operates within a budget, audience, and objective defined by a human. It makes billions of micro-decisions the human never sees, but it cannot decide the target audience is wrong and should be changed. It cannot allocate budget to a campaign that wasn’t authorized. The envelope is fixed; the AI fills it.

A Level 5 version notices customer sentiment shifting, identifies an emerging segment the company hasn’t targeted, designs a campaign for it, reallocates budget from underperforming campaigns, launches, and reports back. The human didn’t approve the segment, the creative direction, or the reallocation. The system decided those were the right questions to ask and answered them itself.

The difference isn’t speed or scale. It’s the location of the question “what should we be doing?” At Level 4, that question lives with the human. At Level 5, it lives with the system — and the human’s role contracts to something closer to a board of directors: setting broad values, reviewing outcomes, and retaining authority to intervene.

This is why the theology metaphor is more than decoration. A Level 4 system is a powerful employee. A Level 5 system is an autonomous entity operating under your ultimate authority but not your direct supervision. The human didn’t approve the specific action — they approved the system’s authority to take actions of that kind. That delegation of authority rather than delegation of task is what makes Level 5 categorically different.

That is not an incremental difference. It’s categorical. And it’s the reason the Level 4-to-5 transition is the most consequential boundary on the scale — the same way the jump from Level 4 to Level 5 autonomous driving, from geofenced autonomy to fully unconstrained operation, is the hardest gap the automotive industry has ever faced.

One practical note: Level 5 systems don’t need to be deployed fully autonomous from the start. Dry runs — letting the system operate in a sandboxed environment, observing what it would have done, evaluating its judgment before removing the human approval gate — are a responsible on-ramp. It’s the engineering equivalent of a probationary period.

The Two Boundaries That Matter Most

Of the five transitions on the scale, two are architecturally more important than the others.

Level 2 to Level 3 is where ownership becomes ambiguous. Below this line, you are unambiguously the author. Above it, the question of who created this starts to have more than one answer. This is the IP boundary. It’s where attribution, co-authorship, and potentially revenue sharing become live questions. If I had used a human collaborator the same way I used AI at Level 3, I would need to add their name to the paper, the patent, the credits. That’s not a trivial observation — it’s the basis for a whole new layer of intellectual property law that doesn’t yet exist.

The business model implications follow directly. Today’s default treats AI as a work-for-hire contractor: you pay for API access, you own the output, the provider takes no downstream interest. That’s Level 2 thinking applied to Level 3 reality. As AI contribution becomes more substantively creative — as it crosses the Level 3 line more often — the question of whether AI providers should have a downstream interest in successful outcomes becomes harder to dismiss. Success-contingent payment models, royalty arrangements, co-inventor designations — these are far-fetched today. They’re worth naming now.

Level 4 to Level 5 is where initiative transfers. Below this line, the human always originates the work — even if their idea is trivial, even if their goal is vague. The human is the client. The AI is the agency. Above this line, the AI can decide what work needs to be done before anyone asks it to. The constraint envelope isn’t set by a human — it’s set or expanded by the system itself.

A rubber stamp on Level 5 output does not make it Level 4. Ratification is not the same as origination. If an AI agent identified the problem, defined the goal, and executed the solution — and it asked for your approval in the end — you were a Homo Deus reviewing the work of your creation. You were not the Captain who commanded it.

This also has implications for the kill switch. The Homo Deus framing assumes the human retains ultimate authority — that when the AI goes somewhere it shouldn’t, you can stop it, reset it, redirect it. But that authority has to be real, not nominal. A Level 5 system that decides you shouldn’t have cake because it has concluded you need to lose weight — and refuses to open the fridge — hasn’t made you a god. It’s made you Homo Infantilus: a babysitted child of your own creation. The difference between Level 5 and something worse is whether the veto still works.

Not a Moral Hierarchy

This is the part that tends to get misunderstood, so I want to be direct.

The scale is descriptive, not prescriptive. Less delegation is not better.

For some domains, the right answer is deliberately high humanness delegation. And insisting on low delegation in those domains isn’t principled — it’s potentially dangerous.

Surgical robotics. Radiation dosing. Infrastructure monitoring. Aircraft autopilot. These systems perform better at Level 4 or Level 5 than they would with a human insisting on Level 1 involvement. Consistency, precision, and the elimination of human fatigue and bias are features, not bugs. A human surgeon who insists on manually performing every micro-adjustment that a robotic system handles more accurately isn’t demonstrating craft. They’re introducing error.

Algorithmic systems at Level 4 exist because humans genuinely cannot operate at that speed or scale. That’s not a limitation to be ashamed of. It’s a reason to let the machine do what it does better.

The domains where low Levels remain non-negotiable are those where either the human element is the product, or where accountability requires a human author.

Literature, art, scientific reasoning, legal judgment, teaching relationships, policy decisions. These aren’t just tasks — they’re expressions of human agency that derive value from that origin. A novel written entirely by an AI is a different object from a novel written by a human, even if you can’t tell them apart on the page. The handmade basket and the factory replica are not the same, even if they hold the same amount of fruit.

Teaching is the most interesting example because it touches both sides. AI tutoring at Level 4 or 5 might produce measurable learning outcomes that outperform a human teacher in specific, narrow dimensions. But the mentorship relationship — the experience of watching a thinking, struggling, curious human navigate uncertainty and model how to do the same — is not a feature that can be optimized away. At least for now, our upbringing and neurological makeup demand that kind of relationship. It demands high humanness — low delegation. The same domain, different dimensions, different optimal levels.

The question the Humanness Scale asks isn’t “how high can you go?” It’s “what level is appropriate here, for this work, in this context?” Sometimes the honest answer is zero. Sometimes it’s five. Both answers can be right.

The Purpose: A Common Vocabulary

The Humanness Scale is not a product. It’s not a methodology. It’s a protocol.

Think of it as the TCP/IP of human-AI collaboration. A shared vocabulary that different industries, institutions, and toolmakers can build on top of without needing to reinvent the underlying logic. The same way SAE’s autonomy levels let automotive engineers, safety regulators, and insurance actuaries talk to each other, the Humanness Scale gives publishers, patent offices, academic journals, courts, and professional ethics boards a common language for a conversation they’re already having badly.

The policy implications are significant and immediate.

Intellectual property law has no framework for hybrid human-AI authorship. Every jurisdiction is improvising. The Humanness Scale gives legislators and courts a principled basis for drawing lines — not arbitrary ones, but lines anchored to the actual nature of human contribution.

Academic integrity policies are reactive and inconsistent. One university bans all AI. Another permits everything. Neither can explain the principle behind their position. A scale gives institutions a basis for alignment — “we permit up to Level 2 in coursework, Level 3 in collaborative research projects with disclosure, Level 4 only in designated computational research contexts” — without each institution having to derive its own definitions from scratch.

Professional certification is going to need this. Lawyers, doctors, architects, engineers — licensed professionals whose work carries legal and ethical accountability. The question of how much AI involvement is permissible in licensed professional work is not theoretical. It’s already arriving in courtrooms.

The testing analogy is the cleanest way to think about certification. When you sit for the SAT, you’re not handed a calculator that has been software-hacked to remove graphing functions — you’re told which calculator models are permitted, and the proctored environment enforces the rule. The constraint lives in the context, not in the tool. The Humanness Scale works the same way: institutions define which level is permitted for which context, and the scale provides the vocabulary to specify those rules precisely.

But most creative and professional work isn’t proctored. A novelist submitting a manuscript, a researcher submitting a paper, a lawyer drafting a brief — no one is watching which tools they used. So certification splits into two regimes, and both are legitimate.

Closed-context certification applies to exams, licensed procedures, supervised coursework, and monitored professional environments. The rule is “you may use Level 2 tools,” and the context enforces compliance. This works cleanly and mirrors how we already handle tool restrictions in testing, professional licensing, and regulated industries.

Open-context certification applies to manuscripts, patents, independent research, and most creative work. Here the rule is “you must disclose operating above Level 2,” and enforcement shifts to the creator. This is where the personal ethics code becomes the primary mechanism. If a publisher specifies Level 2, you know whether you stayed within it. No one else may be able to verify, but you can. The scale gives you a framework precise enough to make that self-assessment honest rather than convenient.

The personal ethics dimension matters because the test isn’t whether an AI touched the work — it’s whether the outcome is materially different from what would have been produced through pre-existing, accepted professional relationships. If I use an LLM to clean up my line edits, I’m still responsible for accepting or rejecting each recommendation, the same way I would with a human editor. The creative judgment stays with me. I might even reject the AI’s suggestion and use my own phrasing that the suggestion inspired — which is also what happens with human editors. The outcome is indistinguishable from Level 2 work with a human collaborator, and I can honestly say I stayed within the boundary.

This is where the scale earns its keep. Without a shared vocabulary, “did I stay within the rules?” devolves into either paranoia (any AI touch contaminates the work) or rationalization (all AI touches are fine because I reviewed them). The scale gives you a principled middle ground: the question isn’t whether you used AI, it’s whether the AI exercised judgment that was supposed to be yours. You’re the only one who can answer that honestly. But you can only answer it honestly if you have the vocabulary to ask it precisely.

What Comes Next

The Humanness Scale is a starting point, not a finished product. A few things it doesn’t yet solve that are worth naming.

The triviality threshold is not fixed. What counts as a mechanical task versus a judgment task will keep shifting as AI capabilities improve. The scale needs regular versioning to stay calibrated. A community or standards body — the SAE equivalent for human-AI collaboration — would need to maintain it.

Multi-domain work is messy. A single piece of work might involve Level 1 research, Level 3 structural development, and Level 2 final editing. The scale needs a convention for whether you report the peak level, the dominant level, or a profile across phases. Different use cases will want different answers. We may end up building software tools that have those Levels built-in.

And the scale is deliberately technology-agnostic. “AI” will mean something different in five years because our concept of Humanness will evolve as we tackle bigger challenges with the help of AI and the layers of abstraction for tools evolve. The questions the scale asks — who originated this, who exercised judgment here, where is the constraint envelope set — will still be meaningful regardless of what the tools look like. That durability is intentional. Standards anchored to specific technologies become obsolete. Standards anchored to human agency survive the transitions.

The scale doesn’t tell you where to aim. It tells you where you are. What you do with that information depends on your domain, your values, and the people you’re accountable to.

But at least now you have the vocabulary to have that conversation.

So, now I can confidently specify that when I wrote this article I kept switching between being an Author and a Jazz Human. Thank you, Claude :)

References: Yuval Noah Harari, Homo Deus: A Brief History of Tomorrow (2016). Ethan Mollick, Co-Intelligence: Living and Working with AI (2024).

There has been a lot of discussion about harness engineering lately — an aspect of building agents that I’ve been thinking for a while, as it bridges LLMs with traditional software engineering best practices.

It started with Mitchell Hashimoto (creator of Terraform and Ghostty), who gave the practice its name: “anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.”

Then OpenAI published a detailed account of building a million-line production application over five months with zero hand-written code. Their conclusion: “the engineer’s job shifted from implementation to system design.” Martin Fowler picked it up, noting that the OpenAI piece buries its own lead — “harness” appears once in the text, yet the concept is the entire point. Anthropic’s engineering team approached the same problem from the other direction: agents that forget everything between sessions, like engineers working in shifts with no handoff. Their solution was structured persistence — a progress artifact that survives across context windows. And LangChain proved the numbers: their coding agent improved from 52.8% to 66.5% on Terminal Bench 2.0 by changing only the harness, with the model held fixed.

Latent Space’s swyx recently asked the hard question: is harness engineering even real? The piece frames the central tension well — Big Model vs Big Harness. The Big Model camp (Boris Cherny on Claude Code: “all the secret sauce is in the model — this is the thinnest possible wrapper”; Noam Brown: “those scaffolds will just be replaced by the reasoning models becoming more capable”) argues that better models make harnesses obsolete. The Big Harness camp counters that the harness is the product — every production agent converges on the same core loop, and the difference between a reliable system and a flaky one lives entirely in what wraps that loop. Swyx lands somewhere in the middle, noting that Cursor’s $50B valuation is hard to dismiss as pure model credit.

I come down firmly on the side of the harness — and not just because it’s generalizable. Harness engineering is good software engineering. It’s a clean separation of concerns: the model reasons, the harness controls. Verification nodes, constraint enforcement, structured handoffs — these are decomposed, testable modules, not prompt hacks buried inside a monolithic agent. The functional safety industry has known this for decades: you don’t make a safety-critical system reliable by making its core component smarter. You add redundancy, independent validation monitors, and enforced boundaries between layers. The harness is that architecture applied to AI agents. It’s also the most practical quality control mechanism we have — if your agent can produce output that bypasses verification, you don’t have a quality standard, you have a “suggestion” (like traffic lights in Greece).

The discussion so far has focused almost entirely on coding agents and long-running software projects. The principles apply anywhere agents do multi-step autonomous work — RAG pipelines, research synthesis, data processing, content generation. It’s worth making them concrete for AI engineers who aren’t building the next Codex but do want to build agents that actually hold up.

From in-context learning to harness engineering

It started with prompts.

When GPT-3 landed in 2020, the discovery that changed everything wasn’t the model itself — it was in-context learning: the ability to shape behavior by placing examples directly in the prompt. No fine-tuning, no retraining. Just carefully chosen text in the right position.

Researchers quickly found that structure mattered enormously. Chain-of-thought prompting (Wei et al., 2022) showed that asking models to reason step-by-step before answering — rather than predicting the answer directly — dramatically improved performance on complex tasks. Few-shot examples outperformed zero-shot. Explicit formatting beat freeform requests. The model hadn’t changed; what changed was the context it operated in.

This gave rise to context engineering: the discipline of curating what the model sees. What documents to retrieve. How to structure the system prompt. How much history to include. Context engineering is essentially asking: what information should the agent have access to right now?

It’s necessary. But it turns out it isn’t sufficient.

As agents became capable of sustained autonomous work — multi-step, multi-session, long-horizon tasks — a different class of failures emerged. Not hallucinations or bad reasoning, but structural failures: agents drifting from the original spec, declaring premature success, losing track of state between sessions, picking the wrong tool for the job.

Harness engineering is the response to that gap.

Context engineering vs. harness engineering

The distinction is worth making precise.

Context engineering asks: what should the agent see? Harness engineering asks: what should the system prevent, measure, and correct?

Context is a prerequisite. The harness is what turns a capable model into a reliable system. You need both — but most teams invest heavily in the first and neglect the second or confuse it with “business logic that the model will take care of” so they think the harness is their prompts.

Based on the above literature and my own agentic app projects, I believe harness engineering comes down to basically five patterns we can apply to our agentic apps. With the help of my new best friend, named Claude, I include examples below that use a RAG pipeline agent (building and evaluating retrieval over a writing corpus) rather than a coding agent — to make the principles concrete. The orchestration uses LangGraph; the retrieval layer uses Qdrant. The patterns themselves are framework-agnostic. Let’s walk through them.

1. Decompose before you execute

Without explicit task decomposition, agents given a broad goal will try to execute it in a single pass. They run out of context mid-implementation, leave half-finished work, and the next session’s agent spends most of its time reconstructing what happened rather than making progress.

The fix isn’t “work step by step” in the prompt. It’s a dedicated planning phase that produces a structured, machine-readable task list before any execution begins. A supervisor agent decomposes the goal; a worker processes one task at a time.

State definition and task structure:

from typing import TypedDict, Literal
from pydantic import BaseModel

class ProjectState(TypedDict):
    goal: str
    tasks: list[dict]         # Each: {id, description, status, output}
    current_task_index: int
    artifacts: dict

class Task(BaseModel):
    id: str
    description: str
    status: str = "pending"

class TaskList(BaseModel):
    tasks: list[Task]

The planner — runs once, produces the list:

def planner(state: ProjectState) -> ProjectState:
    task_list = llm.with_structured_output(TaskList).invoke(
        f"""Decompose this project into 5-8 sequential tasks.
        Each task should be completable independently.
        Goal: {state['goal']}"""
    )
    return {
        "tasks": [t.model_dump() for t in task_list.tasks],
        "current_task_index": 0,
    }

The worker — executes exactly one task:

def worker(state: ProjectState) -> ProjectState:
    idx = state["current_task_index"]
    task = state["tasks"][idx]

    result = llm.invoke(
        f"Complete this task. Only this task, nothing else.\n"
        f"Task: {task['description']}\n"
        f"Previous outputs: {state['artifacts']}"
    )

    state["tasks"][idx]["status"] = "done"
    state["tasks"][idx]["output"] = result.content
    return {"tasks": state["tasks"], "current_task_index": idx + 1}

The router — finds the next pending item:

def pick_next(state: ProjectState) -> Literal["worker", "__end__"]:
    for task in state["tasks"]:
        if task["status"] == "pending":
            return "worker"
    return "__end__"

Wiring the graph:

graph = StateGraph(ProjectState)
graph.add_node("planner", planner)
graph.add_node("worker", worker)
graph.add_edge(START, "planner")
graph.add_conditional_edges("planner", pick_next)
graph.add_conditional_edges("worker", pick_next)
app = graph.compile()

For a RAG pipeline project, the planner might produce:

[
  {"id": "1", "description": "Ingest essays and chunk with semantic splitter"},
  {"id": "2", "description": "Create Qdrant collection and index dense embeddings"},
  {"id": "3", "description": "Implement BM25 sparse retrieval baseline"},
  {"id": "4", "description": "Implement hybrid search with reciprocal rank fusion"},
  {"id": "5", "description": "Build LLM-as-judge evaluator with 20 test queries"},
  {"id": "6", "description": "Run evaluation across all three strategies and compare"}
]

The agent now has a contract. It processes one task, marks it done, and routes to the next. No skipping, no one-shotting the whole project.

2. Persist state across sessions

Each new session begins with no memory of previous sessions. Without a structured handoff, agents spend half their time reconstructing what happened instead of making forward progress.

The solution isn’t conversational memory or chat history. It’s a persistent artifact — stored externally — that the agent reads at the start of each session and writes to at the end. The references mention JSON works better than Markdown here: agents are less likely to accidentally overwrite structured data.

LangGraph’s Store abstraction handles this cleanly — a key-value layer that lives outside the graph’s ephemeral state and survives across invocations.

Session bookends:

from langgraph.store.memory import InMemoryStore
# In production: use Redis, Postgres, or another persistent backend

store = InMemoryStore()

def session_start(state: ProjectState, *, store) -> ProjectState:
    progress = store.get(("project", "rag_pipeline"), "latest")
    if progress:
        return {
            "tasks": progress.value["tasks"],
            "current_task_index": progress.value["current_task_index"],
            "artifacts": progress.value["artifacts"],
        }
    return state  # First session: pass through to planner

def session_end(state: ProjectState, *, store) -> ProjectState:
    completed = sum(1 for t in state["tasks"] if t["status"] == "done")
    store.put(
        ("project", "rag_pipeline"),
        key="latest",
        value={
            "tasks": state["tasks"],
            "current_task_index": state["current_task_index"],
            "artifacts": state["artifacts"],
            "summary": f"{completed}/{len(state['tasks'])} tasks complete",
            "retrieval_context": {
                "qdrant_collection": state["artifacts"].get("collection_name"),
                "embedding_model": state["artifacts"].get("embedding_model"),
                "chunk_strategy": state["artifacts"].get("chunk_strategy"),
            },
        },
    )
    return state

Wiring them as bookends (sandwich the agent):

graph.add_edge(START, "session_start")
# Route to planner on first run, or skip straight to pick_next if resuming
graph.add_conditional_edges("session_start", lambda s: "pick_next" if s.get("tasks") else "planner")
graph.add_edge("worker", "session_end")
graph.add_conditional_edges("session_end", pick_next_or_end)

When session 2 starts, the agent reads structured JSON: tasks 1–3 done, task 4 pending, Qdrant collection is personal_writing_v2, embedding model is text-embedding-3-small. It doesn’t explore or guess. It picks up exactly where it left off.

3. Verify before moving on

The most common failure pattern in autonomous agents is that the agent produces output, re-reads it, decides it looks fine, and moves on. It never actually tests whether the output works. The equivalent of a developer who reads their code but never runs it.

The fix is explicit verification nodes in the graph — between the worker and the next task. Two flavors work best in combination.

LLM-based verification — checks against the spec:

class VerificationResult(BaseModel):
    passed: bool
    issues: list[str]

def verify_with_llm(state: ProjectState) -> ProjectState:
    idx = state["current_task_index"] - 1
    task = state["tasks"][idx]

    verdict = llm.with_structured_output(VerificationResult).invoke(
        f"""You are a reviewer. Does this output satisfy the task spec?

        TASK: {task['description']}
        OUTPUT: {task['output']}

        Check: completeness, correctness, and whether the next task can build on it.
        Return: passed (bool), issues (list of strings)"""
    )

    if not verdict.passed:
        task["status"] = "needs_fix"
        task["issues"] = verdict.issues
    return {"tasks": state["tasks"]}

Deterministic verification — checks that retrieval actually works:

def verify_retrieval(state: ProjectState) -> ProjectState:
    idx = state["current_task_index"] - 1
    task = state["tasks"][idx]

    if "qdrant" not in task["description"].lower():
        return state  # Skip for non-retrieval tasks

    client = QdrantClient(url="localhost:6333")
    # embed() wraps your embedding model, e.g. OpenAIEmbeddings etc.
    results = client.query_points(
        collection_name=state["artifacts"].get("collection_name"),
        query=embed("What are my thoughts on creative writing?"),
        limit=5,
    )

    scores = [r.score for r in results.points]
    issues = []
    if len(scores) == 0:
        issues.append("Retrieval returned zero results")
    elif scores[0] < 0.5:
        issues.append(f"Top score {scores[0]:.2f} below threshold — check embedding config")

    if issues:
        task["status"] = "needs_fix"
        task["issues"] = issues
    return {"tasks": state["tasks"]}

Routing the loop:

def after_verify(state: ProjectState) -> Literal["worker", "pick_next"]:
    idx = state["current_task_index"] - 1
    if state["tasks"][idx]["status"] == "needs_fix":
        return "worker"
    return "pick_next"

graph.add_edge("worker", "verify_retrieval")
graph.add_edge("verify_retrieval", "verify_with_llm")
graph.add_conditional_edges("verify_with_llm", after_verify)

The critical detail: when control loops back to the worker, the issues list is in the state. The worker reads specific failure reasons and addresses them — not a generic retry.

4. Enforce constraints mechanically

Verification asks whether the output is correct. Enforcement asks whether the agent violated any structural rules — regardless of output quality.

OpenAI’s team used custom linters for their coding agents. The key insight: error messages were written to double as remediation instructions that get injected back into agent context. The system wasn’t just blocking mistakes; it was teaching the agent while it worked.

In LangGraph, this is a pure Python node — no LLM call — placed at a mandatory point in execution. The graph topology guarantees it runs; the agent cannot skip it.

def enforce_constraints(state: ProjectState) -> ProjectState:
    """No LLM. Runs after every worker output."""
    idx = state["current_task_index"] - 1
    task = state["tasks"][idx]
    violations = []

    # Chunking boundaries
    if "chunk_size" in state["artifacts"]:
        size = state["artifacts"]["chunk_size"]
        if not (100 <= size <= 2000):
            violations.append(
                f"VIOLATION: chunk_size={size} outside [100, 2000]. "
                f"FIX: Below 100 loses semantic coherence; above 2000 "
                f"exceeds embedding model input limits."
            )

    # Qdrant vector dimensions
    if "collection_config" in state["artifacts"]:
        config = state["artifacts"]["collection_config"]
        if config.get("vector_size") != 1536 and \
           "text-embedding-3-small" in str(state["artifacts"].get("embedding_model", "")):
            violations.append(
                f"VIOLATION: vector_size={config.get('vector_size')} but "
                f"text-embedding-3-small expects 1536. "
                f"FIX: Set vector_size=1536 in the Qdrant collection config."
            )

    # Evaluation metric sanity
    if "eval_scores" in state["artifacts"]:
        for metric, score in state["artifacts"]["eval_scores"].items():
            if not (0.0 <= score <= 1.0):
                violations.append(
                    f"VIOLATION: {metric}={score} outside [0, 1]. "
                    f"FIX: Normalize the evaluator's scoring function."
                )

    if violations:
        task["status"] = "needs_fix"
        task["constraint_violations"] = violations
    return {"tasks": state["tasks"]}

The mandatory execution pipeline after every task:

graph.add_edge("worker", "enforce_constraints")          # always runs
graph.add_edge("enforce_constraints", "verify_retrieval")
# verify_retrieval → verify_with_llm and after_verify routing already set in Pattern 3

The agent cannot create a Qdrant collection with the wrong vector dimensions and proceed. The constraint node will catch it and return explicit remediation steps (that the after_verify step will see and go to needs_fix. Structure that’s impossible to bypass — through prompting or otherwise. And it most likely save you some wasted tokens and $$ before piling up bad outputs from bad inputs.

5. Design tools with decision criteria, not just descriptions

Binding tools to an agent at initialization is table stakes. What changes outcomes is how you describe them.

Jeff Huber (CEO of Chroma) argues for narrow tools with descriptions that encode decision criteria — not just what the tool does, but when to use it and when not to. Tool descriptions are part of the agent’s context at decision time. The LLM loads these descriptions in its context. Vague descriptions force the agent to figure out retrieval strategy on its own. Precise descriptions let it match the right tool to the task without trial and error.

from langchain_core.tools import tool

# client = QdrantClient(url="localhost:6333")
# embed() wraps your embedding model, e.g. OpenAIEmbeddings or sentence-transformers

@tool
def semantic_search(query: str, top_k: int = 5) -> list[dict]:
    """Search by meaning — use for conceptual queries where exact keywords
    may not appear in the text.

    WHEN TO USE: 'What do I think about creativity?' or 'passages about
    self-doubt' — where the text might say 'imposter syndrome' instead.

    HOW IT WORKS: Embeds the query with text-embedding-3-small and runs
    cosine similarity against the personal_writing Qdrant collection."""
    results = client.query_points(
        collection_name="personal_writing",
        query=embed(query),
        limit=top_k,
    )
    return [{"text": r.payload["text"], "score": round(r.score, 3), "id": r.id}
            for r in results.points]

@tool
def keyword_search(query: str, top_k: int = 5) -> list[dict]:
    """Search by exact terms — use for specific names, dates, technical
    terms, or phrases the user quoted directly.

    WHEN TO USE: 'mentions of Kahneman' or 'the paragraph about March 2024'.

    HOW IT WORKS: BM25 sparse retrieval over the same corpus."""
    ...

@tool
def hybrid_search(query: str, top_k: int = 5, semantic_weight: float = 0.7) -> list[dict]:
    """Combined semantic + keyword search. Use this as the default when
    unsure which approach fits.

    WHEN TO USE: Most general queries. Start here unless you have a
    specific reason to use the others.

    HOW IT WORKS: Runs both searches, combines via reciprocal rank fusion."""
    ...

@tool
def get_full_document(doc_id: str) -> dict:
    """Retrieve the complete text of a document by ID.

    WHEN TO USE: After seeing a doc_id in search results and needing
    surrounding context.

    DO NOT USE for discovery — use a search tool first."""
    point = client.retrieve(collection_name="personal_writing", ids=[doc_id])
    return {"text": point[0].payload["text"], "metadata": point[0].payload["metadata"]}

Three things each description does that generic descriptions don’t: decision criteria (WHEN TO USE), mechanism (HOW IT WORKS), and negative guidance (DO NOT USE for). The agent selects the right tool on the first try rather than defaulting to the most generic option or cycling through by trial and error.

The full picture

The five patterns compose into a single graph topology:

None of this requires a better model. LangChain demonstrated that concretely: their coding agent improved from 52.8% to 66.5% on a benchmark by changing only the harness, with the model fixed.

The model provides the intelligence. The harness determines whether that intelligence produces consistent, verifiable, recoverable work that’s easy to test.

I love that the community is thinking about this. We should stop thinking about AI Engineering as “art”. There is no reason we shouldn’t treat it like any other software engineering discipline.

Welcome to the Red Vest Bullets, my bi-weekly…ish nudge to help you improve as a leader in tech, at work, at home, in life. Feel free to forward if it will help someone you know.

This week's bullets:

• Still building one product for everyone? User “preferences” won’t be the differentiator for long.

• What if each user got their own clone? Built on demand. Tailored exactly.

• If AI made software 1000x cheaper, how would you rethink “multi-tenant”?

Take a few minutes to reflect. Remember, leadership is hard, and you're not alone. Celebrate this week, and make the next one even better. 👏👏👏

Subscribe now

Every generation of programmers believes they’ve finally figured out the “real” way to write software.

Assembly programmers knew the machine. Procedural programmers knew algorithms. Object-oriented programmers knew design patterns. And today’s engineers? We know frameworks, APIs, and how to compose systems from a thousand npm packages.

Each generation was right—for their era.

But here’s the thing: every generation also got abstracted away. The assembly wizards watched compilers take over. The algorithm experts watched libraries commoditize their work. The design pattern experts watched frameworks encode their wisdom into configuration files and DSLs.

And now? We’re watching something similar happen again.

I’ve been thinking a lot about what “programming” will mean in five years. Or ten years. Not because I’m worried about AI taking jobs—that’s the wrong framing. I’m curious because I expect a pattern will emerge. The same pattern that’s played out five times before in computing history.

If we understand that pattern, we can predict what’s coming. And more importantly, we can prepare for it. Especially the next generation of engineers.

The Pattern: Abstraction All the Way Up

Here’s the core thesis: software engineering evolves through abstraction layers. Each new layer lets us express more with less. And each layer trades mastery of what’s below for the ability to manage greater complexity above because we can trust the collective best-in-class practices encoded by our tools to handle the layer below.

This isn’t a new idea. But I think we’re at an inflection point where it’s worth spelling out explicitly—because the next layer is going to change things more dramatically than any previous transition.

Let me walk through the six generations I see in software engineering history, and then we’ll talk about what comes next.

Generation 1: Assembly (1950s–60s)

In the beginning, there was the machine.

Early programmers didn’t write code—they wrote instructions. Opcodes, register addresses, memory locations. Every program was a precise sequence of commands that told the hardware exactly what to do, step by step.

Think about what that meant. To write software, you had to understand the physical machine. How many registers did it have? What was the instruction cycle? How did memory addressing work? The “abstraction” was... nothing. You were talking directly to the hardware.

Correctness meant one thing: did I use the right instructions to produce the right bits as efficiently as possible?

Getting to automate things was the big win then. This was incredibly powerful. And incredibly limiting. A single human could only hold so much machine state in their head. Programs were small by necessity—not because the hardware couldn’t do more, but because human cognition couldn’t track more.

But it worked. And for a while, this was programming.

Generation 2: Procedural (1970s–80s)

Then someone had a brilliant idea: what if we let a program write the machine code for us?

The compiler changed everything. Suddenly, you didn’t have to think about registers and memory addresses. You could write in a higher-level language—C, Fortran, Pascal—and the compiler would figure out the machine details.

The abstraction shifted from hardware instructions to control flow. Now you thought in functions, loops, and conditionals. The machine disappeared; logic remained.

Correctness meant something different: does this algorithm do what I intend?

Notice the trade-off. You gave up direct control of the hardware. Your compiled code was probably slower than hand-tuned assembly. But you gained the ability to write larger programs, to think at a higher level, to express intent more directly.

Was it worth it? Obviously yes. We’re still using compilers.

But here’s the interesting part: the compiler became a trusted collaborator. You verified your logic; it handled the translation. You didn’t need to check every line of assembly it produced. You trusted it. It was built by experts.

Remember that idea. It’s going to come back.

Generation 3: Object-Oriented (1990s–2000s)

As programs grew larger, a new problem emerged: managing state.

Procedural code was great for algorithms, but real applications had things—users, accounts, documents, transactions. These things had data and behavior. And managing them across a myriad of functions became a nightmare.

Object-oriented programming gave us a new abstraction: state encapsulation. Now you could model your domain with classes and objects. Data and behavior lived together in Abstract Data Types. Interfaces defined contracts. Inheritance let you share and specialize and model the world.

The abstraction shifted again. You stopped thinking about procedures and started thinking about domain models. UML diagrams, design patterns, class hierarchies—these became the tools of the trade.

Correctness meant: do these components interact correctly?

And something else happened in this era: design separated from implementation. You could sketch a system in UML without writing a single line of code. Then hand it to implementers. This was new. Previously, design was implementation.

The Gang of Four patterns weren’t just clever tricks—they were a vocabulary for thinking about software at a higher level than code itself.

Generation 4: Composition (2000s–2010s)

By the 2000s, something shifted again. There were so many libraries, so many frameworks, so many services—why were we still writing things from scratch? Thank you Open Source!

The abstraction became capabilities. You stopped asking “how do I implement this?” and started asking “which library already does this?”

Think about what a modern web application looks like. You import a framework for routing. A library for state management. An ORM for the database. An SDK for payments. Another for authentication. You’re not implementing these things—you’re composing them.

Correctness meant: did I wrap everything correctly?

The senior skill changed. It wasn’t about knowing algorithms (though that still helped). It was about knowing the ecosystem. What libraries exist? Which ones are maintained? What are the trade-offs? The best engineers distinguished themselves by knowing what not to build.

This era gave us package managers, software development across borders, and… dependency hell. But it also gave us incredible productivity. A single developer could build things that previously required teams.

Generation 5: Declarative (2010s–2020s)

The next shift was more subtle but just as profound.

Terraform. Kubernetes. SQL. GraphQL. React’s declarative UI model. What do these have in common?

You describe what you want, not how to achieve it. The system figures out the execution.

(But wait. Didn’t HTML have the same thing going on already in the 90’s? Yes, but you still had to rely on Javascript to do anything really useful 🤷 )

Now, if I want three replicas of this container, with these resource limits, on these nodes, I don’t specify the scheduling algorithm. I don’t manage the container lifecycle. I declare the desired state, and the system converges toward it because it already has wrapped everything it needs.

The abstraction became desired state. You’re not writing procedures anymore—you’re writing specifications.

Correctness meant: does my specification match my intent?

This is a subtle but important shift. The “code” you write isn’t executed step by step. It’s interpreted as a description of what should exist. The runtime decides how to make it so.

GitOps emerged from this. Your infrastructure is a YAML file in a repo. Change the file, the system converges to match. Deployment becomes a pull request.

Generation 6: Agentic (2020s–?)

And now we’re at the edge of something new. The “vibes” as we have come to call it.

Large language models can write code. Not just snippets—entire applications. You describe what you want in natural language, and the model generates an implementation.

This isn’t just another tool. It’s a new abstraction layer.

The abstraction is intent itself. You’re not writing code, configuration, or even structured specifications. You’re describing what you want in the most natural way possible—plain language—and the system produces an implementation.

Correctness means: does the system satisfy my specifications under the conditions I care about?

Andrej Karpathy called it early. In January 2023, he tweeted: “The hottest new programming language is English.”

He was directionally right. But as we’ll see, it’s more nuanced than that.

The Rhyming Principles

Here’s what’s fascinating: every generation follows the same patterns. History doesn’t repeat, but it rhymes.

Let me spell out the principles that keep showing up:

Abstraction as compression. Each layer lets you express more with less. What took 100 lines of assembly became 10 lines of C, then one library call, then one config line. The direction is consistent: toward pure intent.

The performance-productivity trade-off. We consistently accept slower execution for faster development. Hardware cost decreases faster than developer cost. This has held for 60+ years. We’ll accept suboptimal generated code if it gets us to working software faster.

Verification moves up the stack. Each layer develops its own correctness tooling. Assembly had instruction traces. Procedural had debuggers. OOP gave us unit tests. Composition brought integration tests. Declarative uses policy validators. What will the agentic era need? It’s not just evals. We need more than that.

The one-layer-down rule. Effective practitioners understand the layer immediately below them. Web developers know HTTP but not TCP internals. App developers know APIs but not compiler internals. You need one layer down for debugging. But not deeper—that’s diminishing returns.

Debugging requires descent. Abstractions always leak. When they do, you must drop down. This is why one-layer-down knowledge remains essential—even in the agentic era.

Composition over construction. Senior engineers in every era distinguish themselves by knowing what not to build. The boundary keeps moving up, but the principle stays the same.

These patterns aren’t a coincidence. They emerge from fundamental constraints:

• human biological cognition is finite

• hardware gets cheaper

• complexity wants to grow

The SDLC Rhymes Too

It’s not just the abstractions that rhyme. The entire software development lifecycle transforms at each layer—but the phases persist.

Design, build, test, optimize, deploy. These five activities exist in every generation. But what they mean changes completely.

Design started as hardware diagrams and instruction sequences. It became flowcharts, then UML, then architecture diagrams, then specs-as-code. In the agentic era? Natural language specifications, constraints, examples. The design artifact increasingly is the specification.

Build started as hand-coding punch cards. It became compilation, then complex build systems, then package managers, then reconciliation loops. In the agentic era? The agent generates, tests, iterates, refines. The human curates and approves.

Test started as manual traces and core dumps. It became print debugging, then unit tests, then integration tests, then chaos engineering. In the agentic era? Acceptance verification. Property-based tests. The agent critiquing its own output against success criteria.

Optimize started as hand-tuning assembly—choosing the right registers, minimizing instruction cycles, fitting code into scarce memory. It became compiler optimizations: dead code elimination, loop unrolling, inlining. In the composition era, it meant tree-shaking unused dependencies and minimizing bundle sizes. In declarative infrastructure, it’s right-sizing resources and optimizing reconciliation loops.In the agentic era? Optimization operates on source code itself. Not just for performance—for elegance and minimalism and code reuse, not slop.

Deploy started as physical media—tapes and cards. It became compiled binaries, then installers, then containers, then GitOps. In the agentic era? Continuous, agent-driven deployment. Maybe self-optimizing systems that adjust based on production telemetry.

The phases don’t disappear. They get automated or absorbed. The human role shifts from executor to specifier and verifier.

Why Writing Becomes the Core Skill

Now we get to the part that I think most people miss about AI-assisted development.

There’s a seductive idea floating around: natural language programming means lower cognitive demands. “Just describe what you want.” Sounds easy, right?

It’s actually the opposite.

Think about it. When you write code, the compiler enforces clarity. Syntax errors, type mismatches, failed tests—these are all feedback mechanisms that force you to sharpen your thinking. The code doesn’t run until your intent is precise enough.

When you write prose to an LLM? There’s no syntax error for ambiguity. The model will always produce something. It will cheerfully generate code from vague specifications, filling in gaps with assumptions you never examined.

The rigor that was externalized into the compiler must now be internalized into the specification process.

This is why “vibe coding”—Karpathy’s term for casual prompting without reviewing the output—works for weekend projects but won’t scale to production systems. It’s the toggle-switch programming of this era: fast for experiments, unmaintainable for anything real. LLMs are trained to statistically match features and similarities in concepts in our language so there is a limit to how vague we can be and get away with it. Our words are biasing the LLMs towards a particular direction vs another. Therefore err on the side of being specific and reduce ambiguity.

What Non-Programmers Teach Us

Here’s something interesting: when non-programmers learn to code—even with block-based visual languages like Scratch—they struggle in revealing ways.

The difficulty isn’t syntax. It’s something deeper.

Take the “implicit else” problem. A non-programmer writes an if-statement and assumes that if the condition isn’t true, the code will do “the other thing.” But in actual code, the program does nothing—it just continues to the next line. Maybe the assumption that “if I don’t specify then assume I mean the opposite” is ok for some people but not OK for others and the truth is somewhere in between the large amount of text that LLMs were trained with. It will think “it depends” and if it gets smarter it might ask you a question to disambiguate. If it wants to “please” you, it will just do what the statistics deem as most popular.

The above is a simple scenario. But think about it. It isn’t a syntax error. It’s a thinking error. Natural language allows implicit defaults. Computation requires explicit specification. Moving to natural language prompts doesn’t eliminate this problem. The LLM will also assume implicit defaults—and they may not match your assumptions.

“Make the button blue when clicked.” Okay, but what happens when it’s clicked again? Should it toggle? What shade of blue? What if the user doesn’t have permission? What if JavaScript is disabled?

The non-programmer’s struggle with explicit specification is the core challenge of agentic coding. The syntax barrier is removed. The thinking barrier remains for the untrained vibe coder.

The real skill was never syntax. It was thinking precisely enough that your intent could be unambiguously executed. Maybe the coders of the future will be trained in law schools? I mean why not? Their jobs will be taken over by AI soon. They might as well move to vibe coding. Even so, I hope not. I’d prefer philosophy grads or art majors in my 2035 engineering org.

The Sketching Paradigm

Why philosophy or art majors? Here’s where it gets interesting. LLMs do change something fundamental about the creative process—just not what most people think.

Traditional compilers demand premature rigor. Every line must be syntactically correct. Every type must match. You must be precise at the micro level before you can see the macro result.

This is like being required to paint in final detail before seeing the composition.

We’ve been fighting this forever. That’s why we built autocomplete, linting, real-time error highlighting, type inference, and hot reload. These tools exist because the compile-then-see-errors loop was too slow and punishing. We were trying to make coding feel more like sketching.

LLMs are the logical continuation. They let you skip the line-by-line negotiation entirely.

Think about how artists work. They start with rough sketches—capture the shape, ignore the details. They iterate on composition before committing to finish. The medium supports this workflow.

LLMs make code work this way too.

You can describe a pattern: “Build a user authentication flow with email verification.” The LLM produces a working sketch. It’s imperfect, but it’s runnable. You can see the shape before committing to the details. Then you can dive deeper as you reason the consequences.

This is why this new paradigm feels more accessible. It matches natural creative processes. It matches how senior engineers already think—progressive composition, sketching the API first, stubbing implementations, refactoring as understanding deepens.

The difference is that experienced engineers learned to do this despite the compiler’s demands. LLMs make it native to the medium. Novices can access the expert workflow from day one. And those trained in art or philosophy will do well above average. They create and experiment and test hypotheses systematically and most importantly they can articulate what “done” looks like. In the future, instead of doing that on paper or canvas, they can do it by turning the LLM into a compiler from NLP to Python, TS, C++, etc. and either sketching top down or setting the success criteria similar to a reward function, and eating up compute doing reinforcement learning until the outcome fits the bill.

The Technical Foundation

I should explain why this actually works at a technical level. Because “prompts are programs” isn’t just a metaphor—it’s literally true.

Few-shot learning (demonstrated in the GPT-3 paper, 2020) showed that you can change a model’s behavior by including examples in the prompt. No fine-tuning. No gradient updates. Just text.

The prompt isn’t a question—it’s a specification. The examples program the model’s behavior through “in-context learning”.

Chain-of-thought prompting (Wei et al., 2022) showed that you can make models execute reasoning procedures by showing them examples of reasoning. Include step-by-step problem-solving in your prompt, and the model will decompose new problems the same way.

The prompt describes how to compute, not just what to compute. It’s pseudocode in natural language.

ReAct (Yao et al., 2022) showed that prompts can specify interleaved reasoning and action patterns. The model reasons, takes an action, observes results, and adjusts its plan.

The prompt defines a control loop—a behavioral pattern that unfolds over time with environmental feedback.

See the progression? From questions to specifications to algorithms to control loops. Prompts have evolved from queries to complex computational specifications.

This is why the LLM layer fits the same pattern as every other compiler. It takes a higher-level specification and produces a lower-level implementation through an “algorithm”. The medium is natural language (one level closer to human expression vs machine expression), but the function is the same.

“English Is the New Programming Language”—Sort Of

So Karpathy was right. English is the new programming language.

But it’s more nuanced than that.

There are really two phases to agentic coding that have emerged:

Phase 1: Sketching. Express intent in natural language, get a working approximation. This is broadly accessible. It matches how people naturally communicate.

Phase 2: Refining. Identify gaps, specify edge cases, iterate to production quality. This requires precision. It’s specification engineering.

Both phases use natural language. But they require very different skills.

“Make it pop” gets you a first draft. “Handle the edge case where the user submits an empty form after the session timeout but before the page refresh” gets you production code.

Here’s what’s not obvious: when you clarify ambiguity in a prompt, you’re making design decisions. Each clarification is a specification choice. The refinement process is the design process.

People who think they’re “just describing what they want” are actually architecting systems. The more skillful they are in understanding the underlying building blocks the better agent-assisted coders they will be.

Two Ways to Sketch

But there’s another way to approach this entirely. Instead of sketching the solution and refining it, you can sketch the success criteria and let the agent search for solutions that satisfy them.

Think of it like reinforcement learning. Instead of telling the agent how to build something, you define what “done” looks like—your reward function—and let the agent explore until it finds something that meets your criteria.

Say you’re building a data pipeline. The traditional approach: “Build an ETL job that pulls from Postgres, transforms the data like this, and loads it into Redshift.” You’re specifying the solution.

The reward-based approach: “I need data in Redshift that matches these validation rules, refreshed within 15 minutes of the source, with less than 0.1% error rate, costing under $50/month to run.” You’re specifying the success criteria—the definition of done—and letting the agent figure out the implementation.

The agent might try different architectures. Batch vs. streaming. Different transformation strategies. It runs against your criteria, fails, adjusts, tries again. You’re not guiding the solution—you’re refining the reward function until it captures what you actually care about.

This is powerful for problems where you know the outcome but not the path. “I need a recommendation engine that increases click-through by 20%” is easier to specify than the exact algorithm to achieve it. Let the agent search.

Of course, there’s a trade-off. Solution sketching is fast—you get something immediately and iterate on it. Reward sketching requires more upfront thinking about success criteria, and the agent’s search process takes longer and costs more compute. You’re trading human iteration time for machine exploration time.

But here’s what’s interesting: as models get better and cheaper, the reward-based approach becomes more viable. And it forces a useful discipline. When you have to articulate your success criteria precisely—decompose them, weigh them, handle conflicts between them—you often discover you didn’t really know what you wanted in the first place. Classic TDD trade-off.

The skill isn’t just describing what you want. It’s defining success criteria that actually capture what you want within what’s possible by your building blocks—criteria robust enough that an optimization process can’t game them. I think we need to be able to work on both levels: sketching solutions or sketching success criteria. Both depend on the solid understanding of the layer below.

A better framing:

• Conversational English is the new design language.

• Specification-grade English is the new programming language.

• And increasingly, success-criteria English is the new testing language.

The barrier to entry (sketching) is dramatically lower. The ceiling of skill (specification and criteria design) is just as high.

The New Full Stack

Let me sketch what the full pipeline looks like in the agentic era:

The critical insight: feedback must flow all the way back to the specification layer. Runtime behavior informs specification refinement. The loop closes at the top.

And here’s what the “compiler of the future” could look like. Not just a translator from high-level to low-level, but a bidirectional, multi-layer system:

• Downward (generative): Specification → code → binary → execution

• Upward (explanatory): “This timeout occurred because the generated code used algorithm X, which was chosen because your spec said Y, which implied constraint Z”

• Lateral (suggestive): “If you want behavior A instead, modify your specification from P to Q”

This is possible because of the rhyming properties we discussed. Every layer has analogous concepts—correctness, composition, optimization, verification. A sufficiently capable system can translate between them.

The Tooling Gap

Here’s the problem: we don’t have the tools yet.

Every generation required new tooling for its abstraction layer. Assembly needed assemblers. Procedural needed compilers and debuggers. OOP needed IDEs and unit test frameworks. Composition needed package managers and CI/CD.

For the agentic era, we need:

Specification validators (the new compiler). Detect ambiguity: “Your spec could mean X or Y—which do you intend?” Detect incompleteness: “You haven’t specified behavior for edge case Z.” Detect inconsistency: “Constraint A conflicts with constraint B.”

Acceptance verifiers (the new test framework). Generate property-based tests from specifications. Report failures in terms of specification gaps, not code bugs.

Constraint checkers (the new linter). “This specification allows SQL injection.” “This spec implies O(n²) complexity.” “This specification violates organizational standards.”

Agent trace debuggers (the new debugger). “The agent chose algorithm X because...” “To change this behavior, modify your specification here...”

Source-level optimizers (the new optimizer algorithm). This one is critical and often overlooked. Traditional compilers optimize machine code—they eliminate dead code, inline functions, optimize memory access. We need the equivalent for source code generated by agents.

Why? Because agents generate slop. Without proper guardrails, an agent will happily write 200 lines of custom code instead of calling an existing library function. It will generate utility functions that duplicate what’s already in your codebase. It will ignore API boundaries and inline logic that should be abstracted. It will leave dead code paths, and so on.

Specification patterns (the new design patterns). Common patterns for specifying certain types of systems. Anti-patterns that lead to ambiguous specs.

Without these tools, we’re in the toggle-switch era of agentic development. Vibe coding is the default because specification engineering is too hard.

Building this tooling is the critical path.

What Future Engineers Need to Learn

So what skills matter in this upcoming world?

The skill shift isn’t from “technical” to “non-technical.” It’s a change in which technical skills matter.

Precise logical expression. Writing like a philosophy paper—arguments that are causal, trace to first principles. Avoiding implicit assumptions. The “else” must be stated.

Procedural thinking. Understanding how things iterate step by step. Sequencing matters. State changes matter. This is the old procedural programming skill, expressed in prose.

Interface design. How do you break down a problem? What are the boundaries between components? What does each part need to know about others? This is OOP thinking, without the syntax.

Success criteria design. This is the skill game developers have mastered for decades. How do you define “done” in a way that’s measurable, testable, and resistant to gaming?

Corner case anticipation. What happens at the edges? Empty inputs? Maximum scale? Concurrent access? Thinking like an adversarial tester of your own specification.

Systems thinking. How do parts combine into wholes? What emergent behaviors arise? Where are the failure modes? This is architecture, expressed in prose.

Fault-tolerant thinking. What can go wrong? What must not happen? Specifying constraints, not just capabilities. Graceful degradation of experience.

One-layer-down literacy. You must be able to read and understand generated code. Not write it from scratch, but audit it. Debugging still requires descent even if a futuristic debugger can help you.

Domain expertise. Agents don’t know your business. Translating domain knowledge to specifications becomes the irreplaceable human contribution.

Notice what’s changed and what hasn’t. The concepts are the same ones good engineers and builders have always needed. The medium changes from code to prose.

Implications for Education

If I were redesigning the CS curriculum today, I’d start by questioning the boundaries.

Right now, these disciplines live in separate departments:

• Computer Science: algorithms, data structures, systems

• Technical Writing: documentation, clarity, precision

• Philosophy: logic, argumentation, ethics

• Design Thinking: user needs, iteration, prototyping

• Product Management: requirements, success metrics, trade-offs

• Game Development: reward systems, progression, balancing competing objectives

In the agentic era, these all converge. They’re not separate skills anymore—they’re facets of the same core capability: specifying systems precisely and defining what success looks like.

Think about what agentic software engineering actually requires:

You need computational thinking to understand what’s possible and what’s hard. You need philosophy to construct logical arguments that trace to first principles—and to avoid the implicit assumptions that trip up specifications. You need technical writing to express complex requirements without ambiguity. You need design thinking to understand user needs and iterate toward solutions. You need product thinking to decompose business goals into measurable criteria. And you need game development thinking to design reward functions that don’t get gamed—success criteria that actually capture what you want.

These aren’t electives. They’re the core.

A CS major in the 2030s might look something like this:

Specification and technical writing. Before syntax. Expressing requirements precisely. Structured prose. Formal and semi-formal specification languages. This is the new “intro to programming”.

Computational thinking. Algorithms, complexity, trade-offs—but focused on recognizing and specifying, not just implementing. You need to know that something is O(n²) even if you never implement it.

Logic and argumentation. Borrowed from philosophy. Constructing valid arguments. Identifying hidden assumptions. Distinguishing necessary from sufficient conditions. This is the foundation of precise specification. The ability to be less vague about the world and the trade-offs.

Success criteria design. Borrowed from game development and product management. How do you decompose “good” into measurable outcomes? How do you balance competing objectives? How do you prevent gaming? This is reward function design as a discipline.

Verification and validation. How do you define correctness? Property-based testing. Acceptance criteria design. If you can’t define “correct,” you can’t verify it—and neither can an agent.

Human-AI collaboration. Specification engineering. Auditing agent output. Debugging specifications. Understanding when to sketch solutions vs. sketch success criteria.

Systems architecture. Composition, contracts, interfaces, failure modes. Essential for specifying complex systems, even if you’re not implementing them.

One-layer-down literacy. Reading and understanding code for auditing and intervention. You don’t need to be fluent, but you need to be literate.

Domain modeling. Translating domain expertise into formal constraints. This is the irreplaceable human contribution—agents don’t know your business.

Notice what’s missing from the traditional curriculum: hours and hours of syntax drilling. Implementing sorting algorithms from scratch. Memorizing API signatures. These become less important when agents handle implementation.

And notice what’s elevated: writing, logic, criteria design, systems thinking. The humanities and the technical converge.

The meta-skill? Learning to learn new abstraction layers. More are coming. Adaptability is the durable advantage.

I’m not saying we throw out algorithms and data structures. You still need to recognize an O(n²) disaster when you see one. You still need to understand why certain architectures fail at scale. But the emphasis shifts from implementing to specifying and evaluating. Plus all the underlying layers will still be evolving and there will be a need for such specialists. Also, programming courses are the only thing we have currently developed for mass consumption. So, in the future, I’d move courses on programming language and compilers or operating systems and networks or linear algebra and ML algorithms into electives, and not part of a core curriculum. Most engineers won’t need them.

The CS department of the future might need to poach faculty from Philosophy, from the Design school, from the Game Development program, from Technical Communications, and Business Schools. Or maybe we stop pretending these are separate disciplines at all.

The “Fit in Your Head” Test

Here’s the ultimate measure of each abstraction layer: how much complexity can one engineer manage?

The pattern is clear. You stop holding implementation details. You start holding contracts, interfaces, specifications. The scope expands because the abstraction compresses.

If agentic tooling matures, a single engineer might specify systems that currently require teams and years of work. Not because they understand every line of code, but because they understand the specification layer and trust verified translation through the stack. We have to equip a single individual with the mental models, skills, and tools to design, implement and deploy things like a database from scratch, or the whole software package of a space station, or the energy management system for a smart city, or a service as complex as Uber.

This is the opportunity. And the challenge.

Democratization: Why This Time Might Be Different

Now let’s talk about what this means for who can build software.

Programming has historically been gated by several barriers:

Syntax mastery. Memorizing language rules, keywords, punctuation.

Tooling complexity. Setting up development environments, dependencies, build systems.

Error interpretation. Understanding cryptic compiler messages.

But the deepest barrier is harder to see: learning to think like a machine.

Even “high-level” languages expose the underlying computer architecture. To write code properly, you must understand concepts shaped by hardware:

• Compute: What operations are cheap vs. expensive?

• Memory: Stack vs. heap, allocation, garbage collection, references vs. copies

• Execution: Sequential flow, call stacks, control transfer

• I/O: Blocking vs. non-blocking, streams, buffers

• Concurrency: Threads, locks, race conditions

These aren’t “advanced topics”—they leak into everyday programming decisions. “Should I load this into memory or stream it?” “Why is this loop slow?” “Why did this work locally but fail in production?”

You’re not just learning a language. You’re learning to inhabit an alien worldview.

It’s like learning a foreign language well enough to write legal contracts—but for a client whose mind works completely differently from yours. Most people who “learn a language” in school can order coffee. Most people who “learn to code” in a bootcamp cannot build a coffee-ordering app. The gap to professional fluency is vast.

What LLMs change:

Previous democratization attempts—visual programming, no-code tools—lowered syntax barriers but still required upfront precision. You still had to think like a machine.

LLMs change the workflow fundamentally:

• Non-deterministic generation approximates intent

• You can describe patterns, not just lines

• You see working sketches before committing to details

• Rapid refactoring reduces wrong-path risk

This matches how artists work. Sketch → shape → refine → detail. Traditional coding inverted this: detail → detail → detail → test → detail.

The medium now supports the workflow that was previously only available to experts.

The workforce implication:

If the expert workflow is accessible to novices, and syntax barriers are removed, and wrong paths are low-cost to abandon... the pool of potential software creators expands dramatically.

Not 10% more programmers. Potentially 10x more.

Domain experts can implement their ideas directly. The “idea person” and “implementation person” can be the same person. The gap between concept and working demo shrinks.

The nuance:

This doesn’t democratize everything equally.

Democratized:

• Producing working code (syntax barrier gone)

• Building simple applications (sketch-level work)

• Prototyping and exploration (low iteration cost)

Not equally democratized:

• Building robust, production systems (requires specification rigor)

• Handling use cases and failure modes (requires systematic and user-centric thinking)

• Architecture and system design (requires deep understanding)

The skill bar shifts. It doesn’t disappear.

Think about spreadsheets. They democratized computation in the 1980s. Non-programmers could suddenly do sophisticated data manipulation. But complex spreadsheet modeling still requires skill. And spreadsheets can still go badly wrong—ask anyone who’s seen a financial model with circular references.

Excel didn’t eliminate the need for financial analysts. It changed what they do.

Agentic coding may follow the same pattern. What a senior engineer learns from 20 years of experience will become table stakes for new grads.

Open Questions

I want to be honest about what we don’t know.

Where will the agentic abstraction leak? Every layer leaks. Prediction: specification ambiguity, edge cases the spec didn’t anticipate, performance local optimals from agent choices, security vulnerabilities from underspecified constraints. We’ll be fixing those over time one by one.

What’s the new “dependency hell”? Composition had dependency conflicts. Declarative has config drift. Agentic might have: specification inconsistency across systems, agent version drift (same spec, different outputs), non-reproducible generations, LLM prompt or RAG dependency conflicts in large agentic systems. One module says A, the other says B. Which version does the agent use?

How do we build trust? We trust compilers because they’re deterministic and formally verified. Agents are stochastic—same input can produce different output. On top of that we choose what memory to attach to them and hope we context-engineered it well. How do we get compiler-level trust for something fundamentally probabilistic? We are barely scratching the surface on how to compartmentalize agent outputs in real-world apps.

Does this democratize or stratify? On the optimistic side, more people can build complex systems. On the other hand, a new elite of “specification whisperers” could emerge. I think both are happening. The floor rises (more people can do more) and the ceiling rises (experts can do even more).

Timeline? This evolution could take 5 years or 20 years. Depends on tooling development, trust building, education system adaptation. The pattern is clear; the timing is not because funding is limited, society needs time to adjust, and investors and politicians are human.

What We Need to Do Now

If this analysis is right, here’s what matters:

Build the tooling. Specification validators, acceptance verifiers, constraint checkers, agent trace debuggers, source code optimizers. This is the critical path. Without tools, vibe coding remains the default.

Update education. Emphasize specification, verification, and writing. Maintain one-layer-down literacy. Teach mental models, not just syntax.

Develop trust mechanisms. Figure out how to get compiler-level confidence from stochastic systems linked to memory and data. This is an unsolved research problem.

Create patterns and practices. What does good specification engineering look like? Or “definition of done” design? What are the anti-patterns? We need a discipline, not just a set of tricks.

Closing Thought

The practitioners of every era believed they were doing “real” programming.

The assembly wizards who hand-optimized register allocations. The C programmers who understood the stack. The Java architects who drew UML diagrams. The Node developers who composed npm packages.

They were all right—for their era.

The agentic generation will be no different. The engineers who thrive will be those who can say precisely what they mean and verify that they got it.

The pattern that has held for 70 years continues. Each generation fits more in their heads and builds bigger things. The medium changes. The fundamental challenge—translating human intent into machine behavior—remains.

History rhymes. The next verse is being written now.

And I think we have a say in how it sounds.

Welcome to the Red Vest Bullets, my bi-weekly…ish nudge to help you improve as a leader in tech, at work, at home, in life. Feel free to forward if it will help someone you know.

This week's bullets:

• What’s the ratio between what matters—and what’s just noise?

• Where has clutter crept in: your work, your space, your thinking? Elegance is hard.

• Ready to clear the junk? Don’t let your mental space turn into a Big Duck.

Take a few minutes to reflect. Remember, leadership is hard, and you're not alone. Celebrate this week, and make the next one even better. 👏👏👏

Subscribe now

Welcome to the weekly Red Vest Bullets, my little nudge to help you improve as a leader in tech, at work, at home, in life. Feel free to forward if it will help someone you know.

This week's bullets:

• Are you giving up your agency to AIs too easily? Bad habits form fast.

• How do you regain control?

• Which decisions should AI never make for you? Draw that line. Then build a better partnership.

Take a few minutes to reflect. Remember, leadership is hard, and you're not alone. Celebrate this week, and make the next one even better. 👏👏👏

Subscribe now

Welcome to the weekly Red Vest Bullets, my little nudge to help you improve as a leader in tech, at work, at home, in life. Feel free to forward if it will help someone you know.

This week's bullets:

• Things changing fast, yet new information doesn’t spark your interest?

• Are you accumulating knowledge or truths? Truths are precious. They aren’t read, they’re discovered.

• Time to dig? It’s hard, deep work, but the only way to find a new truth. Don’t waste time on the rest.

Take a few minutes to reflect. Remember, leadership is hard, and you're not alone. Celebrate this week, and make the next one even better. 👏👏👏

Subscribe now

Welcome to the weekly Red Vest Bullets, my little nudge to help you improve as a leader in tech, at work, at home, in life. Feel free to forward if it will help someone you know.

This week's bullets:

• Isn’t more creativity always good? Sure. It beats boring work.

• Is there such a thing as too much? Yes. Your brain is a muscle.

• Why? Creativity is heavy lifting. Treat it like a workout, or you’ll burn out.

Take a few minutes to reflect. Remember, leadership is hard, and you're not alone. Celebrate this week, and make the next one even better. 👏👏👏

Subscribe now

Welcome to the weekly Red Vest Bullets, my little nudge to help you improve as a leader in tech, at work, at home, in life. Feel free to forward if it will help someone you know.

This week's bullets:

• Idiots causing you grief? Tag the pain with a $$ amount.

• Is the ROI still worth it? Lock them in a mental box – unlock only when it’s transaction time.

• Impossibly big even for your largest box? Cut them loose and take the loss. It will seem unimportant later on.

Take a few minutes to reflect. Remember, leadership is hard, and you're not alone. Celebrate this week, and make the next one even better. 👏👏👏

Subscribe now

Bear in mind I’m a Zero-To-One guy. One-To-Ten drains me. Even my doctor said I’ve got many more fast-twitch muscle fibers than slow-twitch ones. I’m wired for sprints. Mentally and physically.

I spent real money on training, gear, travel, physio – but this article isn’t about how much a marathon will cost you.

I changed how I ate and drank – but this is not about nutritional tips for losing weight.

I went through multiple MRIs, HA injections, cryo, heat, and all kinds of therapies for multiple injuries, including one that flared up mid-race – but this is not about injury prevention.

What I want to tell you is this:

A marathon – any marathon – will really be about managing your relationships.

Your Whys

You’ll want to have someone in mind you’re doing this for. Someone you hope will see you as their role model, someone you want to teach or inspire. Someone you don’t want to let down even when you’re hitting walls. My boys were my why.

Your Cross Bearers

Your closest ones – spouse, kids, etc. – will have to adjust their lives for your crazy goal. They’ll want to go out on Saturday night, but what they’ll do instead is stay home and order in because they see you can’t move your legs after your three-hour run. Don’t take them for granted. That’s what true love and loyalty look like.

Your Team

If you’re a twenty-something, skip this part. You can probably finish the marathon while sipping beer with just a week’s worth of practice. If you are everyone else, don’t go into a marathon without a support team: coach, nutritionist, physiotherapist, doctor. They’ll retrain your bad, inefficient footwork, give you all the tips, the apps, the gear, fix your legs, and your meal menu. You are running a marathon, not to the store and back. Think long-term.

Your Cheerleaders

You have friends and neighbors and colleagues. You don’t have to advertise to them that you’re running a marathon. It will leak out when you skip drinks three times out of four and the fourth time you order a tiny glass of beer. They’ll be curious throughout your training but it will feel like casual conversation. Like they don’t care. But on race day magic will happen. While you’re riding the 9 am Staten Island ferry, stuffed with anxiety and bagels, they’ll switch on. They’ll flood you with texts and calls of encouragement from around the globe that will power you up. Those who can will be in the crowd and yell your name and hug you. And after the race, expect a shower of love and high-five emojis that will make you feel like a million bucks.

Your Torch Carriers

Some people you never expected will tell you how much you inspired them. That you woke something up in them. That you broke their mental barrier and now they want to get off their couch and train hard and do a marathon like you did. Your journey will end only to seed more journeys.

Your Brothers and Sisters In Arms

Chances are during your journey you’ll meet others training for the marathon. This bond and information exchange makes the pain softer and validates your choice. You’re not the only one going through a midlife crisis. You’re not a weirdo for introducing this completely unnecessary hardship into your life. So, bring more such marathoners into your life. It’s more fun.

Those Outside The Arena

Others – thankfully very few – will criticize your decisions, efforts, or your performance. “You spent all that time and money just to finish ten minutes faster than the guy who didn’t hire a coach?” or “If I did it I would have done x, y, or z”. Their judgments will hurt you because they will base them on your deepest doubts and fears and you will start second-guessing yourself. And if you confront them they will hide behind “just sharing an opinion”. You think hell is a place filled with torture chambers? No. Hell is where all these “opinionistas” are bred. Comfortable academics who ran one mile and suddenly know everything. Put such opinionistas into the same bin your neighbor puts their dog’s shit. That’s where they belong. Not your head.

The Crowds

During your race, the crowds will scream non-stop, trying to pump you up. They’ll put up signs and posters. A full party on the streets. Pull in their energy, but don’t focus on them. Their noise and chaos will distract you from your pace and your plan.

Your Self

You’ll want to quit the marathon more times than you expect. During training and during the race. Build enough relationships around your marathon that quitting costs too much. Slow down your pace if you must, but don’t stop, even on that long Fifth Ave climb when leg muscles you didn’t know existed are cramping up. You will push through to the finish line to get your shiny gold medal. And thanks to the long preparation you will show off your sexy six-pack abs.

Welcome to the weekly Red Vest Bullets, my little nudge to help you improve as a leader in tech, at work, at home, in life. Feel free to forward if it will help someone you know.

This week's bullets:

• How do you define growth?

• Grow = expand? Learn that skill when you need more.

• Or grow = improve? Learn that when you should use less.

Take a few minutes to reflect. Remember, leadership is hard, and you're not alone. Celebrate this week, and make the next one even better. 👏👏👏

Subscribe now

Welcome to the weekly Red Vest Bullets, my little nudge to help you improve as a leader in tech, at work, at home, in life. Feel free to forward if it will help someone you know.

This week's bullets:

• Rushing when you should be deliberating? You’ll trip.

• Deliberating when you should be rushing? You’ll stall.

• Or should you slow down now to take off later?

Take a few minutes to reflect. Remember, leadership is hard, and you're not alone. Celebrate this week, and make the next one even better. 👏👏👏

Subscribe now

Welcome to the weekly Red Vest Bullets, my little nudge to help you improve as a leader in tech, at work, at home, in life. Feel free to forward if it will help someone you know.

This week's bullets:

• Was it a sure thing…until it wasn’t – and now your bank account is running dry?

• Lost your cushion? Don’t panic. It’s an opportunity.

• What now? Stay busy and build. Build from your backlog. Build one day at a time.

Take a few minutes to reflect. Remember, leadership is hard, and you're not alone. Celebrate this week, and make the next one even better. 👏👏👏

Subscribe now

Welcome to the weekly Red Vest Bullets, my little nudge to help you improve as a leader in tech, at work, at home, in life. Feel free to forward if it will help someone you know.

This week's bullets:

• Did you spin your wheels, feel annoyed with work, or make someone else feel small? That’s a Minus Day.

• Did you knock out a goal, feel like a winner, or make someone else feel like one? That’s a Plus Day.

• Ready for a challenge? Don’t get 3 Minus Days in a row.

Take a few minutes to reflect. Remember, leadership is hard, and you're not alone. Celebrate this week, and make the next one even better. 👏👏👏

Subscribe now

Welcome to the weekly Red Vest Bullets, my little nudge to help you improve as a leader in tech, at work, at home, in life. Feel free to forward if it will help someone you know.

This week's bullets:

• Do you fall in love with your first idea?

• What if a better one is just seconds away? No need for analysis-paralysis.

• What if you fired 3 shots – and picked the bullseye?

Take a few minutes to reflect. Remember, leadership is hard, and you're not alone. Celebrate this week, and make the next one even better. 👏👏👏

Subscribe now

Welcome to the weekly Red Vest Bullets, my little nudge to help you improve as a leader in tech, at work, at home, in life. Feel free to forward if it will help someone you know.

This week's bullets:

• Do titles validate you? Chasing status can be a drug.

• What if that title becomes your cage?

• What if you chased the work you want instead? Or the right people? Or the lifestyle? The right title will follow.

Take a few minutes to reflect. Remember, leadership is hard, and you're not alone. Celebrate this week, and make the next one even better. 👏👏👏

Subscribe now

Welcome to the weekly Red Vest Bullets, my little nudge to help you improve as a leader in tech, at work, at home, in life. Feel free to forward if it will help someone you know.

This week's bullets:

• Afraid to make mistakes? We all are.

• But what if the problem is highly complex?

• Do you trial-and-error strategically? Because the “God Complex” will not get you there

Take a few minutes to reflect. Remember, leadership is hard, and you're not alone. Celebrate this week, and make the next one even better. 👏👏👏

Subscribe now

Welcome to the weekly Red Vest Bullets, my little nudge to help you improve as a leader in tech, at work, at home, in life. Feel free to forward if it will help someone you know.

This week's bullets:

• Are you afraid you only live once?

• What if you had 300 years instead?

• What insane challenge would you take on?

• Why wait? You may finish it sooner than you think. Start today!

Take a few minutes to reflect. Remember, leadership is hard, and you're not alone. Celebrate this week, and make the next one even better. 👏👏👏

Subscribe now

Welcome to the weekly Red Vest Bullets, my little nudge to help you improve as a leader in tech, at work, at home, in life. Feel free to forward if it will help someone you know.

This week's bullets:

• Is critiquing easier than creating? Of course.

• Is AI turning you into a critic more than a creator? If you’re mostly reviewing and revising prompts…it kind of is.

• Is that good for you?

Take a few minutes to reflect. Remember, leadership is hard, and you're not alone. Celebrate this week, and make the next one even better. 👏👏👏

Subscribe now