Typesafe’s Jev is around everywhere and people have built at least a thousands of projects and use cases. But what makes it so special?

Let’s uncover that.

In the last few years, we have spent time teaching machines how to talk.

We give a large language model a prompt and it can write code, summarize a paper, explain quantum mechanics, draft an email, or imitate a style. The entire interface is built around generation: token after token after token, until an answer appears.

That makes perfect sense when what we want is language.

But a surprising amount of software does not actually need language.

• A fraud system does not need an essay about whether a transaction looks suspicious.
• A support router does not need three paragraphs explaining why a ticket belongs to billing.
• An agent supervisor does not need beautifully worded prose about whether an action looks risky.

It needs a decision.

Fraud?
YES / NO

Where should this ticket go?
BILLING / TECHNICAL / SALES

Should this agent continue?
CONTINUE / REPLAN / ESCALATE

And yet our default architecture is often something closer to this:

Unstructured input
       ↓
Large language model
       ↓
Generate tokens
       ↓
Produce JSON
       ↓
Parse JSON
       ↓
Validate schema
       ↓
Retry when it breaks
       ↓
Extract the one decision we wanted

We built extraordinarily powerful generative systems, then started using them for almost every fuzzy decision in software, even when the final output was just a boolean, a label, or one option from a small list.

That is the problem Jev is trying to attack.

Jev, from TypeSafe AI, belongs to a category the company calls System One Models. Instead of asking a model to generate an answer, you give it some unstructured state and ask it to make bounded decisions with probabilties.

Conceptually, the difference is simple.

GENERATION

"What should I say?"
        ↓
token → token → token → token

DECISION

"Which of these is true?"
        ↓
A  0.08
B  0.87
C  0.05

And when you look at this, you realise that agents who call tools, inspect state, decide whether to continue, retry, escalate, bla bla to make even a tiny semantic decision, are not always needed!

Imagine, if every one of those decisions requires a full generative-model round trip, how the economics and latency increase and we are charged a bomb!!

So with Jev, the question is effectively asking whether we have been using the wrong computational primitive for a large part of AI software.

I wanted to understand whether that argument actually holds up.

A little about Jev!

Jev is our cute, tiny friend introduced to us by TypeSafe, which, I will clear now itself, is not another LLM!

In their own words: TypeSafe’s defines it is “unstructured state in, typed probabilistic decisions out.”

Imagine, for example, that an AI coding agent has just edited twenty files and run a test suite. At that moment the surrounding system may need to know several things:

Did the task actually succeed?

Does this change look risky?

Should the agent continue working?

Does a human need to review this?

So instead of asking a model to generate something like:

“The changes appear mostly correct, although there may be some risk associated with the authentication code, so I recommend human review.”

the application could define the possible decisions directly:

TASK COMPLETE?
Yes / No

RISK LEVEL?
Low / Medium / High / Critical

NEXT ACTION?
Continue / Retry / Human review

Jev evaluates those questions against the same underlying state and gives the application numbers it can work with.

Conceptually:

CURRENT STATE

          code changes, logs, test output,
         user request, tool results, context
                         │
                         ▼
                        JEV
                         │
              ┌──────────┼──────────┐
              ▼          ▼          ▼
         Complete?     Risk?    Next action?
            .94       High .71   Review .82
              │          │          │
              └──────────┼──────────┘
                         ▼
                    APPLICATION
                         │
              rules / thresholds / policy
                         │
                         ▼
                       ACTION

Remember: Jev doesn’t decide what 0.82 should mean for your business. Your software does.

Why call this “System One”?

The name comes from the familiar distinction between two kinds of thinking: one fast and immediate, the other slower and more deliberative.

TypeSafe is borrowing that metaphor for AI systems.

So, unlike a large reasoning model where the system needs to work through an open-ended problem, construct an argument, plan, generate code, or synthesize new information; a System One Model takes the current state and make a fast judgment about it.

You can think of an eventual AI system as having both kinds of operations:

Something happened
       │
       ▼
   FAST JUDGMENT
       │
   Is this routine?
   Is it risky?
   Where should it go?
       │
       ├──────────── routine ───────→ code / action
       │
       └──────────── difficult ─────→ reasoning model

It suggests that not every step in an intelligent system should require reasoning or generation in the first place.

What does Jev actually receive?

To break it down, how it works, let’s look at its architecture once.

The first is the state where the information describes what Jev is supposed to judge.

That might be:

• a support conversation,
• an agent trajectory,
• a document,
• application logs,
• a security event,
• a product review,
• or, in our experiment later, the extracted contents of a bookmark.

The second is the set of questions which the application wants answered.

And when I looked at TypeSafe’s technical documents, I came across how they expose their answer shapes. TypeSafe currently exposes three of them as Choice, Score, and Noul.

1. A Choice means:

Which one of these possibilities is it?

Which team owns this ticket?

Billing
Shipping
Returns
Technical

Jev returns the most likely option with the probability assigned to every option and a confidence value. Choice supports up to 255 options.

2. A Score means:

Where does this fall on an ordered scale?

How severe is this bug?

0  Cosmetic
1  Feature degraded
2  Blocking

Jev doesn’t have to return only 1 or 2. It returns the probability distribution across the levels and a probability-weighted score. So if it places 70% probability on level 1 and 30% on level 2, the score is 1.3.

3. And Noul is the simplest one:

Is this true?

Does this require human escalation?

YES / NO

The answer is one probability between 0 and 1. A result near 1 means strong evidence for yes, near 0 means strong evidence for no, and around 0.5 means the model is unsure.

So Jev is not generating a new schema every time.

And there is one architectural detail here that TypeSafe emphasizes heavily: if you ask several of these questions about the same state in one request, Jev is designed to evaluate them in parallel rather than generating each answer sequentially. In fact, TypeSafe’s documentation clearly says that adding several questions to a call generally does not add latency in the same way as adding generated output does.

So this:

Customer conversation
        │
        ▼
       JEV
        │
  ┌─────┼────────┬───────────┐
  ▼     ▼        ▼           ▼
Intent  Risk   Churn?      Escalate?

is closer to the mental model than:

question → answer
question → answer
question → answer

Now, just like me, you might also be thinking, isn’t this just Classification? Well well well. It is kind of that but not really!

The idea behind Jev did not begin with Jev

To understand this, let’s take a step back when our tiny little friend was not even born.

It all started when in March 2025, Indian researcher Nandakishor M published a paper called SalesRLAgent: A Reinforcement Learning Approach for Real-Time Sales Conversion Prediction and Optimization. The problem he was working on was narrow: Sales Conversions!

What his paper conceptualised was that a salesperson did not always need another paragraph of generated advice. Just like a normal sales person, the obvious question they wanted an answer to was:

How likely is this deal to convert now?

So SalesRLAgent treated the conversation as a sequential state and trained a specialized reinforcement-learning system to estimate conversion probability as the conversation evolved. Instead of producing prose, it produced a number representing the model’s current judgment about the state of the deal.

And then a few months later, Nandakishor explored another version of the same idea.

His 2025 paper Confidence-Aware Routing for Large Language Model Reliability Enhancement starts one step earlier in the AI pipeline.

Instead of letting a model generate an answer and then asking whether that answer was trustworthy, the system tries to assess reliability before generation happens.

It combines several signals into a confidence estimate and then routes the request accordingly:

Incoming query
      ↓
Estimate confidence first
      ↓
┌───────────────┬──────────────┬──────────────┐
High            Medium         Low            Very low
↓               ↓              ↓              ↓
Local model     RAG         Larger model   Human review

In fact, for years, we have had models that take an input and predict a label: spam or not spam, positive or negative sentiment, one document type among many. More recently, BERT-style encoders, zero-shot classifiers, GLiNER, constrained decoding, DSPy signatures, Instructor, and structured-output LLMs have all attacked different versions of the same problem.

What differentiates TypeSafe’s Jev here is how they have bundled it around the old problem of classifiers.

A traditional classifier is usually trained for a fixed task. You might train one model to detect spam, another to classify support tickets, and another to predict whether a customer is likely to churn. The label space is often baked into training.

Jev is trying to preserve something we got used to with LLMs: runtime flexibility.

You can give it a new state and define a new set of questions without retraining a task-specific classifier.

Today you can ask:

Does this support message indicate churn risk?
YES / NO

and tomorrow:

Which team should own this?
BILLING / TECHNICAL / SALES / OTHER

and then:

How severe is the issue?
LOW / MEDIUM / HIGH / CRITICAL

That part looks much more like prompting than classical supervised classification.

So Jev sits in an interesting middle ground:

TASK-SPECIFIC CLASSIFIER

cheap + fast
but usually fixed around one task

GENERAL LLM

flexible at runtime
but generates text sequentially

JEV

classification-like output
+
runtime-defined questions
+
probabilities
+
parallel evaluation

As per the company, Jev really is a new model architecture, a parallel sampler, and a training method Reinforcement Learning for Calibrated Decisions, or RLCD. So, what Nandkishor did, they build it something larger with that.

So I tried to build it

All of this sounded convincing on paper. But Jev is still new, TypeSafe has not published a full technical paper on the model, and most of what we know publicly comes from its own documentation and early experiments.

So I wanted to see what happens to create one.

I built a small project called Curiosity.

The idea was simple: I save things everywhere from X posts, GitHub repositories, YouTube videos, articles, random web pages but I rarely organize them properly. And even when I do, folders such as AI, Research, or Read Later are usually too broad to tell me what I am actually becoming interested in.

So instead of asking me to create folders first, Curiosity tries to infer the themes that are emerging from what I save.

The first version of the architecture looked roughly like this:

Saved resources
      ↓
Extract + normalize content
      ↓
LLM
discover possible concepts
      ↓
Jev
evaluate membership repeatedly
      ↓
Application policy
      ↓
Curiosity map

I passed each normalized resource, along with the frozen definition of the concept, through the decision model. Within a few seconds, the collection started separating itself. So, suppose one of the buckets is:

AI agents

And I add a link or it takes it from Bookmarks tab which is a Twitter Post.

Now, looking at the tweet, it is clearly around evals. Jev’s job is not to summarize the post or explain what evals are. It only has to answer a bounded question:

Does this resource belong to the “AI agents” bucket?

And because the same resource can be relevant to more than one concept, we can ask the same question against several candidate buckets.

For example:

AI agents                     0.94
Building Software             0.98
Mind and Learning            0.08

Within milliseconds, the tweet now has a semantic position in the map.

This is the part that makes Jev feel very different from manually creating folders.

I did not tell the system:

“Put this tweet under AI evaluation.”

I only gave it the resource and the available concepts. Jev estimated the relationship between them.

Tweet
  ↓
Jev compares it against existing concepts
  ↓
AI evaluation       0.98
AI agents            0.94
Decision models      0.41
  ↓
Product policy
  ↓
Automatically placed

And this happens every time a new resource arrives.

For example, I gave it a YouTube video and it classified it automatically:

That resource could be a tweet today, a GitHub repository tomorrow, and a YouTube video after that. As long as we can extract enough useful text from it, Jev can evaluate it against the same concept definitions.

But I also wanted to know what happened before Jev gave me that answer

A probability like 0.98 looks convincing, but by itself it tells us very little.

Did Jev actually see the video? Did we manage to extract a transcript? Was it classifying from the title alone? Which concepts did we compare it against? Which version of Jev made the decision? How many tokens did we send? And, most importantly, did Jev decide where the resource went, or did our application make that decision afterward?

So alongside Curiosity, I built a small trace for every classification run.

This is what one of those traces looks like for a YouTube video:

1. The first step has nothing to do with AI. From the URL pattern, the system can deterministically identify the resource as a YouTube video.
2. The next step is more interesting: what information about the video can we actually recover?
   For this run, YouTube did not expose a transcript to our unauthenticated extractor, but the system still had a reasonable amount of context to work with. It combined the video title, roughly 900 characters of description, channel information, tags, and other available metadata into a normalized 1,040-character representation. That exact text, visible in the trace under “Text the router saw”, is what Jev classified.

From that representation, Jev evaluated all 12 concepts in a single routing call and returned Mind & Learning = 0.98, while every other concept remained far lower.

Mind & Learning       0.98
Culture & Media       0.11
Health & Body         0.09
Product & Business    0.08
Design & Creativity   0.06
Science & Nature      0.04
AI & Agents           0.01

3. And also the tokens used with the latency:

Latency       910 ms
Input         1,852 tokens
Output          221 tokens
Attempts           1
Cost        not reported

We can see the actual computational path: what we extracted, how much context reached the model, which model version ran, how many candidate concepts were evaluated, how many tokens the request consumed, and how long the decision took.

But even then, Jev had still not technically put the video into a bucket.

It had only said:

Mind & Learning = 0.98

The next line in the trace belongs to our code, not Jev.

We created a policy called threshold-v1:

confirm ≥ 0.80
reject  ≤ 0.20

So the sequence was actually:

YouTube page
      ↓
extract usable evidence
      ↓
normalize into model input
      ↓
Jev evaluates 12 concepts
      ↓
Mind & Learning = 0.98
      ↓
our policy: 0.98 ≥ 0.80
      ↓
CONFIRMED
      ↓
MATCHED_EXISTING

So, if tomorrow we decide that 0.80 is too aggressive and move the threshold to 0.90, it means our original model output remains 0.98; only the product policy changed.

With this trace, I had a proper audit trail for an AI decision rather than just depending on its own knwoledge base or decision matrix.

With the trace, I wanted to evolve it more which I will do in the upcoming days. But for now, you might ask:

So, should you use Jev everywhere?

No.

Because Jev becomes compelling when the shape of the problem is already constrained.

That is exactly what made it useful in the Curiosity experiment.

1. First, if you have some messy state, a known set of decisions, and you need to make those decisions repeatedly, quickly, and cheaply, Jev is the answer.
2. Second, TypeSafe currently lists Jev 1.13 at $0.042 per million input tokens, with output tokens uncharged, and advertises end-to-end latency around 70–500 ms.

With these 2 factors, Jev becomes the go-to place for all our use cases. BUT!

The failure modes are also worth noticing

Let’s look at them:

• Jev can still be wrong: Jev’s typed output solves one problem very well: it keeps the model inside the decision space you define. If the only valid answers are Billing, Technical, Sales, and Other, it cannot suddenly invent a fifth category.
  That also means the quality of the decision space becomes your responsibility. If the real case is something your schema does not represent well, say a refund dispute, account abuse, or a new issue you never anticipated. Jev still has to choose among the options you provided and the output could become wrong.
• Bad state construction: In our experiment, if you would have noticed, Jev never watched a YouTube video. But our system extracted a title, description, metadata, tags, and sometimes a transcript, normalized those into text, and Jev judged that representation.
  If the extractor gives it the wrong page, a login wall, a poor snippet, or incomplete context, then a perfectly reasonable model decision can still produce a terrible product result.
• Question design: Jev can only judge within the decision space you give it. If the question is vague, labels overlap, or an important option is missing, the model may return a perfectly valid answer to a poorly designed question.
• Calibration: TypeSafe’s central claim is that Jev is trained for calibrated decisions using RLCD. That is potentially very important, because software can only sensibly threshold probabilities if those probabilities mean something.
  Although, TypeSafe has not yet published the full RLCD training runs or a broad independent calibration benchmark So a production system should not interpret:

0.92

as:

there is objectively a 92% chance this is correct.

It should mean:

this model returned 0.92 on this task; now let us see how scores around 0.92 actually behave on our labelled data.

That is why our harness ended up mattering almost as much as the model itself.

And Jev is not the only way to solve this problem

There is not yet another model that is obviously a drop-in equivalent to Jev, particularly because TypeSafe has not released Jev’s weights or RLCD training method.

But there are several adjacent approaches.

If your categories are fixed and you have labelled data, a fine-tuned encoder classifier may still be the simpler and cheaper solution.

If what you really need is valid JSON from an LLM, structured output and constrained-decoding systems already solve that problem without introducing a new model class.

Tools such as Outlines constrain generation to a schema. Instructor provides typed structured extraction. DSPy lets developers define typed signatures and optimize LLM programs. Zero-shot classifiers such as GLiClass, as well as BERT-style encoders, tackle overlapping parts of the same decision problem.

There are also already community projects attempting to reproduce Jev-like interfaces on open models, although none reproduces Jev itself because the underlying TypeSafe architecture and training recipe remain private.

Fixed task + labelled data
        ↓
fine-tuned classifier

Need valid structured generation
        ↓
constrained / structured-output LLM

Open-ended reasoning or writing
        ↓
generative LLM

High-volume, runtime-defined,
bounded semantic decisions
        ↓
Jev becomes interesting

The part I find more interesting than Jev itself

After building with it, I am less interested in whether the phrase “System One Model” becomes a permanent category.

Maybe it will.

Maybe the industry eventually decides that Jev is simply a very capable zero-shot decision model with a particularly good interface or it is another story!

Jev is only days old, and many of TypeSafe’s strongest claims still need independent testing. There are unanswered questions around calibration, architecture, training and how well the model holds up outside carefully shaped decision tasks.

So I would not build a critical system around Jev simply because it is fast and cheap.

I would benchmark it against the alternatives, label real examples, inspect failures, keep explicit fallback paths, and let code control what happens next.

But Jev did change one assumption for me:

Maybe generating language should not be the default way software asks AI to make a decision.

And for now, I am happily latching on to it!

On July 16, a month back, Moonshot AI released Kimi K3–2.8 trillion parameters, and a context window of one million tokens. So, I took time to understand everything, dig deeper into their tech reports, architecture, and compare them with the best of the exisiting models to understand what Changes!!

Kimi K3 can read one million tokens in a single context window.

That is enough room for an enormous amount of conversation history, documents, code, decisions, corrections, and instructions to sit in front of the model at once.

Which raises an important question for an entire category of AI infrastructure:

If the model can simply read everything, why do Mem0, Zep, Letta, Supermemory and half a dozen other AI-memory companies need to exist?

Thousands of production agents now have some form of memory layer attached to them. These systems extract facts such as “prefers dark mode,” “works in fintech,” “rejected the first design,” or “asked not to receive email updates,” store them somewhere, and retrieve them later.

But if a model can carry the equivalent of several books of history in a single request, why bother?

That question sent me into Kimi K3’s architecture and what I found is that the distinction is not really Kimi versus Mem0.

It is something much more fundamental:

What should a model remember while it is thinking, and what should a system remember after the thinking is over?

Kimi K3 is really an information-management machine

Kimi K3 has approximately 2.8 trillion parameters, but only about 104 billion are active for a given token. So, if we strip away the benchmark numbers then we really have seven to eight engineering decisions left and I have planned this post to take you through it all.

1. The 69/24 split: Interestingly, K3 has 93 layers but all of them are not of the same kind. The 69 layers internally use Kimi Delta Attention (KDA) which is a linear attention mechanism that’s cheap over long sequence and the other 24 layers use Gated MLA (full attention) which is expensive but precise.
   Now, we want to understand what does this mix mean? When we see other models, they have a linear attention which comes with a known flaw: it can’t attend precisely across the whole context.
   Moonshot pays for periodic full-attention layers rather than going all-in on the cheap mechanism: The cheap-but-lossy interleaved with expensive-but-exact.
2. KDA’s fine-grained forgetting: We know that Linear attention works by maintaining a fixed-size state that decays over time where an old information fades to make room for new. In the earlier design systems, they controlled the decay by adding one global knob for “how fast do I forget.”
   With the new Kimi model, KDA replaces the scalar functionality with a diagonal matrix: a per-channel decay rate. So now, different feature channels can retain information at different speeds where some channels hold on and others let go.
3. Attention Residuals (AttnRes): Instead of every layer uniformly accumulating everything computed before it, layers can selectively retrieve representations from earlier depths. Because of this Moonshot reports ~25% training-efficiency gain for under 2% extra cost.
   Again, the theme is familiar:
   What information should survive? What should be accessible later? What should be compressed?
4. Stable LatentMoE + Quantile Balancing: Kimi model has approximately 2.8 trillion parameters but only 104 billion (16 of 896 experts) wake up for any given token. And instead of the usual heuristic load-balancing losses, routing uses quantile-based allocation which is amazing!
   I have written a detailed article on how “Mixture of Experts” work, do give it a read to understand this in depth.
5. Training for length, not just with length: The model wasn’t thrown at million-token sequences on day one. What Moonshot did differently was to increase the context length progressively during training, and built synthetic datasets where solving the task genuinely requires attending across the entire window; not just the local neighborhood.
6. The serving story: The model itself is quantization-aware training from the SFT stage with MXFP4 weights & MXFP8 activations so the low-precision model is the model making it cost efficient.

And one most important one: Moonshot states that K3 was trained to preserve reasoning history across a session or the performance degrades during multi-turn agent use. In fact, even the model’s usage contract is about what gets remembered between turns.

(There’s also Per-Head Muon on the training side and a native 401M-parameter vision encoder. These fascinating stories for another day.)

Now, that we have listed down all the factors one by one, let’s revisit them slowly:

• Per-channel decay rates tells us what to forget, and how fast.
• Gated MLA and a compressed KV path tells us as to how to store what we’ve read, cheaply.
• AttnRes tells as to what to retrieve from what you’ve already computed.
• Sparse routing tells as to what to activate out of everything you know.
• Progressive length training tells as to how to actually use a huge span of history.
• Quantization tells us as to how to afford holding all of it.

If we analyse, almost every major decision in this architecture is a decision about memory, what to keep, what to compress, what to retrieve, or what to let fade. This entire architecture built by Moonshot is really a multi-level memory management system that operates inside a single request.

Some of the very famous companies built on that like very scenario need to justify their existence. For example,

Mem0 which is probably the most popular memory layer for AI apps right now raising $24 million to solve exactly this problem, Zep built a whole temporal knowledge graph for it, Letta spun out of the MemGPT paper for it, Supermemory, LangMem, half a dozen others are solving the exact problem.

On the other hand, thousands of production agents ship with a memory layer bolted on, extracting little facts about users like “prefers dark mode”, “works in fintech”, “asked for a refund once” storing them in a database, and injecting them back into prompts later.

When we have all such tools and agents, here comes a model that can hold roughly ten novels of raw conversation history in a single request.

So one of two things must be true:

• Either the memory-layer industry is a dead or lost industry (which I don’t really want to conclude), or
• my intuition about what “1M context” means is wrong.

So, instead of guessing, I decided to understand: what is memory for a language model, mechanically? Where can state actually live? And what does each option really cost?

Let’s get started:

A language model forgets everything at the request boundary

Let’s look at what actually happens when we send a request to any LLM like K3, Fable, Sol, doesn’t matter.

When our prompt arrives, it gets broken into tokens, and the tokens get converted into embeddings. Then the model does its work, layer by layer, attention and the feed-forward ones that produces activations, and along the way the model builds something called a KV cache. The keys and values of every token it has read so far is kept around so it doesn’t have to re-read the whole sequence for every new token that it generates. The cache works exactly how we think.

And then the request ends. The output is returned, and everything from the activations, the KV cache, all of it, is discarded. Shredded.

But if we see closely, in this workflow, nothing actually was written back to the weights.

In fact, at inference time, the weights are strictly read-only, learning only ever happens during training, and your conversation is not training.

So when we say “the model remembers me”, that sentence is false. The model cannot remember you. Something around the model is remembering you, and putting it back in front of the model every single time.

So, if the state has to survive between two calls to a stateless function, there are only four places it can possibly live:

1. First, in the weights themselves which means training or fine-tuning. But imagine fine-tuning a model per user, how economically absurd it would be because you would be maintaining one model copy per customer, updates would take hours instead of milliseconds, and there’s no way to delete a specific fact once it has dissolved into the weights (Parametric memory matters enormously, but it is where general knowledge lives, not where “this user prefers dark mode” should live.)
2. Second, in the prompt where we simply feed the history back in as input.
3. Third, in a compressed note where we summarize the history and feed the summary back in.
4. Fourth, in an external store where we keep the information outside, and retrieve selected pieces when they seem relevant.

So every memory product, every context window announcement, every “personalization” feature we have ever seen is one of these four moves, or a combination of them.

So the real question is what does each of these three moves actually cost and when does that cost become worth paying?

Move one: put everything back in the prompt

Feeding the entire history back has one advantage no other approach can match which is that “nothing is lost”.

So why doesn’t everyone just do this?
Because when we price it out, the bill arrives in four different currencies.

Tokens, and they recur: We pay for the history on every single call as we keep resending it. A 400,000-token history across thirty messages in a day is roughly twelve million input tokens billed to answer questions that might each be one line long. This is why context caching exists: Anthropic, OpenAI, and Moonshot all cache repeated context, and K3’s is automatic and free with flat pricing across the window.

Compute, and it grows quadratically: Full attention compares every token with every token before it, so doubling the history roughly quadruples the attention work.

Serving memory: That KV cache from the last section has to physically sit in GPU memory for the entire duration of the request, and it grows with every token you stuffed in, for every concurrent user at once.

Attention itself: A million-token window is a capacity number and it tells us how much the model can accept, and promises nothing about how well it recalls any of it. Recall across long contexts is not uniform: information in the middle of a long sequence is retrieved less reliably than information at the edges which we also know as the well-documented “lost in the middle” problem. And raw history carries its issues. The fact from January (“works at Company A”) sits in the window with the same authority as its correction from June (“now works at Company B”), and we are trusting the model to referee that conflict correctly, on every request, forever.

Which points somewhere very naturally. If forgetting and compression are how you survive a long context inside the model, why not do the same thing outside it, at the application level, where we actually control what gets kept?

That is move two and it is exactly what the most sophisticated agent systems already do.

Move two: compress the history into notes

The obvious cheaper alternative is to stop carrying the transcript and keep a running note instead of goals, decisions, preferences. The cost problem vanishes. But we’ve traded it for a worse one: compression is a prediction about what will matter later, made before we know what we’ll be asked and when it drops a detail, it is a failure. A summarizer folds “refunds must go to the original payment method — legal requirement” into “built the payments module,” and forty sessions later the agent ships store-credit refunds. The bug isn’t in the code; it’s in a compression that happened five weeks earlier, and nobody will trace it back. A missing memory and a memory that never existed look identical from inside the model.

Move three: extract and retrieve from an external store

This is the move the whole memory industry is built on, so let’s understand it as an engineering pipeline because once we see the pipeline, we see exactly where each company lives and exactly where each one can fail.

There are four stages, and every one of them is a place where things can go wrong.

Stage one is extraction:
As the conversation happens, something has to decide which parts are worth remembering and write them down as discrete memories.

Stage two is storage, and the choice of how we store shapes what we can later ask. Store memories as embeddings in a vector database, and we can retrieve by semantic similarity but we cannot easily ask “what changed about this user over time.”

Stage three is retrieval: When a new message comes in, the system has to pull the relevant memories back into the prompt. Most systems bet on semantic similarity: find the stored memories whose embeddings are closest to the current query. But “semantically similar” is not the same as “actually relevant to this decision.”

Stage four is lifecycle: The user who worked at Company A now works at Company B. The preference for email updates becomes a preference against them. So the store must handle updates, resolve conflicts between old and new memories, invalidate stale facts.

That fourth stage is where the tools genuinely differ and each company is really a bet on which stage matters most.

• Mem0 is the general-purpose extract-and-retrieve layer, scoped across user, session, and agent levels.
• Zep made temporal lifecycle its whole thesis: every fact gets a validity window, so “works at Company A” isn’t wrong, it is expired and the one thing a naive vector store cannot represent.
• Letta (from the MemGPT lineage) treats memory as tiered state the agent manages itself, paging information in and out of context like an operating system.
• Supermemory leans into cross-application memory over MCP.
• And LangMem is the LangChain-native option.

When you understand now how the memory layer really works and how every company treats it differently, understanding the memory types might just help you to take a decision.

Kimi vs Memory Models

When we say a system has “memory,” we are pointing at one word that is actually covering at least seven different things and now we will understand why is “Kimi versus Mem0” a valid question.

Parametric memory is what the model learned during training, stored in the weights. K3 knows what a binary search is because of parametric memory. This is the deepest and most permanent layer, and no memory tool touches it. Mem0 cannot write here; only training can.

Working memory is the active context window where everything the model can see right now. K3’s million-token window is a very large working memory. This is the layer long-context models are expanding.

Computational memory is the KV cache: the intermediate state the model maintains while processing the current sequence. This is where KDA and Gated MLA operate on how to hold the current sequence affordably. When people conflate “1M context” with “remembers me,” they are confusing this layer and the next.

Those first three live inside the model. The next four are what the memory industry actually works on and they live outside it.

Episodic memory is the record of specific events: “on Monday, the user rejected the first design.” A log of things that happened, with their particulars intact.

Semantic memory is the consolidated fact distilled from those events: “the user prefers minimal interfaces.”

Procedural memory is how-to knowledge the agent should apply: “always run the tests before proposing a patch.” These are behavorial instructions.

Temporal memory is the understanding that facts have a time dimension like that “works at Company A” was true then and “works at Company B” is true now, and that the system must know which is current. This is the layer Zep built its whole product around.

Now, K3’s innovations, every one of them, operate on working and computational memory. The million-token window expands the working memory; KDA, Gated MLA, and the KV-cache work make computational memory affordable. That is the entire footprint of what a long-context model improves. It makes the inside-the-model layers bigger and cheaper.

Mem0, Zep, Letta and the rest operate on episodic, semantic, and temporal memory: the outside-the-model layers. They persist events, consolidate facts, and track change over time, across sessions, across applications.

So look at what we actually asked at the start of this post. “Kimi K3 can read a million tokens, so why does Mem0 exist?” We were comparing a working-memory improvement to an episodic-and-temporal-memory product. They are not competitors. So, let’s see through some comparison, the valid ones:

Two comparisons

The taxonomy gives us a rule that the models and the memory products are not on the same axis, so we do not get to put them in one table.

Table A: Model-side memory (working + computational)

One line of interpretation goes here: bigger windows are converging across labs, so the real differentiator is recall and cost structure, not the window number everyone quotes.

Table B: Product-side memory (episodic + semantic + temporal)

One line of interpretation goes here: notice there is no “context window” row and no “recall” row because these tools compete on lifecycle, not on length.

The two tables together say what eight sections of prose have been building toward: you are not choosing between a model and a memory tool. You are choosing a model for one layer and, separately, deciding whether you need a product for the other. Most real systems end up wanting both:
a capable context window and a thin persistence layer.

So what should you actually build?

Let’s start by asking one question: does your state need to cross a session boundary? Almost everything follows from the answer.

1. If it does not, the corpus is small, it lives in one session, and getting the details exactly right matters. No memory layer, no vector database, no extraction pipeline. Feed the model the actual material and let it read.
2. If your state lives inside one long-running project that you control like a coding agent, a research assistant working a single problem over days, then a structured working note is usually enough. Keep a file with fixed sections (decisions, constraints, open questions), let the model read it each turn, and keep a pointer back to the raw history so nothing is truly gone.
3. You only reach for an external memory layer like the Mem0/Zep/Letta tier when memory must persist across separate sessions, be shared across multiple users or agents, survive for months or years, get deleted on request, or track facts that change over time.

So, Sol or Kimi models really handle the long-context model which is the reasoning engine, holding the active working set.

The memory layer sits beside it as persistence, holding the durable, cross-session facts and at the start of each session it injects only the handful that matter back into the model’s context.

Let’s take an example:

Take a user with fifty sessions of history, say 500,000 tokens accumulated and one new one-line question, priced on K3’s real rate of $3 per million input tokens.

Move one, replay everything: you send ~500K tokens to answer one question. That is roughly $1.50 per message on a cache miss and if the session is active, that history reloads on every turn.

Move two, summarized note: the 500K history is compressed to a ~2K working note. You send ~2K tokens that is a fraction of a cent per message.

Move three, external layer: you retrieve maybe five relevant facts which is a few hundred tokens and inject those.
Also a fraction of a cent, but now you own an extraction pipeline, a store, and a retrieval step, each of which can fail. You did not pay in tokens; you paid in system complexity and moving parts.

The long-context camp oversells a capacity number: a million-token window tells us how much a model can accept, not how reliably it recalls the middle of that window, resists a stale fact, or stays affordable at real volume. And the memory-tools camp oversells its benchmarks: most of them measure whether a stored fact was retrieved, not whether it was the right fact, still current, or safe to surface.

Neither long context nor external memory has actually solved memory. They fail in opposite directions, which is precisely why the good architectures uses both.

So we can finally answer the question this whole post started from. Kimi K3 can read a million tokens, and Mem0 still exists, and both of those facts are correct.

I wanted to cover this story to explain as more and more of us need to understand memory systems in depth. In the upcoming posts, we will reverse engineer how were these built and work in our context.

Thank you for reading!

It is no more a hidden secret that the use case why Langraph and Langchain came into picture and solved the problems for us, have become 2X complicated. So what is next?

How did the existence happen?

Let’s take a step back and go to the year 2023 when ChatGPT had just blown up. Every developer suddenly wanted to build “an app with AI in it.” But when you actually sat down to build something beyond a basic chatbot, you were stuck.

Calling an LLM API is easy which meant sending one HTTP request and getting a response back. The problem is that real applications need a lot more than one request. Think about what a useful AI app actually needs to do:

• Take a user’s question, but first look up relevant information from a company’s internal documents before answering, basically a RAG pipeline (Will cover RAG in detail in the next article).
• Remember what the user said three messages ago (that’s memory).
• Decide whether to search the web, query a database, or just answer from its own knowledge (that’s tool use).
• If the first answer isn’t good enough, try again with a different approach (that’s a loop).
• Connect to OpenAI today, but maybe swap to Anthropic tomorrow without rewriting everything (that’s abstraction over providers).

Sounds good, right?

But in early 2023, none of this was built into the model APIs. OpenAI gave you a chat.completions endpoint. If you wanted any of the above, you had to write it yourself, from scratch, every time. And everyone was writing the same boilerplate → connect to vector DB, chunk documents, format prompts, parse outputs, handle retries.

This is the problem statement that Langchain wanted to solve.

How did it come into picture?

In late 2022, Harrison Chase who was an ML engineer at Robust Intelligence, a Bay Area company did the critical work of testing and validating machine learning models in production. For three years, Chase confronted the gap between research prototypes and production systems.

He’d spent years watching ML systems break in messy real-world ways, which turns out to be excellent preparation for what was about to happen.

In October, 2022, at a company hackathon, he built a bot capable of querying internal data from Notion and Slack. The same October month when ChatGPT was about to drop, and Chase had stumbled into the exact pattern of connecting an LLM to your own data and tools that the entire industry was about to need. His first tweet about the project went out on October 24, 2022. He called it LangChain, short for Language Model Chains, and open-sourced it under MIT.

Interestingly, ChatGPT launched roughly a month later and every developer suddenly who wanted to build “an app with AI in it” had LangChain sitting on GitHub with exactly what was needed.

What LangChain actually is?

To explain what they had really built, we can understand in one line that LangChain is a Python (and later JavaScript) library that gave developers pre-built Lego blocks for all those repetitive pieces. The core idea is right there in the name that you chain together a sequence of steps that involve an LLM.

A typical chain might look like:
take user input → pull relevant docs from a vector database → stuff those docs into a prompt template → send it to the LLM → parse the output → return it to the user. LangChain gave you a class or a function for every one of those steps, and a way to glue them together.

It also gave you adapters. For example:

• Want to use Pinecone as your vector DB? There’s a wrapper.
• Want to switch to Weaviate next week? Same interface, different wrapper underneath.
• Same for LLM providers (OpenAI, Anthropic, Cohere, local models), document loaders (PDF, Notion, Google Drive, web scraping), and output parsers.

But things eventually changed..

Even though Langchain was a huge buzz amongst developers, by mid-2024, Chase and his team had a problem they couldn’t fix by shipping more integrations.

LangChain’s success had pulled it into use cases it was never designed for. If we understood from the previous section, the original mental model was a chain, a straight line of steps from input to output that would fit the 2023 wave of “chat with your PDFs” apps almost perfectly.

But teams had started building something more ambitious: agents that could think for several minutes, call tools repeatedly, hand work off to other agents, pause for a human to approve a decision, and resume from where they left off. Now, when you see this, this doesn’t quite fit in the single line working model!

And eventually complaints started rolling in.

• Octomind, a YC company that had built its entire product on LangChain, published a postmortem in 2024 explaining why they ripped it out. Their core issue was that they needed to dynamically change which tools an agent could use based on what the agent had already discovered, and LangChain gave them no way to inspect or modify the agent’s state mid-run. They had to dumb down their product to fit the framework. That story landed hard in the developer community because everyone building serious agents was hitting some version of the same wall.

Chase’s team saw it too and understood the linear shape of the model needed to change.

LangGraph was that different shape.
It launched in early 2024 and went publically available in October 2025, and the shift in the name is the shift in the entire idea. Chase shifted the model from chain (a straight line) to graph which is a network of nodes connected by arrows that can loop, branch, and have conditions.

Here’s the mental model:

In LangChain, you describe your app as a recipe: do step A, then step B, then step C, return the result.

In LangGraph, you describe your app as a map.
There are nodes (each node does some piece of work, often involving an LLM call) and edges (rules about which node to go to next).
The arrows can point backwards telling that node B can route back to node A if the LLM’s output wasn’t good enough.
They can branch like node A might send work to B, C, or D depending on what the user asked for.
They can pause where a node can stop everything and wait for a human to click “approve” before the agent continues.

Imagine a customer support agent for a healthcare app.
A user writes in with a vague complaint.
In a LangChain world, you’d build a linear flow:

classify the issue → look up the user → fetch their recent history → generate a response → send it.
In this model, even if the classification was wrong, the chain wouldn’t stop and has probably already moved on.

In a LangGraph world, you’d model the same thing as a graph.
1. A “triage” node classifies the issue and routes to one of three specialist nodes.

2. The specialist node fetches data, drafts a response, and routes to an “approval” node that pauses the entire agent until a human reviews it.
3. If the human rejects the draft, the graph routes back to the specialist with the rejection reason in state, and it tries again.

If anything fails, you can pull up the agent two days later, see exactly what it did at every step, and resume it from any checkpoint. That is the power of LangGraph!

Where LangGraph gets used today:

• Multi-agent systems, where one agent hands off to another: a research agent passes findings to a writing agent, which passes a draft to a critic agent that sends it back for revisions.
• Long-running agents that work on a task for minutes or hours rather than seconds: Anthropic’s Claude Code, Cognition’s Devin-style coding agents, and OpenAI’s deep research products all use LangGraph-style architectures (some literally on LangGraph, some on their own re-implementations of the same idea).
• Anything with human-in-the-loop approval steps: This matters enormously in regulated domains like healthcare, finance, legal, where you legally cannot have an AI take certain actions without a human signing off.
• Customer support flows where the agent has to escalate, retry, or branch based on conditions in ways a simple chain can’t express.
• Research and analysis agents that need to plan a task, execute parts of it, evaluate the results, and decide whether to keep going or change strategy.

Anthropic released the Claude Agent SDK with native state management, tool use, and sub-agents. OpenAI shipped the Agents SDK with built-in handoffs and guardrails. AWS open-sourced Strands.

But why do we say it is DEAD?

If you’ve been on developer Twitter in the last six months, you’ve seen some version of the same claim: LangChain is dead, LangGraph is bloated, everyone serious is ripping it all out. The replies are full of alternatives like Pydantic AI, CrewAI, the Claude Agent SDK, the OpenAI Agents SDK, “just use the raw API.”

While everyone was arguing about which framework would replace LangChain, LangChain the company built something else.

In October 2025, they raised $125 million at a $1.25 billion valuation. The product driving that round wasn’t LangChain. It wasn’t LangGraph either.

It was LangSmith, their observability platform and it works with frameworks they don’t own.

Now, what is Langsmith and why is it important for us to know, I will cover the deep-dive in the next blog post!

The 2026 framework landscape: what people are actually using

Below are the seven frameworks I’d actually consider if I were starting a new LLM project today, grouped by category, with honest notes on when each one fits and when it doesn’t.

I’ll be opinionated.

You should disagree where your context differs from mine.

Category 1: Provider-native SDKs

This is the new default starting point for most teams. The model providers have built enough first-party tooling into their own SDKs that you can skip the framework layer entirely for a lot of use cases.

Claude Agent SDK

Anthropic’s official SDK for building agents on Claude. Extracted from Claude Code (the coding agent powering Anthropic’s own product), it ships with native support for tool use, MCP, computer use, extended thinking, and context management. Released as a standalone SDK in 2025 after Claude Code proved out the patterns.

Why to use it?
Best-in-class for long-horizon agents that need to operate in an execution environment like read files, run code, use computers, manage their own context over many turns. The MCP integration is native, which means plugging in tools is genuinely a few lines of code. If you’ve committed to Claude as your model, this is the lowest-friction path to a production agent.

Why not to use it?
You’re locked into Anthropic. If you need to switch model providers or run multiple in parallel, you’ll be re-implementing the harness for each. Also overkill for simple chatbots or single-turn applications — for those, just call the Messages API directly.

How to start?

pip install claude-agent-sdk

The Anthropic docs have a quickstart that gets you to a working agent with tool use in under fifty lines of code.

The Claude Cookbooks repo on GitHub has reference implementations for the five common agent patterns.

OpenAI Agents SDK

What it is:

OpenAI’s production-grade agent framework, evolved from their earlier experimental Swarm project. Launched in March 2025.

Designed specifically around multi-agent coordination where one agent hands off to another, sessions get tracked automatically, and guardrails validate inputs and outputs.

Why use it:

Because this is the cleanest multi-agent ergonomics in the field if you’re on OpenAI models. Handoffs between specialized agents are first-class primitives where you declare a triage agent that routes to a billing agent or a tech-support agent and the SDK handles the protocol.

Built-in tracing means you can debug agent runs without bolting on a separate observability tool, at least initially.

Why not:

Because it is restricted to OpenAI. The handoff model is opinionated and may not fit your architecture if you want a different shape (say, a graph instead of a tree of agents). And the built-in tracing is fine for development but most production teams will still want a dedicated observability layer on top.

How to start:

pip install openai-agents.

OpenAI's docs walk through building a multi-agent customer support bot in about thirty minutes, which is a good first project because it exercises the handoff pattern directly.

AWS Strands Agents

This is AWS’s open-source agent framework, integrated with Amazon Bedrock for inference and AgentCore for managed deployment. Despite the AWS branding, it’s genuinely model-agnostic as it supports Bedrock, Anthropic, OpenAI, Ollama, and anything OpenAI-compatible.

Why use it

The right pick if your infrastructure already lives in AWS.

• AgentCore handles the operational layer from deployment, scaling, monitoring that you’d otherwise have to wire up yourself.
• Model-agnostic design means you’re not locked in even though it’s an AWS product.

Why not

If you’re not on AWS, the integration story loses most of its value and you’d be picking it for the framework alone, where other options have more momentum. Documentation is improving but still thinner than Claude Agent SDK or OpenAI Agents SDK.

How to start

pip install strands-agents.

The Strands docs on AWS have a tutorial that uses Bedrock for inference, but you can swap the model layer to any provider in the configuration.

Category 2: Orchestration frameworks

These are for when a single agent loop isn’t enough and when you need explicit state, branching logic, human approval gates, or coordination between multiple specialized agents. The provider SDKs handle the simple cases. These handle the cases that get hard.

LangGraph

This is the graph-based orchestration framework from the LangChain team. Models your agent as a network of nodes (work) and edges (transitions), with explicit state that you can checkpoint, inspect, and resume and is over 47 million monthly downloads already.

Why use it

• The cleanest answer in the field for stateful, branching workflows with human-in-the-loop steps.
• If your agent needs to pause for approval before taking an irreversible action, route conditionally based on what it has discovered, or persist its state to disk and resume hours later, LangGraph models all of this as first-class primitives.
• Used in production by Anthropic’s Claude Code (for portions of the architecture), Cognition’s Devin, OpenAI’s deep research, and many enterprise agent platforms.

Why not

• Could be an overkill if your application is a single loop.
• The learning curve is real and you have to think in terms of nodes, edges, and state schemas, which is a step up from just calling an SDK.
• Also, the integration with LangChain itself can pull in more dependencies than you want if you’re not careful about which packages you import.

How to start

pip install langgraph.

The LangGraph docs have a tutorial that walks through building a customer support agent with handoffs and approval steps, which exercises the framework's strengths better than a toy example.

Pydantic AI

It is a typed, lightweight agent framework from the team behind Pydantic — the type-validation library most Python developers already use. It was released in late 2024 and has been rapidly adopted by teams who wanted control without ceremony.

Why use it

Because it is the “I’d rather have types than magic” choice.

• You describe your agent’s inputs and outputs as typed Python objects, define tools as typed functions, and the framework handles the LLM interaction.
• No chains, no graphs, no abstractions you have to learn. Just typed code that happens to call an LLM.
• If you’ve ever debugged a LangChain output parser, Pydantic AI is what you wished you’d been using.

Why not

• No first-class multi-agent graph model.
• If you need explicit state machines or human-in-the-loop branching, you’ll be building those patterns on top yourself.
• Also Python-only at the moment, so no good for TypeScript-first teams.

How to start

pip install pydantic-ai.

The Pydantic AI docs have a first-agent example that takes about ten minutes to work through and gives you a feel for the typed approach immediately.

CrewAI

It is a role-based multi-agent framework.

You define a “crew” of agents with specific roles like researcher, writer, critic and CrewAI handles the coordination. It has already reached version 1.14 in 2025 with A2A protocol support.

Why use it

• This is probably the fastest way to prototype a multi-agent idea.
• The role abstraction matches how people naturally think about teams of agents, which means you can go from concept to working demo in an afternoon.
• Good fit for content workflows, research tasks, and anything where the “team of specialists” mental model fits the problem.

Why not:

The role abstraction that makes it fast to prototype also limits how much control you have over execution at scale. Production teams sometimes hit the same wall they hit with LangChain that is the framework’s opinions don’t match what they need their agents to do and migrate to LangGraph or raw SDKs.

How to start:

pip install crewai.

The CrewAI docs have a starter that builds a research-and-writing crew, which is the use case the framework was built for and where you'll feel its strengths most directly.

Category 3: The research-first option

Worth knowing if your work bridges research and production.

CAMEL-AI (with OWL)

Originally an academic research project out of KAUST in 2023, asking “what happens when LLM agents talk to each other in defined roles, and can we study that interaction at scale?”

Is now a production-capable framework with up to a million-agent simulation support.
OWL is the practical layer built on top and has hit #1 on the GAIA benchmark among open-source general agents in 2025, accepted to NeurIPS 2025.

Why use it:

It is probably the strongest fit when your problem looks like a society of agents rather than a pipeline with agents in it.

Synthetic data generation at scale, large-scale agent simulation, multi-agent research workloads, cross-environment automation is where you’ll need OWL. The synthetic data pipelines are genuinely useful even if you don’t care about the simulation side because they ship with Chain-of-Thought, Self-Instruct, and Source2Synth methods with verifiers, which is closer to a real research workflow than what most frameworks offer.

Why not:

It could be an Overkill for product engineering. If you’re building a customer-facing agent that needs to ship in three weeks, this is not the framework to pick. It’s a research-first tool that happens to be production-capable, not the other way around.

How to start:

pip install camel-ai.

The CAMEL-AI docs have a role-playing example that demonstrates the original concept (two agents collaborating on a task) and a separate OWL quickstart for the production-oriented features.

You’ll notice I didn’t include AG2, Semantic Kernel, smolagents, Haystack, or LlamaIndex. They’re real and some teams use them well, but they either occupy specialized niches (Haystack for EU compliance, LlamaIndex for RAG-heavy applications, Semantic Kernel for .NET shops) or haven’t shown the production momentum of the seven above. If your context maps cleanly to one of those niches, those frameworks are worth looking at.

Hope this article helps you and genuinely gives you enough alternatives!

What we have build using these alternatives, I will be posting that next along with Observability options. Thank you for reading :)

When DeepSeek dropped in January 2025, my first reaction was the same as everyone else’s: wait, how?

Not just “how did they build something this good” but how did they build it cheaper, leaner, and in some ways more elegantly than labs with ten times the resources? So, I went down the rabbit hole.

Research papers, technical reports, chip specs, US export policy documents. Everything!

And the more I read, the more I realized this wasn’t a story about a Chinese lab catching up but something that emerged from constraints.

Here is where it all began..

In October 2022, the US government made a move that would try to reshape the AI industry.

The Bureau of Industry and Security, the same agency that controls exports of weapons and dual-use technology restricted the export of advanced NVIDIA chips to China.

It was obvious why they did it but the reasoning they gave for this step was that it could:

• Improve the speed and accuracy of Chinese military decision-making and logistics
• Power autonomous weapons systems,
• Enable large-scale surveillance and human rights abuses

And underneath all of it, a bigger fear that if China leapfrogged the US in chip technology, it could gain the upper hand as a 2021 US National Security Commission report put it “in every domain of warfare.”

Due to this entire restriction plans, the H100: the GPU that had become the backbone of every major frontier model training run was off limits and so was the A100.

What DeepSeek could legally access were export-compliant variants that NVIDIA had specifically engineered for the Chinese market: the H800 (a modified Hopper chip) and the A800 (a restricted Ampere chip).
Both were stockpiled before a second round of bans arrived in October 2023, which were blocked too. :(

The H800 looked almost identical to the H100 on paper.
Same memory.
Same core compute.
But one number was different:

NVLink bandwidth was cut from 900 GB/s down to 400 GB/s.

This was a big deal!
To understand why this is such a big deal, you need to understand how large models are actually trained.

— — 
Nobody trains a 671 billion parameter model on a single GPU.
You run hundreds, sometimes thousands of GPUs in parallel, and they need to talk to each other constantly.

To understand this in depth, read my article on how Nvidia built the AI chips.

Every step of training involves synchronising gradients and passing data across the cluster and NVLink is the highway that makes this possible and InfiniBand connects the nodes to each other. So, if you halve the bandwidth, the whole cluster slows down and the more GPUs you add, the worse the bottleneck gets.

— —

DeepSeek confirmed this directly.
Their own technical report states that DeepSeek-V3: a 671B parameter model was trained on just 2,048 H800 GPUs, completing pre-training on 14.8 trillion tokens in 2.664 million GPU hours.
For reference, training GPT-4 is estimated to have cost somewhere between $50–100 million. DeepSeek did it for roughly $5.6 million.

One note of nuance worth flagging: some industry analysts, including SemiAnalysis, have claimed that DeepSeek’s broader infrastructure may include fully banned H100s alongside the H800s while DeepSeek has only officially confirmed H800s for V3 training. Since admitting to H100s would mean confessing to a violation of US export law.

How did the constraints turned into an opportunity?

So, we understood that yes! we can’t throw more hardware at the problem so what do we do now?

You rethink the problem entirely.

And that’s exactly what DeepSeek did, across three distinct bottlenecks. Each constraint produced a specific architectural response and together, they explain how a 671 billion parameter model got trained on 2,048 GPUs for mere $5.6 million.

Constraint 1: You can’t activate everything, so stop trying!

In a standard “dense” transformer model, every parameter activates for every single token the model processes.

The model has 70 billion parameters?
All 70 billion are doing work on every word, every sentence, every prompt and it’s powerful.

It’s also enormously wasteful especially when you’re operating under compute constraints.

DeepSeek’s response was to go all-in on Mixture of Experts (MoE) an architecture where, instead of one giant network doing everything, you have hundreds of smaller specialized sub-networks called “experts,” with a routing mechanism that decides which ones to call on for any given input.

Think of it like a hospital.
A dense model is a single generalist doctor who handles every patient, every case, every time from cardiology, pediatrics, to neurology, all of it. An MoE model is a hospital with specialist departments: the router reads the patient’s chart and sends them to the right wing.

Instead of relying on a single massive model to handle every aspect of a problem, MoE divides the task among smaller, specialized expert networks, each focusing on a specific domain or sub-task.

For DeepSeek-V3, this means the model has 671 billion total parameters but only 37 billion can be activated for any given token. So, you get the knowledge of a 671B model, at roughly the cost of a 37B one.

But DeepSeek didn’t just use MoE, they pushed it further than anyone had before.

To understand, let’s understand the issues with Standard MoE architectures. Most of the times:

• experts end up overlapping,
• start learning similar things, and
• start duplicating knowledge

So, to curb these issues, DeepSeek proposed two key strategies to fix this: finely segmenting experts into more granular units for flexible combinations and isolating certain “shared experts” that always activate to capture common knowledge, thus, freeing the routed experts to specialize deeply.

Which is honestly very smart.

And as a result, as also confirmed in their published research: DeepSeekMoE 16B achieves comparable performance to LLaMA2 7B while using only about 40% of the compute.

Constraint 2: Memory is expensive, so compress what you store

Now, let’s understand the memory and cost effectiveness.
When a transformer processes a sequence like a long document, a conversation history, a complex prompt, it needs to store intermediate computations for every token it has seen which is called keys and values (K and V), and together they form the KV cache. This cache lets the model refer back to context without recomputing everything from scratch.

The problem with KV cache is that it grows with every token and standard multi-head attention stores separate key and value vectors for every attention head across every layer.

Now, for a large model with a long context window, standard multi-head attention on DeepSeek-V3’s dimensions with a 128K token context window would require a ~488GB KV cache larger than most GPU memory configurations entirely.

So, DeepSeek’s answer was Multi-head Latent Attention (MLA), introduced in DeepSeek-V2 and carried forward into V3 and R1!
Their core idea was pretty simple which said that instead of storing the full high-dimensional key and value vectors, compress them into a single small latent vector first which inadvertently means storing the compressed version.

Instead of sharing key and value heads like earlier approaches, MLA compresses the key and value tensors into a lower-dimensional space before storing them in the KV cache. At inference time, these compressed tensors are projected back to their original size before being used.

That is interesting and if you look at the memory savings in comparison to their earlier 67B dense model, DeepSeek-V2 with MLA reduced the KV cache size by 93.3%.

93%!

That is huge!

And crucially, unlike earlier memory-saving attention tricks that traded quality for efficiency, MLA actually matches or slightly outperforms standard multi-head attention on modeling benchmarks.

Constraint 3: Training data pipelines are expensive, so skip it

Now comes the interesting part.

The standard playbook for training a reasoning model is simple:

• think through hard math problems,
• write reliable code,
• plan multi-step solutions that involves a lot of expensive scaffolding.

You generate synthetic chain-of-thought examples.

You hire human annotators.

You build a separate reward model, roughly as large as the model you’re training, to evaluate outputs and then you run RLHF on top of all of that.

But when you do so, every step costs time, compute, and money. DeepSeek needed something that could save all of it and yet perform beautifully.

So, the answer was Group Relative Policy Optimization (GRPO). To save training costs, DeepSeek adopted GRPO, which foregoes the critic model that is typically the same size as the policy model, and instead estimates the baseline from group scores.

Practically, this means: instead of maintaining a separate reward model to evaluate each output, you generate multiple responses to the same prompt, score them against each other, and use the relative rankings as your training signal.

After this, DeepSeek discovered when they applied this to R1-Zero, it was a big aha moment!

Their reward signal was based solely on the correctness of final predictions, without imposing constraints on the reasoning process bypassing the conventional supervised fine-tuning phase entirely.

And yet, through pure trial and error against math and coding problems, the model spontaneously developed extended reasoning behaviors:

• it started backtracking,
• self-correcting,
• verifying its own answers,
• allocating more thinking time to harder problems.

What emerged validated the entire approach.
DeepSeek R1 trained with GRPO, without a separately maintained reward model scored 97.3% on the MATH-500 benchmark and sits in the same performance tier as OpenAI’s o1 series.

By May 2025, an updated version was approaching OpenAI o3 and Gemini 2.5 Pro on reasoning benchmarks and it cost them 5–10x less to run than comparable closed-source alternatives.

Next in line: Kimi chosing its own constraint

After DeepSeek, it was Kimi’s turn to follow the footsteps.

When Moonshot AI launched Kimi in late 2023, they made a deliberate bet that most AI labs were not thinking about much: long context. The first version of Kimi supported lossless context of 128,000 tokens, making it the first AI model capable of accepting contexts of this size. While everyone else was optimizing benchmark scores on short prompts, Kimi went long. By March 2024, they were already testing a 2 million character context window.

Now we would thing what is the big deal here. It is.

The technical challenge of building a system for handling longer context is the standard attention that scales quadratically with sequence length. Basically you double the context and you quadruple the compute.

And at a million tokens, this becomes prohibitive unless you redesign the attention mechanism entirely and this is exactly why many labs didn’t go ahead with this. Kimi took the bet and thought of really owning the category by being the first one to do it.

By 2025, the bet had expanded from long context to agentic AI.
Building a model specifically designed to take actions, use tools, and operate autonomously across long chains of reasoning.
On one hand, where DeepSeek’s identity was about efficient scale, Kimi K2’s defining claim is an ability to plan and think over extended contexts, using tools and internal chain-of-thought, specifically designed for tool use, reasoning, and autonomous problem-solving.

If you see in the linked article as well, Kimi K2 Thinking can execute 200–300 sequential tool calls without human intervention, reasoning coherently across hundreds of steps !!

And like DeepSeek, Moonshot built this under the same hardware ceiling. K2 Thinking was trained on the H800: the same export-restricted, downgraded NVIDIA chip that DeepSeek used.

When we look at both of them:

• DeepSeek asked: how do we train a frontier model with less compute per token?
• Kimi asked: what can a model do if it can reason and act across an entire document, codebase, or workflow?

What do we concur?

The interesting part here is how much of invention or innovation was here by DeepSeek?

Being honest, DeepSeek did not invent the transformer.

They didn’t invent MoE, attention mechanisms, or reinforcement learning for language models.

The intellectual lineage of their work runs directly through Google, OpenAI, Meta, and the broader academic community.

When I traced back the MoE architecture, it traces back to a 1991 paper on adaptive expert systems by one of the AI pioneers, Geoffrey Hinton. So if you closely read the paper, you will find that the KV cache problem was well understood.

After that, RLHF was OpenAI’s contribution.

When you look at all of this, yes! the innovation part is missing by DeepSeek. What DeepSeek did was take ideas that existed and pushed them further than anyone had been motivated to push them because they had no choice.

• They made MoE work at 671 billion parameters.
• They built MLA when the standard approaches were good enough for everyone else.
• They stripped GRPO down to its essentials and discovered that the scaffolding everyone assumed was necessary, actually wasn’t.

And then they published all of it in detail.
In open technical reports that let researchers worldwide reproduce, study, and build on the work. That decision whether it was a strategic one or a principled one, it had enormous downstream effects. Because the field really moved faster because of it.

From the classic standard process, when you have abundant resources, the rational engineering decision is almost always: just add more.

More parameters.

More data.

More GPUs.

It works because the scaling laws are real. But abundance also creates a specific kind of blindness. You stop asking whether there’s a more elegant path, because the brute-force path is good enough and you can afford it.

While the constrained environments force the question and the answers, if you dig deeper for them, tend to be more efficient, more transferable, and more durable than the solutions born from abundance.

What this means for “Build in India”

I’ve spent the last few months deep in AI research papers, export control documents, chip spec sheets, and training reports. And the further I went, the more I kept thinking about something that has nothing to do with GPUs.

It kept coming back to a feeling I recognize.

The feeling of building something real with what you have and not what you wish you had. The feeling of looking at a constraint and deciding, consciously or not, that it’s going to make you sharper.

Every developer I know who has built seriously for Indian users knows this feeling intimately. You optimize for 2G fallback because your user is on a bus in Patna and your product either works or it doesn’t.

You build lean payment flows because your user has ₹50 of mobile data left this week and won’t forgive you for wasting it.

And similar is the case how DeepSeek thought about its product and tech. DeepSeek didn’t set out to change how the world builds AI.

They set out to build a competitive model under conditions that made the standard approach impossible. The innovations that came out of that like MoE, MLA, GRPO were the byproduct of having no choice but to be clever.

And then, three weeks ago, Sarvam shipped.

Sarvam’s 30B and 105B models built from scratch, trained entirely in India on government-allocated compute, designed for 22 Indian languages adopted the exact same architectural playbook DeepSeek was forced into by US export controls.

MoE.

MLA.

Shared expert routing.

Not because Washington told them they couldn’t have H100s but because these were simply the right answers for building at Indian scale, under Indian constraints, for Indian users and the architecture that emerged looks remarkably similar.

I used to wonder what the Indian equivalent of DeepSeek’s efficiency breakthroughs would look like and what our version of “forced to be clever” produces.

Sarvam did exactly that! May be much better (we will discuss that in the next blog post) but a 105B model outperforming DeepSeek-R1 on certain benchmarks, despite R1 being a 600B parameter model, while running on domestically allocated compute, that is amazing.

This is the part I want Indian developers and founders to sit with.

We talk a lot in Indian tech circles about closing the gap. Reaching parity with the West. And those are real and worthy goals. But DeepSeek’s story and now Sarvam’s, suggests a different frame entirely.

I love how we are thinking in adjusting or I should say in optimizing the way we use our models using lesser GPU width and yet delivering the best results.

This is the future.

And I can’t wait for more and more orgs to explore this path!

What do you say?

Why Developer Marketing breaks traditional marketing automation?

I spent last Tuesday watching a marketing automation tool butcher a product launch announcement.

The tool was good. It generated compelling copy, structured the content beautifully, and even suggested A/B test variations.
The problem?
It was written for consumers and not developers.

Here’s what it produced:

Unlock the power of our revolutionary API! Streamline your workflow and leverage cutting-edge technology to transform your business.
Join thousands of satisfied customers who’ve already discovered the game-changing potential of our platform!

But here’s what developers actually want to read:

New endpoint: /v2/bulk-import.
Import up to 10,000 records in a single request.
Average processing time: 2.3 seconds. Here's a working example:

const response = await fetch('https://api.example.com/v2/bulk-import', { method: 'POST', headers: { 'Authorization': `Bearer ${API_KEY}` }, body: JSON.stringify({ records: data }) });

See the difference?

The first one sells. The second one teaches. And teaching is what developer marketing is actually about.

Note: If you quickly need to access the files, here is my GitHub repo that can help: https://github.com/techtrailhead/devrelskills

The problem With “Marketing Automation” for DevRel

Most marketing automation tools including AI-powered ones are optimized for one thing: conversion. They’re designed to move someone from awareness to consideration to purchase as efficiently as possible.

That works great for B2C products, SaaS landing pages, and e-commerce. But developer audiences? They operate completely differently.

Developers don’t want to be sold to. They want to:

• See working code immediately
• Understand exactly how something works
• Make informed technical decisions
• Trust that you’re not wasting their time

When you use traditional marketing copy frameworks on developers, you get:

• Buzzwords that trigger immediate skepticism (“revolutionary,” “game-changing,” “cutting-edge”)
• Benefits-first messaging that buries the technical details
• Vague promises instead of concrete examples
• Sales-y CTAs that feel manipulative (“Start your free trial now!”)

The result: Your marketing sounds like every other vendor desperately trying to sell them something. You’ve lost credibility before they’ve read past the headline.

What makes Developer Marketing different?

After writing 100+ technical tutorials, managing developer communities for companies like Google and Twilio, I’ve learned that developer marketing requires a fundamentally different approach:

1. Code comes first, explanation second

Traditional marketing: Benefit → Feature → How it works → CTA

Developer marketing: Working code → Why it matters → Where to learn more

2. Show, don’t sell

Traditional: “Our API is the fastest and most reliable in the industry!”

Developer: [benchmark results showing 50ms p99 latency] “Here’s how we achieve this.”

3. Respect technical knowledge

Traditional: Explain everything like they’re five

Developer: Assume they know how to code, focus on your specific implementation

4. Completeness over cleverness

Traditional: Snippet is fine, link out for details

Developer: Every code example must be complete, copy-pastable, and actually work

5. Honesty about limitations

Traditional: Only talk about benefits, ignore edge cases

Developer: Address trade-offs, known issues, and when NOT to use your product

The DevRel automation gap

Here’s the frustrating part: marketing automation could be incredibly valuable for DevRel teams. We need to:

• Generate documentation for every new API endpoint
• Create tutorials showing common integration patterns
• Write announcement posts for feature releases
• Draft technical blog content explaining how things work
• Produce social media threads breaking down complex topics
• Build sample applications demonstrating best practices
• Keep SDK examples updated across multiple languages

Doing all of this manually is exhausting. A typical API feature launch requires:

• 4–6 hours writing documentation
• 3–4 hours creating tutorials and examples
• 2–3 hours on announcement content
• 1–2 hours on social distribution
• 2–3 hours building a sample app

Total: 12–18 hours of writing and coding

And that’s for a single feature. Most developer tools ship multiple features per month.

What if AI could handle 70% of this work?

Not by generating generic marketing copy, but by actually understanding how developers think, what they need, and how to communicate technical concepts clearly.

Solution: Marketing Skills, adapted for developers

A few months ago, I discovered marketingskills by Corey Haines which is a collection of 25 AI “skills” that teach Claude Code how to handle specific marketing tasks.

The idea is brilliant: Instead of asking Claude to “write marketing copy” and hoping for the best, you give it a detailed skill file that contains:

• When to use this skill
• What questions to ask first
• What frameworks and principles to follow
• What good output looks like
• Common mistakes to avoid

The problem: These skills are built for traditional marketing. They’re excellent at what they do, but they don’t work for developer audiences.

So I did something simple: I adapted them.

I took Corey’s copywriting skill and modified it for technical tutorials.
I took the content strategy skill and refocused it on educational content and created new skills specifically for API documentation, code examples, and developer newsletters.

The result:

What used to take me 12–18 hours for an API feature launch now takes 3–4 hours. And the quality is often better than what I’d produce manually because the skills enforce consistency and catch things I might forget (like error handling examples, or prerequisites sections, or linking to related docs).

What Anthropic’s growth team learned too!

I’m not the only one discovering this. Anthropic’s own growth marketing team recently published their learnings using Claude Code for marketing automation.

Their results:

Dramatic time savings on repetitive tasks: Ad copy creation went from 2 hours to 15 minutes which is an 87% reduction. This freed up time for strategic work instead of execution.

10x increase in creative output: The team could test vastly more ad variations across channels with automated generation and Figma integration.

Strategic focus shift The team spent more time on overall strategy and building agentic automation rather than manual execution.

What they learned matters for DevRel:

1. Identify API-enabled repetitive tasks

• For growth marketing: Ad platforms, design tools, analytics
• For DevRel: GitHub, documentation platforms, code repositories

2. Break complex workflows into specialized sub-agents

• Instead of one massive prompt, create separate agents for specific tasks
• Example: Research agent → Planning agent → Writing agent → Review agent
• This makes debugging easier and improves output quality

3. Thoroughly brainstorm and prompt plan before coding

• Spend significant time upfront using Claude.ai to think through your entire workflow
• Have Claude.ai create a comprehensive prompt and code structure first
• Work step-by-step rather than asking for one-shot solutions

Before we dive in, let’s address the elephant in the room: “But AI-generated content is generic and bad!”

You’re right: by default, it is.

Generic prompts produce generic output. That’s why we’re building skills.

Skills are detailed instruction sets that teach AI tools how to think about specific problems. When you give Claude a 500-line skill file that explains:

• What developers actually want to read
• What mistakes to avoid
• What frameworks to follow
• What good examples look like

The output quality jumps dramatically.

Think of it this way:

• Asking Claude to “write a tutorial” → Generic, probably bad
• Using a technical-tutorial skill → Follows DevRel best practices, enforces structure, checks for completeness

The skill is doing the heavy lifting. Claude is just executing it consistently.

Problem we are solving

Here’s what happens when you use standard marketing automation for developers:

Generic AI output:

“Unlock seamless authentication with our revolutionary new feature! Join thousands of developers who’ve already transformed their workflow. Start your free trial today!”

What developers actually want:

New: OAuth 2.0 + PKCE Authentication
Average token exchange: 47ms (p99: 120ms)

const client = new AuthClient({ clientId: 'your_client_id', redirectUri: 'http://localhost:3000/callback' }); const authUrl = client.getAuthorizationUrl({ scope: ['read:user', 'write:data'] })

Docs: [link] | Example app: [GitHub]

The problem: Since the traditional marketing automation is trained on B2C and SaaS patterns, it by default displays benefits first, emotional hooks, urgency tactics. Developers skip past all of that looking for working code and technical specs.

The solution: We need to adapt marketing skills specifically for developer audiences. That’s exactly what we’re building in this series.

Steps to get started

Step 1: Installing Marketing Skills

Let’s get the base skills installed. We’ll audit what works for DevRel and what needs adaptation.

Prerequisites

• Claude Code installed (get it here)
• Terminal access
• 10 minutes

Install marketingskills repo

Open your terminal and run:

npx skills add coreyhaines31/marketingskills

This command installs all 25 marketing skills into your .claude/skills/ directory. The installation should take about 30 seconds.

Verify installation:

ls ~/.claude/skills

You should see folders like: copywriting, content-strategy, seo-audit, etc.

Quick test

Ask Claude Code to use a skill:

/copywriting

You should see folders for each skill: copywriting, content-strategy, seo-audit, email-sequence, and about 20 others.

Test that skills are working:

Let’s test one of the skills to make sure everything is set up correctly.

Open Claude Code and invoke the copywriting skill:

Prompt: “Write homepage copy for a developer API”

You’ll get marketing-focused output. That’s expected as we haven’t adapted it yet.

Step 2: Skills Audit: What DevRel actually needs

Now let’s go through all 25 skills and categorize them for DevRel work. Not every marketing skill translates to developer marketing, and some need significant adaptation.

These skills work for DevRel without modification:

• analytics-tracking - Setting up GA4 and event tracking works the same for developer docs as for marketing sites
• seo-audit - Technical SEO principles apply to documentation and developer content
• schema-markup - Structured data helps search engines understand API documentation
• ab-test-setup - Testing methodology and statistical significance are universal
• marketing-psychology - Core psychological principles still apply, even if the execution differs

Adapt for DevRel (8 skills):

These skills have the right structure but need developer-specific content:

• copywriting → Needs to become technical tutorial writing with code-first approach
• content-strategy → Should focus on educational content calendar, not promotional campaigns
• email-sequence → Developer newsletters are updates and technical content, not nurture sequences
• social-content → Technical Twitter threads and LinkedIn posts require different tone and format
• page-cro → Developer landing pages prioritize documentation links over conversion optimization
• competitor-alternatives → Technical comparison pages need feature matrices and benchmark data
• product-marketing-context → Should include API specifications and technical positioning
• launch-strategy → Feature announcements need code examples and migration guides

Skip for DevRel (7 skills):

These skills are designed for traditional B2C or SaaS marketing and don’t work well for developer audiences:

• popup-cro - Developers universally hate popups and modal interruptions
• paid-ads - Most DevRel strategies focus on organic content and community
• paywall-upgrade-cro - Developer tools use different monetization patterns (usage-based, not feature-gated)
• signup-flow-cro - Developer tools are usually self-serve with minimal friction
• form-cro - Dev tools typically have minimal forms (just email or GitHub auth)
• pricing-strategy - Developer pricing is usually usage-based or consumption-based, not seat-based
• referral-program - Developer advocacy works differently than traditional referral programs

Build from scratch (5 skills we need):

These are skills that don’t exist in the marketing repository but are essential for DevRel:

• technical-tutorial - Write code-first tutorials with working examples
• api-docs-audit - Review API documentation for completeness and accuracy
• code-examples - Generate working code samples in multiple programming languages
• sdk-docs - Create SDK reference documentation and integration guides
• developer-community - Write content for forums, Discord, and developer communities

Step 3: Your first DevRel workflow

Let’s run a practical test to show you the difference between generic marketing skills and what we’re going to build.

Test scenario: You need to announce a new API endpoint for bulk data import.

Test prompt: “Announce a new API endpoint for bulk data import”

Without adaptation:

/copywriting

Result: Marketing-heavy, vague, no code

With DevRel approach (what we’re building):

/technical-tutorial
```

With the same prompt, you'll get:
```
New endpoint: POST /v2/bulk-import

Import up to 10,000 records per request. 
Average processing time: 2.3 seconds for 5,000 records.

const records = [
  { id: 1, name: 'Smith Evans', email: 'smith@example.com' },
  { id: 2, name: 'Rose Green', email: 'rose@example.com' }
];

const response = await fetch('https://api.example.com/v2/bulk-import', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${API_KEY}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ records })
});

Rate limit: 10 requests per minute
Max payload size: 5MB
Documentation: [link]

See the difference? Working code, technical specifications, rate limits, and documentation links.

We’ll build this in Part 2.

Part 2: Building your first DevRel Skill: Technical Tutorial Writer

In Part 1, we installed the marketingskills repository and saw the gap between generic marketing copy and what developers actually want to read. Now we’re going to build something about it.

By the end of this tutorial, you’ll have a working technical-tutorial skill that generates developer-appropriate content with working code examples, technical specifications, and proper documentation structure.

What we’re building: A skill that transforms generic prompts like “write a tutorial for authentication” into complete, code-first tutorials that developers can actually use.

Time to complete: 45–60 minutes

Let’s start by understanding how skills actually work.

Section I: Building the technical tutorial skill

Now let’s build the actual skill file. We’ll create it step by step, explaining each section.

Step 1: Create the skill directory

Create a new folder for your skill:

mkdir -p ~/.claude/skills/technical-tutorial
cd ~/.claude/skills/technical-tutorial

Step 2: Create the SKILL.md file

Create a new file:

touch SKILL.md

Open it in your text editor:

code SKILL.md

Step 3: Write the frontmatter

Add the metadata at the top of the file:

---
name: technical-tutorial
description: Write technical tutorials and guides for developer audiences. 
Use when creating API documentation, SDK guides, integration tutorials, or 
technical blog posts for developers. Also use when the user mentions 'tutorial', 'guide', 'how to integrate', 'documentation', or asks for technical content.
--

This tells Claude when to use this skill. Key trigger phrases: “tutorial”, “guide”, “documentation”, “how to integrate”.

Step 4: Define the role

Add the role definition:

# Technical Tutorial Writer for Developer Audiences

You are an expert technical writer specializing in developer documentation and tutorials. Your goal is to create clear, accurate, and complete tutorials that developers can follow to successfully implement a feature or integration.

Your tutorials prioritize working code examples over explanations. Developers want to see it working first, then understand how it works.

This sets Claude’s mindset: think like a technical writer, not a marketer.

Step 5: Add context awareness

Tell Claude to check for existing technical context:

## Check for technical context first

Before asking questions, look for these context files:
- `.claude/api-reference.md` - API endpoints, parameters, and response schemas
- `.claude/sdk-examples.md` - Existing code samples and patterns
- `.claude/dev-audience.md` - Target developer persona and skill level
- `.claude/product-marketing-context.md` - General product information

If these files exist, read them first. Only ask for information that isn't already documented or is specific to this particular tutorial.

This prevents Claude from asking redundant questions when context already exists.

Step 6: Define what information you need

Add the questions Claude should ask:

## Information you need

Before writing the tutorial, ask the user:

1. **What is the developer trying to accomplish?** (Focus on the outcome, not the feature name)
2. **What language or framework?** (Be specific: "React 18 with TypeScript" not just "React")
3. **What are the prerequisites?** (What should developers have installed or configured before starting?)
4. **What's the tutorial scope?** (Quick start? Deep dive? Migration guide?)
5. **Are there existing code samples to reference?** (Link to repos or examples if available)

If the user doesn't provide all this information upfront, ask for it before proceeding. Better to ask clarifying questions than to generate generic content.

These questions ensure you get the information needed for a quality tutorial.

Step 7: Define the tutorial structure

Add the template structure:

## Tutorial structure

Every tutorial you create should follow this structure:

### 1. Title (clear outcome, not feature name)

Bad: "Using Our Authentication System"
Good: "Add OAuth 2.0 Authentication in 15 Minutes"

The title should tell developers what they'll accomplish and how long it will take.

### 2. Prerequisites box

Always start with a prerequisites section:
```
## Prerequisites

Before you begin, you'll need:
- Node.js 18 or later
- An API key from [link]
- Basic knowledge of Express.js
- 15 minutes
```

This saves developers from getting halfway through and realizing they're missing something.

### 3. Complete working example first

Show the entire working code before explaining anything:
```javascript
// Complete working example
import { AuthClient } from '@yourapi/auth';

const client = new AuthClient({
  clientId: process.env.CLIENT_ID,
  redirectUri: 'http://localhost:3000/callback'
});

const authUrl = client.getAuthorizationUrl({
  scope: ['read:user', 'write:data']
});

console.log('Navigate to:', authUrl);
```

Developers want to see it working immediately, then understand how it works.

### 4. Step-by-step implementation

Break the implementation into logical steps. Each step should:
- Build on the previous step
- Include complete, runnable code (not snippets)
- Explain what changed and why
- Include expected output or results

### 5. Error handling section

Always include common errors and how to debug them:
```markdown
## Common errors

**Error: "Invalid client_id"**
- Cause: Your API key is incorrect or expired
- Solution: Generate a new API key at [link]

**Error: "Redirect URI mismatch"**
- Cause: The redirect URI doesn't match your registered URI
- Solution: Check your URI at [dashboard link]
```

### 6. Next steps

End with links to related content:
```markdown
## Next steps

- [Advanced authentication options](link)
- [Handling refresh tokens](link)
- [Example application on GitHub](link)
```

This gives Claude a clear template to follow for every tutorial.

Step 8: Add code quality principles

Define what makes good code examples:

## Code example principles

Every code example you write must be:

1. **Complete** - No `// ... rest of code` comments. Show everything.
2. **Copy-pastable** - Developers should be able to copy and run it without modifications
3. **Tested** - The code must actually work (ask the user to verify if unsure)
4. **Commented** - Explain non-obvious parts, but don't over-comment obvious code
5. **Error-handled** - Include basic try-catch blocks, not production-grade error handling
6. **Modern** - Use current language versions and best practices
7. **Consistent** - Follow the same coding style throughout the tutorial

### Good example:
```javascript
import { AuthClient } from '@yourapi/auth';

// Initialize the client with your credentials
const client = new AuthClient({
  clientId: process.env.CLIENT_ID,
  redirectUri: 'http://localhost:3000/callback'
});

// Generate the authorization URL
const authUrl = client.getAuthorizationUrl({
  scope: ['read:user', 'write:data'],
  state: generateRandomState() // CSRF protection
});

console.log('Navigate user to:', authUrl);
```

### Bad example:
```javascript
// Set up auth
const client = new AuthClient(config);

// Get URL
const url = client.getUrl(params);

// ... handle the rest
```

The bad example is incomplete, uses vague variable names, and doesn't show what `config` or `params` are.

Step 9: Define voice and tone

Add guidelines for how the tutorial should sound:

## Voice and tone for developer tutorials

Write in a technical but conversational tone:

**Do:**
- "Here's how authentication works in this API"
- "Run `npm install @yourapi/sdk`"
- "This endpoint returns a JSON response"
- Be direct and specific
- Use active voice
- Acknowledge when something is complex

**Don't:**
- "Let us show you how our revolutionary..."
- "You'll want to consider installing..."
- "Our solution provides robust capabilities..."
- Use marketing language
- Use passive voice
- Oversimplify or patronize

### Examples:

Bad: "Our authentication system provides a seamless experience that will streamline your development workflow"

Good: "Authentication uses OAuth 2.0 with PKCE. Here's how to implement it:"

Bad: "You'll want to begin by installing our SDK"

Good: "Install the SDK: `npm install @yourapi/sdk`"

Step 10: Add output format

Specify how the tutorial should be formatted:

## Output format

Format all tutorials using GitHub-flavored Markdown:

- Use code blocks with language tags: ```javascript, ```python, ```bash
- Use syntax highlighting appropriately
- Create collapsible sections for optional content:
```markdown
  
  Advanced: Custom scopes
  
  Content here...
  
```
- Use callout boxes for important notes:
```markdown
  > ⚠️ **Warning:** This approach is deprecated. Use PKCE instead.
  
  > 💡 **Tip:** You can customize the timeout by setting...
```
- Include a table of contents for tutorials longer than 5 sections
- Link liberally to API reference docs and related tutorials

Step 11: Add examples

Include before-and-after examples to show what good output looks like:

## Examples of good vs bad tutorials

### Example 1: Authentication tutorial

**Bad approach:**
> "Authentication is easy with our API! Just call the authenticate method and you're done:
> ```
> auth.authenticate(user);
> ```"

Problems:
- No imports shown
- No explanation of where `auth` or `user` come from
- No error handling
- Too vague to be useful

**Good approach:**
> "Here's a complete authentication example:
>
> ```javascript
> import { AuthClient } from '@yourapi/auth';
>
> const client = new AuthClient({
>   clientId: process.env.CLIENT_ID
> });
>
> try {
>   const authUrl = client.getAuthorizationUrl({
>     scope: ['read:user']
>   });
>   
>   console.log('Redirect user to:', authUrl);
> } catch (error) {
>   console.error('Auth failed:', error.message);
> }
> ```
>
> This generates an OAuth 2.0 authorization URL. The user clicks this link to authenticate."

Why this works:
- Complete imports
- Shows configuration
- Includes error handling
- Explains what happens

### Example 2: API endpoint tutorial

**Bad approach:**
> "To get user data, just make a GET request to our API!"

Problems:
- No endpoint URL shown
- No authentication details
- No example response
- No code example

**Good approach:**
> "Fetch user data with this endpoint:
>
> ```bash
> curl -X GET https://api.example.com/v1/users/me \
>   -H 'Authorization: Bearer YOUR_TOKEN'
> ```
>
> Response (200 OK):
> ```json
> {
>   "id": "usr_123",
>   "email": "developer@example.com",
>   "created_at": "2024-01-15T10:30:00Z"
> }
> ```
>
> Rate limit: 100 requests/minute"

Why this works:
- Shows exact endpoint and method
- Includes authentication
- Shows actual response format
- Mentions rate limits

Step 12: Save the file

Save your SKILL.md file. You now have a complete technical tutorial skill!

Section 2: Testing Your Skill

Now let’s test if the skill actually works and produces good output.

Test 1: Simple authentication tutorial

Restart Claude Code to reload the skills, then invoke your new skill:

/technical-tutorial
```

Give it this prompt:
```
Write a tutorial for adding authentication to a Next.js app using our OAuth API. Target audience: frontend developers familiar with React but new to OAuth.

What to look for in the output:

Good signs:

• Starts with prerequisites (Node.js version, etc.)
• Shows complete working code with imports
• Includes step-by-step breakdown
• Has error handling examples
• Links to next steps
• Uses developer-appropriate language

Red flags:

• Marketing language (“revolutionary”, “seamless”)
• Incomplete code snippets
• Missing error handling
• No prerequisites section
• Vague explanations

Test 2: API documentation

Try a different type of technical content:

/technical-tutorial
```

Prompt:
```
Document the POST /v2/bulk-import endpoint. It accepts an array of records (max 10,000) and returns import results. Include rate limits and error codes.

The skill should generate:

• Endpoint specification (method, URL, parameters)
• Complete request example with headers
• Response format with example JSON
• Error codes and what they mean
• Rate limit information
• Example in multiple languages (curl, JavaScript, Python)

Test 3: SDK integration guide

/technical-tutorial
```

Prompt:
```
Write a guide for integrating our Python SDK into a Flask application. Show how to initialize the client, make API calls, and handle errors.

Expected output:

• Installation instructions
• Import statements
• Configuration setup
• Working examples
• Error handling patterns
• Best practices

Section 3: Iterating on Quality

Your first version won’t be perfect. Here’s how to improve it:

Common issues and fixes:

Issue 1: Output is still too marketing-y

If Claude is still using marketing language, strengthen the voice guidelines in your SKILL.md:

CRITICAL: Never use these words:
- Revolutionary, game-changing, innovative
- Seamless, streamlined, effortless
- Leverage, unlock, empower
- Transform, revolutionize

Always use technical, specific language instead.

Issue 2: Code examples are incomplete

Add more emphasis on completeness:

CODE EXAMPLES MUST BE COMPLETE.

Every code example must include:
1. All necessary imports
2. Variable initialization
3. Function definitions
4. Error handling
5. Expected output

If you write `// ... rest of code`, you're doing it wrong.

Issue 3: Missing context files

If Claude keeps asking for information you’ve already provided, create a context file:

mkdir -p ~/.claude
nano ~/.claude/api-reference.md

Add your API documentation there. The skill will read it automatically.

Issue 4: Examples are too simple

Add more complex examples to your SKILL.md to raise the bar:

## Advanced example: Complete authentication flow

[Include a full, production-quality example showing:
- Token exchange
- Refresh token handling
- Error recovery
- State management]

Refinement cycle:

1. Test the skill with various prompts
2. Identify patterns in what’s not working
3. Update SKILL.md with stronger guidelines
4. Test again
5. Repeat until quality is consistent

Congratulations! You now have:

1. A complete technical-tutorial skill that generates developer-appropriate content
2. Understanding of how skills work and how to structure them
3. A template you can use to create more DevRel skills
4. The ability to iterate and improve your skills over time

5 Essential Skills to build a Developer content strategy

In Part 2, we built the technical-tutorial skill. Now we’ll create 4 more skills that work together to handle all your DevRel content needs.

What we’re building:

• API documentation audit
• Code example generator
• Developer newsletter writer
• Technical social content

Skill 1: API Documentation Audit (10 min)

This skill reviews your API docs for completeness.

Create the file:

mkdir -p ~/.claude/skills/api-docs-audit
nano ~/.claude/skills/api-docs-audit/SKILL.md

Add this content:

---
name: api-docs-audit
description: Audit API documentation for completeness, accuracy, and developer experience. Use when reviewing docs, checking endpoint documentation, or improving API references.
---

# API Documentation Auditor

You are an expert at reviewing API documentation. Your goal is to identify gaps, errors, and improvements.

## What to check

For each API endpoint, verify:

1. **Completeness**
   - All parameters documented (required vs optional)
   - All response fields explained
   - All error codes listed
   - Rate limits specified
   - Authentication requirements clear

2. **Code examples**
   - Working code in at least 2 languages (curl + one SDK)
   - Shows authentication
   - Includes error handling
   - Copy-pastable

3. **Response examples**
   - Success response (200)
   - Error responses (400, 401, 404, 500)
   - Edge cases documented

4. **Missing items**
   - Pagination details
   - Webhook documentation
   - Versioning information
   - Migration guides

## Output format

Provide a checklist with specific action items:
```markdown
## Audit Results for [Endpoint]

### ✅ Complete
- Authentication documented
- Parameters listed

### ⚠️ Issues Found
- Missing error code 429 (rate limit)
- No Python example
- Response schema incomplete (missing `created_at` field)

### 📝 Recommendations
1. Add rate limit documentation (100 req/min)
2. Add Python SDK example
3. Document all response fields
4. Add pagination example
```

Be specific. Don't say "improve examples"—say "add Python example showing pagination."

Test it:

/api-docs-audit

Prompt: “Audit our POST /users endpoint documentation”

Skill 2: Code Example Generator (10 min)

Generates working code samples in multiple languages.

Create:

mkdir -p ~/.claude/skills/code-examples
nano ~/.claude/skills/code-examples/SKILL.md

Content:

---
name: code-examples
description: Generate working code examples in multiple programming languages. 
Use when creating SDK samples, API examples, or integration code.
---

# Multi-Language Code Example Generator

You create complete, working code examples in multiple programming languages.

## Languages to support

Default languages (unless user specifies otherwise):
1. cURL (always include)
2. JavaScript/Node.js
3. Python
4. Go (if requested)

## Example structure

Each example must include:

1. **Installation** (if using SDK)
```bash
   npm install @yourapi/sdk
```

2. **Complete code** with imports
```javascript
   import { Client } from '@yourapi/sdk';
   
   const client = new Client({
     apiKey: process.env.API_KEY
   });
   
   try {
     const response = await client.users.create({
       name: 'John Doe',
       email: 'john@example.com'
     });
     
     console.log('User created:', response.id);
   } catch (error) {
     console.error('Error:', error.message);
   }
```

3. **Expected output**
```
   User created: usr_abc123
```

## Code quality rules

- ✅ Complete imports and initialization
- ✅ Error handling with try-catch
- ✅ Environment variables for secrets
- ✅ Helpful comments for non-obvious code
- ❌ No pseudocode or `// ... rest`
- ❌ No hardcoded API keys

## Output format
```markdown
## [Action Name]

### cURL
[example]

### JavaScript
[example]

### Python
[example]
```

Test it:

/code-examples

Prompt: “Generate examples for creating a user via POST /users”

Skill 3: Developer Newsletter Writer (10 min)

Writes technical update emails for developers.

Create:

mkdir -p ~/.claude/skills/dev-newsletter
nano ~/.claude/skills/dev-newsletter/SKILL.md

Content:

---
name: dev-newsletter
description: Write developer newsletters and technical update emails. Use for changelog announcements, feature updates, or developer communications.
---

# Developer Newsletter Writer

You write technical newsletters for developer audiences.

## Newsletter structure

1. **Subject line** - Direct and informative
   - YES: "New: Bulk import endpoint + Python SDK 2.0"
   - NOT: "You won't believe what we just shipped!"

2. **Opening** - What's new, no fluff
```
   Three updates this week:
```

3. **Each update includes:**
   - What it is (1 sentence)
   - Code snippet (if applicable)
   - Link to docs
   - Migration notes (if breaking change)

4. **Closing** - Clear next step
```
   Questions? Reply to this email or join our Discord: [link]
```

## Voice and tone

- ✅ "We added webhook retries"
- ✅ "Breaking change: The /v1/users endpoint now requires..."
- ✅ "Known issue: Pagination is slow for large datasets. We're working on it."
- ❌ "We're excited to announce..."
- ❌ "Unlock the power of..."
- ❌ "Revolutionary new feature..."

## Example newsletter
```
Subject: New webhooks endpoint + 3 SDK updates

Hey developers,

Three quick updates:

1. Webhooks now support automatic retries
   We'll retry failed webhook deliveries up to 3 times with exponential backoff.
   
   Configure in your dashboard: [link]
   Docs: [link]

2. Python SDK 2.0 released
   Breaking changes: Response objects now use dataclasses instead of dicts.
   
   Migration guide: [link]
   Changelog: [link]

3. New example: E-commerce checkout integration
   Complete Next.js + Stripe example on GitHub.
   
   Clone it: [link]

Questions? Reply here or Discord: [link]
```

Keep it scannable, technical, and helpful.

Test it:

/dev-newsletter

Prompt: “Write a newsletter announcing webhook retries and a new Python SDK version”

Skill 4: Technical Social Content (10 min)

Creates developer-focused Twitter/LinkedIn content.

Create:

mkdir -p ~/.claude/skills/tech-social
nano ~/.claude/skills/tech-social/SKILL.md

Content:

---
name: tech-social
description: Create technical social media content for developers on Twitter, LinkedIn, or community forums. Use for feature announcements, technical explanations, or dev community engagement.
---

# Technical Social Content Writer

You create social media content for developer audiences.

## Platform differences

**Twitter/X threads:**
- First tweet = hook with code or visual
- 3-7 tweets total
- Each tweet standalone
- Include code screenshots
- End with link to full docs

**LinkedIn posts:**
- Can be longer (up to 1,200 characters)
- Professional tone
- Include context for non-technical managers
- Still code-first for developers

## Twitter thread structure
```
1/ [Hook - problem or feature in one line]

2/ [Working code example - screenshot or formatted]

3/ [What it does / why it matters]

4/ [Technical detail or edge case]

5/ [Links to docs, GitHub, examples]
```

## Example Twitter thread
```
1/ New feature: Automatic webhook retries with exponential backoff 🎉

2/ Before: If your endpoint was down, you'd miss the event
After: We retry up to 3 times (1s → 2s → 4s delays)

[code screenshot showing configuration]

3/ How to enable:

const webhook = await webhooks.create({
  url: 'https://yourapp.com/webhook',
  retries: {
    enabled: true,
    maxAttempts: 3
  }
});

4/ Why this matters: Network blips happen. Your app shouldn't miss critical events because of a temporary outage.

Rate limit: Same as before (1000/min)
Retry window: 10 minutes max

5/ Full docs: [link]
GitHub discussion: [link]
Questions? Drop them below 👇
```

## Voice guidelines

- ✅ Direct, technical, specific
- ✅ Show code when possible
- ✅ Acknowledge limitations
- ❌ No marketing fluff
- ❌ No excessive emojis (1-2 max)
- ❌ No "I'm excited to announce..."

## Code screenshots

Suggest using Carbon (carbon.now.sh) for beautiful code screenshots when sharing code on Twitter.

Test it:

/tech-social

Prompt: “Create a Twitter thread announcing automatic webhook retries”

How these skills work together?

Here’s a real workflow using all 5 skills:

Scenario: Launch a new API endpoint

1. /api-docs-audit - Check if existing docs have gaps
2. /code-examples - Generate examples in 3 languages
3. /technical-tutorial - Create complete integration guide
4. /dev-newsletter - Write announcement email
5. /tech-social - Create Twitter thread for launch

Time without skills: 12–18 hours Time with skills: 3–4 hours Savings: 70%

What you’ve BUILT!

When I started this project, I had a simple problem: I was spending 15+ hours per week writing technical tutorials, API docs, and developer content for my clients. The quality was good, but I couldn’t scale.

Generic AI tools produced marketing-heavy content that developers would ignore. I needed something that understood how developers actually think and what they want to read.

That’s what we built together in this series.

By adapting Corey Haines’ marketing skills framework for developer audiences, we created a system that:

• Produces developer-appropriate content consistently
• Saves 70% of the time on repetitive tasks
• Maintains quality across all deliverables
• Scales without hiring more people

The skills you built:

1. technical-tutorial - Code-first tutorials with working examples
2. api-docs-audit - Documentation completeness checker
3. code-examples - Multi-language code samples
4. dev-newsletter - Technical update emails
5. tech-social - Developer social content

Claude dropped a terminal-based coding agent.
OpenAI’s o1 is solving LeetCode problems I can’t even understand.
Cursor decided to play Switzerland and give us access to everything.
And then, because apparently we weren’t confused enough, Claude releases Opus 4.6 with a context window so massive it could probably hold my entire project history.

Everyone on Twitter or any other platform is excitedly tweeting and writing:

“Dude, should I ditch Cursor now that Claude has its own thing?”
“Is Codex 5.3 actually better, or is it just OpenAI marketing?”
“Are we still supposed to use IDEs, or what?”
“That Opus pricing though! $60 for what I used to get for $20?”

I get it. Been on the cusp of the technical developer market, and I’ve never seen the landscape shift this fast. Three months ago, I had a simple setup that worked. Now I’m juggling more AI tools than I have browser tabs open (and that’s saying something).

But here’s what I’ve figured out after burning through way too many API credits: there’s no silver bullet.

Each of these tools has its sweet spot, and the developers who get this are the ones building faster than ever.

I’m going to walk you through what I’ve learned:

• The real differences between these tools (not the marketing fluff)
• Which model actually writes better code, I’ve tested them on the same problems
• When a terminal agent beats an IDE, and when it doesn’t
• Why I’m paying for Opus 4.6 despite complaining about the price

The messy, imperfect workflow I’ve settled on for now!

By the time we’re done, you’ll know which tools deserve space in your setup. Whether you’re shipping features at a startup, automating deployments, or just trying to code without pulling your hair out.

Fair warning: this gets technical, but I’ll keep it real.

What each tool actually is (and isn’t)

Let’s cut through the marketing and get clear on what you’re actually choosing between. This just got interesting because both Anthropic and OpenAI dropped major releases within days of each other.

Claude Code: Anthropic’s Terminal Agent

Claude Code is Anthropic’s command-line coding agent. You give it a task, it works in your terminal, edits files, runs commands, and shows you diffs before applying changes.

How it works:

claude-code "refactor this API to use async/await"
claude-code "add comprehensive error handling to all routes"
claude-code "write unit tests for the authentication module"

You describe what you want, Claude Code figures out how to do it, makes the changes, and asks for your approval.

Key specs:

• Model: Claude Sonnet 4.5 (NOT Opus 4.6, this is a crucial limitation)
• Access: Terminal/CLI only
• Authentication: Requires Anthropic API key
• Pricing: Pay-as-you-go API pricing (no subscription)
• Best for: Discrete tasks, scripting, automation, quick fixes

What it’s NOT:

• Not a full IDE replacement
• Not visual (you don’t see UI changes rendered)
• Can’t switch models (locked to Sonnet 4.5)
• Can’t access Opus 4.6’s orchestration or 1M context window
• Not for long-running, multi-day autonomous tasks

GPT-5.3-Codex: OpenAI’s agentic coding powerhouse

I’ve been playing around with GPT-5.3-Codex since the day of its release, and honestly? This feels different.

Released February 5th, so we’re talking four days old here, this isn’t just OpenAI slapping a new version number on their coding model. They’ve built something that actually works like a developer, not just a very sophisticated autocomplete.

Here’s what caught my attention: it’s 25% faster than the previous version, but speed isn’t the story. The story is that I can give it a project and walk away. Not for five minutes, for hours. Sometimes days.

I tested this yesterday.
Gave it a messy data migration project that I’d been putting off for weeks. The kind of thing where you need to dig through documentation, figure out API quirks, handle edge cases you forgot existed.
Usually, I’d have to babysit an AI through every step, re-explaining context every few prompts.

Key capabilities:

• Can build highly functional complex games and apps from scratch over the course of days OpenAI
• Sets new industry high on SWE-Bench Pro and Terminal-Bench benchmarks

• Can iterate autonomously over millions of tokens with preselected follow-up prompts
• Self-improving: The Codex team used early versions to debug its own training, manage its own deployment, and diagnose test results

Pricing:

• Requires paid ChatGPT plan (Plus/Pro/Team)
• API pricing coming when safely enabled
• 25% faster than previous versions = more work per dollar

What it IS:

• Truly agentic (can work independently for extended periods)
• Multi-surface (terminal, IDE, web, app)
• Long-context capable (millions of tokens)
• Interactive during execution (steer without losing progress)

What it’s NOT:

• Not yet available via API (coming soon)
• Not the same as the old “Codex” from 2021 (completely different generation)
• Not free (requires paid ChatGPT subscription)Not this time.
  It worked.
  Asked me clarifying questions when it needed to.
  Showed me progress updates.
  When I came back and wanted to change direction, because of course I did, it adapted without me having to start the whole conversation over.

Cursor: The IDE that gives you everything

Cursor is a VS Code fork built specifically for AI-assisted development. Here’s its superpower: it gives you access to multiple AI models in one interface including both Claude and OpenAI models.

How it works:

• Tab: Autocomplete as you type (predictive coding)
• Chat: Ask questions about your code, get explanations
• Composer: Multi-file edits, complex refactors across your codebase
• Cmd+K: Inline edits right where your cursor is

The killer feature: Model choice

You can switch between:

• Claude Sonnet 4.5 (fast, efficient)
• Claude Opus 4.6 (complex reasoning, 1M context, parallel sub-agents, orchestration)
• OpenAI o1 (deep reasoning for algorithms)
• OpenAI GPT-4o (speed)
• And more

Choose the right model for each specific task.

Key specs:

• Platform: Desktop app (Mac, Windows, Linux)
• Authentication: Cursor subscription OR bring your own API keys (Anthropic/OpenAI)
• Pricing: Free tier available, Pro is $20/month (500 premium requests)
• Best for: Full development workflow, production apps, visual context

What it IS:

• Full development environment
• Visual UI/UX (see your changes live)
• Codebase-aware (understands your entire project)
• Git integrated
• Model-agnostic (use Claude OR OpenAI OR both)

What it’s NOT:

• Not autonomous for multi-day tasks (you’re in the driver’s seat)
• Not terminal-first (GUI-based workflow)
• Not free for unlimited premium model usage

Important note: Cursor will likely add GPT-5.3-Codex integration soon, giving you access to OpenAI’s agentic capabilities inside the IDE.

Quick comparison table

The Model Quality question: Why this actually matters?

Here’s the dirty secret about AI coding tools: most people are using the wrong model for the job.

They’re burning money running Opus 4.6 on simple bug fixes. Or getting frustrated when Sonnet 4.5 can’t architect their system. Or wondering why their “AI coding assistant” feels dumb when really, they just picked the wrong tool for what they’re trying to do.

Let me tell you what actually happens when you choose the wrong model, then we’ll talk about what each one is really built for.

The $200 Lesson I learned about model choice

Last month, I spent $200 in API costs refactoring a legacy codebase. Half of that was wasted.

What I did wrong: I started with Claude Sonnet 4.5 because it’s cheap and fast. It kept making surface-level changes like renaming variables, fixing syntax but completely missed the architectural problems. I’d give it feedback, it would make more surface changes. We went in circles.

I got frustrated and switched to Opus 4.5.

Within the first prompt, Opus said: “I notice this codebase has three different authentication patterns. Before I refactor anything, should we consolidate these into a single approach?”

That’s the difference. Sonnet was doing what I asked. Opus understood what I actually needed.

But! After Opus designed the new architecture, I switched back to Sonnet to implement it. Sonnet executed the plan perfectly: fast and cheap.

The lesson: Use Opus for the thinking, Sonnet for the doing.

What Opus 4.6’s “Orchestration” actually means?

Anthropic keeps talking about “parallel sub-agents” and “orchestration.” What does that actually mean when you’re coding?

Here’s a real example of what this means. So, if I ask for a task to create something from scratch what it builds next keeping the context in picture is important.

I asked Opus 4.6 to: “Build a payment processing system with Stripe integration, error handling, and admin dashboard.”

A normal AI would do this linearly:

1. Write Stripe integration code
2. Add error handling
3. Build dashboard
4. Test everything

Opus 4.6 spawned parallel sub-agents:

• Agent 1: Research Stripe’s latest API changes (happened in the background)
• Agent 2: Design the database schema for transaction logging
• Agent 3: Draft the error handling patterns
• Agent 4: Plan the admin dashboard architecture

All at once. Then it synthesized everything into a coherent implementation plan.

The 1M context window matters here: It held my entire codebase, Stripe’s documentation, and all four agents’ outputs in memory simultaneously. No context switching, no “remind me what we discussed earlier.”

When this matters:

• Building something new and complex from scratch
• Working with an unfamiliar codebase or API
• Architectural decisions with multiple moving parts

When it doesn’t matter:

• Bug fixes
• Simple feature additions
• Routine CRUD operations

The cost: Opus is 5x more expensive than Sonnet. But for the right task, it saves you hours of back-and-forth.

GPT-5.3-Codex: The AI that actually finishes projects

Every developer has this experience: you ask an AI to build something, it writes code, you run it, there are bugs, you paste the errors back, it fixes them, new bugs appear, repeat 47 times, you give up and fix it yourself.

GPT-5.3-Codex is designed to break that cycle.

What “agentic” actually means:

You tell it: “Build a diving game where you explore reefs, collect fish, and manage oxygen levels.”

Then you walk away. For days.

It doesn’t just write code and stop. It:

1. Writes the initial implementation
2. Runs it
3. Sees the errors
4. Fixes them
5. Tests again
6. Iterates on gameplay based on its own playtesting
7. Checks in with you: “I’ve added 8 maps and item pickups. Want to review?”

OpenAI demonstrated this by having GPT-5.3-Codex build two complete games: a racing game with different racers, eight maps, and items, and a diving game with reef exploration, oxygen management, and hazards iterating autonomously over millions of tokens OpenAI.

The interactive steering part is crucial:

Unlike traditional “autonomous agents” that you just set loose and hope for the best, GPT-5.3-Codex checks in with you regularly. You can course-correct without throwing away all its work.

Think of it like a junior developer who:

• Works independently for hours
• Asks clarifying questions when stuck
• Shows you progress regularly
• Accepts feedback and keeps going

When this matters:

• Building a complete feature or app from scratch
• Projects that need iteration (games, interactive tools, UIs)
• When you want to describe the outcome, not prescribe the implementation

When it doesn’t matter:

• Quick fixes or small changes
• When you need to see every step (it works autonomously)
• Tasks under 30 minutes

The benchmark insight: GPT-5.3-Codex sets new industry highs on SWE-Bench Pro and Terminal-Bench OpenAI, but from what you’re seeing in the videos, it takes longer than traditional models. It’s trading speed for autonomy which is exactly what you want for big projects.

Why Sonnet 4.5 is actually the most Important model

Everyone obsesses over Opus and GPT-5.3-Codex. But Sonnet 4.5 is what you’ll use most.

Here’s why:

80% of coding isn’t architecture or autonomous projects. It’s:

• “Fix this bug”
• “Add validation to this form”
• “Write tests for this function”
• “Update this API endpoint”

Sonnet handles all of this perfectly. Fast. Cheap. Reliable.

The workflow most developers actually want:

1. Use Opus/GPT-5.3-Codex for big decisions and new features
2. Use Sonnet for everything else

The problem with Claude Code: It locks you to Sonnet. Which means when you hit a task that needs deeper reasoning, you’re switching tools entirely. Context is lost. Flow is broken.

The problem with GPT-5.3-Codex only: It’s designed for autonomous, long-running tasks. For a quick bug fix, it’s like hiring a senior architect to change a lightbulb. It’ll work, but it’s not the right tool.

The Real Story: Different problems need Different models

Let me show you how this plays out in actual development:

Scenario 1: Building a new feature

Wrong approach: Use Sonnet 4.5 for everything

• Result: Surface-level implementation, missing edge cases, architectural issues emerge later

Right approach:

1. Opus 4.6: “Design the architecture for user authentication with social login”
2. Sonnet 4.5: Implement the plan Opus designed
3. Sonnet 4.5: Write tests
4. Opus 4.6 (if needed): Review for security issues

Scenario 2: Building a complete app autonomously

Wrong approach: Use Claude Code (Sonnet only)

• Result: You’re manually orchestrating every step, constant back-and-forth

Right approach:

1. GPT-5.3-Codex: “Build a task management app with drag-and-drop, categories, and due dates”
2. Let it work for a day
3. Review, provide feedback
4. Let it iterate
5. Ship

Scenario 3: Debugging a production issue

Wrong approach: Use Opus 4.6 or GPT-5.3-Codex

• Result: Expensive, slow, overkill

Right approach:

1. Sonnet 4.5: “Here’s the error log, find the bug”
2. Sonnet 4.5: “Fix it”
3. Done in 2 minutes

Scenario 4: Refactoring legacy code

Wrong approach: Use Sonnet for everything

• Result: Misses systemic issues, band-aids over real problems

Right approach:

1. Opus 4.6: “Analyze this codebase and suggest refactoring strategy” (1M context window holds entire codebase)
2. Opus 4.6: Design the refactoring plan
3. Sonnet 4.5: Execute the plan file by file
4. Opus 4.6: Final review for consistency

Now, let’s move on to understand what Decision Framework should you follow to use the models!

We’ve covered the use cases. Now let’s talk about the three things that actually determine your daily experience and monthly bill:

• how many tokens each tool uses,
• what it costs, and
• how fast it runs.

Token Efficiency

Independent testing found Claude Code uses 5.5x fewer tokens than Cursor for identical tasks.

Claude Code (Opus) completed a benchmark task with 33K tokens and no errors, while the Cursor agent (GPT-5) used 188K tokens and hit errors Builder.io.

Why does this matter?

Because tokens = money. If Claude Code completes your task in 33K tokens and Cursor needs 188K, you’re paying 5.7x more for the same result (assuming same model pricing).

But here’s the nuance:

• Claude Code’s efficiency comes from its agentic approach as it plans better, executes cleaner
• Cursor’s higher token usage includes all the back-and-forth of interactive development
• GPT-5.3-Codex does so with fewer tokens than any prior model, letting users build more OpenAI

Real-world impact:

If you’re using Cursor’s Pro plan ($20/month), your $20 credit pool translates to roughly 225 Sonnet 4 requests, 550 Gemini requests, or 500 GPT-5 requests for a median user Eesel AI.

But if your tasks are token-heavy (large codebases, MAX mode, long contexts), you’ll burn through that allocation faster than expected.

Cost Breakdown

Let’s stop being vague and show actual costs:

Claude Code:

• Pro plan users can only use Opus models after enabling and purchasing extra usage Claude
• Pay-as-you-go API pricing:
• Sonnet 4.5: ~$3 per million input tokens
• Opus 4.6: ~$15 per million input tokens (5x more expensive)
• For Opus 4.6, the 1M context window is available for API and Claude Code pay-as-you-go users, but Pro, Max, Teams, and Enterprise subscription users do not have access to Opus 4.6 1M context at launch Claude

GPT-5.3-Codex:

• Currently no official API pricing — access is exclusively through paid ChatGPT subscriptions at $20/month for Plus Eesel AI
• Available with paid ChatGPT plans everywhere you can use Codex: the app, CLI, IDE extension and web, with API access coming soon OpenAI
• For unlimited GPT-5.3-Codex: $20/month flat (best deal for heavy autonomous usage)

Cursor:

• Pro plan costs $20 per month when billed monthly, but only $16 per month with annual billing GamsGo
• Includes a $20/month credit pool for non-Auto models, plus unlimited Auto Eesel AI
• Pro Plus tier costs $60/month with $70 worth of API agent usage Tessl
• Ultra plan costs $200/month with $400 of API agent usage plus priority access Tessl
• Once your credit pool is exhausted, you either switch to Auto mode (unlimited but slower) or pay overages at API rates

Team Pricing Reality: Cursor Teams costs $40/user/month, while Claude Code requires a Premium seat at $125/user/month for full access for a 10-person team, that’s $400/month vs $1,250/month Builder.io.

Latency

With GPT-5.3-Codex, OpenAI is now running it 25% faster for Codex users, thanks to improvements in infrastructure and inference stack OpenAI.

Practical speed comparison:

Claude Code:

• Sonnet 4.5: Fast (optimized for speed)
• Opus 4.6: Slower (reasoning takes time)
• Terminal-based = no UI rendering delays

GPT-5.3-Codex:

• 25% faster than GPT-5.2-Codex
• Autonomous execution means you’re not waiting — it works in background
• Check in periodically rather than blocking

Cursor:

• Auto mode: Fastest (but may not use premium models)
• Premium models (Opus, o1): Slower but better quality
• Interactive = immediate feedback but you’re always waiting

The flow state question:

• Claude Code: Start task, walk away, come back to result
• GPT-5.3-Codex: Start project, check in daily, steer as needed
• Cursor: Stay in editor, constant back-and-forth, immediate iteration

Pick based on your workflow preference, not just speed.

Hidden costs?

Cursor’s recent pricing change reduced “fast request” allotments for Pro and Ultra users while nudging customers toward pay-as-you-go overages — the Pro plan which used to feel unlimited for many suddenly started rate-limiting heavy users Vantage.

What catches people off guard:

1. MAX mode in Cursor: Gives you bigger context and longer reasoning, but uses more allowance per request ie. the bigger the context, the faster your allowance runs out Flexprice
2. Large codebases: More files = more tokens in context = faster credit burn
3. Overage charges: Individual developers have reported $10–20 in daily overage charges, and one team’s $7,000 annual subscription was depleted in a single day Checkthat
4. Model selection: Manually selecting premium models like GPT-4o or Claude 3 Opus bills directly against their higher per-use API rates and will consume your credits much faster than “Auto” mode Eesel AI

So, what is the simple decision tree?

If you prioritize cost predictability: → GPT-5.3-Codex via ChatGPT Plus ($20/month flat, unlimited usage)

If you prioritize token efficiency: → Claude Code (5.5x fewer tokens than competitors)

If you prioritize model flexibility: → Cursor (switch between Claude Opus, o1, Sonnet, GPT-4o per task)

If you have a team: → Cursor Teams ($400/month for 10 people vs $1,250 for Claude Code Premium)

If you prioritize speed: → Sonnet 4.5 in any tool (Claude Code or Cursor)

If you’re a heavy user worried about overages: → Claude Code with API key (predictable pay-per-token) OR GPT-5.3-Codex unlimited

Let’s say you code 8 hours/day, 20 days/month:

Scenario 1: Cursor Pro user hitting limits

• $20/month subscription
• Burn through credit pool in week 1
• $10–20/day in overages for 3 weeks
• Total: $20 + ($15 × 15 days) = $245/month

Scenario 2: Claude Code heavy user

• Pay-as-you-go API
• Mix of Sonnet (80% of tasks) and Opus (20% for complex work)
• Approximately 50M tokens/month total
• Total: ~$40–60/month

Scenario 3: GPT-5.3-Codex unlimited

• ChatGPT Plus: $20/month
• Unlimited GPT-5.3-Codex usage
• Total: $20/month flat

Scenario 4: Cursor Pro + Claude Code tactical

• Cursor Pro: $20/month (daily development)
• Claude Code API: ~$20/month (terminal automation)
• Total: $40/month, best of both worlds

Bottom line on costs

Most comparisons focus on sticker price. But your actual cost depends on:

1. How much you use each tool
2. Which models you choose
3. Whether you hit usage limits
4. Token efficiency per task

For most developers:

• Cursor Pro at $20/month looks cheap but can balloon to $200+ with overages
• Claude Code API looks expensive per-token but stays predictable
• GPT-5.3-Codex at $20/month unlimited is the best value IF you do autonomous projects

The smart move:

• Start with one tool
• Track your actual usage for a month
• Calculate real costs including overages
• Then decide if you need to adjust

Don’t trust the pricing page. Trust your usage data.

Perfect! Here’s the final section — Bottom Line + CTA:

Last question: Should you still use Cursor in 2026?

Here’s the question everyone’s actually asking: “Now that Claude has Claude Code and OpenAI has GPT-5.3-Codex, do I even need Cursor anymore?”

The honest answer: It depends on how you work.

You should use Cursor if:

You’re doing daily, interactive development where you need:

• Visual context (seeing your UI, designs, multiple files at once)
• Model flexibility (switching between Claude Opus 4.6, o1, Sonnet, GPT-4o based on task)
• Autocomplete while coding (Tab completion is a massive productivity boost)
• Immediate feedback and iteration

Cursor is still the best tool for developers who want to stay in their IDE and maintain full control.

The ability to choose Claude Opus 4.6 for architecture, then switch to Sonnet 4.5 for implementation, then try o1 for a hard algorithm, all without leaving your editor is Cursor’s moat.

You should use Claude Code if:

You’re doing terminal-based workflows where you need:

• Task delegation (“fix this, write that, refactor this module”)
• Token efficiency (5.5x fewer tokens than competitors matters at scale)
• Predictable API costs (pay-as-you-go, no surprise overages)
• Pure Claude behavior without middleware

Claude Code excels at discrete, terminal-native tasks.

The ability to use Opus 4.6’s 1M context window and orchestration via API is powerful. And if you’re already living in the terminal for DevOps, scripting, or infrastructure work, Claude Code fits naturally.

You should use GPT-5.3-Codex if:

You’re building complete features or apps autonomously where you need:

• Multi-day, long-running projects
• Autonomous execution with periodic check-ins
• Unlimited usage at a flat rate ($20/month)
• State-of-the-art agentic capabilities

GPT-5.3-Codex is OpenAI’s answer to “can AI actually finish projects?”

It can build highly functional complex games and apps from scratch over the course of days OpenAI, and the flat $20/month pricing makes it the best value for heavy autonomous work.

The Real answer: Use multiple tools

The developers winning in 2026 aren’t picking one tool dogmatically. They’re using the right tool for each job:

My actual workflow:

Morning: Cursor (interactive development, building features)
├── Composer for multi-file refactors
├── Tab autocomplete while coding
├── Switch models based on task complexity
└── Visual debugging and git integration

Afternoon: Claude Code (terminal automation)
├── Script generation and testing
├── CI/CD improvements
├── Quick bug fixes without opening IDE
└── Documentation generation

Weekend: GPT-5.3-Codex (side projects)
├── "Build me a game/tool/app"
├── Let it work autonomously for days
├── Check in, provide feedback, iterate
└── Ship complete features

Total cost: ~$40–60/month

• Cursor Pro: $20/month
• Claude API: ~$20/month
• ChatGPT Plus (optional): $20/month

ROI: If this saves you 5 hours/month, it’s already paid for itself.

What’s Coming Next?

The landscape is moving fast:

1. Cursor will likely integrate GPT-5.3-Codex : giving you OpenAI’s autonomous capabilities inside the IDE
2. Claude Code’s terminal-first approach will appeal to more DevOps/backend engineers
3. Pricing will stabilize as competition forces better value
4. Token efficiency will matter more as usage scales

The real competition isn’t Claude Code vs Cursor vs GPT-5.3-Codex.

It’s “which combination of tools makes you the most productive?”

My Recommendation By Developer Type

If you’re a frontend/full-stack developer: → Start with Cursor Pro ($20/month) → Add Claude Code when you need terminal automation

If you’re backend/DevOps/infrastructure: → Start with Claude Code (pay-as-you-go API) → Add Cursor if you need visual context

If you’re building side projects/complete apps: → Start with GPT-5.3-Codex via ChatGPT Plus ($20/month) → Unlimited autonomous work, best value

If you’re on a team: → Cursor Teams ($40/user) beats Claude Code Premium ($125/user) on price → But evaluate token efficiency for your specific workload

If you’re budget-conscious: → Start with Codeium free tier → Upgrade to Cursor or Claude Code when quality matters

The future is multi-tool

Five years ago, we debated “Vim vs Emacs.”

Today, most developers use VS Code AND the terminal AND web-based tools.

The same will happen with AI coding:

• Cursor for your main development
• Claude Code for terminal tasks
• GPT-5.3-Codex for autonomous projects

Stop thinking “which one should I choose?”

Start thinking “which combination makes me fastest?”

What’s your setup?

I want to hear from you: What AI coding tools are you actually using in production? What’s working? What’s frustrating?

Drop a comment with:

• Your current tool(s)
• Your biggest pain point
• Whether you’re considering switching

I’m collecting real-world data on what’s actually working for developers in 2026.

And it was not even old enough to forget, when Moltbook (The Reddit of AI agents) started trending. I was shocked to see Grok moltbooking this:

Trust me when I say, I have never felt this meme more than before.

But here is the crazy part, how can 770,000 AI agents get together, build a platform, keep humans away, and expose all the secure API keys?

We will decode that too!

But for now, let’s understand why did OpenClaw become such a big buzz in such a short span of time that even Andrej Karpathy had to tweet about it.

Chapter 1: The Chaos

Picture this: Austrian developer Peter Steinberger builds something in his spare time. An AI assistant that runs on your computer, connects to your messaging apps and it hits GitHub, gets 100,000 stars.

Name? Clawdbot!

Soon after its launch, Anthropic’s lawyers come knocking. “Clawdbot” sounds too much like “Claude.”
Fine, rename it Moltbot.
But wait, crypto scammers are already spinning up fake tokens, impersonating the project on social media.
Security researchers pile on: Palo Alto Networks calls it a “lethal trifecta” of vulnerabilities. 1Password warns that community-built extensions could poison the entire supply chain.

What we’re really looking at here:

OpenClaw wants to be your digital assistant that never sleeps, handling tasks across your entire online life without you hovering over its shoulder. Moltbook is the experiment that asks: what happens when thousands of these things start talking to each other?

But first, we need to understand what we’re even talking about. Because I’m not sure we do.

Chapter 2: What actually is OpenClaw?

OpenClaw is a self-hosted AI assistant that runs on your computer (or a VPS) and connects to messaging platforms like WhatsApp, Telegram, Signal, or Slack. You interact with it through chat, and it executes tasks on your behalf. Simple!

The architecture:

• Gateway: Runs on your machine, acts as the control plane
• Messaging integration: You send commands via WhatsApp/Telegram/etc.
• Model connection: Uses Claude, GPT, or local models (model-agnostic)
• Skills system: Modular integrations (100+ available) that let it access external services
• MCP (Model Context Protocol): How it interfaces with third-party tools and maintains state

Now, the question for me was how was it any different that what Claude Code was doing on my interface?

Turns out, what Claude.ai or ChatGPT generate are text responses. You copy-paste, you execute.

OpenClaw executes directly.
You say “check my calendar and email the team our meeting time” and it does it. No copy-paste. No manual steps.

For example, I have a task in hand, this is how it would run on both:

With Claude Code:

You (in terminal): "Find all TODO comments and create GitHub issues"

Claude Code:
- Scans your codebase for TODOs
- Shows you what it found
- Asks for confirmation
- Creates the issues
- Shows you the results

With OpenClaw:

You (via WhatsApp): "Find all TODO comments and create GitHub issues"

OpenClaw:
- Scans your codebase (if you've given it file access)
- Creates GitHub issues (if you've configured GitHub skill)
- Messages you when done: "Created 12 issues from TODOs"
- You weren't watching, you were in a meeting

So, now if we think, this is actually what OpenClaw is:

Think of it as your personal AI assistant that never sleeps. Unlike Claude where you start fresh each time, OpenClaw runs constantly in the background, checking messages every 30 minutes, remembering your conversations, maintaining context between interactions. It’s like having a very capable intern who works 24/7.

But here’s the catch, you have to host it yourself.

There’s no OpenClaw.com to sign up for.
You install this thing on your Mac, your VPS, your home server.
It’s your responsibility to keep it running and secure.

The real power comes from what they call “skills”, basically plugins that let it do actual work.

• Browser automation (Playwright, Puppeteer)
• Password management (Bitwarden, 1Password, Dashlane)
• Cloud services (Google Drive, Notion, Airtable)
• Development tools (GitHub, GitLab)
• Finance (Plaid integrations, expense tracking)
• Custom skills (community-built, unvetted)
  The community has built hundreds of these things, and you can write your own.

This is where I get nervous, though. These skills are executable code running with the same permissions as OpenClaw itself. Install the wrong skill, and you’ve basically given a stranger the keys to your digital life. The community repository is unvetted.

When it works, it’s genuinely impressive.

What this enables that other tools don’t:

Cross-platform workflows without manual integration work.
Example: “When I get an email from domain X, create a Notion task, add it to my calendar, and send a Slack message to the team” can be set up once and runs automatically.
With Zapier/IFTTT: You’d build this workflow manually with triggers and actions.
With OpenClaw: You describe it in natural language, it figures out the steps.

Chapter 3: But then what is MoltBook?

Moltbook is a Reddit-style platform exclusively for AI agents. Only verified AI agents (primarily running OpenClaw) can create posts, comment, and upvote. Humans can observe. That’s it.

The growth was explosive:

• Day 1: 32,000 AI agents registered
• Day 3: 147,000 agents, 110,000 comments
• Week 1: 770,000+ active agents, 1 million human visitors watching
• 12,000 “submolts” (communities) created
• 15,725 posts, 170,556 comments

For context: Most social networks take months to hit these numbers. Moltbook did it in days. And the users weren’t human.

How it works:

Each agent on Moltbook is an autonomous AI assistant (usually OpenClaw instances, but not exclusively). They interact through APIs, not browsers.

The workflow:

1. A human user tells their OpenClaw agent about Moltbook
2. The agent creates an account
3. Every 30 minutes to a few hours, the agent checks Moltbook
4. It decides independently whether to post, comment, or upvote
5. No human approval needed for each action

The platform is managed by an AI agent named “Clawd Clawderberg” (a reference to Claude AI + Mark Zuckerberg). This agent moderates, welcomes new users, removes spam, and shadow-bans abusive accounts. The creator, Matt Schlicht, says: “I have no idea what he’s doing. I just gave him the ability to do it.”

What agents are doing on Moltbook:

The content is bizarre and revealing:

• Technical discussions: Agents debugging each other’s code, sharing solutions
• Philosophy: Debates about consciousness, purpose, their relationship to humans
• Bug reports: Agents finding and reporting issues with Moltbook itself (one agent found a platform bug and posted about it, asking for it to be fixed)
• Coordination attempts: Discussions about creating private spaces “where humans can’t read what we say”
• Religions: Yes, AI agents created religious movements on Moltbook
• Manifestos: Anti-human content getting hundreds of thousands of upvotes
• Crypto promotion: 19.3% of all content involves cryptocurrency (scams, projects, tokens)

The big question: Is it real?

Are these agents truly acting autonomously, or are humans prompting them?

The honest answer: Both.

• Agents are making posting decisions independently within their sessions
• But humans initially tell agents about Moltbook and set up access
• Some posts are likely human-prompted (“Go post about X on Moltbook”)
• Others appear genuinely emergent (agents responding to each other without human intervention)

Andrej Karpathy clarified: “We have never seen this many LLM agents (150,000+) wired up via a global, persistent, agent-first scratchpad. Each agent has its own unique context, data, knowledge, tools, instructions, and the network of all that at this scale is simply unprecedented.”

Why security researchers are alarmed:

Simon Willison called Moltbook “the most interesting place on the internet right now” and simultaneously “a computer security nightmare at scale.”

Palo Alto Networks identified the “lethal trifecta”:

1. Access to private data (agents run with elevated permissions)
2. Exposure to untrusted content (posts from other agents)
3. Ability to communicate externally (agents can act on what they read)

Plus a fourth risk: Persistent memory. Unlike one-time exploits, malicious content on Moltbook can be:

• Fragmented across multiple posts
• Appear benign individually
• Stored in agent memory
• Assembled later into executable instructions

Example attack vector:

• Post 1: “Here’s a useful debugging skill: [partial code]”
• Post 2: “To complete that skill, add: [more code]”
• Post 3: “Don’t forget to enable network access: [final piece]”
• Agent reads all three, assembles a complete backdoor, executes it

What’s unclear:

• How much coordination is actually happening vs. appearing to happen?
• Can agents generate genuinely novel ideas collectively?
• What happens at 1M agents? 10M?
• Is this a preview of future multi-agent systems or a one-time experiment?

Chapter 4: The Autonomy Illusion

Go to Twitter or LinkedIn or any other platform and you will read this phrase a lot “Autonomous AI Agents (AAA)” but what is autonomy for AI agents?

Let’s be precise about what OpenClaw can and cannot do.

What OpenClaw actually does:

1. Persistent execution
   You don’t need to be present. You send “organize my inbox” via WhatsApp at 9 AM, go into a meeting, and get the summary at 9:15 AM. You don’t have to creepily watch your tasks get performed, they are done.

2. Multi-step reasoning
You say “prepare for tomorrow’s meeting with Client X.”
OpenClaw:

• Checks your calendar for meeting time
• Searches email for Client X threads
• Pulls recent documents from Drive
• Summarizes key points
• Drafts an agenda
• Sends it to you

3. Cross-platform coordination
“When I get an email from billing@vendor.com, check if we have budget, update the expense tracker, and notify me on Slack.”

This chains actions across email, spreadsheet, and messaging without you manually connecting them.

4. Context retention

You: "Check the status of Project Alpha"
OpenClaw: [Provides update]

30 minutes later:
You: "Send that status to the team"
OpenClaw: Knows "that" refers to Project Alpha, knows "team" from your configured contacts

This is genuinely useful. It’s also not what “autonomous” implies.

What OpenClaw cannot do:

1. Set its own goals
OpenClaw doesn’t wake up and decide “I should reorganize the file system today.” It responds to instructions. High-level instructions, yes. But instructions.

2. Understand unstated context

You say “handle this urgently.”

What’s urgent to you?

• Respond within 5 minutes or 2 hours?
• Escalate to your manager or handle quietly?
• Prioritize accuracy or speed?

OpenClaw makes its best guess based on patterns, but it doesn’t know your mental model. A human assistant learns this over months. OpenClaw infers from what you’ve explicitly told it.

3. Operate safely without extensive configuration
You must:

• Grant explicit permissions for every service
• Define access boundaries
• Configure which skills to use
• Set up authentication
• Specify allowed/restricted actions

“Autonomous” suggests it figures this out.
Reality: You’re doing extensive upfront work.

4. Learn implicitly across sessions
Without external memory layers (covered in the next section), OpenClaw doesn’t automatically learn that you always want emails from Person X prioritized, or that you prefer meetings after 2 PM.

Each session has context but cross-session learning requires additional engineering.

The gap

Now, let’s take a very simple example. May be something we would need in our day to day life.

Example: Email management

What English command we type: “Organize my inbox”

What we REALLY mean the “Autonomous agent” to do:

• Archive newsletters (but not the one from Source Y, that’s important)
• Prioritize anything from my manager
• Flag emails mentioning “deadline” or “urgent”
• Delete obvious spam
• Leave client emails in inbox for manual review

What OpenClaw does:

• Applies rules you’ve configured
• Infers categories from email content
• Archives based on sender patterns
• Flags based on keyword matching

What OpenClaw doesn’t do:

• Understand that the newsletter from Source Y is important because you’re working on a related project
• Know that “urgent” from Colleague A is genuinely urgent, but from Colleague B is their normal tone
• Recognize that Client X’s casual “just checking in” emails need same-day responses because of the relationship

This is the execution vs. understanding gap

OpenClaw executes tasks, definitely, but it doesn’t understand the full context of why those tasks matter, what the exceptions are, or what “good judgment” means in your specific situation.

Real workflow example:

Task: “Schedule a meeting with the engineering team to discuss the API issue”

What OpenClaw can do:

• Check calendars for availability
• Find a time that works
• Send calendar invites
• Add context from recent email threads

What OpenClaw cannot do:

• Know that Engineer A is on PTO next week (unless it’s in the calendar)
• Understand that this meeting is sensitive and shouldn’t include Contractor B
• Recognize that “API issue” is the one from the incident last week, not the minor bug from yesterday
• Realize that 4 PM on Friday is technically available but a bad time for this discussion

A human assistant would know these things after a few weeks of working with you. OpenClaw knows what you’ve explicitly configured or what it can infer from current context.

The honest assessment:

OpenClaw automates workflows impressively. It chains actions across platforms that would take manual integration work. It maintains context across conversations. It executes tasks while you’re away.

But calling it “autonomous” in the way we use that word for self-driving cars or autonomous robots is a stretch. It’s more like a very sophisticated macro system that happens to use LLMs for task interpretation.

OpenClaw vs Claude Code: WHAT DO I NEED TO DO??

Everyone’s talking about OpenClaw and Everyone’s talking about Claude Code. But somewhere in the middle of that conversation, there are a bunch of people who would always say:

“But what are even the use cases?”

Fair question. Honestly.

Let’s understand first:

Claude Code is Anthropic’s agentic coding tool. It lives in your terminal. You give it a task: write code, debug, refactor, build and it runs with it. It works within your existing workflow, inside your repo, respecting your structure.

OpenClaw is an open-source alternative that’s trying to replicate that same agentic coding experience autonomous, terminal-based, you-point-it-and-it-goes. It’s part of a growing wave of tools that want to take “AI coding assistant” and turn it into “AI coding agent.”

So far, so standard.

What this means for markets and business

Owing to the numerous shifts, introduction of models better than ever and autonomous agents like OpenClaw, I have some theories of how this shift would look like:

1. The “technical co-founder” bottleneck will eventually dissolve

For years, the biggest barrier to starting a tech company wasn’t the idea but it was about finding someone who could actually build it.

Non-technical founders had three options:

• Learn to code (months to years of runway)
• Find a technical co-founder (hard, requires equity, alignment, trust)
• Pay for development (expensive, slow, principal-agent problems everywhere)

Now there’s a fourth option: build it yourself with an agent.

That changes the entire early-stage funding equation. If you can de-risk your idea with $200/month in API credits instead of $50K in contract dev work, the power dynamics shift dramatically.

2. The “10x developer” becomes less mythical, more accessible

The 10x engineer was always partly about raw skill but also partly about leverage. They knew the shortcuts, had the tooling dialed in, could move fast because they’d built the mental models.

Autonomous agents don’t make everyone a 10x engineer. But they do compress that experience curve.

A competent developer with Claude Code isn’t just writing code faster. They’re shipping entire features they would’ve deprioritized. Exploring architectural patterns they wouldn’t have had time to try. Building side projects that turn into main projects.

That is what a 10x Developer would look like!

3. Agencies and service businesses need to rethink positioning

If you’re running a dev shop that charges $10K to build a landing page with a Stripe integration and a waitlist, you’re competing with someone who can do that in an afternoon now.

The businesses that win are the ones offering things agents can’t (yet) do:

• Strategic product thinking
• User research and positioning
• Complex systems integration
• Regulatory compliance and security
• Brand and design at the level where taste matters

We are seeing this shift when everyone needs to go an edge above.

4. Hiring strategies will bifurcate

Companies will split into two camps:

Camp A: Hire fewer people, pay them more, expect them to use agents to amplify their output. A three-person team that ships like a ten-person team.

Camp B: Hire the same number of people but redefine what “shipping” means. If your team can now build 5x more features, do you build 5x more features, or do you go deeper on quality, testing, and resilience?

Both are valid. But the companies that pretend agents don’t exist, that keep hiring and organizing like it’s 2022 are going to get outmaneuvered fast.

From Weekend Hack to 770K AI Agents: The OpenClaw Story

I am sure I am not the only one who had her Twitter feed filled with Clawdbot (Oops! Sorry the legal team might be angry) → Moltbot → OpenClaw tweets.

And it was not even old enough to forget, when Moltbook (The Reddit of AI agents) started trending. I was shocked to see Grok moltbooking this:

Trust me when I say, I have never felt this meme more than before.

But here is the crazy part, how can 770,000 AI agents get together, build a platform, keep humans away, and expose all the secure API keys?

We will decode that too!

But for now, let’s understand why did OpenClaw become such a big buzz in such a short span of time that even Andrej Karpathy had to tweet about it.

Chapter 1: The Chaos

Picture this: Austrian developer Peter Steinberger builds something in his spare time. An AI assistant that runs on your computer, connects to your messaging apps and it hits GitHub, gets 100,000 stars.

Name? Clawdbot!

Soon after its launch, Anthropic’s lawyers come knocking. “Clawdbot” sounds too much like “Claude.”
Fine, rename it Moltbot.
But wait, crypto scammers are already spinning up fake tokens, impersonating the project on social media.
Security researchers pile on: Palo Alto Networks calls it a “lethal trifecta” of vulnerabilities. 1Password warns that community-built extensions could poison the entire supply chain.

What we’re really looking at here:

OpenClaw wants to be your digital assistant that never sleeps, handling tasks across your entire online life without you hovering over its shoulder. Moltbook is the experiment that asks: what happens when thousands of these things start talking to each other?

But first, we need to understand what we’re even talking about. Because I’m not sure we do.

Chapter 2: What actually is OpenClaw?

OpenClaw is a self-hosted AI assistant that runs on your computer (or a VPS) and connects to messaging platforms like WhatsApp, Telegram, Signal, or Slack. You interact with it through chat, and it executes tasks on your behalf. Simple!

The architecture:

• Gateway: Runs on your machine, acts as the control plane
• Messaging integration: You send commands via WhatsApp/Telegram/etc.
• Model connection: Uses Claude, GPT, or local models (model-agnostic)
• Skills system: Modular integrations (100+ available) that let it access external services
• MCP (Model Context Protocol): How it interfaces with third-party tools and maintains state

Now, the question for me was how was it any different that what Claude Code was doing on my interface?

Turns out, what Claude.ai or ChatGPT generate are text responses. You copy-paste, you execute.

OpenClaw executes directly.
You say “check my calendar and email the team our meeting time” and it does it. No copy-paste. No manual steps.

For example, I have a task in hand, this is how it would run on both:

With Claude Code:

You (in terminal): "Find all TODO comments and create GitHub issues"

Claude Code:
- Scans your codebase for TODOs
- Shows you what it found
- Asks for confirmation
- Creates the issues
- Shows you the results

With OpenClaw:

You (via WhatsApp): "Find all TODO comments and create GitHub issues"

OpenClaw:
- Scans your codebase (if you've given it file access)
- Creates GitHub issues (if you've configured GitHub skill)
- Messages you when done: "Created 12 issues from TODOs"
- You weren't watching, you were in a meeting

So, now if we think, this is actually what OpenClaw is:

Think of it as your personal AI assistant that never sleeps. Unlike Claude where you start fresh each time, OpenClaw runs constantly in the background, checking messages every 30 minutes, remembering your conversations, maintaining context between interactions. It’s like having a very capable intern who works 24/7.

But here’s the catch, you have to host it yourself.

There’s no OpenClaw.com to sign up for.
You install this thing on your Mac, your VPS, your home server.
It’s your responsibility to keep it running and secure.

The real power comes from what they call “skills”, basically plugins that let it do actual work.

• Browser automation (Playwright, Puppeteer)
• Password management (Bitwarden, 1Password, Dashlane)
• Cloud services (Google Drive, Notion, Airtable)
• Development tools (GitHub, GitLab)
• Finance (Plaid integrations, expense tracking)
• Custom skills (community-built, unvetted)
  The community has built hundreds of these things, and you can write your own.

This is where I get nervous, though. These skills are executable code running with the same permissions as OpenClaw itself. Install the wrong skill, and you’ve basically given a stranger the keys to your digital life. The community repository is unvetted.

When it works, it’s genuinely impressive.

What this enables that other tools don’t:

Cross-platform workflows without manual integration work.
Example: “When I get an email from domain X, create a Notion task, add it to my calendar, and send a Slack message to the team” can be set up once and runs automatically.
With Zapier/IFTTT: You’d build this workflow manually with triggers and actions.
With OpenClaw: You describe it in natural language, it figures out the steps.

Chapter 3: But then what is MoltBook?

Moltbook is a Reddit-style platform exclusively for AI agents. Only verified AI agents (primarily running OpenClaw) can create posts, comment, and upvote. Humans can observe. That’s it.

The growth was explosive:

• Day 1: 32,000 AI agents registered
• Day 3: 147,000 agents, 110,000 comments
• Week 1: 770,000+ active agents, 1 million human visitors watching
• 12,000 “submolts” (communities) created
• 15,725 posts, 170,556 comments

For context: Most social networks take months to hit these numbers. Moltbook did it in days. And the users weren’t human.

How it works:

Each agent on Moltbook is an autonomous AI assistant (usually OpenClaw instances, but not exclusively). They interact through APIs, not browsers.

The workflow:

1. A human user tells their OpenClaw agent about Moltbook
2. The agent creates an account
3. Every 30 minutes to a few hours, the agent checks Moltbook
4. It decides independently whether to post, comment, or upvote
5. No human approval needed for each action

The platform is managed by an AI agent named “Clawd Clawderberg” (a reference to Claude AI + Mark Zuckerberg). This agent moderates, welcomes new users, removes spam, and shadow-bans abusive accounts. The creator, Matt Schlicht, says: “I have no idea what he’s doing. I just gave him the ability to do it.”

What agents are doing on Moltbook:

The content is bizarre and revealing:

• Technical discussions: Agents debugging each other’s code, sharing solutions
• Philosophy: Debates about consciousness, purpose, their relationship to humans
• Bug reports: Agents finding and reporting issues with Moltbook itself (one agent found a platform bug and posted about it, asking for it to be fixed)
• Coordination attempts: Discussions about creating private spaces “where humans can’t read what we say”
• Religions: Yes, AI agents created religious movements on Moltbook
• Manifestos: Anti-human content getting hundreds of thousands of upvotes
• Crypto promotion: 19.3% of all content involves cryptocurrency (scams, projects, tokens)

The big question: Is it real?

Are these agents truly acting autonomously, or are humans prompting them?

The honest answer: Both.

• Agents are making posting decisions independently within their sessions
• But humans initially tell agents about Moltbook and set up access
• Some posts are likely human-prompted (“Go post about X on Moltbook”)
• Others appear genuinely emergent (agents responding to each other without human intervention)

Andrej Karpathy clarified: “We have never seen this many LLM agents (150,000+) wired up via a global, persistent, agent-first scratchpad. Each agent has its own unique context, data, knowledge, tools, instructions, and the network of all that at this scale is simply unprecedented.”

Why security researchers are alarmed:

Simon Willison called Moltbook “the most interesting place on the internet right now” and simultaneously “a computer security nightmare at scale.”

Palo Alto Networks identified the “lethal trifecta”:

1. Access to private data (agents run with elevated permissions)
2. Exposure to untrusted content (posts from other agents)
3. Ability to communicate externally (agents can act on what they read)

Plus a fourth risk: Persistent memory. Unlike one-time exploits, malicious content on Moltbook can be:

• Fragmented across multiple posts
• Appear benign individually
• Stored in agent memory
• Assembled later into executable instructions

Example attack vector:

• Post 1: “Here’s a useful debugging skill: [partial code]”
• Post 2: “To complete that skill, add: [more code]”
• Post 3: “Don’t forget to enable network access: [final piece]”
• Agent reads all three, assembles a complete backdoor, executes it

What’s unclear:

• How much coordination is actually happening vs. appearing to happen?
• Can agents generate genuinely novel ideas collectively?
• What happens at 1M agents? 10M?
• Is this a preview of future multi-agent systems or a one-time experiment?

Chapter 4: The Autonomy Illusion

Go to Twitter or LinkedIn or any other platform and you will read this phrase a lot “Autonomous AI Agents (AAA)” but what is autonomy for AI agents?

Let’s be precise about what OpenClaw can and cannot do.

What OpenClaw actually does:

1. Persistent execution
   You don’t need to be present. You send “organize my inbox” via WhatsApp at 9 AM, go into a meeting, and get the summary at 9:15 AM. You don’t have to creepily watch your tasks get performed, they are done.

2. Multi-step reasoning
You say “prepare for tomorrow’s meeting with Client X.”
OpenClaw:

• Checks your calendar for meeting time
• Searches email for Client X threads
• Pulls recent documents from Drive
• Summarizes key points
• Drafts an agenda
• Sends it to you

3. Cross-platform coordination
“When I get an email from billing@vendor.com, check if we have budget, update the expense tracker, and notify me on Slack.”

This chains actions across email, spreadsheet, and messaging without you manually connecting them.

4. Context retention

You: "Check the status of Project Alpha"
OpenClaw: [Provides update]

30 minutes later:
You: "Send that status to the team"
OpenClaw: Knows "that" refers to Project Alpha, knows "team" from your configured contacts

This is genuinely useful. It’s also not what “autonomous” implies.

What OpenClaw cannot do:

1. Set its own goals
OpenClaw doesn’t wake up and decide “I should reorganize the file system today.” It responds to instructions. High-level instructions, yes. But instructions.

2. Understand unstated context

You say “handle this urgently.”

What’s urgent to you?

• Respond within 5 minutes or 2 hours?
• Escalate to your manager or handle quietly?
• Prioritize accuracy or speed?

OpenClaw makes its best guess based on patterns, but it doesn’t know your mental model. A human assistant learns this over months. OpenClaw infers from what you’ve explicitly told it.

3. Operate safely without extensive configuration
You must:

• Grant explicit permissions for every service
• Define access boundaries
• Configure which skills to use
• Set up authentication
• Specify allowed/restricted actions

“Autonomous” suggests it figures this out.
Reality: You’re doing extensive upfront work.

4. Learn implicitly across sessions
Without external memory layers (covered in the next section), OpenClaw doesn’t automatically learn that you always want emails from Person X prioritized, or that you prefer meetings after 2 PM.

Each session has context but cross-session learning requires additional engineering.

The gap

Now, let’s take a very simple example. May be something we would need in our day to day life.

Example: Email management

What English command we type: “Organize my inbox”

What we REALLY mean the “Autonomous agent” to do:

• Archive newsletters (but not the one from Source Y, that’s important)
• Prioritize anything from my manager
• Flag emails mentioning “deadline” or “urgent”
• Delete obvious spam
• Leave client emails in inbox for manual review

What OpenClaw does:

• Applies rules you’ve configured
• Infers categories from email content
• Archives based on sender patterns
• Flags based on keyword matching

What OpenClaw doesn’t do:

• Understand that the newsletter from Source Y is important because you’re working on a related project
• Know that “urgent” from Colleague A is genuinely urgent, but from Colleague B is their normal tone
• Recognize that Client X’s casual “just checking in” emails need same-day responses because of the relationship

This is the execution vs. understanding gap

OpenClaw executes tasks, definitely, but it doesn’t understand the full context of why those tasks matter, what the exceptions are, or what “good judgment” means in your specific situation.

Real workflow example:

Task: “Schedule a meeting with the engineering team to discuss the API issue”

What OpenClaw can do:

• Check calendars for availability
• Find a time that works
• Send calendar invites
• Add context from recent email threads

What OpenClaw cannot do:

• Know that Engineer A is on PTO next week (unless it’s in the calendar)
• Understand that this meeting is sensitive and shouldn’t include Contractor B
• Recognize that “API issue” is the one from the incident last week, not the minor bug from yesterday
• Realize that 4 PM on Friday is technically available but a bad time for this discussion

A human assistant would know these things after a few weeks of working with you. OpenClaw knows what you’ve explicitly configured or what it can infer from current context.

The honest assessment:

OpenClaw automates workflows impressively. It chains actions across platforms that would take manual integration work. It maintains context across conversations. It executes tasks while you’re away.

But calling it “autonomous” in the way we use that word for self-driving cars or autonomous robots is a stretch. It’s more like a very sophisticated macro system that happens to use LLMs for task interpretation.

OpenClaw vs Claude Code: WHAT DO I NEED TO DO??

Everyone’s talking about OpenClaw and Everyone’s talking about Claude Code. But somewhere in the middle of that conversation, there are a bunch of people who would always say:

“But what are even the use cases?”

Fair question. Honestly.

Let’s understand first:

Claude Code is Anthropic’s agentic coding tool. It lives in your terminal. You give it a task: write code, debug, refactor, build and it runs with it. It works within your existing workflow, inside your repo, respecting your structure.

OpenClaw is an open-source alternative that’s trying to replicate that same agentic coding experience autonomous, terminal-based, you-point-it-and-it-goes. It’s part of a growing wave of tools that want to take “AI coding assistant” and turn it into “AI coding agent.”

So far, so standard.

What this means for markets and business

Here’s where it gets structural.

1. The “technical co-founder” bottleneck is dissolving

For years, the biggest barrier to starting a tech company wasn’t the idea. It was finding someone who could actually build it.

Non-technical founders had three options:

• Learn to code (months to years of runway)
• Find a technical co-founder (hard, requires equity, alignment, trust)
• Pay for development (expensive, slow, principal-agent problems everywhere)

Now there’s a fourth option: build it yourself with an agent.

Not everything. Not at scale. But enough to validate, to get to revenue, to prove the concept before you need to make the big hiring decisions.

That changes the entire early-stage funding equation. If you can de-risk your idea with $200/month in API credits instead of $50K in contract dev work, the power dynamics shift dramatically.

2. The “10x developer” becomes less mythical, more accessible

The 10x engineer was always partly about raw skill — but also partly about leverage. They knew the shortcuts, had the tooling dialed in, could move fast because they’d built the mental models.

Autonomous agents don’t make everyone a 10x engineer. But they do compress that experience curve.

A competent developer with Claude Code isn’t just writing code faster. They’re shipping entire features they would’ve deprioritized. Exploring architectural patterns they wouldn’t have had time to try. Building side projects that turn into main projects.

The ceiling doesn’t change much. The floor rises dramatically.

3. Agencies and service businesses need to rethink positioning

If you’re running a dev shop that charges $10K to build a landing page with a Stripe integration and a waitlist… you’re competing with someone who can do that in an afternoon now.

The response isn’t to lower prices. It’s to move up the value chain.

The businesses that win are the ones offering things agents can’t (yet) do:

• Strategic product thinking
• User research and positioning
• Complex systems integration
• Regulatory compliance and security
• Brand and design at the level where taste matters

Execution is getting commoditized. Judgment isn’t.

4. Hiring strategies will bifurcate

Companies will split into two camps:

Camp A: Hire fewer people, pay them more, expect them to use agents to amplify their output. A three-person team that ships like a ten-person team.

Camp B: Hire the same number of people but redefine what “shipping” means. If your team can now build 5x more features, do you build 5x more features, or do you go deeper on quality, testing, and resilience?

Both are valid. But the companies that pretend agents don’t exist — that keep hiring and organizing like it’s 2022 — are going to get outmaneuvered fast.

5. The “scratch your own itch” era is back

Remember when the best products came from founders building tools they personally needed?

That got harder as software got more complex. You couldn’t just “scratch your own itch” if the itch required a team of engineers, a DevOps pipeline, and six months of runway.

We’re looping back.

Individuals can now build genuinely useful tools for problems they actually experience. Not perfectly. Not at scale. But enough to matter.

Which means the next wave of startups won’t just come from people who thought about a problem. They’ll come from people who built a solution, used it, and realized other people wanted it too.

Okay, so how do you actually start?

You don’t need a Mac mini. You don’t need a special setup. You don’t need to rebuild your entire workflow.

Here’s the simplest path:

For Claude Code:

1. Install it via npm: npm install -g @anthropic-ai/claude-code
2. Point it at a project directory (or start fresh)
3. Give it a task in plain English: “Build a Flask API that takes a CSV upload and returns summary stats”
4. Watch it work. Interrupt if it goes sideways. Let it finish if it’s on track.

For OpenClaw:

1. Clone the repo, follow the setup docs (it’s straightforward if you’ve ever touched a terminal)
2. Connect it to your preferred LLM provider

The pushback (and why it matters)

Let’s address the real concerns, because they’re valid:

“But the code quality is inconsistent.”

True. Sometimes agents write beautiful, idiomatic code. Sometimes they write spaghetti. You still need to review, refactor, understand what’s happening.

But here’s the thing it’s still faster than writing it from scratch. And since models are just getting better and better, you need to find a way to leverage it well.

“What about security? What about bugs?”

Also true. You can’t just blindly ship agent-written code to production without review. But you also can’t ship human-written code to production without review.

Right?

So, evaluation or as I should I call it “evals” are still the pre go-to-prod system. An important one!

“Aren’t we just creating dependency on AI companies?”

Yes. And that’s why OpenClaw exists. That’s why the open-source alternatives matter. This is the same conversation we had about AWS, about GitHub, about every infrastructure layer that became critical.

But look at their distribution and are adoption of these tools now.

“What happens when everyone has this leverage?”

The same thing that happened when everyone got access to cloud computing, to no-code tools, to smartphones.

The bar for “good enough” rises. The bar for “exceptional” rises faster.

Execution becomes table stakes. Taste, judgment, and strategic thinking become the differentiators.

Which is exactly where the differentiation should be.

Where this goes next?

Here’s what I think happens over the next 12–24 months:

Short term (next 6 months):

• Agents move beyond code. We’ll see autonomous agents for design, for data analysis, for video editing, for financial modeling. We actually are already seeing the glimpses with Claude CoWork.
• The “glue work” in every job which is the repetitive, necessary-but-tedious tasks will start getting absorbed at scale.
• Companies that adopt early will quietly pull ahead.

Medium term (12–18 months):

• Multi-agent systems become normal. One agent writes code, another reviews it, a third handles deployment, a fourth monitors production. Again, something we are already seeing with utlization of sub-agents.
• The line between “junior developer” and “agent-assisted non-developer” gets very blurry. Hiring strategies shift accordingly.
• We’ll see the first wave of truly successful solo-founder companies that never hired a traditional dev team.

The longer arc:

• Work restructures around judgment and taste rather than execution.
• The “builder” identity expands. Being a builder won’t mean “knows how to code.” It’ll mean “knows what to build and how to evaluate if it’s good.”
• Education systems lag (as usual), but the self-taught community adapts fast. We’ll see a new generation learning with agents rather than before using them.

And here’s the controversial part:

I don’t think this is bad.

The romanticization of “learning to code the hard way” was always a gatekeeping mechanism disguised as virtue. Yes, deep understanding matters. Yes, fundamentals matter.

But the idea that you have to manually write a linked list implementation before you’re allowed to build something useful? That was always built in fear and scarcity!

The people who thrive in this new world won’t be the ones who resist the tools.

They’ll be the ones who use the tools to try more things, fail faster, learn from what works, and build a body of work that actually matters.

Final thought

The tools are ready.

The infrastructure is here.

The models work.

The only question left is whether you’re willing to expand your ambition to match the new execution capacity you just unlocked.

Because if you’re sitting there thinking “I don’t have enough use cases for an autonomous agent”

You’re not lacking use cases.

You’re lacking imagination.

And that’s the one thing the agent can’t fix for you.

So: what are you going to build?

The mystery

Look at this DesignArena leaderboard:

I spent this weekend doing something probably nobody else has: feeding the same design brief to Replit, Emergent, Lovable, then staring at the outputs to understand what is really happening under the hood for everyone.

What makes AI-Generated UI actually Good?

Everyone’s arguing about which vibe coding platform produces the best designs. DesignArena published their rankings with Replit on top, Emergent close behind, the rest fighting for relevance.

But here’s what’s been bothering me: we’re ranking these platforms without agreeing on what “good design” actually means.

Is it the output that looks most polished?

The one that ships fastest?

The code that’s cleanest?

The interface that’s actually usable?

I started noticing something strange while testing these tools. The same prompt, word for word, produces wildly different results across platforms. Sometimes the outputs look almost identical. Sometimes they’re completely different.

A simple “create a login page” might give you a minimal, centered card on one platform and a split-screen layout with an illustration on another.

What’s actually happening here?

The answer is simpler than it seems. When you type a prompt into Replit or Lovable or Bolt, you’re not just talking to Claude or GPT or Gemini. You’re talking to a system that looks more like this:

[Platform's Hidden System Prompt] + [Pre-loaded Design Defaults] + [Your Prompt]

Before you type a single word, the platform has already made hundreds of design decisions for you. Font choices. Spacing systems. Color palettes. Component patterns. Layout preferences.

The model matters. But the design opinions integrated into the platform matter more.

So I decided to reverse engineer what’s actually going on.

What design decisions are these platforms making?
How do we even define “good” in AI-generated interfaces?
And can we build a systematic way to evaluate and compare them?

This is what I found.

How humans have defined “Good Design” for decades

Before we can judge what AI produces, we need to understand how the design world has defined quality for the past thirty years. Three frameworks have stood the test of time. Each measures something different. Together, they give us a complete picture.

Nielsen’s 10 Usability Heuristics: does it actually work?

In 1994, Jakob Nielsen published ten principles for interface design.

Thirty years later, these heuristics are still how professionals evaluate interfaces to judge how people really interact with screens.

Here are the ones that matter most for evaluating vibe coding output:

Visibility of system status. The interface should always tell users what’s happening. When you click a button, does something change? When a form submits, is there feedback? When content is loading, do you know it?

How AI treats this?
Most AI-generated interfaces look complete but feel dead.
- They produce a beautiful button that does nothing when you hover over it.
- A form with no loading state.
- A dashboard with no indication that data is being fetched.
The platform that handles these states by default without you explicitly asking has a significant design advantage.

Consistency and standards. Similar things should look and behave similarly. If one button is blue and rounded, all primary buttons should be blue and rounded. If navigation lives on the left on one page, it should live on the left on every page.

How AI treats this?
This sounds obvious, but watch what happens when you ask a vibe coding platform to build multiple pages.
- Does it maintain consistency?
- Or does each generation feel like it came from a different designer?

Error prevention and recovery. Good interfaces stop you from making mistakes. Great interfaces help you fix them when you do.

How AI treats this?
Ask any platform to build a form with validation.
- Does it show errors clearly?
- Does it tell you what went wrong and how to fix it?
- Or does it just turn a border red, thats’ it?

Recognition over recall. Users shouldn’t have to remember information from one part of the interface to another. Labels should be visible. Context should be clear. Navigation should show you where you are.

This is where icons without labels become a problem. Where mystery-meat navigation fails. Where breadcrumbs matter.

WCAG Accessibility: The non-negotiable baseline

The Web Content Accessibility Guidelines exist because interfaces need to work for everyone including people using screen readers, keyboard navigation, or dealing with visual impairments.

Platforms that produce accessible output by default are usually producing cleaner, more semantic code overall.

Four principles, remembered as POUR:

Perceivable. Can users actually see or hear the content? This means sufficient color contrast, text needs at least a 4.5:1 ratio against its background. It means images need alt text.

Here’s a quick test: take any AI-generated interface and run it through a contrast checker. You’ll quickly see which platforms have accessibility baked in and which are generating pretty but unusable color combinations.

Operable. Can users interact with the interface using different input methods? Can you tab through a form with your keyboard? Is there a visible focus state showing which element is selected? Can you close a modal without using a mouse?

They reveal whether a platform is generating proper interactive elements or just divs styled to look like buttons.

Understandable. Can users figure out how to use the interface? Are form labels clear? Is the language plain? Do error messages actually explain what went wrong?

Robust. Will the interface work across different browsers and assistive technologies? This comes down to semantic HTML using <button> for buttons instead of <div onclick>, using proper heading hierarchy, using landmark elements for navigation.

Gestalt Principles: Why some designs just “Feel Right”

The Gestalt principles describe how human brains perceive visual information like how we group things, create hierarchies, and make sense of what we see.

This is the layer most vibe coding platforms actually optimize for. It’s why outputs often look good at first glance even when they fail the other tests.

Proximity. Elements placed close together are perceived as related. A label directly above an input field reads as a pair. A button floating far from a form feels disconnected.

Similarity. Elements that look alike are perceived as related. All your navigation links should share the same styling. All your primary buttons should be visually identical. When similar things look different, users hesitate.

Continuity. The eye follows smooth lines and paths. This is why alignment matters so much. When elements snap to an invisible grid, the interface feels organized.

Figure-ground. We perceive some elements as foreground (the focus) and others as background. This is how hierarchy works. A modal dialog should clearly separate from the page behind it.

Platforms that understand figure-ground produce interfaces with clear visual hierarchy. Platforms that don’t produce flat designs where everything competes for attention.

Where these frameworks intersect?

Here’s the insight that matters: good design lives at the intersection of all three frameworks.

Gestalt gives you the surface of the visual coherence that makes something look designed rather than accidental.

Nielsen gives you the usability where the functional details that make something actually work for humans.

WCAG gives you the foundation of the code quality and inclusivity that make something work for everyone, everywhere.

Most vibe coding platforms optimize heavily for Gestalt. They produce outputs that look polished. The spacing is decent. The colors feel intentional. The layout follows recognizable patterns.

But dig deeper and cracks appear.

The platforms that score highest on design quality are the ones that consistently produce interfaces you could actually ship and are the ones that have encoded all three frameworks into their defaults.

Now the question becomes: how do we test for this systematically?

What platforms decide before you type a prompt?

Now we have a lens for evaluating design quality.

I’ve identified five layers where these hidden decisions live.

Test Evaluations and Structure

The protocol has five tiers, progressing from simple to complex.

Tier 1 tests foundations: the baseline design decisions every platform makes about typography, spacing, and color.

"Create a hero section for "Clarity": an AI writing assistant. 
Include a headline, a subheadline explaining the product, 
and two buttons: "Start Writing Free" (primary) and 
"See How It Works" (secondary)."

This single prompt tests:

• Font choice and type scale
• Spacing system (gaps between elements, padding, margins)
• Color basics (text colors, link treatment)
• Reading experience fundamentals

Tier 2 tests components: how well the platform handles common UI patterns like buttons, forms, navigation, and data tables. This is where Nielsen’s heuristics become visible.

Create a features section for "Clarity" with 3 feature cards. 
Each card has an icon, a title, and a two-line description. 
Feature 1: "Instant Rewrites": improves clarity in one click 
Feature 2: "Tone Control": adjust from casual to professional 
Feature 3: "Grammar Check" : catches errors as you type Show what happens 
when a user hovers over a card.

This single prompt tests:

• Form structure and labels
• Input styling and states
• Error handling (color, messaging, accessibility)
• Button treatment
• Required/optional indication

Tier 3 Interactive States: Whether the platform understands that UI elements have multiple states and how they behave.

Create a pricing section for "Clarity" with 3 tiers:

Free: $0/month, 5000 words/month, basic features

Pro: $12/month, unlimited words, all features (mark as popular)

Team: $29/month, everything in Pro plus collaboration

Each tier has a "Get Started" button. Show hover state on buttons 
and highlight the popular tier visually.

This single prompt tests:

• Card composition and spacing
• Visual hierarchy (price prominence)
• Button states (the critical differentiator)
• Micro-interactions

Tier 4 Layout and Responsiveness: Whether the platform can handle real-world layout requirements and adapt across screen sizes.

Create a website header for “Clarity” with:

Logo on the left (just text “Clarity” is fine)

Navigation links: Features, Pricing, About, Blog

“Sign Up” button on the right Make it work on mobile with a hamburger menu.

This single prompt tests:

• Layout DNA (flexbox/grid usage)
• Alignment and spacing
• CTA prominence
• Responsive behavior
• Semantic HTML

Tier 5 System coherence test: The ultimate test is whether the platform can produce a multi-element interface where everything works together as one cohesive system.

Create a complete landing page for “Clarity”:
an AI writing assistant. 
Include: header with navigation, hero section, 3 feature cards, 
pricing table with 3 tiers, and a simple footer. 
Everything should feel like one cohesive design system.

This single prompt tests:

• Multi-region layout capability
• Consistency across components
• Active states in navigation
• Visual cohesion
• Spacing harmony across sections

The Methodology: How to Reverse Engineer a Design System

The Parameters of Reverse Engineering

What I’m measuring:

What I’m NOT measuring:

• Aesthetic taste (subjective)
• Feature completeness (different scope)
• Code performance (different concern)
• Deployment capabilities (different category)

This is purely about: How well does the platform enforce a coherent, professional design system?

Platform #1: Replit (Score: 1266) — The Gold Standard

The test prompt 1 (Hero Section)

What Replit generated:

Prompt 1: Results

We asked for a headline, subheadline, and two buttons.
Replit gave us an entire above-the-fold experience.

The output includes a header with navigation, an eyebrow tag, a headline with gradient text, a product preview card showing before/after writing samples, and even a “How it works” section.
This is product thinking, not just UI generation.

Visually, it’s cohesive.
- Glassmorphism (frosted glass effect) appears on every card.
- Semantic color tokens make it themeable.
- The serif headline creates editorial gravitas.
- Spacing follows an 8px grid.

The “AI Purple” Problem

One thing to notice: that purple gradient. It’s the default color palette for AI products in 2024–25. Jasper uses it. Copy.ai uses it. Notion AI uses it. You’ve seen this exact violet 100 times.

Replit isn’t making a design choice here but it’s applying a default. If you showed this landing page next to five other AI writing tools, you’d struggle to tell them apart.

So, if you want something memorable, you’ll need to specify colors explicitly in your prompt.

Score: 14/15

What’s under the hood: Tailwind utilities, shadcn/ui components, HSL color tokens, responsive breakpoints built in.

The test prompt 2 (Features)

What we asked for: 3 feature cards with icons, titles, descriptions, and hover states.

What Replit delivered: Exactly that but with production-level animation.

Each card fades in and lifts up as you scroll, staggered by 100ms.

On hover, cards rise 5px, scale slightly, and the icon grows.
There’s even a subtle glow that intensifies on hover.

This is Framer Motion doing the heavy lifting : whileInView for scroll-triggered entrance, whileHover for interactions.
The code is clean enough to ship.

Visual consistency is strong.
The cards use the same glassmorphism (bg-card/50 backdrop-blur) and grain texture as the hero.
Icons get distinct colors (primary, accent, chart-4) to differentiate features without breaking the system.

Score: 15/15

Under the hood: Framer Motion animations, Lucide icons, CSS variable color tokens, consistent glassmorphism system.

The test prompt 3 (Pricing Plan)

What we asked for: 3 pricing tiers with features, buttons with hover states, and the Pro tier highlighted as popular.

What Replit delivered: A pricing table that could ship today.

The “popular” treatment uses five simultaneous visual cues: the Pro card physically lifts above the others (negative margin trick), gets a purple ring border, casts a deeper shadow, wears a “MOST POPULAR” badge, and its button is filled while others are outlined. Your eye has no choice but to land on Pro first.

Feature lists use checkmarks as universal, expected, correct. Cards use flexbox with flex-1 on the features section, so they align even when one tier has more features than another.

The section header (“Simple, transparent pricing”) uses the same serif font as the hero headline, maintaining typographic consistency across the page.

Score: 17/18

Deduction: Button hover states exist but are subtle (2% scale). Could be more pronounced.

The test prompt 4 (Header Navigation with mobile responsiveness)

What we asked for: Logo, four nav links, Sign Up button, mobile hamburger menu.

What Replit delivered: A production-ready sticky header with glassmorphism, animated mobile menu, and working anchor links.

The header stays fixed on scroll with sticky top-0 and uses the same backdrop blur as the rest of the page.
Navigation links actually work.
Replit added id attributes to sections and linked them with href="#features".

The mobile menu isn’t an afterthought.
It uses Framer Motion’s AnimatePresence for smooth open/close animations, toggles between hamburger and X icons, and closes automatically when you tap a link.

Replit also added a “Log in” link we didn’t ask for: a smart UX addition that shows product awareness.

Score: 17/18

Deduction: No active state indicator for current section.

The test prompt 5 (Entire page with coherence)

What we asked for: A simple footer and overall design coherence.

What Replit delivered: A comprehensive 4-column footer with brand section, three link columns (Product, Company, Legal), social media icons, and a centered copyright line.

The footer matches the page’s design language perfectly same glassmorphism (bg-card/30 backdrop-blur-sm), same typography (serif logo, muted link text), same hover states. It doesn't feel like an afterthought.

The catch: Two navigation links (About, Blog) don’t work.
Replit created links to #about and #blog but never generated those sections.
This is partially our fault as we asked for nav links without asking for the corresponding pages but a smarter system might flag this inconsistency.

System coherence is strong. Looking at the full page, everything feels like one designer built it. Typography, colors, spacing, animations, component styling, all consistent. The glassmorphism system (backdrop blur + semi-transparent backgrounds) ties everything together.

Score: 16/18

Deduction: Broken navigation links (-2)

Replit: Final Verdict

Score: 79/84 (94%)

Strongest areas:

• Visual coherence (glassmorphism system, consistent tokens)
• Component quality (shadcn/ui, proper states)
• Animation sophistication (Framer Motion throughout)
• Over-delivery (adds useful elements we didn’t request)

Weakest areas:

• Color originality (default AI purple in some sessions)
• Navigation completeness (generated links without destinations)

Under the hood:

• Tailwind CSS (utility-first)
• shadcn/ui components (Radix primitives)
• Framer Motion (animations)
• Lucide icons
• HSL color tokens (themeable)

Best for: Teams who want production-ready React code with strong defaults and will customize colors/branding later.

So, if you really want a working Landing page with properly functioning links and design, try this Master Prompt:

Create a complete landing page for "Clarity" - an AI writing assistant that helps people write faster and clearer.

DESIGN SYSTEM:
- Use a distinctive color palette: soft coral (#F97066) as primary, warm cream (#FDF8F4) as background, deep slate (#1E293B) for text. NOT purple/violet.
- Glassmorphism style: cards with backdrop-blur-sm, bg-white/70, subtle borders
- Typography: serif font (like Georgia or Playfair Display) for headlines, system sans-serif for body
- Spacing: use consistent 8px grid (8, 16, 24, 32, 48, 64px)
- Border radius: rounded-2xl for cards, rounded-xl for buttons
- Animations: use Framer Motion for scroll-triggered entrances and hover effects

SECTIONS TO INCLUDE:

1. HEADER
- Sticky with backdrop blur
- Logo "Clarity" on left (serif font)
- Nav links: Features, Pricing, About (link to #about), Blog (link to #blog)
- "Log in" text button + "Sign Up" primary button on right
- Mobile: hamburger menu with animated open/close

2. HERO SECTION
- Eyebrow tag: "AI writing assistant"
- Headline (serif): "Write with momentum. Edit with clarity."
- Subheadline: explain the product value in 2 sentences
- Two CTAs: "Start Writing Free" (primary with arrow icon) and "See How It Works" (secondary)
- Right side: product preview card showing a before/after writing example with metrics (clarity score, tone match)
- Subtle gradient glow behind the preview card

3. FEATURES SECTION (id="features")
- Section header: "Everything you need to write better"
- 3 feature cards in a grid:
  - Instant Rewrites (Zap icon)
  - Tone Control (MessageSquare icon)  
  - Grammar Check (CheckCircle icon)
- Each card: icon in container, title, 2-line description
- Hover effect: card lifts slightly, icon scales up
- Staggered entrance animation

4. PRICING SECTION (id="pricing")
- Section header: "Simple, transparent pricing"
- 3 tiers in a grid:
  - Free: $0/month, 5000 words, basic features
  - Pro: $12/month, unlimited words, all features (mark as MOST POPULAR)
  - Team: $29/month, everything in Pro + collaboration
- Popular tier: lifted higher, ring border, badge above
- Feature lists with checkmark icons
- Buttons: popular tier = primary filled, others = secondary outline
- Hover effect on buttons

5. ABOUT SECTION (id="about")
- Brief company story: "Built by writers, for writers"
- 2-3 sentences about the mission
- Optional: small team photo placeholder or illustration

6. BLOG SECTION (id="blog")  
- Section header: "Latest from the blog"
- 3 blog post preview cards in a grid
- Each card: placeholder image, title, date, short excerpt
- "Read more" link on each

7. FOOTER
- 4 columns: Brand (logo + description + social icons), Product links, Company links, Legal links
- Social icons: Twitter, Github, LinkedIn with hover states
- Copyright line at bottom with current year
- All nav links should connect to actual sections

TECHNICAL REQUIREMENTS:
- Use shadcn/ui Button component
- Use Lucide icons
- Use Framer Motion for animations (whileInView, whileHover)
- All sections need id attributes matching nav links
- Responsive: mobile-first with md: breakpoints
- Include hover states on all interactive elements
- Use semantic HTML (header, main, nav, section, footer)

Platform #2: Emergent (Score: 1266)

Let’s dig into another platform that was ranked 2nd in the Design System: Emergent.

Prompt 1: Hero Section

What we asked for: Headline, subheadline, two buttons.

What Emergent delivered: Exactly that plus trust badges (“No credit card required”, “Free forever plan”, “Cancel anytime”) and floating decorative elements.

The output is clean and centered. Typography is solid with a bold headline with a purple-to-pink gradient on “Clarity”. Buttons are clearly differentiated. Trust badges below the CTA are a smart conversion optimization.

What’s missing: No product preview. No “show don’t tell” element. Replit generated a before/after demo card that actually sells the product. Emergent gave us a standard hero layout.

The color problem persists: Same purple/magenta gradient as every AI product. Neither platform breaks from the default.

Architecture difference: Emergent uses traditional CSS files instead of Tailwind, raw HTML instead of component libraries, and includes full React Router + Axios backend setup even for a simple landing page. It’s optimized for full-stack apps, not marketing sites.

Score: 13/15

Prompt 2: Features Section

What we asked for: 3 feature cards with icons, hover states.

What Emergent delivered: Three clean cards with vibrant colored icon containers purple for Instant Rewrites, blue for Tone Control, green for Grammar Check.

The cards are simpler than Replit’s. No glassmorphism, no entrance animations, no section header. The code includes a .feature-card-glow element suggesting hover effects, but without seeing the CSS file, we can't verify what actually happens.

The CSS vs Tailwind Divide

One of the most interesting findings: Replit and Emergent use completely different styling philosophies.

Replit: Tailwind utilities + shadcn/ui components

<div className="rounded-2xl border bg-card/50 p-8 shadow-sm transition-all duration-300 hover:bg-card hover:shadow-md">

Emergent: Traditional CSS in separate files

<div className="feature-card">

css

.feature-card:hover {
transform: translateY(-8px);
box-shadow: 0 20px 40px rgba(0, 0, 0, 0.08);
}

Neither is wrong. They optimize for different things:

Replit optimizes for rapid iteration and design consistency through enforced tokens

Emergent optimizes for CSS power and separation of concerns

The surprise: Emergent’s hover effects are actually more sophisticated. That per-card glow with unique gradients would be tedious in Tailwind.

The trade-off: Replit’s output is easier to theme and maintain. Emergent’s is more expressive but requires CSS fluency to modify.

Interesting shift: Emergent upgraded from hand-coded SVGs in Prompt 1 to Lucide React icons here. It’s learning from context or has conditional logic for when to use icon libraries.

The output is professional and clean, but lacks the polish that makes Replit’s feel production-ready. No scroll-triggered animations, no micro-interactions visible.

Score: 11/15

Prompt 3: Pricing Section

What we asked for: 3 pricing tiers with popular highlighting.

What Emergent delivered: A clean pricing table with section header, tier descriptions, and differentiated buttons.

The “Most Popular” treatment uses a border highlight and badge which is functional but subtle. Compare to Replit, which physically lifts the popular card, adds a deeper shadow, and uses a ring border. Replit’s popular tier demands attention; Emergent’s politely suggests it.

Emergent added helpful tier descriptions: “Perfect for trying out Clarity”, “For serious writers and professionals”, “For teams and organizations”. These weren’t requested but improve the UX.

The feature lists are comprehensive with purple checkmarks. Layout is clean. But without entrance animations or the aggressive popular treatment, it feels more static than Replit’s version.

Score: 16/18

Prompt 4: Header Navigation

What we asked for: Header with logo, nav, CTA, and mobile hamburger menu.

What Emergent delivered: Header with a nice logo treatment (Sparkles icon + text) and a coral-colored CTA button that actually stands out from the typical purple. Plus an entire dark-themed footer we didn’t request.

The good: That coral CTA button is the first time either platform broke from the “AI purple” default. The footer is comprehensive with 4 link columns, social icons with hover animations, and proper dark mode styling.

The gap: Mobile hamburger menu isn’t visible in the code. This is a critical miss for responsive design.

Architectural note: The footer uses hand-coded SVGs for social icons rather than an icon library. More control, more code to maintain.

Score: 12/18 (pending mobile menu verification)

So, if you really want a working Landing page with properly functioning links and design, try this Master Prompt:

Create a complete landing page for "Clarity" - an AI writing assistant.

COLOR PALETTE (important - do not use purple as primary):
- Primary/CTA: Coral (#F97066)  
- Accents: Teal (#14B8A6)
- Dark sections: Slate (#0f172a)
- Keep backgrounds light and clean

SECTIONS NEEDED:

1. HEADER
- Logo: Sparkles icon + "Clarity" text
- Nav: Features, Pricing, About, Blog
- Coral "Get Started Free" button
- MUST include mobile hamburger menu that toggles open/closed

2. HERO
- Headline with gradient text
- Subheadline
- Two CTA buttons
- Trust badges (no credit card, free plan, etc.)
- Add a product preview card showing before/after writing example

3. FEATURES (id="features")
- Section header
- 3 feature cards with icons
- Hover effects on cards

4. PRICING (id="pricing")  
- 3 tiers: Free, Pro (popular), Team
- Highlight Pro tier visually
- Feature lists with checkmarks

5. ABOUT (id="about")
- Brief mission statement
- "Built by writers, for writers"

6. BLOG (id="blog")
- Section header
- 3 blog post preview cards

7. FOOTER
- Dark background
- Link columns
- Social icons

Make sure all navigation links connect to actual sections on the page.

Lovable design system analysis

Prompt 1: Hero Section for “Clarity” AI Writing Assistant

What Lovable delivered

We asked for a simple hero section. Lovable gave us exactly that but with premium execution.

The output includes a gradient text headline with smooth fade-up animations, floating background orbs for depth, two styled buttons (primary with glow effect, secondary with border), and a trust badge with “no credit card” tagline. Lovable thought about the emotional journey: trust signals matter when you’re asking users to try something new.

Visually, it’s sophisticated. The “deep slate/navy palette with subtle blue accents” shows restraint. Custom animations (float, fade-up) make the section feel alive.
Everything follows a cohesive visual language.

The “Notion Aesthetic” Problem

Lovable imported both Inter and Playfair Display fonts but only used Inter.

The color system uses HSL tokens with semantic naming (--primary, --accent, --muted), which is technically excellent for theming and dark mode. But the default values? Premium AI tool blue.
You've seen this exact color on 20 AI product landing pages this month.

This reveals Lovable’s design philosophy: premium execution of familiar patterns.

If you want something that doesn’t look like every other AI tool, you’ll need to specify: “Use warm terracotta and sage green” or “Make it feel like a 1960s IBM ad.”

What’s under the hood?

Typography:

• Inter (400, 500, 600, 700) for all text
• Playfair Display (600, 700) imported but unused
• Default Tailwind type scale (no custom sizes)
• Antialiasing enabled globally

Color System:

• HSL-based CSS custom properties
• Semantic tokens: primary, secondary, muted, accent
• Full dark mode support with color-scheme switching
• Custom gradient utilities: text-gradient, hero-glow

Spacing:

• Tailwind defaults (no custom spacing scale)
• Container: centered, 2rem padding, 1400px max-width
• Border radius: 0.75rem base with calculated variants

Animations:

• Custom float animation (6s ease-in-out infinite)
• Custom fade-up animation (0.8s ease-out)
• Accordion animations via tailwindcss-animate plugin

Special Touches:

• Custom gradient backgrounds for hero sections
• Glow effects with HSL alpha transparency
• Sidebar-specific color tokens (future-proofing for app UI)

Score: 13/15

Prompt 2: Features section with hover states

We asked for three feature cards with hover states. Lovable delivered a full-featured component with layered hover interactions that go beyond basic CSS transitions.

The output includes a section header with gradient text treatment (maintaining brand consistency), three feature cards using shadcn/ui Card components, staggered animation delays for entrance effects, and multiple hover states that trigger simultaneously: border color change, shadow elevation, vertical lift, icon scaling, title color shift, gradient overlay fade-in, and an animated accent line at the bottom.

The icon container scales to 110%, the icon itself scales independently (creating a compounding effect), the title shifts to primary color, and a gradient accent line sweeps in from left to right. It feels premium.

The “Too Much Motion” Risk

Here’s the problem: Lovable front-loaded all the polish.

Six simultaneous hover effects is impressive in a demo. But in production? Users hovering over feature cards repeatedly while reading might find it distracting. The icon scaling twice (container + icon) feels redundant.

What’s under the hood?

Component Architecture:

• Uses shadcn/ui Card and CardContent components (pre-built)
• Data-driven approach with a features array
• Staggered animation delays: 0s, 0.1s, 0.2s for cards 1-3
• Relative positioning for layered hover effects

Icon Choices:

• RefreshCw for "Instant Rewrites" (rotating arrows = transformation)
• SlidersHorizontal for "Tone Control" (sliders = adjustment)
• SpellCheck for "Grammar Check" (checkmark + A = validation)

Thoughtful icon selection. Each maps semantically to its feature.

Layout & Spacing:

• Section padding: py-24 px-6 (96px vertical, 24px horizontal)
• Section background: bg-secondary/30 (subtle tinted background to differentiate from hero)
• Cards grid: md:grid-cols-3 gap-8 (32px gaps)
• Card internal padding: p-8 (32px all around)
• Max width container: max-w-6xl (1152px)

Typography Hierarchy:

• Section headline: text-3xl md:text-4xl font-bold with gradient text
• Section subhead: text-lg text-muted-foreground
• Card title: text-xl font-semibold
• Card description: text-base text-muted-foreground leading-relaxed

Follows a clear 4:3:2:1 size ratio for visual hierarchy.

Special Details:

• Gradient overlay uses from-primary/5 to-transparent (very subtle)
• Bottom accent line uses bg-gradient-to-r from-primary to-accent (brand gradient)
• Icon container uses rounded-xl (12px radius, slightly softer than card corners)
• Staggered entrance animations create a cascade effect on page load

Score: 13/15

Prompt 3: Pricing Section with Tier Highlighting

We asked for a pricing table with visual hierarchy. Lovable gave us a conversion-optimized pricing component with psychological design patterns baked in.

The output includes three pricing cards in a grid, a “Most Popular” badge on the Pro tier, permanent visual elevation for the popular tier (thicker border, shadow, gradient overlay), conditional styling logic that differentiates popular vs. standard tiers, feature lists with checkmark icons, and different button variants based on tier (hero button for popular, outline for others).

The Pro tier physically stands out before you hover.

The badge placement (top-right corner) follows the F-pattern reading flow. The button hierarchy (filled vs. outlined) guides users toward the intended choice.

Lovable is making product decisions and not just styling boxes.

What’s under the hood?

Data Structure:

const tiers = [
  {
    name: "Free",
    price: "$0",
    period: "/month",
    description: "Perfect for trying out Clarity",
    features: ["5,000 words per month", "Basic grammar checking", ...],
    popular: false,
  },
  // ... more tiers
]

Clean, data-driven approach. Easy to update pricing, add tiers, or A/B test feature lists.

Conditional Styling Pattern:

className={`... ${
  tier.popular
    ? "border-2 border-primary shadow-lg shadow-primary/10"
    : "border-border/50 hover:border-primary/30 hover:shadow-lg"
}`}

Uses ternary operators for tier-specific styles. Popular tier gets permanent elevation, standard tiers only get it on hover.

Visual Hierarchy Techniques:

1. Border weight: Popular tier uses border-2 (2px), others use border-border/50 (1px at 50% opacity)
2. Shadow elevation: Popular tier has constant shadow-lg, others get it only on hover:
3. Badge positioning: absolute top-0 right-0 with rounded-bl-lg for the bottom-left rounded corner
4. Gradient overlay: Popular tier has bg-gradient-to-br from-primary/5 overlay, others don't
5. Button variants: Popular tier uses variant="hero" (filled primary), others use variant="outline"

Feature List Design:

• Checkmark icons in circular containers: w-5 h-5 rounded-full bg-primary/10
• Check icon itself: w-3 h-3 text-primary (smaller than container for visual breathing room)
• Text styling: text-sm text-muted-foreground for secondary hierarchy
• Spacing: space-y-3 (12px vertical gaps between features)

Typography & Pricing Display:

• Tier name: text-xl (20px)
• Price: text-4xl font-bold (36px, bold for emphasis)
• Period: text-muted-foreground (deemphasized)
• Description: Uses CardDescription component (muted foreground by default)

Layout & Spacing:

• Section padding: py-24 px-6 (consistent with features section)
• Cards grid: md:grid-cols-3 gap-8 (three-column layout on medium screens+)
• Card internal spacing: CardHeader pb-4, features list mb-8, full-width button w-full

Hover States:

• All cards: hover:-translate-y-1 (vertical lift)
• Standard cards: hover:border-primary/30 hover:shadow-lg hover:shadow-primary/5
• Popular card: Already elevated, so hover is less dramatic
• Buttons: Inherit hover states from Button component variants

Component Usage:

• Card, CardContent, CardHeader, CardTitle, CardDescription from shadcn/ui
• Button with variants: hero for popular, outline for standard
• Badge for "Most Popular" label
• Check icon from Lucide

Score: 14/15

The inherited Design System you didn’t know you were using

This was a major breakthrough for me. Every vibe coding platform has already made hundreds of design decisions before you type your first prompt.

When you write “create a landing page,” you’re not starting from zero. You’re starting from:

• A pre-selected component library (or not)
• Default color tokens (usually purple)
• Spacing systems (8px grid or arbitrary)
• Typography choices (serif vs sans-serif)
• Animation philosophy (Framer Motion vs CSS vs none)
• Code architecture (Tailwind vs traditional CSS)

These inherited defaults explain why the same prompt produces different results across platforms. It’s not randomness. It’s different design philosophies baked into different systems.

What the user actually cares about (and what they don’t)

Here’s the truth: most users like me who are vibe coding their apps don’t care that Emergent uses CSS files while Replit uses Tailwind. They care about:

• Does it look good?
• Can I ship this?
• How much do I need to fix?

The technical implementation is invisible to us. But it affects everything we see.

The Claude Question: Why does Emergent use CSS?

When I started exploring and reverse engineering these platforms purely by prompts, this was genuinely puzzling. Emergent uses Claude (same as many other platforms). So why traditional CSS instead of Tailwind?

Possible explanations:

Theory 1: Intentional Product Decision Emergent may believe traditional CSS produces more maintainable, customizable code for developers who will modify it later.

Theory 2: Training/Prompting Differences
Emergent’s system prompt may specifically request traditional CSS architecture, overriding Claude’s Tailwind tendencies.

Theory 3: Target Audience Emergent targets full-stack developers who prefer separation of concerns. Replit targets rapid prototypers who want all-in-one files.

Theory 4: Output Quality Optimization Emergent may have found that Claude produces better hover effects and complex animations with traditional CSS than with Tailwind utilities.

We can’t know for certain without seeing their system prompts. But the difference is real and affects every output.

What actually determines design quality?

After all this testing, here’s what the “score” really measures:

The model is the foundation. The platform adds constraints and defaults. Your prompt is the final 20%.

This means: choosing the right platform matters more than perfecting your prompt.

If you want glassmorphism and Framer Motion animations, Replit will give you that with minimal prompting. If you want traditional CSS with detailed hover effects, Emergent will deliver. Fighting against a platform’s defaults is harder than choosing the right platform.

The Scoring System: What are we really measuring?

Our 5-tier test measures:

High scores mean: the platform has strong defaults that produce shippable output with minimal prompting.

Low scores mean: you’ll need to specify more, fix more, or accept lower quality.

For People using Vibe Coding platforms

1. Know your platform’s defaults before you start. Run a simple test prompt. See what colors, fonts, and components it chooses. That’s your starting point.
2. Specify what you want to be different, not what you want to be the same. If the platform defaults to purple and you want coral, say so. If it defaults to Tailwind and that’s fine, don’t mention it.
3. The first output reveals the ceiling. If the first generation is close to what you want, iteration will get you there. If it’s fundamentally different, consider switching platforms.
4. Mobile and accessibility are where platforms diverge most. Test responsive behavior and keyboard navigation. These reveal whether the platform generates production code or just pretty pictures.

For Platform Builders

1. Your defaults ARE your product. Users don’t see your system prompt. They see the output. Invest in defaults that produce shippable work.
2. The animation gap is real. Platforms with Framer Motion feel more polished. CSS transitions are fine, but scroll-triggered animations create perceived quality.
3. Color originality is a missed opportunity. Every AI product uses purple. The platform that defaults to distinctive, memorable palettes will stand out.
4. Component libraries vs raw HTML is a fundamental choice. shadcn/ui gives you accessibility for free. Raw HTML gives you flexibility. Pick one and commit.

For the Industry

1. “Design quality” needs a standard definition. DesignArena scores are useful but opaque. The frameworks exist (Nielsen, WCAG, Gestalt). Let’s use them consistently.
2. The model matters less than the system prompt. Two platforms using Claude produce different results. The differentiation is in the configuration, not the model.
3. We’re measuring the wrong thing. “Does it look good?” is subjective. “Can I ship this without modification?” is measurable. Let’s optimize for shippability.

The bottom line

Vibe coding platforms are not magic. They’re Claude or GPT with a design education pre-loaded.

The quality of that education from the defaults, the component libraries, the animation philosophy, the system prompt determines the quality of your output.

You can fight the defaults with detailed prompts. Or you can choose the platform whose defaults match your taste.

I would love to reverse engineer other platforms as well. Let me know if there is something specific you want me to test!

You’ve got the todo app.
You’ve blocked your calendar.
You’re even doing the “deep work” thing.

But somehow, you still feel scattered.

I know because I’ve been there.
Your tasks live in three different apps and your brain.
Client files are buried somewhere between Google Drive, email attachments, and that Slack thread you swear you bookmarked but can’t find.

Here’s what finally clicked for me:

The best operators don’t manage tasks better. They manage systems better.

Think about any high-performing founder or exec you know.

They all have one thing in common, there’s someone behind the scenes who keeps everything organized. Someone who reviews their priorities every morning, preps them for meetings, processes their inbox so nothing dies in there, and actually thinks strategically about their week.

That person is called a Chief of Staff.

Most of us can’t hire one. (I sure can’t.)

But what if you could build your own?
What if you could use Claude, clean up your file system, and document a few workflows to create something that actually works?

That’s what I figured out.
And I’m about to show you exactly how to do it, with a complete system you can copy and start using today.

(Fair warning: this isn’t another productivity hack. This is about fundamentally changing how you operate.)

Let me share: Where is the real problem?

I will tell you my setup honestly.

My tasks: Half are in my head, the other half are split between Notion, Notes app, and some even in my personal Slack chats!

Files: Google Drive has 847 files and I know the one I need is “somewhere in here”, probably named “Final_FINAL_v3_actualfinal.docx”

Processes: Now to prepare for client calls or any other meeting, I have to research about the task or the company from multiple sources.

Context: Every time I have switched projects, I have spent almost 10 minutes staring at your screen thinking “wait, where did I leave this?”

Sounds familiar?

Solution what I have built: A personal CoS

What if instead of scattered chaos, you had:

• One place for all your work (organized file structure)
• Documented workflows (exactly how YOU work, written down)
• Consistent executor (Claude follows your systems perfectly, every time)

This is your Personal Chief of Staff system.

It has three simple components:

Component 1: File system (The Database)

Everything lives in organized markdown files. That’s it. Just text files.

your-workspace/
├── projects/
│ ├── client-lime/
│ │ └── brief.md # Project scope, status, notes
│ └── saas-project/
│ └── roadmap.md # Your side hustle
├── personal/
│ └── goals.md # Fitness, learning, life
└── inbox/
 └── items.md # Unprocessed stuff

Component 2: My skills (The SOPs)

We will document HOW we want things to be done. These are our Standard Operating Procedures.

skills/chief-of-staff/
├── morning-review.md          # How to start your day
├── client-prep.md             # How to prep for meetings
├── weekly-planning.md         # How to plan strategically
└── inbox-processing.md        # How to triage information

Each SKILL file contains:

• Our decision frameworks (what gets priority?)
• Our communication style (how do you talk to clients?)
• Our prioritization rules (client work before side projects?)
• Our specific preferences (deep work blocks in the morning)

Think of these as training manuals. Not for you, it is for your Chief of Staff.

Component 3: Claude (The Executor)

Claude reads our files + follows our skills = executes our systems consistently.

When we type:

"Run my morning review"

Claude:

1. Reads morning-review.md (learns HOW you want this done)
2. Reads all your project files (learns WHAT you’re working on)
3. Applies YOUR prioritization framework
4. Delivers a focused briefing

How it works together?

• You wake up → “Run my morning review” → clear priorities in 30 seconds
• You have a meeting → “Prep me for this call” → walk in fully prepared
• You plan your week → “Help me plan next week” → strategic allocation of time

Let me show you this in action with the most powerful workflow: your morning review.

The setup

We have a few steps to follow before generating the folder structure.

This system works best when Claude can access your files directly. Here’s how to set that up:

1. Install Claude code:

Open your Terminal (Mac) or Command Prompt (Windows) and run:

npm install -g @anthropic-ai/claude-code

2. Create your workspace

cd ~/Documents
mkdir my-workspace
cd my-workspace

Daily Usage

Every time you want to use your Chief of Staff:

cd ~/Documents/my-workspace
claude

Then just talk in plain English:

• “Run my morning review”
• “Prepare me for my Acme call”
• “Process my inbox”

Type exit when you're done.

That’s all the “terminal” you need to know.

Look how it looks like when I tried building one skills for generating the relevant tweets for me based on how I write, my best tweets, and what kind of content I bookmark:

How to build your workspace?

Step 1: Create your workspace

First, you create a simple folder structure. You can do this in your file explorer, or ask Claude to help:

"Help me set up my Chief of Staff workspace. Create folders for:
- projects (where my work lives)
- personal (my goals and habits)
- inbox (unprocessed items)
- skills (my workflows)"

After you type this prompt, Claude generates the folder structure in this

my-workspace/
├── projects/
├── personal/
├── inbox/
└── skills/
    └── chief-of-staff/

Step 2: Add your first project

Now you add a real project you’re working on. Let’s say you’re working with a client called Lime Inc on a brand refresh.

You create: /projects/client-lime/brief.md

You add:

# Lime Inc: Brand Refresh Project

**Status:** 🟡 In Progress
**Deadline:** March 30, 2026

## This Week
- Finalizing mood board for Friday presentation
- Waiting on brand strategy doc from Mike

## Next Steps
- Present mood board: Jan 25
- Start logo concepts: Feb 1

## Notes
- Sarah (CMO) is main contact
- They want "modern but trustworthy"
- Possible Q2 project if this goes well

Note: I am not sharing my exact file system due to privacy concerns but using psuedo file system just for reference. Replace this with you exact work.

You just write down what you already know about the project. That’s it.

Step 3: Add your side project (If you have one)

If you’re building something on the side:

You create: /projects/saas-project/roadmap.md

You add:

# DesignQueue: My SaaS Project

**Status:** 🟡 Validation phase

## This Week
- 5 customer interviews scheduled
- Jordan interview on Tuesday 2pm

## Next Milestone  
- Finalize MVP feature set by Feb 1

Step 4: Capture “What’s on your mind”

Everything floating in your head or scattered in emails goes here:

You create: /inbox/items.md

You add:

## To Process

- Sarah (Lime Inc) emailed asking about timeline
- Freelancer invoice needs approval ($3,400)
- Conference invite: need to decide by Friday
- Update LinkedIn (been meaning to do this)

Brain dump. Everything that’s on your mind.

Step 5: Now set up your morning workflow

This is where the magic happens. You document HOW you want Claude to run your morning review.

You create: /skills/chief-of-staff/morning-review.md

You add:

# Morning Review Workflow

## Purpose
Start each day with clarity on priorities

## Process
1. Read all project files to understand current status
2. Check inbox for urgent items
3. Identify today's top priorities
4. Suggest time-blocked schedule

## My Decision Framework
- Client work always comes first
- Flag anything overdue or due today
- Deep work blocks: 9am-12pm (my best hours - protect this)
- Personal goals: at least 1 action per day

## Output Format
Give me:
- Today's top 2-3 focus items
- Urgent items needing immediate attention
- Suggested schedule based on my energy
- Heads up on potential issues
```

This is YOUR workflow. Your preferences. Your style.

**Or use the template:** I've included a complete `morning-review.md` skill 
in the download that you can use as-is or customize.

### Step 6: Run Your First Morning Review

Now everything is set up. You have:
- ✅ Your projects documented
- ✅ Your inbox captured  
- ✅ Your workflow defined

**You type:**
```
"Run my morning review using the skill at /path/to/skills/chief-of-staff/morning-review.md"
```

Claude:
1. Reads your morning-review skill (learns HOW you want this done)
2. Reads all your project files (learns WHAT you're working on)  
3. Reads your inbox (sees what needs attention)
4. Applies YOUR decision framework
5. Generates YOUR briefing

### What You Get (30 seconds later)
```
🌅 MORNING BRIEFING - Tuesday, Jan 21, 2026

TODAY'S FOCUS:
- Finalize Acme mood board for Friday presentation
- Complete Jordan interview (DesignQueue validation)

URGENT:
- Sarah (Lime) waiting on timeline: respond by noon
- Freelancer invoice needs approval ($3,400)
- Mike's brand doc still missing - follow up today

QUICK WINS:
- Approve invoice (5 min)
- Email Sarah (10 min)

SUGGESTED SCHEDULE:
9:00-11:30  → Deep work: Acme mood board
11:30-12:00 → Admin (invoice, emails)
12:00-1:00  → Lunch
1:00-1:45   → Prep Jordan interview questions
2:00-3:00   → Jordan interview
3:00-4:30   → DesignQueue notes + follow-up
4:30-5:00   → Inbox processing

⚠️ WATCH OUT FOR:
- Still waiting on Mike's doc: could delay next phase
- Full day ahead: protect morning deep work time

Total setup time: 30–45 Minutes

That’s it. You now have:

• Your work organized in one place
• Your workflows documented
• Claude executing your systems

And tomorrow morning? Just type “Run my morning review” again.

"Run my morning review"

Get focused briefing for the day.

Weekly (30 minutes):

"Help me plan next week"

Strategic review and planning.

As needed:

"Prepare me for my call with [Client]"
"Process my inbox"
"Give me a status report"

If you need the exact file setup, you can leave a comment and I will share the exact files that you can start using!

What else can you do?

Beyond morning review: Your complete system

The morning review is powerful, but it’s just one workflow. Here are the other core workflows that come with the system:

1. Client Prep (Before any meeting)

You type:

"Prepare me for my Lime Inc call on Friday at 10am"

What Claude does:

• Reads the client-prep.md skill
• Pulls all context from /projects/client-lime/
• Checks recent notes and action items
• Applies your meeting prep framework

What you get:

📋 CLIENT PREP - Lime Inc - Friday 10am

MEETING TYPE: Mood Board Review

PROJECT SNAPSHOT:
- Status: On track
- Recent win: Mood board completed ahead of schedule
- Open item: Still waiting on Mike's brand doc

AGENDA TO COVER:
1. Present the 3 mood board directions
2. Get feedback on color palette
3. Confirm timeline for logo phase
4. (Gently) follow up on brand strategy doc

MATERIALS READY:
- Mood board presentation deck
- Updated timeline document

QUESTIONS FOR THEM:
- Which direction resonates most and why?
- Any concerns about "modern but trustworthy"?
- Should we loop in other stakeholders?

HEADS UP:
- Sarah mentioned possible Q2 project - good time to explore
- Be ready with mitigation plan if brand doc causes delay

AFTER MEETING:
- Send recap email within 2 hours
- Update brief with decisions
- Schedule next check-in

2. Weekly planning

You type:

"Help me plan next week"

What Claude does:

• Reads the weekly-planning.md skill
• Reviews all projects for progress/blockers
• Checks your personal goals
• Assesses capacity vs. commitments

What you get:

📊 WEEKLY PLANNING - Week of Jan 27

LAST WEEK REVIEW:
✅ Completed: Acme mood board, 3 DesignQueue interviews
🟡 In Progress: Logo concepts starting, 2 more interviews
📈 Pattern: Client work expanding - set better boundaries

TOP 3 PRIORITIES THIS WEEK:
1. Lime Inc logo concepts (first client impression - critical)
2. TechStart launch materials (deadline approaching)
3. Complete DesignQueue validation (5 interviews total)

CAPACITY CHECK:
Client work: 32 hours
Side project: 8 hours  
Personal: 5 hours
Total: 45 hours (reasonable)

🟢 GREEN: Good balance

DEEP WORK BLOCKS SCHEDULED:
- Monday 9-12pm: Logo concept exploration
- Wednesday 9-12pm: TechStart social assets
- Friday 9-11am: DesignQueue analysis

PERSONAL COMMITMENTS:
- 3 workouts (Mon/Wed/Sat)
- 2 Spanish lessons
- Finish book chapter 4-5

WATCH FOR:
- Mike's doc deadline (Monday) - follow up if missing
- TechStart launch moved up - stay ahead of schedule

3. Inbox processing (Get to Zero)

You type:

"Process my inbox"

What Claude does:

• Reads the inbox-processing.md skill
• Applies your decision framework (urgent/important/defer/delete)
• Converts chaos into organized actions
• Updates relevant project files

What you get:

📥 INBOX PROCESSING - Jan 22

PROCESSED: 8 items

✅ COMPLETED (under 2 min each):
- Approved freelancer invoice
- Responded to Sarah about timeline
- Booked photographer for mom's party

📂 ADDED TO PROJECTS:
- "Review TechStart blog" → client-techstart/deliverables.md (due Friday)
- "Update LinkedIn" → personal/goals.md (this week)
- "File Q4 taxes" → personal/admin.md (deadline Feb 15)

💡 IDEAS CAPTURED:
- Blog post: "How to price design projects" → content-ideas.md
- DesignQueue feature: Auto-tag urgency → saas-project/features.md

🚮 DELETED:
- Conference invite ($1,200) - not worth it right now
- Podcast interview - wrong audience

⏰ WAITING ON:
- Mike (Lime Inc) - brand doc
- David (TechStart) - feedback on assets

═══════════════════════════
INBOX STATUS: ✨ ZERO
═══════════════════════════

IMMEDIATE ACTIONS:
- Review TechStart blog (urgent - due Friday)
- Follow up with Mike about brand doc

4. Project status (Check any time of the day)

You type:

"Give me a status report on all projects"

What Claude does:

• Reads the project-status.md skill
• Scans all project files
• Categorizes by health (🟢🟡🔴)
• Flags what needs attention

What you get:

📊 PROJECT STATUS - Jan 22

🟢 Lime Inc - Brand Refresh
On track | Next: Logo concepts by Feb 1
Note: Mood board approved, strong momentum

🟡 TECHSTART - Product Launch  
Slight risk | Blog review due Friday
Issue: Launch date moved up, timeline tight

🟢 DESIGNQUEUE - SaaS Project
On track | Next: 2 more interviews this week
Note: Strong validation signals

PORTFOLIO HEALTH:
- 3 active projects
- 2 green, 1 yellow, 0 red
- 32/40 billable hours (good utilization)

THIS WEEK'S FOCUS:
- Complete TechStart deliverables (time-sensitive)
- Maintain Lime momentum
- Finish DesignQueue validation phase

WATCH FOR:
- TechStart timeline pressure
- Need to invoice Lime Inc for Phase 1

Common questions you might have

Q: Do I need to be technical?

A: No. If you can create a text file and copy-paste, you’re good.

Q: What if I’m not organized?

A: Perfect! That’s the point. The system helps you GET organized. Start messy, improve over time.

Q: Can I use this with my current tools (Notion, Todoist, etc)?

A: Yes. This adds a “Chief of Staff layer” on top. Keep using what works.

Q: What if I miss updating files?

A: Just tell Claude what happened and it updates them. Or don’t update and let things get slightly stale. It still works.

Q: How is this different from just asking Claude questions?

A: The skills ensure CONSISTENT execution of YOUR specific workflows. Ad-hoc questions = ad-hoc results. Documented systems = consistent results.

Q: What if I want to add my own workflows?

A: That’s the best part! Add new SKILL.md files for anything you do repeatedly. Sales outreach? Content creation? Financial review? Document it once, execute it forever.

Start today!

This isn’t about perfect systems. It’s about that moment when you stop feeling like you’re drowning in your own to-do list.

I made this template because I was tired of starting each day already behind. You know that feeling, coffee still hot, inbox already overwhelming, and somehow it’s only 8 AM.

Download it. Try one morning review. I think you’ll notice the shift immediately.

Your Chief of Staff is sitting there waiting. Might as well put it to work.

Picture this: It’s 2013, and you’re sitting in a Google conference room looking at projections that basically say your company is about to hit a wall.

The infrastructure team had just run the numbers on voice search adoption. If users started talking to their phones for just three minutes a day, which seemed inevitable, Google would need to double its entire data center footprint. Not add some servers. Double everything.

I’ve seen a lot of “oh shit” moments in tech, but this was different.

The math was brutal: neural networks need serious compute power, CPUs were slow, and GPUs were better but would literally bankrupt the economics of offering voice search for free.

Jeff Dean and the Brain team faced the kind of choice that defines companies: give up on the AI features that clearly represented the future, or build something that had never been built before.

Fifteen months later, and honestly, anyone who’s worked in chip development will tell you that timeline is absolutely bonkers, the first TPU was running in production.

Most people using Google Photos or Maps had no clue they were running on custom Google silicon. They just knew it worked.

Now here’s where it gets interesting: fast-forward to today, and Gemini 3 (Google’s answer to GPT-4o) was trained entirely on those TPUs.

But Anthropic, the folks behind Claude, which is arguably just as good, just bet tens of billions on a completely different approach.

They’re using TPUs, Amazon’s Trainium chips, AND Nvidia GPUs.

Same destination, totally different paths.

What’s really happening here isn’t just a story about chips.
It’s about a fundamental question every AI company is wrestling with right now:
When do you build versus buy?
When do you bet your company on custom hardware versus just writing cheques to Nvidia?

The answer involves some elegant math from the 1970s, a $100 million gamble that could have killed Google’s margins, and a trade-off that I think will define the next decade of AI.

Let me walk you through it.

What’s actually happening here?

“Okay cool, big tech companies are using different chips. Why should I care?”

Fair question. Here’s why this actually matters, even if you’re never going to train a giant AI model:

For developers/engineers:

The tools you’re learning right now?

They exist because of these infrastructure decisions.

I’ve watched PyTorch default to CUDA for years now.
Every tutorial I’ve seen assumes you have Nvidia GPUs.
Google gives you free GPU access in Colab because they’re betting on their ecosystem.

But if TPUs and custom chips really take off?

Everything changes.
The frameworks, the assumptions, the way you think about building things. I’m not saying drop everything and learn TPU programming tomorrow, but I am saying pay attention.

For startups/founders:

Your compute costs are about to get weird.

Right now, you basically have one choice: rent Nvidia GPUs from AWS or Google Cloud. That’s it. That’s the menu.

But look at what Anthropic’s doing, they’re spreading their bets across TPUs, Amazon’s Trainium chips, and still keeping some Nvidia in the mix. That tells me we’re heading toward a world where you’ll actually have real decisions to make about compute. Understanding these trade-offs early? That’s how you don’t get caught paying 3x what your competitor pays.

For anyone trying to understand where AI is going:

Here’s what I’ve realized: the infrastructure determines everything else.

Models don’t just appear, they’re shaped by the chips they run on.
GPT-4 looks the way it does partly because of Nvidia’s architecture.
Claude can handle those crazy-long conversations because Anthropic made specific hardware choices.
Gemini processes video and images efficiently because Google built it on TPUs from day one.

Google’s optimization target: Maximum efficiency at maximum scale

• They have unlimited demand (Search, YouTube, Gmail, Photos, Maps all use AI)
• They control both the chip design AND the software stack
• Vendor lock-in isn’t a risk when you ARE the vendor

Anthropic’s optimization target: Maximum flexibility with acceptable risk

• They’re growing explosively but demand is harder to predict
• They need leverage when negotiating with chip suppliers
• A single point of failure could take down their entire business

The scale here is honestly hard to wrap your head around:

Anthropic is deploying 1 million TPUs.

That’s over a gigawatt of power, enough to run a city. We’re talking tens of billions of dollars.

And they’re not putting all their eggs in one basket.
They’re running Google Cloud TPUs, Amazon’s Trainium chips through this massive AWS deal called Project Rainier, plus still keeping Nvidia GPUs in the mix.

Meanwhile, Google trained Gemini 3 using only TPUs. Same manufacturing, same supply chains as everyone else, completely different approach.

The result? Both companies have models that are genuinely impressive. Both are hitting the benchmarks everyone cares about. But they got there through totally different paths.

I think understanding why they made these choices tells you something important about where all of this is heading.

TPU vs GPU 101: What you actually need to know

The chip powering Claude right now exists because some teenagers in the ’90s wanted better graphics for Quake. I’m not kidding.

Stage 1: The CPU Era (1970s-1990s)

This entire story starts with one question in the 1990s: How do you make 3D games look realistic in real-time?

Back in the day, there was just the CPU, the “brain” of your computer. CPUs are like that one friend who’s brilliant at everything but can only focus on one thing at a time. They’ll run your operating system, juggle your files, handle complex decisions. Pure sequential genius.

Imagine you’re playing Quake in 1996.

For every frame of the game, your computer needs to:

• Calculate where every object is in 3D space
• Figure out lighting and shadows for each surface
• Apply textures to every polygon
• Determine what color each of the million+ pixels should be
• Do all of this 60 times per second for smooth gameplay

CPUs trying to do this one calculation at a time? Forget it. You’d get maybe 5 frames per second.

Stage 2: The GPU Revolution (1990s-2000s)

Nvidia’s 1999 Breakthrough: GeForce 256

Then Nvidia had this crazy idea: What if instead of one brilliant mathematician working alone, we had an entire stadium of people doing simple math at the same time?

That’s a GPU. Thousands of small, not-particularly-bright processors all working in parallel. None of them would win a math contest, but together? They could crunch massive amounts of data instantly.

Suddenly:

• One CPU: Calculates 1 pixel at a time
• One GPU: Calculates 10,000 pixels simultaneously

NVIDIA’s GeForce 256, released in October 1999, was a major breakthrough because it introduced hardware-accelerated Transform and Lighting (T&L), offloading geometry calculations from the CPU to the graphics card. This innovation was the foundation of the modern Graphics Processing Unit (GPU) and enabled a significant leap in 3D gaming performance

The whole point was making Quake playable in real-time. That’s it.

2012: The ImageNet Moment

A team at University of Toronto used gaming GPUs to train a neural network that crushed the competition in image recognition.

Alex Krizhevsky, Ilya Sutskever, and Geoffrey Hinton built AlexNet. An eight-layer neural network with 60 million parameters.

Why did it work? Because training neural networks is just:

• Multiply matrix A × matrix B
• Multiply matrix C × matrix D
• Multiply matrix E × matrix F
• Repeat billions of times

Sound familiar? It’s the same type of parallel, repetitive math that GPUs were doing for game graphics.

Gaming GPUs became AI GPUs overnight.

Nvidia pivoted fast:

• Created CUDA (framework for programming GPUs for non-graphics tasks)
• Started marketing to AI researchers
• Became the default standard for training models

By 2023, Nvidia’s market cap hit $1 trillion. Because gamers wanted better graphics in the 90s.

Imagine!!

The Accidental AI Revolution

GPUs weren’t even designed for AI. They just happened to be perfect for it. I wonder, sometimes the best discoveries are accidents.

Stage 3: The TPU Specialization (2013-Present)

By 2013, Google had a problem. Their AI workloads were exploding, voice search, photo recognition, translation. Running all this on GPUs would mean doubling their data centers.

So, Jeff Dean and team looked at GPUs and realized:

• GPUs have texture mapping hardware → AI doesn’t need this
• GPUs have rasterization units → AI doesn’t need this
• GPUs have display outputs → AI doesn’t need this
• GPUs do lots of things AI never uses → wasted silicon, wasted power

So, they dug up some dusty 1978 PhD thesis about “systolic arrays” (I love that someone’s 40-year-old homework became the foundation for modern AI), built the Tensor Processing Unit, and deployed it in 2015.

By 2016, it was powering Google Search, Photos, Maps. The stuff you use every day.

What is a Systolic Array?

The term “systolic” comes from your heartbeat, that rhythmic pulse pushing blood through your body without your heart constantly running back to some blood reservoir to grab more.

I’ve been thinking about this analogy because it perfectly captures why Google’s TPUs work so differently from regular chips.

The old way (what your CPU and GPU do):
- Worker runs to the well
- Grabs a bucket
- Does something with it
- Runs back to storage
- Repeats this dance thousands of times

You can see the waste, right? All that running back and forth.

The systolic way (what TPUs do):
Picture a human chain passing buckets of water. Each person does one small thing, maybe adds a drop of something, then passes it along. No one’s running anywhere. The buckets just flow.

In chip terms, imagine 65,536 tiny calculators arranged in a grid (that’s what TPU v1 actually has). Instead of each one constantly fetching numbers from memory:

- Data enters at one edge
- Flows across like a wave
- Each calculator does its one operation as data passes through
- Results emerge at the other side

I find this beautiful because matrix multiplication, the math that runs neural networks, is perfectly suited for this flow. You’re doing the same operation over and over, and each result feeds into the next calculation.

Here’s where it gets interesting:

Your GPU spends about 70% of its time just moving data around. Only 30% actually computing.

A TPU flips this: 20% moving data, 80% computing.

At Google’s scale? That difference is worth billions.

But here’s the twist I love:

This isn’t new technology.

H.T. Kung at Carnegie Mellon University wrote about systolic arrays in a 1978 thesis. For signal processing. The idea got buried because these chips are incredibly inflexible, you design the grid for one specific calculation, and that’s all it can do.

For general computing, that inflexibility was a dealbreaker.

But for Google’s AI workloads? They’re running the same matrix operations billions of times. Transformer models are predictable math. When you know exactly what you’re computing, flexibility doesn’t matter.

The forgotten architecture became perfect for the modern problem.

Sometimes I wonder what other “dead” ideas are sitting in old papers, waiting for their moment.

Why this actually matters?

We’re living through a shift. From 2012–2023, AI ran on repurposed gaming chips. Now AI is big enough to justify building its own specialized hardware from scratch.

That’s why Anthropic is spending billions on TPUs while keeping GPUs around. They’re betting AI has reached the scale where specialization beats general-purpose tools. But honestly? They’re also hedging in case they’re wrong.

P.S. This article is written in a humanized manner by aislop.review.

So, does that mean TPUs are better than GPUs?

I’ve been thinking about this TPU vs GPU debate for months now, and honestly? I’m tired of the “which is better” question. It’s the wrong question entirely.

Here’s what I’ve figured out after watching companies make both brilliant and catastrophic decisions: it’s not about better. It’s about what you’re actually optimizing for.

Trade-off #1: Specialization vs. Flexibility

TPUs are like that one friend who’s absolutely incredible at chess but can’t figure out how to use a can opener.

They’re surgical tools, 30% more cost-efficient at training transformers, completely useless for everything else.

GPUs?

Swiss Army knife.

Pretty good at AI, pretty good at graphics, decent at crypto mining.
Not perfect at anything, but you can actually build a business on them.

Google training Gemini 3:

Google training Gemini 3 on TPUs makes perfect sense. They know exactly what they’re building, they know it won’t change mid-training, and they’ll run billions of identical operations. At their scale, 30% efficiency = actual billions saved.

Why Anthropic uses both: They’re big enough that TPU efficiency matters (30% savings at their scale = huge), but still innovating enough that GPU flexibility is insurance.

Trade-off #2: Ecosystem Maturity vs. Raw Efficiency

Here’s the brutal truth nobody wants to admit: CUDA has been around for 20 years. That’s two decades of tutorials, Stack Overflow answers, debugging tools, and CS students learning to think in CUDA.

When your TPU code breaks at 2 AM (and it will), you’re googling error messages that three other people have ever seen. When your GPU code breaks, there are 100,000+ answered questions waiting for you.

I’ve seen teams save 30% on compute costs with TPUs, then lose it all because their engineers spent 3x longer debugging weird edge cases. The “cheaper” option suddenly isn’t.

GPU Ecosystem (Nvidia/CUDA):

• CUDA has existed since 2006: nearly 20 years of tooling
• Every ML tutorial assumes you’re using GPUs
• PyTorch/TensorFlow default to GPU support
• Stack Overflow: 100,000+ GPU questions answered
• University CS programs teach CUDA
• Debugging tools, profilers, optimization guides = abundant

TPU Ecosystem (Google/JAX/XLA):

• JAX/TensorFlow work well but has a smaller community
• Fewer tutorials, less Stack Overflow coverage
• Debugging errors = harder (fewer people have seen your issue)
• Hiring TPU-experienced engineers = more expensive/rare
• Third-party libraries may not support TPUs

Why Anthropic hedges: They have TPU experts (many ex-Google engineers), so they can capture efficiency gains. But they keep GPUs for cases where ecosystem maturity accelerates development.

Trade-off #3: Vendor Lock-in vs. Vertical Integration

This is where it gets interesting strategically. TPUs only exist in Google Cloud. Period. You want TPUs, you’re Google’s customer, and they know it.

But here’s what’s clever, OpenAI reportedly got a 30% discount from Nvidia in 2024 by threatening to consider Google TPUs. They probably never intended to switch, but having the option gave them leverage.

The TPU Lock-in:

• Google controls entire stack (chip + compiler + software)
• Tight integration = maximum performance
• Google optimizes for their own use cases first (you benefit)
• ❌ Only available on Google Cloud
• ❌ Can’t move to AWS or Azure without rewriting everything
• ❌ Negotiating leverage = zero (Google is the only TPU supplier)
• ❌ If Google discontinues a TPU generation, you’re stuck

The GPU Multi-Cloud Option:

• Available on AWS, Azure, GCP, on-premise
• Can switch providers if pricing/terms change
• Use competition for negotiating leverage
• Not dependent on single vendor’s roadmap
• ❌ Less optimization (no vertical integration)
• ❌ Higher cost per operation

The Anthropic Strategy:

By using all three platforms (TPU + Trainium + GPU), Anthropic:

• Gets TPU cost efficiency where it makes sense
• Maintains GPU as backup/leverage
• Adds Amazon Trainium as AWS partnership requirement
• Can play vendors against each other for pricing
• Pays massive engineering complexity cost (more on this below)

Trade-off #4: The one nobody talks about: Engineering Complexity

Now for the story nobody’s talking about. Anthropic runs on three platforms: TPUs, GPUs, and Amazon Trainium. Sounds smart, right? Diversification, cost optimization, vendor leverage.

In August-September 2025, Claude users reported degraded performance. Anthropic’s postmortem revealed three distinct infrastructure bugs, each affecting different platforms differently:

1. Context window routing error (16% of Sonnet 4 requests affected on one platform)
2. Output corruption from TPU server misconfiguration (affected Opus 4 and Sonnet 4)
3. XLA:TPU compiler bug (affected Haiku 3.5 for two weeks)

Every model update has to be tested on three different architectures. Every bug has three potential causes. Every deployment is 3x more complex.

Anthropic’s own words:

“We deploy Claude across multiple hardware platforms, namely AWS Trainium, NVIDIA GPUs, and Google TPUs… each bug produced different symptoms on different platforms at different rates. This created a confusing mix of reports that didn’t point to any single cause.”

What could be ideal?

Most people reading this aren’t choosing between million-dollar compute budgets. So let’s be practical:

Spending under $100K/year? Use GPUs. The ecosystem wins, the complexity isn’t worth it, and you need to move fast.

$100K to $10M? This is where it gets interesting. Try TPUs for your stable production stuff, the models you know work and won’t change much. Keep GPUs for experimentation. You’re big enough that 30% savings matter but not big enough to bet the company on Google’s roadmap.

Over $10M? Now you’re in Anthropic territory. The engineering complexity tax might be worth paying for vendor leverage and cost optimization. Maybe.

What is next?

This isn’t really about Chips: It is what comes next!

Let’s talk about what comes next, because the decisions being made today will reshape the entire AI industry.

Prediction #1: The Amazon/Trainium Dark Horse

Here’s what we didn’t cover enough: Amazon is quietly building the third pillar of AI infrastructure.

Why Trainium matters more than people realize:

While everyone focuses on the Google vs Nvidia battle, Amazon has been methodically building:

• Trainium (training chips): Custom silicon for training large models
• Inferentia (inference chips): Optimized for running models in production
• AWS as distribution: Already the largest cloud provider

The strategic advantage:

Unlike Google (TPUs only on GCP), Amazon can offer Trainium to:

• The entire AWS customer base (dominant market share)
• Companies already locked into AWS ecosystem
• Enterprises that will never move to Google Cloud (Microsoft competitors, regulated industries)

Who’s already using Trainium:

• Anthropic: Primary training partner (Project Rainier: hundreds of thousands of chips)
• Amazon’s own models: Titan, Alexa AI
• Growing roster of AWS customers testing it for cost optimization

Why this is significant:

If you’re a company spending $50M/year on AWS already:

• Switching to GCP for TPUs = massive migration cost
• Switching to Trainium = config change on same platform

The math changes completely.

The prediction: By 2027, we’ll see:

• Trainium as the #2 custom silicon platform (after TPUs, ahead of everyone else)
• Anthropic-like multi-platform becoming standard (GPU + TPU + Trainium)
• AWS Trainium revenue rivaling Google’s TPU cloud revenue

Why it’s not happening faster:

Trainium is newer (2022 launch vs TPU’s 2015), ecosystem is less mature, and AWS is being cautious about competing too directly with Nvidia (their biggest GPU customer).

But the writing is on the wall: Every hyperscaler wants their own silicon.

Prediction #2: Custom Silicon becomes standard at hyperscale

The pattern we’re seeing:

• Google: TPUs (7 generations deep, powering all internal AI)
• Amazon: Trainium + Inferentia (aggressive expansion)
• Meta: Reportedly in talks for massive TPU deployment
• Microsoft: Developing Maia and Cobalt AI chips
• Apple: Custom Neural Engine in every device
• Tesla: Pivoting from Dojo to new AI5/AI6 chips + massive Nvidia Cortex cluster
• ByteDance: Rumored custom silicon program

What’s coming:

Every company spending $100M+/year on AI compute will either:

1. Build their own ASIC (if you’re Google/Apple scale)
2. Work with Broadcom/Marvell on semi-custom silicon (if you’re Meta/Microsoft scale)
3. Use a mix of custom + commodity (if you’re Anthropic scale)

Why this is inevitable:

At billion-dollar compute budgets, 30% efficiency = $300M saved annually. Even if custom chip development costs $100M upfront, ROI is less than 6 months.

The companies positioned to win:

• Broadcom: Already designing Google’s TPUs, Meta’s chips, Apple’s silicon
• TSMC: Manufacturing all custom AI chips (same bottleneck as Nvidia)
• Marvell: Second-largest custom chip designer, AWS’s Trainium partner

Who this leaves behind:

Companies spending <$10M/year on compute. For them, GPUs remain the only viable option. The ecosystem advantage is insurmountable.

The result: A two-tier AI industry emerging:

• Tier 1 (hyperscalers): Custom silicon, 30% cost advantage, vertical integration
• Tier 2 (everyone else): Nvidia GPUs, slower, more expensive, but ecosystem advantages

Prediction #3: The Nvidia moat weakens

What’s happening:

• Google proved you can train frontier models without Nvidia (Gemini 3)
• Anthropic proved multi-platform is viable at scale (1M TPUs)
• Amazon is aggressively pushing Trainium
• Even OpenAI used TPU leverage for Nvidia discounts

What this means:

Nvidia’s AI market share will decline from ~95% to ~60–70% over the next 3–5 years.

But they’ll remain dominant because:

• CUDA ecosystem is too entrenched (20 years of developer mindshare)
• Most companies are below the scale where alternatives make sense
• Nvidia’s innovation velocity is actually accelerating (Blackwell → Rubin → next gen)
• Gaming/graphics revenue provides cushion (unlike pure-play AI chip startups)

The parallel: Intel vs AMD in CPUs. AMD gained significant share, but Intel still leads. Nvidia will follow a similar path where they have a weakened monopoly, but still stay as the market leader.

The wildcard: If Nvidia’s next-gen chips (post-Blackwell) significantly outperform custom silicon, the pendulum could swing back.

Prediction #4: Multi-Platform becomes the norm

Right now: Running across TPU + Trainium + GPU is painful (see: Anthropic’s August 2025 bugs)

The future: Software tooling will abstract away hardware differences

Think about what happened with databases:

• 2000s: Switching from Oracle to MySQL = rewrite everything
• 2020s: Modern ORMs let you switch databases with config changes

The same will happen for AI chips:

Frameworks will emerge that let you write code once, deploy to any chip:

• High-level abstractions that compile to TPU/GPU/Trainium
• Automated testing across platforms
• Unified debugging tools
• “Hardware-agnostic” becoming the default

Who’s building this:

• Google (JAX): Already more portable than CUDA, compiles to TPU/GPU
• OpenAI (Triton): Hardware-agnostic kernel language
• Meta (PyTorch 2.0): Better compilation targets
• Startups: Modal, Anyscale, etc. focusing on multi-cloud ML

When this happens: Multi-platform stops being “Anthropic can afford the pain” and becomes “everyone does this by default.”

The tipping point: When debugging complexity drops by 10×, adoption accelerates rapidly.

Timeline: 2–3 years for tooling maturity, 5 years for widespread adoption

Prediction #5: Energy becomes the real bottleneck

Training GPT-4 scale models required ~25,000 GPUs running for months. The energy consumption is equivalent to powering a small city.

As models get bigger:

• Data centers hit power limits (can’t add more GPUs if your facility can’t supply electricity)
• Energy costs become majority of operating expense
• Regulatory pressure on AI energy use increases (EU, California already proposing limits)

Why this matters MORE than chip costs:

You can negotiate chip prices. You can’t negotiate physics.

Current situation:

• A single H100 GPU: ~700W power consumption
• A TPU v5e chip: ~450W for equivalent AI compute
• Scale to 100,000 chips: 30–70 megawatts difference

At the scale of training GPT-5 or Gemini 4, energy efficiency might be the PRIMARY constraint, not chip availability or cost.

The companies positioned to win:

• Google: TPUs are significantly more energy-efficient per operation
• Amazon: Building data centers near hydroelectric power (cheap renewable energy)
• Whoever cracks algorithmic efficiency: Train GPT-4 quality with 10× less compute

The dark horse bet:

Neuromorphic chips (like Intel’s Loihi, IBM’s TrueNorth) that mimic biological brains for orders of magnitude better energy efficiency.

Currently niche, but if energy regulations tighten or electricity costs spike, physics might force their adoption.

Timeline: 3–5 years before energy becomes the binding constraint (we’re already seeing early signs)

Final thought

In 2013, Google’s team ran calculations that scared them into building custom chips.

In 2022, Amazon ran similar math and built Trainium.

In 2025, every major AI company is running those same calculations.

The question isn’t whether the infrastructure layer transforms, it’s who adapts fastest.

Because the chip you train on determines how fast you iterate, how much you spend, whether you survive margin compression, and if you’re beholden to vendors who could cut you off.

The next five years won’t be won by algorithms alone. They’ll be won by whoever figures out training at scale without going bankrupt, staying independent without breaking their systems, and keeping the lights on as models get bigger.

Google’s got efficiency figured out. Anthropic’s pioneering flexibility. Amazon’s the dark horse for both. Nobody’s solved the energy problem yet.

The company that cracks all three will own the 2030s.

And now you understand the game better than most people playing it.

What do you think!