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

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 sharp are your questions?

• Are they teaching you, or just checking boxes?

• Are they pointing you to your next move in the infinite sea of (AI-parsed) knowledge?

• Will the AI give you the right answers? Only if you ask the right questions. This matters more than ever now. So keep sharpening your skills!

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:

• Dropping the ball a lot lately?

• Do you keep saying “I thought you were doing that”?

• What if you got rid of the handoff? Don’t think like a factory. Agency grows when handoffs are strategic, automatic or gone.

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