DEV Community: Asfiya M

The picks and shovels are the story. Here's the chip nobody outside AI infra can explain.

Asfiya M — Wed, 22 Jul 2026 10:21:39 +0000

There's a line from a recent David Lin conversation with Clem Chambers that stuck with me: the real money in AI isn't the chatbots. It's the physical layer. Chips, servers, drives, cables, cooling, power, buildings, and the banks writing the cheques for all of it.

You can't buy OpenAI or Anthropic directly. You can buy the people selling them electricity and silicon.

That framing is easy to nod along to and hard to act on, because most people arguing about AI hardware are actually arguing about one company's stock price. So I want to go a level down. Not "buy the picks and shovels" as a slogan, but: what is the actual bottleneck inside the box, who is attacking it from which angle, and what does a founder do with that information on a Tuesday morning.

I'll use Groq as the worked example, because it's the clearest case of a company that ignored the obvious problem and went after a different one.

Part 1: Why the physical layer argument holds

The podcast made four points about infrastructure that I think are correct, and one that I'd push back on.

Demand for compute has no natural ceiling. This is underrated. A social network saturates when everyone has an account. Compute doesn't saturate, because every improvement in model quality creates new things worth computing. Reasoning models burn 10-50x the tokens of a single-shot answer for the same question. Agents burn more again, because one user action becomes fifteen chained model calls. The unit of demand keeps getting bigger even when the user count stays flat.

There's no prize for second place. Correct at the lab level, and it's why capex runs hot for years rather than months. If you believe you might have the best model in eighteen months, underspending now is how you guarantee you won't.

Electricity is the binding constraint. This one I'd put first, not fourth. You can order more chips. You cannot order more grid. A gigawatt of new generation plus interconnect is a multi-year permitting problem in the US, and that timeline doesn't compress with money. Which is why "performance per watt" stopped being a spec-sheet vanity metric and became a business constraint. If your data centre is power-capped rather than budget-capped, the chip that does more inference per watt literally lets you serve more customers from the same building.

Where I'd push back: "spread across the AI supply chain, hold ten years, ignore the news" treats the supply chain as one thing. It isn't. Power generation, transmission, and cooling are genuinely long-cycle businesses with physical moats. Silicon is a knife fight where architectures get obsoleted in 24-month cycles. Holding both for ten years with the same conviction is treating two different risk profiles as one bet.

Which brings me to the interesting part.

Part 2: The bottleneck outside infra

Running a language model is two completely different jobs wearing one name.

Job one is prefill: reading your prompt. The model processes all your input tokens at once, in parallel. This is compute-heavy. Lots of maths, all of it independent, all of it able to happen simultaneously. GPUs are exceptional at this. It's essentially what they were built for.

Job two is decode: writing the answer. The model produces one token, looks at everything it has written so far, then produces the next one. It cannot parallelise. Token 50 needs token 49 to exist first.

And here's the catch that makes decode a hardware problem rather than a maths problem: to generate each single token, the chip has to read the entire model's weights out of memory. All of them. For a 70-billion-parameter model, that's roughly 140GB moved from memory to compute, per token.

So the compute units sit mostly idle, waiting. The pipe from memory is the ceiling. People in the field call this the memory wall.

An H100 has around 3.35 TB/s of memory bandwidth. Do the arithmetic on 140GB per token and you can see why GPU decode speeds land where they land. The chip isn't thinking slowly. It's queuing.

Every serious inference chip company is an answer to this one question: how do you stop the weights from having to travel so far?

Part 3: How Groq works...

Groq was founded in 2016 by Jonathan Ross, who led the team that built Google's first TPU. He left with a specific prediction: memory bandwidth, not compute, would become the thing that decides AI performance. He was early by about six years.

Their answer has three ideas. All three are simple once you see them.

Idea one: don't fetch the weights from anywhere

A GPU keeps model weights in HBM, which is memory that sits next to the processor and gets read across a bus. Fast, but it's still a journey.

Groq's LPU puts hundreds of megabytes of SRAM directly on the die and uses it as primary weight storage rather than as a cache. The weights don't live somewhere else and get fetched. They live on the chip, already there, permanently.

The Groq 3 generation carries around 500MB of on-chip SRAM with roughly 150 TB/s of bandwidth, against the H100's 3.35 TB/s. That's not a 10% improvement. It's a different order of magnitude, and it's the whole ballgame for decode.

The analogy I use with non-technical people: a GPU is a chef with a huge, well-stocked walk-in freezer down the hall. Every dish, they walk to the freezer and back. Fast walker, big freezer, but the hallway is the constraint. The LPU is a chef whose ingredients are all pre-laid out on the counter within arm's reach. Tiny counter. Nothing in the freezer. But no walking.

Idea two: schedule everything before you start

A GPU decides at runtime what happens next. Threads get scheduled, caches hit or miss, memory access patterns vary. This is flexible and it's why GPUs run anything. It also means the exact same request takes 40ms sometimes and 95ms other times.

The LPU throws that out. There are no caches, no dynamic scheduling, no out-of-order execution. A compiler works out the entire schedule ahead of time, down to which data arrives at which unit on which clock cycle. The chip then just executes the score.

Groq describes this as a programmable assembly line, and the metaphor is exact. On an assembly line nobody decides at 2pm what station three does next. It was decided when the line was designed, and the part arrives at station three at the moment station three is ready for it.

Notably, Groq wrote the compiler before they designed the chip. The hardware was shaped to fit the software rather than the other way round.

Idea three: make many chips behave like one

Because 500MB is small, a real model doesn't fit on a single LPU. It gets split across many chips, which then have to coordinate.

On GPU clusters this coordination is a well-known source of unpredictable delay. Switches, routing, packets arriving in odd orders. Groq extends the static schedule across the whole rack. The compiler knows when data will arrive at each chip, so chips connect directly with no switches deciding anything at runtime. Hundreds of chips act as one large processor.

What all this actually buys you

Speed, obviously. Roughly 5-10x GPU decode throughput depending on model and generation.

Tail latency, which matters more and gets discussed less. Deterministic execution means the same work takes the same time every time. On a GPU your median response might be 200ms and your 99th percentile 900ms. When one user action fans out into fifteen sequential model calls, you're not exposed to the median. You're exposed to the worst one in the chain, fifteen times over. This is why agent products feel unpredictably slow in production while feeling fine in demos.

Energy per token. No HBM stacks, no complex cooling. Groq's racks are air-cooled by design. Circle back to the electricity bottleneck from part one and you can see why this is a commercial argument, not an environmental one.

And what it costs you

I'd rather you hear this from me than find out during a migration.

It can't train. Training needs backpropagation, gradient accumulation, optimiser states. Wrong shape entirely for a statically-scheduled inference pipeline. You still need GPUs upstream.

Compile time is real. Solving that scheduling puzzle for a new model takes serious time. Great for a model you'll serve for six months. Painful for research where the architecture changes weekly.

Small memory per chip means you need lots of chips, which is why Groq serves a curated catalogue of open models rather than letting you upload anything.

Prefill isn't its strength. Long-context, document-heavy work leans on the phase GPUs win. The emerging pattern is hybrid: GPU does prefill, hands the KV cache to the LPU, LPU does decode. That works but it adds real infrastructure complexity.

Part 4: The competitive picture

Five different bets on the same problem. I've kept this to what changes a decision.

	Nvidia GPU (H200/B200)	Groq LPU	Cerebras WSE	SambaNova RDU	Google TPU / AWS Trainium
Core bet	General-purpose parallel compute wins everything	Kill the memory wall with on-chip SRAM + static scheduling	One wafer-sized chip removes chip-to-chip overhead	Reconfigurable dataflow, sits between GPU and fixed ASIC	Vertical integration; own the silicon under your own cloud
Train or infer	Both	Inference only	Both	Both	Both
Speed vs GPU	Baseline	~5-10x on decode	~15x claimed	~5x claimed (SN50)	Competitive, varies
Where it wins	Anything and everything; unmatched ecosystem	Real-time decode, agent loops, voice	Very large models, long context, HPC	On-prem enterprise, very large models	Cost at hyperscale inside one cloud
Where it loses	Cost per token; latency variance	No training, weak prefill, curated models only	Cost, footprint, niche software	Smaller ecosystem	Locked to GCP / AWS
How you access it	Buy, or any cloud	API (GroqCloud) or on-prem racks	API or on-prem	Mostly on-prem	Only that cloud
Data residency	Fully yours if on-prem	Vendor infra unless you buy racks	Either	On-prem strength	Vendor cloud
Switching cost	—	Near zero, OpenAI-compatible API	Low, API-based	High, on-prem commitment	Medium, cloud lock-in
Company risk	Investment grade	Independent post-Nvidia deal, $1.75B raised	Public (NASDAQ: CBRS)	Private, $1.5B raised	Backed by trillion-dollar parents

Two patterns worth pulling out of that table.

Nobody is beating Nvidia at being Nvidia. Every challenger wins a specific dimension and loses the general case. Nvidia's roughly 80% share isn't inertia. It's that one architecture credibly does training and inference and vision and research, with a software ecosystem fifteen years deep. The challengers aren't trying to replace that. They're trying to peel off the workload where specialisation pays.

Inference is where challengers can actually win, because inference rewards specialisation and grows with usage rather than with lab budgets. Training demand is concentrated in maybe a dozen buyers. Inference demand is every company shipping a feature.

Part 5: The open-source angle, which is the part founders should care about

This is the connection most coverage misses.

Groq doesn't serve Claude or GPT. It can't. Those weights aren't available. The catalogue is open-weight models: the GPT-OSS family, Qwen, Llama, Whisper for speech.

That's usually described as a limitation. I'd argue it's the entire strategic point.

The economics of open models only work if inference is cheap and fast. Open weights are free to download and expensive to serve. That's why "just self-host Llama" is advice that sounds better than it works. The moment someone specialises the hardware for exactly those models, the calculus shifts. Prices land around $0.05 per million input tokens on smaller models, against a couple of dollars for frontier proprietary ones. Meta partnered with Groq for the official Llama API. That's an ecosystem forming, not a vendor selling boxes.

Where this leaves a founder: the honest answer is not "switch to Groq." It's tiering.

Most products have a boring tier and a hard tier, and most teams route everything to the hard tier because it's one API key. Classification, routing, extraction, summarisation, reformatting — that's the boring tier, and an 8B open model on fast cheap hardware handles it. Genuine multi-step reasoning, ambiguous judgement, anything customer-facing where quality is the product — that's the hard tier, and a frontier model earns its price.

Two providers, a router in between. Because both speak an OpenAI-compatible API, this is a config change, not a rewrite. That's the whole migration.

And there's a category where the speed isn't an optimisation but the product itself. Voice agents live or die on a sub-second turn budget split between speech-to-text, model, and text-to-speech. At GPU decode speeds the loop doesn't close and the conversation feels stilted. At LPU speeds it does. Same for live translation, coding autocomplete, and anything where a human is watching tokens appear.

Part 6: The uncomfortable footnote

I'd be doing you a disservice if I stopped at the technology.

In late 2025 Nvidia paid roughly $20B for access to Groq's inference architecture. Jonathan Ross and president Sunny Madra went to Nvidia. Simon Edwards is now Groq's CEO. Nvidia showed a Groq 3 LPX inference accelerator at GTC 2026. Reporting still differs on whether that was a non-exclusive licence or an acquisition of the inference unit.

Groq raised $650M in June 2026 and GroqCloud continues to operate independently. And in June 2026, Groq deprecated most of the model IDs that every LangChain tutorial written before that date depends on. I found that out the way everyone does, with a 400 error that says the model has been decommissioned.

Which is the real lesson, and it isn't about Groq. Speed is a feature you rent. Portability is a feature you own. Write your code against an OpenAI-compatible interface. Keep model IDs in config, never in source. Query the provider's model list programmatically instead of hardcoding what a tutorial told you eighteen months ago. Then the question "which chip is fastest this quarter" becomes a pricing decision rather than an engineering project.

The podcast's advice was to hold the physical layer for ten years and ignore the daily noise. For investors, maybe. For builders, the opposite applies. The silicon underneath you will get replaced two or three times in that window. Build so you don't care which one is winning.

David Lin Podcast: https://www.youtube.com/watch?v=12GGEIB4Tco

Sources: Groq's LPU architecture documentation and engineering blog, Groq's TSP papers from ISCA 2020 and 2022, arXiv work on prefill/decode-aware accelerator evaluation, and current vendor benchmarks. Performance figures are largely vendor-supplied and should be treated accordingly. Model availability on GroqCloud changes frequently — check the live catalogue before building against any specific model ID.

Your model isn't broken. It's just badly tuned.

Asfiya M — Tue, 14 Jul 2026 14:13:13 +0000

What's in here

Splitting your data (and why the old rules don't apply anymore)
The mismatch trap
Bias and variance: the only two problems you have
The recipe
Regularization: making the model less confident
Why does this actually stop overfitting?
Dropout: randomly break your own network
- Why does dropout work?
Two cheaper tricks
Normalize your inputs (seriously, just do it)
- Why bother?
Vanishing and exploding gradients
- The single neuron fix
What I'd tell past me

Most people learn neural networks backwards.

You learn how to build one. Then you build one. Then it performs badly and you have no idea why, so you go back and change the number of layers, and it still performs badly, and now you're just guessing.

I've been going through the fundamentals again properly, and the thing that clicked for me is this: almost every "my model doesn't work" problem falls into one of two buckets. Once you know which bucket you're in, the fix is almost mechanical.

Here's what I've learned so far, written the way I wish someone had explained it to me.

Splitting your data (and why the old rules don't apply anymore)

You split your data into three chunks:

Train set - the model learns from this.
Dev set (also called validation) - you use this to pick between different model ideas. Should I use 3 layers or 5? Should the learning rate be 0.01 or 0.001? You try both, check the dev set, keep the winner.
Test set - you touch this once, at the very end, to get an honest number for how good your model actually is.

The classic textbook split is 60/20/20. That was fine when datasets had 10,000 rows.

But if you have a million examples, do you really need 200,000 of them just to compare two learning rates? No. A few thousand is enough to tell two models apart. So modern splits look more like 98/1/1.

The dev and test sets aren't there to be big. They're there to be enough.

And honestly, if you don't need a fully unbiased final number, you can skip the test set entirely. Lots of teams do. They just call their dev set a "test set," which is technically wrong but nobody's stopping them.

The mismatch trap

Here's a mistake that silently destroys models.

Say you're building a cat classifier. You scrape 200,000 clean, well-lit cat photos from the web for training. Then for your dev and test sets, you use 10,000 blurry photos taken by actual users on their phones.

Your model will look great in training and fall apart in the real world. Not because the model is bad, but because you trained it on a different world than the one you're testing it in.

The rule: your dev and test sets must come from the same distribution. And that distribution should be the data you actually care about performing well on.

You can still train on the web photos (data is data). But dev and test both have to look like the real thing. Otherwise you're optimizing for a target that doesn't exist.

Bias and variance: the only two problems you have

Forget the formal statistics definitions for a second. In practice, you diagnose this with two numbers.

Let's say a human can identify cats with ~0% error. That's roughly your ceiling.

Train error	Dev error	Diagnosis
1%	11%	High variance (overfitting)
15%	16%	High bias (underfitting)
15%	30%	High bias AND high variance
0.5%	1%	You're fine. Go home.

Read that table again, it's the whole game.

High variance = your model memorized the training data. It's brilliant on data it's seen, useless on data it hasn't. The gap between train and dev is the tell.

High bias = your model is too simple to even learn the training data. It's bad everywhere, equally. There's no gap, just a high floor.

Both at once feels weird when you first see it, but it happens. Imagine a model that's mostly a straight line (too simple for most of the data) but has a few wild spikes where it memorized specific weird examples. Underfitting in general, overfitting in spots. Bad train error and a big gap.

One caveat on that ~0% ceiling. If you're classifying blurry images that even humans get wrong 15% of the time, then 15% train error isn't high bias. It's near-optimal. Always compare against what's actually achievable, not against zero.

The recipe

This is the flowchart I now run in my head every time a model underperforms:

1. Do I have high bias? (check train error)
If yes → bigger network, train longer, try a different architecture. Keep going until train error looks good.

2. Do I have high variance? (check the train-to-dev gap)
If yes → get more data, or regularize. Then go back to step 1 and re-check.

3. Repeat until both are low. Then stop.

What makes this useful is the order. Fix bias first, because a model that can't even fit the training data has nothing to regularize. And notice that the two fixes are different: throwing more data at a high-bias model does nothing at all.

Back in the pre-deep-learning days there was a real tradeoff. Reducing bias meant increasing variance and vice versa. Now? A bigger network reduces bias without much variance cost (as long as you regularize), and more data reduces variance without touching bias. The tradeoff isn't gone but it's much weaker.

Regularization: making the model less confident

When you have high variance and can't get more data (which is most of the time), you regularize.

For logistic regression, you add a penalty term to your cost function:

J(w, b) = (1/m) × Σ Loss(ŷ, y)  +  (λ / 2m) × ||w||²

That second term is L2 regularization. ||w||² is just the sum of every weight squared. λ (lambda) is how hard you punish big weights. It's a hyperparameter you tune on the dev set.

You usually skip b in the penalty. It's one number out of millions, it doesn't matter.

For a neural network, same idea, but you sum the penalty across every weight matrix in every layer:

J = (1/m) × Σ Loss  +  (λ / 2m) × Σ_l ||W[l]||²

The matrix version of this norm has a fancy name (Frobenius norm) but it's the same thing: square everything, add it up.

In backprop, this adds a (λ/m) × W term to your gradient. Which means the weight update becomes:

W = W - α × (backprop_gradient + (λ/m) × W)
W = W(1 - αλ/m) - α × backprop_gradient

See that (1 - αλ/m) factor? Every single step, before you even apply the gradient, your weights get shrunk slightly. That's why L2 regularization is also called weight decay. Your weights are constantly leaking toward zero, and only the gradient pushes back.

Why does this actually stop overfitting?

Two ways to see it.

The intuition: crank λ way up. The penalty dominates, so the optimizer drives weights toward zero to minimize cost. Weights near zero means many neurons contribute almost nothing. Your huge network effectively behaves like a much smaller, simpler one. Simpler network, less capacity to memorize.

Obviously you don't set λ that high. But somewhere in the middle you land on a network that's "just simple enough."

The better intuition (my favorite): think about tanh as your activation. When z is small, tanh is basically a straight line. When z is large, it saturates into curves.

Big λ → small W → small z → every neuron is operating in its linear zone. And a network made of linear pieces can only learn roughly linear things. It literally cannot draw the wildly wiggly decision boundary that overfitting requires.

Regularization doesn't just make the model smaller. It makes it smoother.

Dropout: randomly break your own network

This one sounds insane the first time you hear it.

On every training pass, you randomly switch off a chunk of neurons. Different ones each time. Train on the crippled network. Repeat.

Here's how you implement it (this is inverted dropout, the standard version):

keep_prob = 0.8   # keep 80% of neurons in this layer

d3 = np.random.rand(*a3.shape) < keep_prob   # boolean mask
a3 = a3 * d3                                  # zero out the dropped ones
a3 = a3 / keep_prob                           # ← the important line

That last line is what makes it "inverted," and it's the part people skip and then wonder why their loss is weird.

If you zero out 20% of your activations, the sum feeding into the next layer drops by ~20%. Dividing by keep_prob scales it back up so the expected value stays the same. Without it, every layer's output shrinks and your network quietly falls apart.

At test time: you do not use dropout. No mask, no scaling, no randomness. You want deterministic predictions, and because you already scaled during training, your activations are already at the right magnitude. Nothing to fix.

If you'd used the old non-inverted version, you'd have to manually rescale at test time. Which is exactly why nobody uses it anymore.

Why does dropout work?

Take one neuron in the middle of the network. Its job is to combine inputs from the layer below.

With dropout on, any of those inputs could vanish at any moment. So the neuron can't afford to bet everything on one input. It has to spread its weights out across many inputs, because any single one might be gone next iteration.

Spreading weights out shrinks their squared norm. Which means dropout ends up doing something similar to L2, just through a completely different mechanism.

A few practical notes:

You can set a different keep_prob per layer. Big weight matrices are where overfitting lives, so drop harder there (maybe 0.5). Small layers, leave them alone (1.0). Input layer, keep it near 1.0.

The annoying part: your cost function is no longer well-defined, because you're changing the network every iteration. J doesn't decrease monotonically anymore, so you can't debug with a nice descending loss curve. My workaround is to turn dropout off, confirm the loss decreases properly, then turn it back on.

Computer vision people use dropout almost by default, because they basically never have enough pixels-worth of data. Elsewhere, only reach for it when you actually see overfitting. It's not free.

Two cheaper tricks

Data augmentation. More data fixes variance, but real data is expensive. So fake it. Flip your cat photos horizontally (still a cat). Crop, rotate, zoom, distort. For digits, small rotations and warps. It's not as good as genuinely new data, since a flipped cat carries less new information than a new cat. But it's nearly free.

Early stopping. Plot train error and dev error as training goes on. Train error keeps dropping forever. Dev error drops, bottoms out, then starts climbing. Stop at the bottom.

Why does it work? At the start your weights are tiny (random init). As you train they grow. Stopping mid-training means stopping at a mid-sized W, which is roughly what L2 was trying to give you anyway.

But I'll be honest, I don't love it. Early stopping tangles two jobs together: fitting the training data, and preventing overfitting. Now one knob controls both, and you can't tune them independently. L2 keeps them separate. The only cost is you have to search over λ, which is more compute.

Normalize your inputs (seriously, just do it)

Two steps:

mu = np.mean(X, axis=1, keepdims=True)
X = X - mu                       # now mean is zero

sigma2 = np.mean(X**2, axis=1, keepdims=True)
X = X / np.sqrt(sigma2)          # now variance is one

Use the same mu and sigma from the training set on your dev and test sets. Don't recompute them. Both sets need to be transformed identically or you've broken your own distribution.

Why bother?

Picture feature 1 ranging from 0 to 1, and feature 2 ranging from 1 to 10,000.

Your weights end up wildly different in scale, and the cost surface turns into a long, thin, stretched-out valley. Gradient descent bounces back and forth across the narrow walls, inching forward. You're forced to use a tiny learning rate or it diverges.

Normalize, and that valley becomes a round bowl. Every direction is equally steep. Gradient descent walks straight to the bottom, and you can use a much larger learning rate.

Cheap to do. Never hurts. Just make it a habit.

Vanishing and exploding gradients

This is the problem that kept deep networks from working for years.

Imagine a very deep network. Simplify hard: linear activations, ignore b, and every weight matrix is the same:

W[l] = [[1.5, 0], [0, 1.5]]

Then your output is roughly 1.5^L × x, where L is the number of layers.

With L = 150, that's 1.5^150. An astronomically large number. Your activations explode, your gradients explode, your loss becomes NaN.

Now flip it to 0.5. Output becomes 0.5^150, which is effectively zero. Activations vanish. Gradients vanish. The early layers get updates so small they never learn anything.

The scary part is how sharp this is. Slightly above 1, explode. Slightly below 1, vanish. In a deep network there's almost no middle ground, because you're compounding the error 150 times.

The single neuron fix

Look at one neuron with n inputs:

z = w₁x₁ + w₂x₂ + ... + wₙxₙ

The more inputs (larger n), the bigger z gets, just from adding more terms. So to keep z reasonable, each individual wᵢ should be smaller when n is larger.

That gives you the initialization rule. Set the variance of your weights to 1/n:

W = np.random.randn(shape) * np.sqrt(1 / n_prev)

For ReLU, 2/n works better in practice (this is He initialization):

W = np.random.randn(shape) * np.sqrt(2 / n_prev)

For tanh, 1/n is the common choice (Xavier initialization).

It doesn't fully solve vanishing/exploding gradients. But it makes the compounding start from a much safer place, and in a 150-layer network, where you start matters a lot.

What I'd tell past me

The whole thing collapses into a loop:

Check train error. Too high? Bigger model.
Check the gap. Too big? More data or regularization.
Normalize your inputs. Initialize your weights properly.
Repeat.

That's it. No mysticism. Most of the time when a model isn't learning, it's one of these, and the fix is on this page.

What still bugs me is the λ search. Tuning it properly means training the model over and over just to compare numbers, and there has to be a better way than brute force.

Working on it.

Stop Prompting. Start Briefing: What Changes When an AI Can Plan for Three Days Straight

Asfiya M — Wed, 08 Jul 2026 18:11:41 +0000

Anthropic built Fable 5 for long-horizon work. Give it a real goal and it can plan across stages, delegate pieces of the problem to itself, check its own output, and keep going without a babysitter. It holds a million tokens of context, which in plain terms means you can hand it a pile of research, a brand doc, three competitor teardowns and a messy Slack thread, and it won't quietly forget the first thing you told it by message four. In one of Anthropic's own tests, it handled a 50-million-line Ruby codebase migration in about a day. That's not a chatbot trick. That's a different category of tool.

I saw a creator use this exact shift to take an Instagram account with no business behind it and build out a brand, a product, a content calendar and a launch plan, all in a single chat. The interesting part wasn't the output. It was the pattern: use the expensive, deep-thinking model once to build the "brain," then hand the execution to cheaper, faster models forever after.

That pattern generalizes way past content creation. Here's where it actually pays off.

1. Turning a vague idea into a real go-to-market plan

If you're a solo founder or a contractor trying to position yourself in a crowded niche, the hard part was never writing. It was figuring out what to say and to whom.

Feed Fable 5 your background, a few competitor profiles, and an honest description of who you're trying to reach. Ask it to argue against its own ideas before it commits to one, the same way an investor would poke holes in a pitch. Because it can hold everything you gave it in context at once, it stops giving you generic advice and starts giving you a plan that's actually shaped by your specific market gap.

2. Auditing a legacy codebase before you touch it

Anyone who's inherited a five-year-old repo knows the real cost isn't writing new code, it's understanding what's already there without breaking it.

Point Fable 5 at the whole thing and ask it to map dependencies, flag dead code, and propose a migration order before you write a single line. Because it can run for hours instead of minutes, it doesn't need the codebase pre-summarized for it. It reads the actual thing.

3. Making sense of document-heavy analysis

If your job involves financial models, legal contracts, or research papers full of charts and tables, you already know most AI tools choke on anything that isn't clean text. Fable 5 is built to read charts and tables inside PDFs directly and reason across them, which matters if your actual workday is finance decks and messy scanned reports rather than tidy prompts.

4. Building the operating system for a small business once

This is the part the creator I mentioned nailed. Instead of asking an AI to write one post at a time, ask it to build the whole system: positioning, offer, content pillars, and a 30-day plan, all connected to each other. Do this once, save the output as a set of documents, and every future request (to any model, even a cheap one) inherits that context instead of starting from a blank page.

Why this actually matters, not just sounds cool

The obvious benefit is depth. A model that can plan across stages and check its own work catches mistakes a single-shot answer never would.

The less obvious benefit is cost. You don't need to run your expensive model on every task forever. You run it once to build the strategy, the brand rules, the technical map, whatever your "brain" is, and then your daily driver model executes against it for weeks. That's the actual economics of this generation of tools: pay for depth once, get speed everywhere after.

The last benefit is one nobody markets well: it stops you from having to re-explain your business every single time you open a new chat. That alone is worth more than any single feature on a spec sheet.

If you've been treating your AI model like a vending machine for quick answers, try handing it a real problem instead. Give it the goal, the constraints, and the mess. Let it plan. You might be surprised how much of the thinking it can actually do for you.

My friend froze his opinions in 2016. I didn't. Now what?

Asfiya M — Mon, 29 Jun 2026 09:46:39 +0000

A friend repeated something back to me last month. An opinion. He said it like settled fact, the kind of line you don't bother arguing with.

I argued with it.

Then I realized the opinion was mine. I'd said it to him years ago, said it well enough that it stuck, and he'd been carrying my old take around like it was current. Meanwhile I'd swapped it out for a different one somewhere along the way and never told a single person. Including, apparently, myself.

That's a strange feeling. Like running into an old photo of yourself and not loving the haircut. Except it isn't a haircut. It's something you used to believe with your whole chest.

Nobody decides to change their mind

Here's the part I keep coming back to. The update never happens at a desk. You don't sit down one morning and go, right, time to retire opinion number fourteen. It happens quietly, in the background, one conversation and one bad day and one thing you read at a time, until some afternoon a friend hands you the old version and you flinch.

And we resist that flinch hard. Because changing your mind feels like losing. Admitting the old take was wrong feels like admitting you were the kind of person who'd hold a wrong take in the first place. So we defend it.

You've done this. I've done this. Argued a point ten minutes past the moment you stopped believing it, purely because backing down in front of someone felt worse than being wrong.

The opinion stops being a thought you have. It becomes a thing you are. And nobody likes deleting part of themselves in the middle of an argument.

This is the one place a machine has it easier

When a model's answers start drifting, when the world moves and its predictions quietly go stale, you retrain it. The model doesn't sulk. It doesn't insist it was right in 2019. It doesn't take the new data personally.

You feed it the updated world and it adjusts. No ego. No face to save.

We can't do that. We get the new evidence and the first thing that fires isn't "let me update," it's "let me defend." Which is how a person sits on an outdated opinion for a decade while looking exactly as certain as the day they formed it. Same confidence. Worse answer. They never got retrained, and unlike the model, some part of them didn't want to be.

The opposite trap, and you know this person

You also meet the version who had one bad experience and turned it into a permanent rule. One landlord, so all landlords. One breakup, so all relationships. The sample size was a single rough afternoon and the conclusion now runs the rest of their life.

A model that does this we call overfit. It memorized a handful of examples so hard it can't handle anything new. Same wiring in people, just with feelings bolted on.

We take this seriously for machines and not for ourselves

We monitor models for drift and retrain them on a schedule. We get genuinely nervous about one that hasn't been updated in a year.

Then we run opinions from five years ago at full volume and never once check the date on them.

The people who stay interesting to talk to aren't smarter than everyone else. They've just made peace with being wrong in small amounts, often, on purpose. They treat changing their mind as maintenance, not defeat. Everyone else is quietly protecting a version of themselves that stopped shipping updates a long time ago.

The part worth fixing

I never corrected my friend. Felt strange to argue with my own old work.

But I went home and tried to list the opinions I haven't actually questioned since the day I formed them. Found more than I'd like. Some I still stand by. A few were just sitting there, sounding sure of themselves, running on data I collected back when I was a different person.

The fix was never about being right. It's about noticing when you've quietly turned into someone new, and remembering to update the part of you that still talks like the old one.

Three Weeks Into AI and My Best Skill Is Closing Tabs

Asfiya M — Sat, 27 Jun 2026 13:09:50 +0000

Last week I finally understood decision trees.

Not the textbook version. The real one. A tree is just the checklist you already run in your head, turned into code. Ask the question that splits the group best, then ask again inside each smaller group. Ask, split, repeat. That's it.

I felt smart for about an hour.

**Then I read one more line: **change a few rows of your data and the whole tree can rebuild itself into something different. The thing I just learned was shaky. The fix is ensembles, which is a whole other layer I haven't touched yet.

That's the part nobody warned me about. Learning AI isn't one mountain. It's layers, and every layer makes the one below it look incomplete.

The floor keeps dropping

Here's the pattern I keep hitting.

I learn a thing. I feel like I get it. Then I learn the thing that sits on top of it, and suddenly the first thing was just the warm-up.

Linear regression felt like the whole game until logistic regression showed up. Logistic felt solid until trees. Trees felt clever until I found out they're unstable and ensembles exist. I haven't even reached the layer after ensembles and I already know it's there.

If you're starting out, here's what would've saved me some panic: feeling like you understand something is not the same as being done. It usually means you've cleared one layer and the next one is about to load.

That's not discouraging. It's just the shape of the thing. Once you expect it, you stop feeling stupid every time the floor drops.

The rabbit hole is real and it looks like progress

The dangerous part is what happens next.

You learn trees, you hear "ensembles," so you open a tab. That tab mentions XGBoost. XGBoost mentions gradient boosting. Gradient boosting mentions a paper. Three hours later you have eleven tabs open and you've built nothing.

It feels like progress because you're reading hard things. It isn't. It's just falling.

**What I do now: **when I hit the next layer mid-learning, I write it down and close the tab. "Ensembles, look at next." Then I go finish the thing I was actually on. The note means I won't forget it. Closing the tab means I won't drown in it today.

Depth is good. Depth at the wrong time is just a nicer way to procrastinate.

"Which tool should I use" has a boring answer

The other thing that almost broke me is the tool zoo.

I spent a week on APIs. Just for two systems to talk to each other, there's REST, GraphQL, SOAP, gRPC, and WebSockets. Each one has fans who'll tell you it's the right one. As a beginner you sit there thinking you have to learn all five before you're allowed to build anything.

You don't.

REST covers the large majority of cases. gRPC is for fast backend to backend stuff. WebSockets are for live two-way things like chat or live prices. The "best" tool doesn't exist. There's only the right tool for the job in front of you, and most of the time the job is boring and REST is fine.

Most teams overthink this. Reaching for gRPC or GraphQL early adds tooling pain for almost no gain. Once I saw that, the panic of "I don't know all the tools" turned into a calmer question: what does this specific problem actually need?

There's still a scarier version of this I haven't solved. What if there's a tool that's perfect for my problem and I just don't know it exists? No clean answer yet. Right now I solve it by building the dumb version first, then asking people who've done it longer what they'd have reached for. The dumb version is rarely wasted. It teaches you what the problem actually is.

Sometimes the answer isn't AI at all

This one surprised me.

I kept assuming automation meant an LLM somewhere in the pipe. It doesn't. A lot of "automation" is just basic conditions. If this, then that. No model, no fine-tuning, no GPU.

Half the maturity in this field seems to be not reaching for the fancy thing when a plain one works. An LLM is the answer to fewer problems than the hype suggests. Learning to tell the two apart is its own skill, and it isn't a technical one.

Be skeptical of clean numbers

Last layer, for now.

I read a research paper comparing two big data tools. The numbers didn't add up. It claimed more memory and processing power than its own machines had, and never explained why. Another paper claimed a 56 to 69 percent improvement, but I only had the summary, and summaries always show the best result against whatever weak thing made them look good.

Reading papers taught me less about the tools and more about not swallowing claims whole. When something is presented clean and impressive, that's usually the cue to ask what got left out. Not because people lie, but because nobody advertises their own gaps.

What I'd actually tell a beginner

I'm three weeks deep, so take this as field notes, not a map.

Pick one real problem. Find the simplest thing that solves it, even if it's embarrassingly basic. When you hit a rabbit hole, write it down and close the tab. Match the tool to the job, not to the hype. And when a number looks too clean, poke it.

I still don't know what I don't know. Next month's version of me will probably think this post missed the point. ngl, that's kind of the whole thing about layers.

The floor's going to drop again. I'm starting to think that's the job.