~~side note ~~
was it just me or the cognition and factory ai incident was kind of like the kendric/drake of tech?

underneath the discourse are two real approaches.

you can buy a harness like Claude Code, Codex, Hermes, or OpenCode and rebuild your software development lifecycle around it.

or you can buy an out-of-the-box factory, connect it to Slack and GitHub, and review the massive pull requests it creates.

honestly, i think the answer depends on the organization.

some teams want control over context, routing, models, and verification.

others want the outcome without becoming an infrastructure company for agents

it is too early to declare one universally better.

at , we wanted to get comfortable with autonomous graphs and long-running loops before turning them into our default way of shipping.

we already used agents for every ticket. but we had never let a loop own something large enough to expose whether the system actually worked.

then a user asked:

when is android coming out?

our plan was to launch on iOS, perfect it, and eventually spend a long sprint on android.

during a 1:1, i asked our CEO whether we intended to make Android meaningfully different.

“feature wise, it’s the same.”

so that weekend it was a perfect opportunity to try loops out.

it was not on the roadmap. nobody assigned it to me. there was no launch plan, no android team, and honestly not much direction.

perfect conditions for an experiment.

the repo was the experiment

the project started as a native port of the iOS app. it grew in three pushes.

the first push was the port: roughly 150 commits, moving module by module from the iOS source and our shared OpenAPI contract.

this was not “build me an Android app.” every screen needed a source. every network shape needed a contract. every Android divergence needed a reason.

translation with receipts.

the second push was feature close: another 200+ish commits covering all features such as , in app notification center, seasonal pushes, feature flags, CI, widgets, observability, and release plumbing.

anything blocked on Google Play, oauth, fcm, or production provisioning went behind a flag or a no-op fallback. the code could continue moving even when an external account or credential was not ready.

the third push was the parity loop.

it compares android against a pinned iOS build, turns every gap into a node, launches the work, tries to refute the result, and keeps going until the graph is dry.

the 315 commits on main came from the first two pushes. parity had to earn its way through integration/ios-parity .

the factory ran on an old 8 GB Mac

this entire experiment ran on a base M2 Mac with 8 GB of RAM.

not a rack of GPUs. not a giant cloud runner. one small laptop trying to run an orchestrator, many coding agents, git worktrees, Xcode, Gradle, an iOS simulator, and an Android app.

the physical constraint became part of the graph.

i connected a real android phone over usb. android builds and tests could install and run on the device while the Mac handled the pinned iOS simulator. a build and device lease protocol made sure expensive jobs ran one at a time when they competed for memory.

the agents could work in parallel. Xcode and Gradle could not.

parallel agents are great. parallel Xcode and Gradle on an 8 GB Mac is performance art.

the factory floor: a base M2 Mac with 8 GB of RAM, a pinned iOS simulator, and a USB-connected Android phone doing real-device verification.

the limitation was useful. it forced resource ownership to become explicit.

a worker could not just “use the device.” it had to acquire the lease, run a bounded job, store the evidence, and release the resource. that is not a workaround. that is orchestration.

building the factory before asking for output

i spent the first full weekend setting up the repo, architecture, context, rules, ledgers, and device protocol.

almost no product.

if you are used to prompting, this feels wrong. you can ask an agent to write compose screens immediately and it will happily cook.

then agent two invents another architecture. agent three changes the API contract. agent four starts gradle while xcode is already eating the machine.

now you own 40,000 lines of artisanal slop.

the harness combined Claude, Codex, and OpenCode.

my agent-config repo (yes you should have one to not be harness locked in) shows the general shape: investigate first, make surgical changes, use specialist reviewers, bring in a council when disagreement helps, and verify before stopping.

skills are not magic prompts. they are compressed operating knowledge.

when i caught myself repeating an instruction, correcting the same failure, or explaining the same architecture choice, i tried to turn it into a rule, skill, test, or gate.

codifying yourself does not remove you from the loop. it means you do not have to personally run the same loop forever.

stop chaining your agents

almost every multi-step agent workflow i open is secretly a queue.

do A, then B, then C, then D. one head. one context. one thing at a time. eventually the context fills up and the agent quietly forgets why it started.

people call this a workflow because it has steps. technically yes.

the better question is not “what happens next?”

it is: does the next step actually need the previous step’s output?

if no data crosses between them, there is no dependency. cut the arrow. run them side by side.

THE DEFAULT LINE

spec → implement → review → merge

THE GRAPH

spec
     → implement
     → [iOS diff + docs + correctness + parity + simplicity]
     → device gate
     → merge

nodes are jobs. edges are data.

this framing shows where work can fan out, where a barrier belongs, where a verifier belongs, and where an expensive agent step should really be a ten-line deterministic script.

agents for judgment. code for plumbing.

what the graph actually does

one long-running orchestrator wakes every 30 minutes.

it does not treat its transcript as project state. it rereads Linear and git every time.

Linear says what work exists, what is blocked, and what done means. git says what happened. if they disagree, the loop does not get to invent a third reality.

each parity gap becomes a node:

spec → implement in an isolated worktree → correctness review → iOS parity review → simplicity review → device gate → squash merge into integration/ios-parity

implementation happens in isolated worktrees so parallel changes cannot step on each other.

then three independent reviewers try to kill the change.

one checks correctness. one checks iOS parity. one checks simplicity. all three are refute-by-default.

the implementer wants to merge. the reviewer’s job is to explain why it should not. agents have author bias too. they can also generate 4,000 words defending a bad abstraction before breakfast.

the device gate runs the pinned iOS build and the Android PR build with explicit leases. the Android phone provides real-device evidence while the simulator provides the iOS reference.

every screen gets a flow document and a checklist row. a daily drift-intake job diffs iOS develop against the pin and creates new nodes.

parity is not a destination when iOS keeps changing underneath the port.

routine merge conflicts go to a resolver script. it reconciles file histories and the ledgers, then re-anchors ledger rows against the merged source.

no model call required.

agents for judgment. code for plumbing.

graphs are shape. loops are time.

the graph describes the work. the loop decides whether to run the graph again.

“keep going until done” is not a stopping condition. it is a prayer with a token budget.

the loop is closer to this:

while (unfinished nodes exist) {
    read Linear and git
    select runnable nodes
    launch bounded workflows
    verify the outputs
    merge survivors
    write failures and evidence back to state
}

stop when the graph is dry

the important line is write failures back.

dedupe against everything the loop has seen, not only what it confirmed. otherwise a rejected finding returns as “new” 30 minutes later and you pay to rediscover the same dead end.

when the same failure appears twice, do not only patch the output. patch the loop.

make a contract, skill, test, review rule, or gate. the system gets harder to fool because it remembers how it was fooled.

verification is the product

the loop has now run more than 200 workflows.

individual workflows used between roughly 1.0 and 3.4 million worker tokens. the mean was around 1.8 million.

about 65% of worker spend went to reviews and gates, not writing code.

a node took around five rounds on average because the reviewers would not pass anything unverified. yes, that included ledger line numbers.

apparently i built a bureaucracy, but for robots.

this is an absurd amount of tokens for something that was not on the roadmap.

but it made one thing painfully clear: generation is cheap relative to confidence.

optimize for raw output and you get a slop cannon. optimize for accepted change and most of the system becomes verification.

the next optimization is model routing. bounded extraction and mechanical edits can go to cheaper workers. architecture, synthesis, and adversarial review keep the stronger model.

the metric is not tokens burned.

it is accepted change per dollar, reviewer minute, and escaped defect.

the original idea came from Bun

the core idea came from Jarred Sumner’s write-up on rewriting Bun in Rust.

the Bun team used around 50 dynamic workflows over 11 days. at peak, four workflows ran in separate worktrees with 16 Claude workers each.

the repeating shape was implementer, adversarial reviewers, fixer. compiler errors became a queue. test failures became another. all six CI platforms turning green became the stopping condition.

the lesson was not “spawn 64 agents and tokenmaxx your way into enlightenment.”

the lesson was that huge work becomes tractable when you split it into bounded nodes, isolate writes, preserve evidence, and loop around deterministic feedback.

Lora Android used the same primitive under much dumber physical constraints.

one base-model laptop. one Android phone. two mobile apps requiring visual and behavioral comparison. provisioning that might not exist yet. a source app changing every day.

same primitive, different graph.

how slop stays out

a graph does not make generated code correct.

it gives you more places to say no.

Polylane’s production-impact system makes a similar point.
generic tests and diff review are not enough when the change is disconnected from the production system

around it.

they connect code to cloud resources and telemetry, then investigate possible failure paths against reality.

for android parity, the system is larger than the android diff. it includes iOS behavior, gateway contracts, flags, linear acceptance criteria, device state, CI, and the release environment.

“it compiles” tells me almost nothing.

1. does it match intended behavior? the spec and Linear node are the contract.

2. does it match iOS where parity matters? the pinned build is evidence, not vibes.

3. is it simpler than the alternatives? agents love solving local ambiguity with global machinery.

4. does it work on a device? simulator and real-device evidence beat a confident paragraph.

5. can failure stay local? worktrees, flags, fallbacks, and leases contain damage.

6. can the next loop understand what happened? every result writes back to git, Linear, or a ledger.

observability is the difference between automation and psychosis.

you should be able to see every worker, decision, rejection, retry, and dollar.

otherwise you did not build a factory. you released raccoons into the server room.

lessons learnt: the engineer is not dead. the category is.

there is a lot of talk about software engineering disappearing.

i think the narrower identity is disappearing faster than the work.

coding used to be the gate between an idea and a product. that gate is collapsing. non- technical people can now build real software. great.

then complexity shows up.

where is the code? how do we deploy it? what happens when the database dies? why did the API bill become $40,000? why does the agent keep “fixing” auth by deleting auth?

the pendulum swings back toward engineering.

an engineer adds architecture, tests, constraints, observability, and economics. then the agent and product owner can move again. each pass leaves behind better rails, so the swing back gets smaller.

eventually the useful role sits somewhere in the middle.

the engineer who understands product. the product person who can inspect systems. someone who can read a balance sheet and a stack trace.

call it an agentic builder, agentic product engineer, or professional maker of things. titles are mostly occupational compression anyway.

this article is the best evaluation i have seen how the role is evolving

you are not valuable because you type code faster. you are valuable because you can draw the graph, choose the constraints, read the evidence, and know whether the thing was worth building

what i learned

1. start with one repeated pain. do not build a software factory because the phrase sounds cool.

2. make nodes boring. one job, explicit input, validated output.

3. cut fake dependencies. if no data crosses the arrow, stop making it wait.

4. use code for edges. routing, dedupe, retries, budgets, and stopping conditions should be deterministic.

5. use agents for judgment. implementation, synthesis, classification, and adversarial review are where models earn tokens.

6. isolate parallel writes. worktrees are cheaper than forensic archaeology.

7. make reviewers hostile. “looks good” is not a verification strategy.

8. make loops converge. track seen-state, dry rounds, budgets, and deadlines.

9. store truth outside the chat. git, Linear, tests, ledgers, and telemetry survive compaction.

10. when failure repeats, fix the loop. the output is temporary. the process is the asset.

from product to launch

android started as a directionless weekend side project.

that was the best part.

there was no pressure to pretend the first architecture was right. the repo could be a lab for graphs, loops, context, verification, and the question i actually cared about:

can we turn software development from a sequence of chats into a system that compounds?

the result is not “AI built an Android app.” that framing deletes all the interesting work.

the result is a graph where Linear and git hold truth, agents work inside isolated nodes, independent reviewers try to kill every change, devices provide evidence, iOS drift creates new work, and the loop keeps running until it can prove it should stop.

all of it ran on a base M2 Mac with 8 GB of RAM and a phone plugged into USB.

the constraint did not prevent the factory. it forced the factory to become real.

this is how we are trying to perfect the loop from product to launch at Lora.

product context becomes executable work. implementation fans out. evidence flows back. bad changes die before production. every launch teaches the next loop what to do better.

a prompter asks a question.

an architect draws a graph.

after a couple or real engineer eyes on iteration, we are up for pre-registration

sources and further reading

→ Rewriting Bun in Rust, Jarred Sumner

→ How we prevent slop from hitting prod, Polylane

→ Tomasz Tunguz on software factories

→ Joseph Suarez on agent orchestration

browse the job posts, and if any look like a match for you, just reply to this and if relevant i’ll make an introduction.

• head of engineering -holly ai

  applied ai for the government human capital and budgeting stack.

• founding engineer - smoke ai

  agent workspace that runs sales, marketing, and ops for small teams.

—housekeeping—

recent stats show more than 30% of readers read the substack

but don’t subscribe?

why?

doesn’t make sense!

we’re close to 3k subscribers!

Subscribe now

so i just read a pretty long essay

it’s been open in my browser tab for close to a month now

it’s titled “the future of everything is lies, i guess”

subtitle - “bullshit about bullshit machines”

—now’s the point you realize the title isn’t original—

—still……please read till the end- :) —

think both the title and the subtitle are heavy?

the content definitely is

the essay is

one of the most through ,

clear-eyed skeptical takes on ai i’ve read

ever

it outlines a ton of valid problems within the ecosystem

some i don’t think i even wanna comment on

but here’s some points that stood out for me

unreliable narrators and the jagged edge

the essay argues that llm are not intelligent

—i go back and forth on this—

—tldr if pattern matching is intelligence then llms are intelligent—

they are sophisticated pattern matchers that produce text

without any grounding in truth. ‘

they have a “jagged edge” where they’re simultaneously brilliant and idiotic,

and you can never predict which you’ll get.

they’re unreliable narrators by design, not by accident.

i agree with this more than most people in ai probably would.

i’ve said it directly before

ai is only as good as the person using it.

it doesn’t replace taste, judgment, or accountability.

i’ve had agents completely misinterpret commands because of tiny context shifts.

i talked about this last year about that

until we crack human-like causal inference,

we’re just building better pattern matchers

but here’s where i diverge from this:

acknowledging the jagged edge doesn’t mean you stop using it.

it means you get better at the steering wheel.

—really proud of this analogy—

the human contribution gets smaller and more concentrated,

but it doesn’t disappear

— it becomes more important—

managing the chaos

he points out that ml models are chaotic systems.

they are sensitive to initial conditions, vulnerable to adversarial attacks, and inherently unpredictable.

embed them in larger systems, and you get cascading unpredictability

the whole thing becomes less controllable, not more.

this is real.

i’ve literally frozen my machine running 5 claude instances + cursor + whisper + desktop assistant simultaneously.

the system-level chaos is not theoretical for me

i dont think this should be framed as a reason for despair.

i frame it as a reason for documentation.

organizations with strong writing cultures will win

because agents need written context to function.

if the system is chaotic,

you manage chaos with structure.

you don’t abandon the system.

ghosts in the machine

models are cultural artifacts.

they encode and reproduce existing media.

kingsbury notes that humans anthropomorphize them dangerously

and we lack frameworks for relating to them appropriately

we either treat them as oracles or dismiss them entirely.

this extremly hits hard deeply.

(again not to sound like an ai)

compared big tech to gibson’s zaibatsus controlling information and manipulating reality.

we are living inside the sci-fi warnings.

geb predicted the current ai mess better than most futurists.

but the answer isn’t to avoid ai or refuse to engage

it’s to engage with clear eyes.

the original hacker culture was about understanding systems deeply,

not worshipping them.

the poisoned well

ml shifts the cost balance

creating content becomes nearly free while consuming

filtering it becomes expensive.

kingsbury argues crawlers degrade the open web,

the information environment gets polluted with slop,

and truth becomes harder to find.

here’s my 2 cents on this

-my core thesis on  ai privacy: build a full hardware-and-software ecosystem where privacy is convenient, not an obstacle. if the open web is getting poisoned — and it is — then local, private, trusted systems become the answer. the cyberdeck isn’t cosplay. it’s architecture. air-gapped, privacy-first, zero third-party trust. local inference, mesh networking, offline knowledge. it’s the logical conclusion of self-sovereign AI in a world where the public information layer can’t be trusted anymore. kingsbury diagnoses the disease. i’m trying to build one version of the cure.

the new work

in the essay there is an arguement software development is becoming “more like witchcraft than engineering.”

it calls the enthusiasm for “ai coworkers” preposterous, suggesting that automation paradoxically makes systems less robust because humans lose the ability to intervene meaningfully.

cannot disagree more

calling ai coworkers “preposterous” ignores what’s actually happening on the ground. i run multi-agent workflows daily.

i do pull requests, (non ai)

i push to staging then production

on a live platform with paying users.

ai didn’t make my work less legible

it made the bar higher.

everyone is now a 10x engineer compared to two years ago.

that raises the bar. it requires more self-awareness, sharper judgment, and better taste.

software dev isn’t becoming witchcraft.

it’s becoming more like directing

you need to know what good looks like even if you’re not writing every line.

the skill isn’t coding.

it’s seeing problems clearly and making better decisions under ambiguity.

kingsbury is right that blind trust in ai makes systems fragile.

but practitioners who understand the jagged edge and document their systems aren’t doing witchcraft

they’re doing engineering at a different altitude.

the blur of new jobs

kingsbury predicts new roles will emerge

at the boundary between human and ML: “incanters” (prompt specialists), process engineers who design human-ai workflows, and statistical engineers who control output quality.

work reorganizes around the interface between human judgment and machine capability.

these are predictions ,

i dont have a strong opinion here

because predicting specific job titles is a game i can’t win.

what i will say is that roles are already collapsing

product managers ship features,

designers build prototypes,

engineers make product judgment calls.

the boundaries are blurring faster than anyone can categorize.

trying to name the new jobs feels premature.

i’d rather focus on the underlying skills that transfer regardless of title:

judgment, taste, decision-making under ambiguity,

and the ability to steer powerful systems.

where do we go from here

kingsbury acknowledges he hasn’t devoted space to the wonders of ml and wrestles with how to move forward given all the problems he’s outlined.

this is where the practitioner and the theorist diverge most.

he spent 50 pages on the problems. i

spend every day building despite them.

the go champion at the sf go club said it best —

after ai surpassed all human play, he laughed and said, “i find it fascinating that after all these years, i can still learn and discover something new because of ai.”

same.

the answer isn’t optimism or pessimism.

it’s building with clear eyes, documenting everything, owning your own systems,

and knowing that the steering wheel matters more than ever

— not less

browse the job posts, and if any look like a match for you, just reply to this and if relevant i’ll make an introduction.

head of engineering -holly ai

applied ai for the government human capital and budgeting stack.

—housekeeping—

recent stats show more than 40% of readers read the substack

but don’t subscribe?

why?

doesn’t make sense!

Subscribe now

---

i’ve been hearing about the term “post-scarcity” a lot

every time a new model drops that moves the needle.

something out of brave new world

it’s not.

to put an actual definition behind it

an abundance economy is one

where goods and services needed for a decent life can be produced in huge quantities with minimal human labor.

cheap or effectively free at the point of use.

the thing that i now have clarity on

abundance is not the end of economics.

it’s a shift in what we’re fighting over.

not everything becomes abundant.

land, time, attention, status

those stay scarce.

economics doesn’t disappear,

it reorganizes around the stuff you still can’t copy-paste into existence.

compounding cognition

production wont look like headcount and hours anymore.

intelligent systems plus humans form what i’d call compound cognition machines processes and organizations that learn and improve on their own.

productivity stops scaling linearly with how many people you hire.

it scales with how fast your systems can learn, adapt, and pattern-match.

automated manufacturing, self-replicating machines, AI-driven logistics

all of this makes physical goods cheaper and more reliable, given enough energy and raw materials.

if you’ve been following what i write about agents and superwork and single-person companies, this is the endgame.

the abundance economy is built by tiny human teams orchestrating huge automated capability. three people and a fleet of agents replacing what used to take 50.

what actually becomes scarce

there’s a pattern here that keeps repeating through history and nobody talks about it enough.

when technology made information cheap (printing press, internet), attention became the scarce resource. suddenly everyone could publish, but not everyone could get read.

when distribution became abundant, trust became scarce. anyone could reach you, but you couldn’t trust everyone who did.

now ai is making creation itself abundant.

and so judgment and taste become the new bottlenecks.

deciding what to build, what to believe, and where to point the machines.

here’s a clean rule that i keep coming back to: when something becomes 10x easier to produce, its price collapses.

when something becomes 10x harder to filter, its value explodes.

that’s the whole game.

street-level abundance

let me paint what this actually looks like day to day, because the macro stuff means nothing if you can’t feel it.

the basic bundle: housing is stable and heavily subsidized or automated. food and energy are cheap due to advanced production and logistics. information, education, health guidance

all provided by near-free AI services.

most people do far less coercive labor.

survival is covered.

“jobs” tilt toward creative work, care work, exploration, and coordination.

not routine production.

that’s gone.

picture a 22-year-old in 2040. rent is low.

ai handles most admin tasks

scheduling, taxes, paperwork, research.

the real fight isn’t for survival anymore.

it’s for audience and belonging.

the visible inequality isn’t in stuff, it’s in experiences and status: exclusive places, tight communities, unbottled attention from high-leverage humans, and the ability to steer powerful systems.

someone will say “this sounds utopian”

and yeah, maybe.

but the trajectory is already pointing here. the question is speed, not direction.

markets when stuff is cheap

zoom back out to firms and markets for a second.

value creation shifts from making units to orchestrating intelligence.

companies compete on how well their systems learn and personalize, not on raw production capacity.

most “products” move to freemium or public-good tiers.

monetization clusters around premium access

— priority, latency, customization —

plus community,

and high-stakes domains like health, finance, governance.

the biggest moats sit in the scarce layers:

proprietary data, long-term trust with users, regulation, and control of compute and energy infra.

raw content and code? over-abundant.

low value. attention? highly scarce.

high value. trust and reputation? scarce, slow to build.

high value. compute and energy? capital-intensive.

high value. human judgment?

non-scalable. the highest value there is.

if you’re building something right now, look at that list and ask yourself which layer you’re sitting on. that’s your answer.

who owns the sun amongst the many questions i still have……..

here’s where it gets political and i’m not going to pretend it doesn’t.

a post-scarcity society is only “abundant” if people can actually access what’s produced.

politics decides how automated output is distributed.

three governance paths i keep thinking about:

private cloud-lords controlling most compute (where we’re trending), sovereign/national AI infrastructure (what some countries are trying), and decentralized public compute and model co-ops (the dream, honestly).

the tension is simple:

abundance of capability vs scarcity of power.

who gets to steer the gains of automation becomes the central political fight of the next two decades.

maybe the next century.

i don’t have the policy answers. but the stakes need to be legible for everyone, not just people who read twitter.

abundance without automatic meaning

last thing. and this might be the most important thing.

even in material abundance, people still face scarcity of meaning, attention, and recognition.

post-scarcity doesn’t auto-solve loneliness, status anxiety, or purpose.

if anything it might make them worse because you can’t blame your circumstances anymore.

work shifts from “i must do this to survive” to “i choose to do this to matter.”

and not everyone has a ready-made answer for that. most people don’t.

in an abundance economy, the hard part is no longer “how do i eat?” but “what is worth pointing all this power at?”

that’s the question i keep sitting with. probably the one we should all be sitting with.

browse the job posts, and if any look like a match for you, just reply to this and if relevant i’ll make an introduction. everyone is hiring for swe’s

orde -series b

supply chain and logistics platform connecting public and private schools to fresh breakfast and lunch for students, cooked and delivered by local chefs.

stealth - seed

ai operating system for the $150b home care industry.

—housekeeping—

recent stats show more than 40% of readers read the substack

but don’t subscribe?

why?

doesn’t make sense!

Subscribe now

---

wrapper vs. agent

most people using ai right now are not using an agent.

they are using a wrapper.

and the difference matters more than almost anything else in this conversation.

a wrapper is a ui layer on top of an api.

you type something.

it responds.

the session ends.

there is no memory.

there is no autonomy.

there is no persistent understanding of who you are,

what you are building, or what happened yesterday.

a wrapper is a tool that forgets you the moment you close the tab.

an agent is fundamentally different.

an agent has memory. it has tools. it has context that persists across sessions.

it does not just respond to you.

it acts on your behalf

always within the constraints you define ,

with an understanding of your work that deepens over time.

the distinction is not semantic,

it determines whether ai is a novelty you interact with briefly,

or an extension of how you think and work.

a great deep read on this

elif5

strip everything down to the simplest version

an ai agent is a personal executive assistant that learns.

not a chatbot. not a search engine. not a fancy autocomplete.

it handles the repeatable.

the mechanical.

the administrative.

the drafting.

the scheduling.

the first pass on research. the boilerplate. the formatting. the sorting. the filing.

the things that consume hours and require no real judgment.

and it gets better over time because

it remembers what you told it,

learns your preferences,

and builds up an understanding of your work.

you do not need to be an engineer to start.

a good place to start:

install claude code.

write a claude.md.

describe what you do,

what you are working on,

what matters to you.

start using it for real work, not toy experiments.

let it learn.

go further: set up obsidian as your local knowledge base.

start building a personal wiki.

document your projects, your decisions, your patterns.

feed that into your agent’s context.

let it compound.

the complexity is what would personlize your agent for you.

the foundation is accessible to anyone willing to spend an afternoon setting it up.

the gap between people who do this and people who do not will compound faster than any previous technological advantage.

not because the tool is magic. but because leverage always compounds for the people who actually pick up the lever.

great resource to structuring obsidian and claude code

the death of “vibe coding”

karpathy coined the term “vibe coding”.

it captured the feeling of working with ai

less typing, more directing, trusting the model to fill in what you meant.

but the term has become a liability. “vibe coding” implies looseness.

imprecision.

aesthetic over rigor.

it makes the work sound casual.

what is actually happening is agentic engineering, and the difference is massive.

we have evolved through three distinct eras:

-prompt engineering (crafting individual prompts),

-context engineering (optimizing what goes into the context window through .md files),

-and now agent engineering (designing specialized, reusable, efficient ai agents).

there is no “official documentation” on this so this is my definition of it

it’s the discipline of designing systems around agents.

writing markdown specifications.

defining structure and guardrails.

sequencing tasks through orchestration layers.

reviewing outputs.

tightening the loop when agents drift.

making sure the final result reflects real product judgment.

the developers who get 100x more from agents are not writing better prompts.

they are building better systems around the agents.

“vibe coding” gives permission to be sloppy. “agentic engineering” demands rigor.

in practice, the work i do at lora looks like this nothing like vibes.

i write markdown specs,

define agent roles,

set up orchestration layers,

run multiple claude instances in parallel (until my poor m3 mac gives up),

review and tighten,

push to prod. the leverage is real. the work is hard. the output is 10x. but none of it is casual.

the harness

on march 31, 2026, a security researcher found that claude code’s entire source had leaked via a source map file in the npm registry.

512,000 lines of typescript. 1,900 files. the entire agent harness was public.

some people focused on the security failure. (well it was a big one)

the more useful reaction was studying what the harness actually looked like.

and the key revelation was this

roughly 40 percent of what makes claude code good is not the model.

it is the harness

the engineering layer between the model and the world.

parallelism systems.

permission management.

memory compaction.

a 4-type persistent memory architecture.

a 5-layer config hierarchy.

tools for filesystem access, git operations, web search, and shell execution.

a 7-stage bootstrap pipeline that initializes the agent before it writes a single line of code.

this is what most people miss when they evaluate ai tools.

they test the model. they rarely test the harness.

but the harness is what turns a language model into an agent.

without it, you have a very smart entity with no hands, no memory, and no idea where it is.

the leak was embarrassing for anthropic (again my opinion not theirs) from a security standpoint.

but it showed exactly what “agentic engineering” means in practice

not better prompts, but better infrastructure around the model.

read garry tan on the harness philosophy: “thin harness, fat skills.”

giving your agent a second brain

in early april , karpathy revealed a significant shift in how he uses llms.

he is spending less time generating code and more time building personal knowledge bases

structured, interlinked markdown wikis that an llm compiles and maintains.

the architecture is surprisingly simple.

three layers:

-raw sources (documents, notes, transcripts),

-llm-compiled markdown pages (cross-referenced wiki articles),

-and a schema file that maps the structure. instead of retrieving and re-synthesizing documents on every query like traditional RAG, the llm “compiles” them once into persistent wiki pages, then reads from the compiled layer at query time.

karpathy published the full architecture as a github gist. he calls it LLM Wiki.

the obsidian community adopted it immediately.

the underlying insight: ai does not replace thinking. it replaces forgetting.

karpathy’s shift reframes the llm as a librarian.

a compiler of knowledge. a system that takes the mess of your intellectual life

notes, documents, conversations, research and organizes it into something an agent can actually use.

obsidian is the natural substrate for this.

local-first, markdown-native, no vendor lock-in,

functions as both the human interface and the agent’s knowledge layer.

learn how to build your second brain

memory as infrastructure

if the second brain is the knowledge layer,

memory is the behavioral layer.

most ai tools have no memory.

every conversation starts from zero.

you explain who you are, what you are working on, what you tried yesterday,

what failed. then you close the tab and the slate is wiped clean.

this is the fundamental limitation of stateless ai.

it can be brilliant in the moment and useless over time.

honcho, by plastic labs, is the most serious attempt to solve this.

it is a memory engine for agents —

currently SOTA on LoCoMo, LongMem, and BEAM benchmarks. the fastest, cheapest, and most token-efficient memory solution currently available.

the key insight from honcho’s architecture is the difference between stuffing 100,000 tokens of raw history into context versus giving the agent 10,000 tokens that actually matter.

memory is not about storing everything.

it is about surfacing the right things at the right time.

continual learning, not infinite context.

when your agent has real memory, something changes.

it stops being a tool you use.

it becomes something closer to a partner that knows your patterns, your preferences, your history, your blind spots. the relationship compounds.

an agent with memory is categorically different from an agent without it,

in the same way a colleague who has worked with you for a year is different from a stranger you just met.

https://blog.plasticlabs.ai/blog/Memory-as-Reasoning

read plastic labs’ blog on memory as reasoning.

the practical stack

there are multiple ways to build an agent stack.

these are the most serious options right now

and more importantly, how to configure them.

if you are going to use one tool and nothing else,

make it claude code.

not cursor. not copilot. not a browser-based chat window.

claude code is the terminal-native agent that runs locally, has full filesystem access, understands your codebase,

and operates as an autonomous engineering partner rather than a suggestion engine.

the setup matters. more than the prompts, imo.

most people install it and start prompting immediately.

that is like hiring someone brilliant and giving them no context about the company, the codebase, the conventions, or the goals.

they will produce output.

the output will be mediocre.

and the user will conclude the tool is overhyped.

the real setup starts with claude.md.

it sits in your project root and tells the agent who it is working for, what the project is, what conventions matter, what to avoid, what the architecture looks like.

it is the single most important file in your entire development workflow and most people either skip it or write three lines and move on.

the config hierarchy matters too.

five layers

-global settings

-project-level claude.md,

-directory-level .claude files,

-session context,

- in-conversation instructions.

each layer scopes the agent’s behavior more tightly. when these are set up correctly, claude code does not need to be told the same thing twice.

it just knows.

a quick note on claude code vs claude cowork

this confuses people.

claude code is the local terminal agent.

it runs on your machine with full filesystem access and full autonomy within the permissions you set.

claude cowork is the cloud/async variant,

designed for teams and longer-running tasks you want to fire off and come back to.

both are powerful, but if you are a solo builder running the entire stack,

claude code is the one.

faster, more intimate with your codebase, tighter feedback loop.

the tooling landscape

beyond claude code, two other options deserve attention.

openclaw -hermes agent (-the better openclaw)

yes i said it (also take your pick)

it takes a fundamentally different approach.

it is open-source, multi-platform (telegram, discord, whatsapp, slack, signal, home assistant),

and built around persistent identity.

hermes has soul.md -for global agent identity,

hermes.md for project-level instructions,

a memories/ directory for persistent knowledge,

and a self-improving skills system that lets the agent write

and save its own reusable tools.

the core difference:

claude code is a coding agent with world-class harness.

hermes agent is a life agent with genuine multi-platform presence and evolving self-awareness.

hermes integrates with honcho for user modeling

it builds an evolving psychological profile of you and uses it to improve its behavior over time.

three tiers of memory. self-written skills. actual learning.

garry tan open-sourced gstack

his personal claude code configuration that hit 66,000+ github stars within weeks.

gstack packages 23 specialist skills and 8 power tools into slash commands.

it turns a single ai assistant into a virtual dev team

executive-level product thinking,

design system generation,

engineering management,

release management,

documentation,

QA.

the whole pipeline.

my preferred stack:

hermes agent for the persistent, multi-platform layer with honcho as memory.

gstack skills layered on top for development work. obsidian as the local knowledge base feeding into the second brain.

it sounds complex.

and the full version is.

but the entry point is simple (as mentioned above): install claude code, write a calude.md, start building context. everything else is progressive enhancement.

context engineering: how to build it

the people who win with agents are not the people with the best prompts.

they are the people who built the best context.

context engineering is a real skill.

and it is underrated because it is invisible.

start with claude.md in your project root.

describe the project, the architecture, the conventions,

the things the agent should always do

and never do.—this is important

be specific. “we use typescript with strict mode” is better than “follow best practices.”

add agents.md for multi-agent setups

define roles, handoff protocols, scope for each agent.

use directory-level .claude files for scoped context.

the frontend/ folder gets frontend conventions.

the api/ folder gets api conventions.

write markdown specifications for every non-trivial task before handing it to the agent.

the spec is the product of your thinking. the agent executes against the spec.

this is where judgment lives.

build self-improving context files.

let the agent update its own claude.md as it learns about the codebase.

and critically: build context about yourself.

your agent should know how you think, what you value, how you make decisions.

building your own brain

farza did something wild.

he took 2,500 entries from his diary, apple notes, and iMessage conversations,

fed them to an llm, and had it create a personal wikipedia.

400 detailed articles.

about his friends, his habits, his decisions, his history, his patterns.

he called it farzapedia.

if you think about it for more than a moment,

the thesis: everyone should be building context about themselves.

not for vanity. for leverage.

when your agent knows your history, your preferences, your patterns, your relationships, your communication style, your decision-making tendencies

it stops being a generic tool and starts being an extension of you.

the gap between “ai assistant” and “digital partner” is context.

and context comes from deliberate self-documentation.

soul.md is a tool designed for exactly this.

let claude code or another agent ingest your data and build your ai soul

a personality file that captures how you think, how you write, what you care about, what you avoid.

this connects karpathy’s knowledge base to farza’s personal wiki to the agent memory layer.

it is all the same thesis: context compounds.

the more your agent knows, the more useful it becomes,

and the more it feels less like a tool and more like a version of yourself that never forgets.

the sovereign future (i hope for)

your agent does not have to live on a macbook (or linux if you’re wild like me) tethered to an api.

the whole stack can go mobile.

it can go local.

it can go offline.

if your agent needs wifi and a laptop to function, it is still a desk tool.

it is not an extension of you.

extensions travel.

on the mobile side: termux plus llama.cpp on android gives you local inference on a phone with 4+ GB of RAM.

pocketpal runs offline llm on mobile. simple.

on the local side: ollama, llama.cpp, vLLM. running models on your own hardware means no api costs, no data leaving your machine, no dependency on any company staying online or staying friendly.

vitalik buterin published his full self-sovereign local llm setup

air-gapped, privacy-first, zero third-party trust required.

do i recommend going fully local yet? not quite. there are limitations.

but you have to assume the tech always gets better

better hardware and better open-source lightweight models.

on the extreme end: the cyberdeck. —attempting to build this for myself

a pelican case with a raspberry pi or mini pc. local llm. solar panel. mesh networking. offline wikipedia. no internet required.

portable offline knowledge, ai, and mesh communication platform.

this is not cosplay.

it is the logical conclusion of self-sovereign ai.

if you actually own your agent

if it has your memory, your context, your personal wiki, your communication history, your decision patterns

then running it locally is not paranoia.

it is architecture.

privacy becomes a moat.

not an inconvenience.

the whole stack —> hermes agent, honcho memory, gstack skills, obsidian vault, local model —> can be packed into something you carry. your second brain, literally in a bag.

if you want inspiration, check out the cyberdeck cafe.

some cool inspo, if this enticing

some light thinking

clark and chalmers argued that our minds extend into the external instruments we use. if the mind extends into tools, then a portable agent with your full context is a portable extension of cognition.

the cyberdeck is the physical manifestation of the extended mind thesis.

it sounds extreme until you consider the alternative: all of your context, your memory, your digital self, living on someone else’s server, subject to someone else’s terms of service, accessible only through someone else’s interface.

the sovereign version is harder to set up. is not harder to justify.

living in a world with agents

we are not just adding tools.

we are changing the relationship between a person and their work.

when your agent has memory, context, judgment scaffolding, and the ability to act

it is no longer a tool you pick up and put down.

it is a persistent collaborator that evolves alongside you.

this raises questions that no documentation answers.

what does it mean when your digital self remembers things you have forgotten?

what does it mean when the agent’s understanding of your work is more complete than your own, because it never loses context and you do?

what does identity look like when part of your cognition is externalized and persistent?

these are not future questions.

they are present ones.

if you have set up any of the systems described above, you are already living them.

the variance between people who build this infrastructure and people who do not will compound faster than any previous technological gap.

not because agents are magic.

but because the lever amplifies what is already there.

curiosity becomes exploration.

initiative becomes speed.

taste becomes prolificacy.

but passivity is amplified too. so is denial. so is fear dressed up as sophistication.

the same tool in two different hands becomes two different futures.

the question is not whether agents are real.

they are.

the question is what you build with them

while the rest of the world is still arguing about whether they work.

browse the job posts, and if any look like a match for you, just reply to this and if relevant i’ll make an introduction

stealth -pre-seed

ai workspace that automates the manual tasks running your business

birches health - series a

beating the online gambling epidemic with virtual therapy for gambling addiction

—on a side note—

judging a couple of hackathons in april and may

hope to see a lot of incredible builders show up and build cool stuff

tackling government tech, design ,robotics , hardware!

stay tuned!

also i still have a lot of questions about “the age of abundance” if you can answer them, hmu?

fair warning ——you’ll have more questions than answers after this one——

everyone likes to talk about the promises of an “ai-native” world

and how it will bring “the age of abundance”

at-least in my tech bubble………..

and to be honest, i didn’t know what it was

maybe still dont.

after talking to a lot of people on x

and a few dinners

here’s the cusp of my knowledge …

ai gets smart enough
(or is already that smart if you talk to people who’ve use anthropic’s mythos)

then energy gets cheap enough,

and the defining constraint of human civilization

not having enough —> begins to dissolve
*pretty chill*

right?

infinite intelligence on tap

the marginal cost of a first draft → prototype, an analysis, diagnosis,

approaching zero

the entire creative and engineering stack rewritten

underneath us, in real time……..

while most people still argue the validity of the tools

parts of this are already true.

but the word itself is doing a lot of work, and most of the people using it have not stopped to ask what it actually means.

what it is

no one agrees.

what i believe it to be………….

at its core,

it’s a future where the convergence of ai, robotics, and cheap energy makes material goods, healthcare, and food effectively free.

it completely decouples human survival from traditional paid labor. if you look at the macro predictions mapped out in the research by kokotajlo, alexander, larsen, and dean

the timeline for this decoupling is accelerating faster than traditional economic models can track.

enough that i wont make any predictions to not be rendered obsolete by another new model drop

just gonna analyze the different definitions and predictions by “experts”

for sam altman,

abundance is what follows AGI…….

scientific breakthroughs cascading into material wealth so broad it reshapes the economy.

for the linkedin crowd,

it is a productivity thesis: 100x output, exponential leverage,

do more with less.

for tom blomfield, it is a health and longevity story as much as an economic one.

for jurgen gravestein, it is not the end of jobs, but the rise of “superwork”,

james o’sullivan treats the idea with open suspicion.

James O'Sullivan

James O’Sullivan writes on digital culture, textual and cultural analytics, and the evolving interplay between algorithms, expression, and society.

for the skeptics

it is a fantasy dressed in optimism.

margi prideaux warns that climate stress could reverse the entire narrative before it fully arrives.

what it isn’t

the definition shifts depending on who is selling and what they need you to believe.

but beneath the disagreements there is a real phenomenon.

the cost of producing intellectual output

so called “knowledge work”

coding, writing, analysis, design, strategy, even rudimentary research

is collapsing.

open-source models run local inference on a laptop.

agents coordinate tasks that used to require teams.

a single engineer can carry an entire product.

this is not speculative.

if you build anything right now, you feel it daily.

what it promises

the optimistic case is genuinely compelling, and dismissing it outright requires ignoring what is already happening.

blomfield laid it out directly
”AI does not just make existing work faster, it opens categories of work that were previously inaccessible. drug discovery, protein folding, personalized education, climate modeling. the cost of a first attempt at almost anything approaches zero.”

gravestein extends the thesis further: automation of drudge work, longer healthspan, the slow rewiring of how economies allocate human time. roel smelt argues the transition is already underway and the main challenge is no longer technical. it is perceptual. we are living inside the shift but narrating it in the past tense."

the christensen institute frames it through disruption theory — when intelligence becomes cheap and abundant, the scarce inputs change. the work that matters migrates. what was once bottlenecked by production becomes bottlenecked by judgment, interpretation, coordination, and trust.

thegreyswan’s essay captures this cleanly: value always migrates to the new bottleneck. in an age of plenty, the bottleneck is no longer making things. it is knowing what is worth making.

this is the strongest version of the abundance argument.

not that everyone gets everything.

but that the floor rises, the tools become available, and the constraint moves from capability to discernment.

what happened

the conversation shifted sometime in late 2025 and accelerated through 2026.

it stopped being about whether ai was useful and became about what happens when intelligence is effectively free.

a few things drove it.

open-source models caught up. mistral, deepseek

couple others (but can’t say they “caught up”)

serious inference running on consumer hardware. the cost of intelligence cratered faster than anyone modeled. what was exotic eighteen months ago became a weekend project.

agents got real.

functional enough that the gap between a single person and a small team started compressing.

one engineer orchestrating a fleet of agents through markdown specs and review loops could ship what used to take a team of five, in a fraction of the time.

and the discourse exploded.

not just in tech circles but across economics, education, philosophy, policy.

the synthesis published a piece in march framing the central question clearly: every technology that mattered made something abundant that used to be scarce, and every time, the interesting question was not what got cheap but what got expensive.

that question is now unavoidable.

the timeline

the techno-optimists say three to five years for material abundance

cheap energy via solar and fusion,

ai-driven manufacturing, automated logistics.

the moderates say ten to twenty years for meaningful economic restructuring.

the skeptics say never, because scarcity is a coordination problem, not a technical limitation, and no model fixes politics.

the honest answer is probably layered.

intellectual abundance is already here.

the tools exist. the costs are low. the capability is real.

material abundance is….lets say still far!

energy, housing, food, water

these do not follow the same cost curves as tokens.

the physical world has friction that software does not.

and social abundance

the version where the gains are broadly distributed and the transition does not leave millions behind

is the part nobody has a credible plan for.

the world economic forum projects that by 2030, structural labor-market transformation will affect 22 percent of today’s jobs. 170 million roles created. 92 million displaced. a transition can be productive in the aggregate and still brutal for the people inside it.

that gap

between the timeline of capability and the timeline of distribution

is where most of the real suffering will live.

the underclass argument so to say

the opposite

the obvious answer is scarcity. but that is too clean.

scarcity is the economic opposite. it is not the human one.

the human opposite of abundance is meaning.

the uncomfortable truth

when you can generate anything

any image

any essay

any codebase

any song

the question “why” becomes louder than “how.”

and most people have not spent much time on “why.”

they were too busy with “how.”

the grind answered the question for them.

the difficulty of production provided a sense of purpose by default.

remove the difficulty and the question returns, louder than before.

the stoics understood this.

seneca warned that surplus breeds softness and confusion.

not because comfort is wrong, but because comfort without intention dissolves the self.

abundance without philosophy is not freedom. it is noise.

nietzsche saw the same thing from a different angle.

he called it the last man problem

a world so comfortable that nobody strives for anything.

everything available, nothing earned, and the human spirit flattening under the weight of its own ease.

i do believe that the absurdity was always there.

abundance does not create the void,

it just removes the distractions that kept people from noticing it.

and the response is the same as it always was-

you create anyway, not because it is scarce,

but because creation is the only dignified response to a universe that offers no inherent meaning.

the deeper opposite of abundance is not deprivation.

it is the loss of the question that deprivation used to force people to answer:

what is this life actually for.

the positive case

the upside is real and it would be dishonest to minimize it.

-a kid in lagos with a laptop and claude can build software that competes with venture-backed teams.

-a researcher in dhaka can run experiments that used to require an MIT lab.

-a solo founder can carry an entire product stack

-backend, frontend, database, design and ship on timelines that would have been absurd three years ago.

the democratization of intelligence is the most egalitarian force technology has ever produced.

not because it eliminates inequality, but because it lowers the floor of what is possible for a single motivated person.

blomfield is right that health outcomes will transform.

gravestein is right that the nature of work will become unrecognizable within a decade.

the christensen institute is right that education systems need to rethink what they are training people for.

the best version of abundance is not “everyone gets everything.”

it is “everyone gets the tools to discover what they are actually capable of, without needing permission or proximity to power.”

that is a version worth building toward.

the negative case

the shadow is real too

pretending otherwise is just a different kind of self-deception.

o’sullivan’s skepticism is not wrong.

scarcity does not vanish because ai can write code.

water is still scarce.

housing is still scarce.

attention is more scarce than ever.

prideaux’s warning about climate reversing the abundance story is not fear-mongering. it is physics.

there is a certain fact that abundance of intellectual output does not mean abundance of wisdom.

it might mean the opposite. more content, less signal. more tools, less craft. more capability, less intention.

and there is a harder question underneath.

when ai can do most cognitive work, the question is not “what will people do.”

the question is “what are people for.” that is not a product question.

that is not a policy question.

that is the oldest philosophical question there is, and no roadmap addresses it.

adaptation is not evenly available.

it is easier to pick up a new lever when there is slack, savings, autonomy, and room to be temporarily bad at something new. for a mid-career worker with narrow specialization, a mortgage, and weak institutional support, the lever does not arrive as an exciting option. it arrives as a demand.

the long-run graph can point upward while a person’s life, in the short run, is thrown into disorder. any serious view of technological change has to admit that cost.

abundance without distribution is just concentration by another name.

what remains

the people who navigate this well will not be the loudest optimists or the most sophisticated skeptics.

they will be the ones who told the truth early, even when it was inconvenient to their self-image.

they will stop confusing the cost of production with the value of what is produced. they will stop treating effort as proof of seriousness. they will stop mistaking the tool for the self.

and they will go where the human work still lives: judgment, context, trust, taste, responsibility, synthesis, and the willingness to choose under uncertainty when the stakes are real and the answer is not obvious.

abundance does not eliminate the need for those capacities. it reveals how rare they always were.

the tools do not care what you build with them.

the question is whether you do.

questions that remained unanswered (for me)

what does the economy look like?

what does the market look like?

how do we distribute the massive wealth generated by ai without creating techno-feudalism?

what happens to physical constraints like housing and land when digital goods are free?

if human labor is decoupled from survival, who actually owns the underlying ai infrastructure?

will a universal basic income cause hyper-inflation in the few things that remain scarce?

if you are an expert on this , please reply!

browse the job posts, and if any look like a match for you, just reply to this and if relevant i’ll make an introduction

lora -pre-seed

new consumer app reimagining how people understand themselves and connect with the world

stealth - seed

building the ux layer for ai agents

—on a side note—

me and my friends hosted a world models hackathon this past weekend

a lot of incredible builders, showed up and built cool stuff

from explorable 3d experiences to rapidly generating robotic training data from a single screenshot

special shout out to world labs, soma capital, lovable

planning to host even bigger ones to meet more cool people

stay tuned!

ps. if anyone would like to sponsor a track in the upcoming hackathons, hmu!

---

the real villain: memory

if you’ve actually shipped anything with a big model,

you know the real bottleneck isn’t compute,

(if you’re a nvidia employee you better spend those tokens)

it’s your kv cache melting your hardware.

every message you send to a transformer isn’t just “new input.”

it’s the model dragging the entire conversation back onstage,

re-reading all the tokens it’s ever seen in that session.

to avoid recomputing everything from scratch,

it stores intermediate representations in this kv cache

ELI5 -basically short-term working memory.

and that thing grows linearly with context.

• 128k tokens on a 70b model? ~40 gb of gpu memory just for the cache.

• at long contexts, the cache can consume more memory than the model weights.

this is why your “one gpu, many users” dream dies the moment you turn on long context.

this is also why a lot of long-context marketing is…

let’s say “aspirational.”

google enters the chat!

on march 25, google research drops turboquant.
just a paper and pseudocode.

headline:
compress the kv cache from 16 bits to 3 bits per value. ~6x less memory. up to 8x faster attention. basically no accuracy loss.

wall street sees “6x less memory” and goes full silicon valley parody:

• sandisk: -11%

• micron: -7%

• sk hynix: -6.2%

• samsung: -4.7%

• nvidia: -4.2%

• philadelphia semiconductor index: -4.8%

all while the nasdaq is up.

someone compared it to “aramco crashing because toyota made a better hybrid engine.”

which is a great line and also kind of wrong.

wtf is turboquant?

it compress almost as much as physics allows,

without the usual “whoops, we broke your model”

two main pieces:

1. polarquant
   rotate the vectors so their distribution becomes predictable, then quantize in that nicer coordinate system.
   translation: you precompute the quantizer once, you don’t need calibration, and you avoid wasting 1–2 bits on metadata like other methods.

2. qjl
   whatever error is left, you squash it down to basically a sign bit and correct bias so attention scores stay clean.
   result: the compressed output is statistically identical to full precision.

anobody a fan of silicon valley the show? kind of like that

but not “we invented compression.”

rather
it’s “we got rid of overhead and crept up to the shannon limit.”

there’s a line in the paper: any quantization algorithm has a hard lower bound on error given the rate.

turboquant is already flirting with that boundary.

benchmarks that matter

the numbers:

• memory: 6x reduction minimum. 70b kv cache from ~80 gb to ~13 gb in their setup.

• speed: up to 8x faster attention on h100 (4-bit vs 32-bit).

• accuracy: perfect needle-in-a-haystack retrieval, even at aggressive quantization.

• cost: 50%+ cut in inference spend for long-context workloads.

• compat: plug-and-play on llama, mistral, gemma, etc., no retraining.

caveats included:

• 8x speed is for attention kernels, not full-model latency.

• most tests are on sub-10b models; 70b+ is still “we expect it to work, but to be proven.”

this is absurdly impactful.

hacker culture at it’s finest

google didn’t release official code.

the internet shrugged and shipped.

within 24 hours:

• custom triton kernel in pytorch, tested on gemma 3 4b on an rtx 4090 with byte-identical outputs at 2-bit compression.

• a 35b model running on apple silicon via mlx, hitting 6/6 needle-in-a-haystack at every quantization level.

• multiple cuda and c implementations wired into llama.cpp, one reporting 18/18 tests passing.

• someone used gpt-5.4 to write an mlx implementation in 25 minutes.

of course, there was a footgun: naive qjl implementations produced garbage. without proper bias correction, quantization errors explode and your model turns into a word salad generator.

you actually have to respect the math.

but the bigger signal is this:
a serious research paper can now go from “pdf” to “running in prod-ish environments” in a weekend.

if you’re shipping agent infrastructure, you can’t afford to be three pdfs behind.

hitting the compression ceiling

everyone’s obsessing over the 6x.
but……..

you probably won’t get 20x from another clever quantization trick.

rough compression journey so far:

• no compression: 1x baseline

• basic quantization: 2–3x

• outlier-aware methods: 3–4x

• turboquant in real systems: ~4–4.5x effective, with error rates near the theoretical minimum

the paper literally proves a mathematical lower bound: you cannot beat shannon. turboquant is hovering near that floor.

so:

• if your strategy doc says “we’ll just keep compressing more every year,” that’s not a strategy,

• the next big unlocks will have to come from new architectures, new attention schemes, or a different way of storing and retrieving context.

someone will say: “but we always find new tricks. look at hardware over the last 40 years.”

sure. but information theory is not vibes. at some point, you actually hit the wall.

turboquant is a giant “objects in mirror are closer than they appear” sticker on that wall.

the jevons paradox:

cheaper memory, more memory

this is where wall street got the story backwards.

on paper: 6x less memory needed per request.

in reality:
if you make memory effectively cheaper, people don’t use less

they use more.

jevons paradox 101:

• save 6x on memory per session → cool, now you can afford models 6x bigger or context 6x longer.

• suddenly, real-time video, million-token docs, always-on multimodal agents stop being “lol maybe someday” and become line items.

• one gpu that could serve 1 heavy session now serves 6. demand will not politely stop at 6. it will grow to 60.

analysts are already saying the quiet part: turboquant-like tech lowers adoption friction and expands total demand. memory vendors likely win over a long enough horizon.

this is exactly what happened with cheaper training (deepseek vibes): everyone said “this will kill gpu demand.” instead, more people could train, so more people did.

if you build infra, this matters: your unit economics change, but your volume assumptions should too.

your hardware just got a upgrade

for indie builders.

no new chip. no new device. just software. and suddenly:

• mac mini: 100k-token conversations with no quality drop—aka full book-length context on a ~$600 box.

• smartphones: 32k+ token context windows via software alone. no hardware refresh.

• rtx 4090: workloads that previously needed multi-gpu rigs can now squeeze onto a single card.

• enterprise: for long-context stuff, you can cut the gpu count for a workload dramatically, potentially slashing cloud spend by 50%+.

the gap between “local ai” and “cloud-tethered ai” just shrank hard.

running serious models at home is slowly shifting from “cute hack” to “default assumption.”

if you’re building ai-native products and you’re still designing everything as if local is a toy, you’re about to get leapfrogged by someone who isn’t.

strip away the charts and stock tickers, and you’re left with a few uncomfortable-but-useful truths:

1. context is no longer the excuse
   “we can’t afford long context” is a worse excuse post-turboquant. if your product relies on stateless prompts and short-term memory, that’s a design choice now, not a physics constraint.

2. architectures, not just tricks, are the next frontier
   you won’t be able to ride an endless wave of compression hacks. if you’re serious about long-horizon agents, you should care about new attention, retrieval, external memory, all the boring stuff.

3. local-first ai is going from fringe to default
   when a mac mini can handle book-length conversations and a 4090 can host models that used to need 2–4 gpus, you get a new class of indie infra. the stack shifts from “rent everything” to “own more than you think.”

4. agent design has to assume cheap-ish, persistent context
   the interesting agents won’t be prompt macros—they’ll be systems that keep rich, long-lived state and learn over time. turboquant doesn’t solve that for you, it just removes one major excuse.

someone will say: “yeah but it’s just one paper, and real workloads are messy.”

fair. but the community already has working implementations.
and even if this exact algorithm ends up with rough edges, it proves a point: compression is basically solved enough that the next constraints are on you, not the hardware.

to sum it up

turboquant isn’t just “6x memory savings.”
it’s the moment we quietly hit the compression ceiling and were told

ok, no more free lunches from quantization

if you want the next 10x, you’ll need to rethink how your systems actually work.

if you suddenly get 4–6x more context and throughput for free, what would you build that felt impossible last week—and what’s stopping you from starting on it now?

—hiring—
browse the job posts, and if any look like a match for you, just reply to this and if relevant i’ll make an introduction

ordo -series b

supply chain and logistics platform connects public and private schools to fresh breakfast and lunch that students love, cooked and delivered by local chefs.

altitude -series a

ai copilot built for america’s 300K nurse practicioners, delivering supervision and skills intelligence, targetted uspkilling, role-specific simulations, and most valuable actions ahead of upcoming visits based on clinical, actuarial, and operational priority and insights.

—on a very vulnerable side note—

we crossed 1000 subscribers!

a month ago when i started writing, i didn’t think this would grow so fast

especially after i started yapping philosophically

who am i? naval?

i truly appreciate each and everyone one of you

please let me know what topics do you want more of

there’s definitely tons of other sources of content out their for you

so i wanna be the best

let me know what topics would hit the trifecta for you

-emotion

-value

-entertainment

here’s what’s happening:

every single time openai, anthropic, or google ships a new feature,

a whole category of startups silently dies.

or someone just posts about it claiming they are

and they pivot

i’ve been thinking about this a lot

as someone building at an early-stage company,

watching friends’ startups evaporate after a single model update,

and talking to founders who are genuinely confused about what’s defensible anymore.

so this is my dump to while to try to lay out what i think actually matters.

the playbook that keeps killing you

there’s a pattern big tech has been running for decades

google with seo.

apple with the app store.

facebook with the social graph.

the playbook is always the same: open the gates, let everyone build on top of you, get massive, then close the gates and tax the ecosystem.

the part that’s different every time?

each cycle gets faster. g

google took 10+ years to pull it off. facebook did it in 5. linkedin in 3. with ai platforms, this playbook might run in weeks (days with the newer models).

and right now we’re in the “open the gates” phase.

free apis. generous rate limits. friendly docs.

but if your entire product is a nice ui on top of someone else’s model,

you’re not building a company.

you’re building a feature that the model provider will eventually ship themselves.

what might survive

i’ve been reading a lot of takes on this and talking to bunch of founders who have raised massive amounts and plan to grow even bigger

someone mentioned about making your app a “claude skill.”

someone mentioned making “systems of engagement” as the new moat.

someone mentioned making “systems of record” as the new moat.

someone mentioned proprietary data as a moat

the buzzword for consumer startups is “community”

i strongly believe that “x as a moat” concept is not a thing anymore, it’s a combination of multiple things , that make it harder for others to compete not impossible.

1. your value is not the ui or the prompts but the data. if a product is something where every user interaction makes the product smarter, then it becomes hard to replicate for others. that’s a flywheel i belive makes the product harder to mimic but not impossible

2. there’s a massive difference between an ai wrapper and ai agent, make a product so good that if removing your product it requires a migration plan, that’s another plus point for you

3. optimize your ai product to be a tool ai reaches for not a human, i think this is the most underrated one now, don’t fight the adoption of new models, make your product indispensable to them, add api’s , clis, mcp , so it is trivally easy for an ai agent to use your product as a tool (and suggest the same to a vibe coder), so the more builders out the more leverage you have , ideally aim to have claude use you but not replace you, you’re in the safest position possible then (this is really far fetched but not impossible)

4. ai is going to produce a ton of intermediate work that needs human judgment. the companies that build great interfaces for humans to review, tweak, and approve ai output ,then send the corrected version back, become load-bearing infrastructure. you’re not competing with the ai. you’re the bridge between the ai and the human who signs off.

what absolutely wont

“but what about my workflow automation feature?”

but claude code now has scheduled tasks.

the case for building your own zapier-inside-the-app keeps collapsing with every release.

“SOTA next generation coding agent.”

if you’re spending cycles building your own coding agent from scratch, you’re on a treadmill. claude and codex keep getting better automatically.

seat-based pricing
if one “seat” can run 10,000 agent actions a month, your pricing model is already broken. the world is moving to usage-based. design for that now before it’s an emergency later.

do not skip this

don’t miss this “very obvious if you think about it piece”:

the companies that die won’t be the ones that failed to integrate with ai.

they’ll be the ones that thought being a standalone app was enough.

look at the historical data to confirm this

amazon didn’t kill merchants who had brands, proprietary inventory, and customer relationships. it killed the ones selling commodity products. apple didn’t kill apps with network effects and proprietary data. it killed the thin wrappers.

ai will do the same thing. the graveyard won’t be full of ai-integrated companies.

it’ll be full of the ones that never made themselves essential to the ai workflow.

homework time……

i copied this from a friend and colleague of mine “shoutout ”, i’m gonna start doing homework assignments to upskill my subscribers!

open your product. ask yourself: if claude tried to use this right now, could it? is there an api? an mcp server? a cli? or would it hit a login wall, a sales call, a 14-day trial form?

because the agents are trigger-happy. friction kills. if your product isn’t accessible to ai in under 60 seconds, the agent moves on. and so does the human behind it.

you’re not building software anymore. you’re building an ai skill. make it load-bearing.

(fair warning: this advice has maybe a 6-month shelf life. possibly less. but that’s kind of the point.)

—hiring—
browse the job posts, and if any look like a match for you, just reply to this and if relevant i’ll make an introduction

ordo -series b

supply chain and logistics platform connects public and private schools to fresh breakfast and lunch that students love, cooked and delivered by local chefs.

altitude -series a

ai copilot built for america’s 300K nurse practicioners, delivering supervision and skills intelligence, targetted uspkilling, role-specific simulations, and most valuable actions ahead of upcoming visits based on clinical, actuarial, and operational priority and insights.

—on a very vulnerable side note—

we crossed 1000 subscribers!

a month ago when i started writing, i didn’t think this would grow so fast

especially after i started yapping philosophically

who am i? naval?

i truly appreciate each and everyone one of you

please let me know what topics do you want more of

there’s definitely tons of other sources of content out their for you

so i wanna be the best

let me know what topics would hit the trifecta for you

-emotion

-value

-entertainment

one tweet.

that’s all it took to mass-mobilize an army of developers against a funded saas product.

guido appenzeller posted two days ago that granola went closed.

encrypted their local database, killed local access, no cloud api.

his take: in a world where notes are managed by agents, the app now has zero value.

329k views later, something wild happened.

within 24 hours, somewhere between 5 and 10 open source alternatives appeared.

fully local, agent-friendly, doing exactly what people actually want from a notes tool in 2026.

built by developers and vibe coders who saw the gap and just…

shipped.

this is weirdly underrated as a case study. so let’s break it down.

the old playbook is dead

for years, the saas playbook was simple.

get users in, lock their data down, make switching painful.

the moat wasn’t the product. it was the friction of leaving.

granola did exactly this. they encrypted the local database so your own agents couldn’t read your own notes.

no api.

no export path that plays nice with the tools people are actually building workflows around.

five years ago, this would have been fine. annoying, maybe, but fine. switching costs were high enough that most people would just grumble and stay.

but here’s the thing

the cost of building a replacement just collapsed.

what actually happened in those 24 hours

guido’s tweet went viral. 329k views. and the response wasn’t just outrage or hot takes. it was code.

developers saw the gap and started shipping. not in weeks. in hours. open source meeting note tools that are:

1. fully local -- your data stays on your machine

2. agent-friendly -- your ai tools can actually read and use your notes

3. extensible -- apis, integrations, the stuff people need in an agentic workflow

4. free

the speed here is the story.

this used to take months of coordinated engineering.

now a motivated developer with cursor and a weekend can build a credible alternative to a funded startup’s core product.

that’s not a minor shift. that’s a structural change in how software competition works.

the real moat in 2026 is not your database encryption

someone will say “but granola has features these clones don’t have. polish, ux, integrations.” and yeah, probably true.

today.

but that gap closes fast when:

- ai tools make building faster every month

- the open source community is building in public with shared momentum

- users are actively motivated to switch because you locked them out of their own data

the moat used to be switching cost. now the moat is trust.

here’s what might help:

1. agent-friendliness is table stakes. if your users’ ai tools can’t access the data, you’re creating a reason for replacement, not retention.

2. data portability is a feature, not a vulnerability. the founders who get this are building products people choose to stay in, not products people are trapped in.

3. community is your real defense. open ecosystems create network effects that closed ones can’t. the products that win will be the ones developers want to build on top of.

4. speed of iteration beats speed of lock-in. you can’t out-encrypt the open source community. you can only out-ship them on the things that actually matter -- ux, reliability, the hard product problems.

what i’m seeing as a builder

the products that survive the next few years won’t be the ones with the best lock-in.

they’ll be the ones with the best reason to stay.

that means building for interoperability.

building for agents.

building for a world where your users’ workflows extend way beyond your app’s borders.

it’s counterintuitive.

opening up feels like giving away your advantage.

but in practice, the companies that make themselves indispensable to an ecosystem

not just a workflow

are the ones that become genuinely hard to replace.

the irony is that granola’s moat strategy is exactly what made them replaceable.

the bigger pattern

this isn’t just about granola. this is about the entire saas category.

we’re entering a world where:

- building a functional product takes days, not months

- the open source community has ai-powered leverage that didn’t exist two years ago

- users expect their tools to play nice with agents

- one viral moment of frustration can catalyze a replacement ecosystem overnight

granola just became a case study. but they won’t be the last.

so what do you do about it?

if you’re a founder:
audit your product for agent-hostility.
anywhere you’re blocking programmatic access to user data is a vulnerability now,
not a feature.

if you’re an engineer:
this is the golden age of replacement products. every closed saas tool with locked data is an opportunity for an open alternative. the tools to build it are better than they’ve ever been.

if you’re a user:

start paying attention to which products treat your data like it belongs to you. because the ones that don’t are about to learn this lesson the hard way.

what’s one product you use that would get the granola treatment if someone called it out publicly? i bet you can think of at least three.

-founding product designer at ai consumer startup

-founding engineer at seed stage stealth ai startup (reply for application link)

every company i know is drowning in ai tools and starving for someone who can actually wire them into daily work.

i saw a tweet wher a ceo quoted a founder who flew an engineer to hq for a full week.

the engineer’s only job?
get every single person using claude for at least one workflow.
not building product.
not shipping features.
just... teaching people how to use the tools already sitting in front of them.

and the replies were wild.
multiple teams saying they’ve been doing this for weeks.

one person called it “prompt archaeology”
digging through existing workflows to figure out what translates to AI and what needs to be rethought from scratch.

another predicted a “chief claude officer” role.
someone else pushed back and said this isn’t what a forward deployed engineer even means.

i personally like chief claude officer …..

maybe just cause it’s a c-suite title……

most orgs might be missing

lenny rachitsky published a piece arguing claude code is the most underrated tool for non-technical people.

his key reframe: stop calling it “claude code” and start thinking of it as “claude local” or “claude agent.”

because the real unlock isn’t writing code

it’s having a super-intelligent assistant running on your machine that can organize your files, sort invoices, synthesize customer calls, generate lead lists, and fifty other things nobody in marketing or ops would ever think to try.

i truly believe the barrier isn’t technical.
the installation is literally one terminal command.
yes terminal is not something i believe to be technical ….. i said what i said

the barrier is that nobody in most orgs knows this is possible, and nobody’s job is to show them.

the internal AI enablement role

i think we’re about to see a new function emerge in every serious org.

not a “head of ai” who builds models.

not a consultant who parachutes in for a week.

an internal person
maybe an engineer (most likely),
maybe not ,

whose job (not entirely but parts) would be:

1. auditing existing workflows for ai leverage points

2. teaching teams to use tools like claude code, cursor, and agents in their actual daily work

3. building lightweight internal tooling and templates that lower the activation energy

4. teaching the same to other colleagues so they can build their own stack

5. staying current on the firehose of new capabilities so individuals don’t have to

this is weirdly underrated as a role because it doesn’t look like “real engineering” and it doesn’t look like “real management.”

it lives in this weird middle ground between ops, engineering, and training.

and that’s exactly why most companies don’t have it yet.

maybe wouldn’t ever have it until it becomes truly mainstream

this could be you!

if you’re an engineer reading this

especially early-career or between things

this might be the highest-leverage role you could step into right now.

not because it’s glamorous, but because the person who teaches an entire org to be 2-5x more effective has much more massive impact than the person shipping one more feature.

people wanna dismiss this “this is just internal tooling with extra steps” and yeah,
the assumption with internal tools is that the users know what to ask for

this role starts upstream

it figures out what people don’t even know they should be asking for.

it’s the difference between building a dashboard nobody uses

to sitting next to someone while they realize claude can do 80% of their weekly reporting.

what’s non-obvious?

the companies that will win

aren’t the ones with the best models or the biggest budgets.

that metric is just for the frontier labs

they’re the ones that invest in the boring middle layer: a person (or small team) whose entire job is closing the gap between what ai can do and what their team actually does with it.

and right now, almost nobody is hiring for this.

if you’re building, founding, or leading eng at a company right now

the highest-ROI hire you could make this quarter might not be another senior engineer.

it might be someone whose job title doesn’t even exist yet.

what would you call it?

—side note—

this substack is growing

to my shock, lot of you liked the previous one

hitting hard on the philosophy

i’m beginning to make this more of a regular thing after the wonderful feedback

but i actually looked into who’s reading it.

i used my browser agent to dig through the subscriber list, and here’s the tldr:

“a mix of founders and execs at startups (pre-seed through series A), some vc’s, and a lot of mid-to-senior engineers.”

so instead of just rambling into the void, i want to make this genuinely useful.

starting now, i’m adding a hiring section to every issue. vc have enough dealflow ,i’m not going to spam them but they do want to hire for their portfolio companies. and founders are always looking for people.

if you want to post a role, just reply to this email with job posting!

Hiring @ Lora
Founding Head of Engineering

Founding Designer/Head of Design

Senior iOS Engineer

and many more check them out here

everyone’s inherently cognitive miser.

that’s not an insult.

it’s how humans are wired.

we conserve mental energy wherever we can.

we take shortcuts, defer decisions, batch problems, avoid context-switching.

it’s why meetings exist…….. (or so i’ve been told)

not because they’re efficient,

but because they let five people split the cognitive load of one hard decision.

this is the one thing ai native tools help with

and what makes them more adopted in workspaces

and not so much with general consumers

that is the unlock

if used properly - i like to highlight this

the core work problem

saw somebody mention this framework a while ago,

you have two kinds of work:

1. core work -- the thing you’re actually hired to do. building features, writing, designing systems, shipping product.

2. supporting work -- meetings, emails, planning meetings about meetings, admin, context-gathering, coordination overhead.

the supporting work at this point has pretty much being automated and will be fully autonomous (depends on whom you ask) at one point

previously

for most people, supporting work was roughly constant.

it doesn’t matter if you’re working 30 hours or 60

you’re still doing ~20 hours of emails and syncs and status updates. so the only variable is how much core work you get done with whatever time is left.

now after ai when it’s eaten all of that supporting work.

not all of it. —yet— but enough that the ratio flips.

suddenly you’re spending 80% of your time on core work instead of 40%. same hours.

the more models get better the gap shrinks and the core work merges with other roles

the team is shrinking. that’s the point.

the gossip in the air so to say is “ai is going to take jobs.”

and yeah, it will.

this is about what happens to the jobs that survive.

the answer: they expand.

not in hours. in scope.

the person who survives isn’t the specialist who does one thing extremely well. it’s the generalist who can operate across the full stack of technical (or non-technical):

- machine learning

- software engineering

- agent engineering

- product management

-operations

i know that list sounds like a recruiter’s fever dream.

but this is weirdly underrated: a single person with a CS background and ai tools can now credibly do all of these at a level that used to require a team of five.

not because they’re geniuses (sorry fellow cs grads)

because ai is a cognitive miser’s best friend.

“this is just hustle culture repackaged”

and yeah, i get it. “one person does everything” sounds like a recipe for burnout.

but it’s already happening

also

the people who are doing it

it’s so awesome to see how much fun they are having.

it’s not surprising

it is fun to be in flow and to have a sense of solving interesting problems at a higher level of abstraction.

this isn’t about working more hours. it’s about working the same hours with dramatically less supporting work overhead.

the cognitive miser in you should be thrilled.

ai handles the context-switching, the boilerplate, the “let me look up how this api works”

you just... think about the problem and ship the solution.

the few people who figure this out aren’t going to be grinding 80-hour weeks.

they’re going to be operating at the scope of a small team while maintaining their sanity.

because the bureaucracy that used to justify large teams the syncs, the handoffs, the “alignment meetings”

most of it is (was) unnecessary.

what this means if you’re building right now

1. stop hiring for headcount. hire for range.

this has been universally true actually

the next great early-stage engineer isn’t a “backend developer.” they’re someone who can move between data, ml, product, and infra without needing a ticket filed for each transition.

2. invest in your ai workflow before your org chart.

the team of 3 that ships like a team of 15 isn’t using ai as autocomplete.

they’ve restructured their entire workflow around it -- context engineering, agent delegation, verification loops.

side note- someone mentioned a chief claude officer, could be something to look into

3. treat supporting work as a bug, not a feature.

every recurring meeting, every status update, every “quick sync”

ask whether ai can handle it. most of the time, it can. what’s left is the actual hard thinking.

4. get comfortable being the whole stack.

if you’re an engineer, learn the data side.
if you’re a data person, learn to ship product.
if you’re both , learn product management

the boundaries between these roles are dissolving faster than most orgs realize.

the real question

the future of work should be “can i become the person who does the job of fifty people without it feeling like fifty jobs.”

the answer is increasingly yes. but only if you stop thinking of yourself as a specialist and start thinking of yourself as a system.

i don’t know exactly what this looks like at scale yet. i don’t think anyone does. but the people figuring it out first aren’t going to be teams of 50. they’re going to be teams of one.

what’s the one domain you’ve been avoiding learning because “that’s someone else’s job”? might be worth picking it up this week.

side note -world models

. world models are becoming a thing

systems that don’t just pattern

match but actually maintain an internal representation of how things work together.

this matters because the reason teams exist isn’t just division of labor.

it’s division of context.

the data engineer understands the pipeline. the ml engineer understands the model.

the product manager understands the user. nobody holds the full picture.

world models collapse that.

one person with the right ai tools can hold the full context of a system from data ingestion to model serving to user experience in a way that used to require three standups and a confluence page nobody reads.

the coordination cost was always the real overhead. not the work itself.

society confuses the tool with the self. that confusion is ancient. but it has become more expensive.

every few centuries, a new lever appears. the printing press. the engine. the computer.

each time, the people who built identity around the old way of doing things felt existential panic.

each time, the panic said less about human value itself than about a particular story people were telling about where that value lived.

we are in that moment again.

ai is a lever. levers do not replace people in the abstract.

they expose which parts of the work were always mechanical and which parts were always human.

the question is whether that distinction can still be seen clearly.

for many people, it cannot.

when identity hardens around output, any tool that produces similar output begins to feel like a threat to existence.

but that is a problem with the identity, not the tool.

the knowledge worker made a quiet bargain with suffering.

the late nights. the impossible deadlines. the dense expertise carried in a single tired mind.

hardship gave the work gravity. if something consumed weekends and health, it had to matter.

pain became proof of value.

but it never was that

it was proof of friction.

and friction is what tools are built to remove.

that is why this moment feels destabilizing.

when a machine makes the first draft easy, it does not necessarily diminish the person who used to produce it by hand.

it removes one layer of drag. the real question is what remains once the drag is gone.

much of what remains is harder to fake and harder to outsource: judgment, taste, courage, responsibility, synthesis, the willingness to choose under uncertainty when the stakes are real.

those capacities were often buried beneath the grind. As the grind recedes, they become visible again.

leverage

the honest framing is not replacement.

it is leverage.

a lever does not care who holds it. it amplifies what is already there.

curiosity becomes exploration. initiative becomes speed. taste becomes prolificacy.

but passivity is amplified too.

so is denial.

so is fear dressed up as sophistication.

the same tool in two different hands becomes two different futures.

in one pair of hands, acceleration. in another, theater.

a few experiments. a shallow dismissal. a fresh layer of rationalization.

the variance between people was always there.

leverage simply makes it harder to hide.

there is evidence that the lever is real.

in an nber study of 5,179 customer-support agents, access to a generative ai assistant increased productivity by about 14 percent on average, with roughly 34 percent gains for novice and lower-skilled workers and little effect for the most skilled workers.

in a separate mit-led study, workers using chatgpt for certain writing tasks finished about 40 percent faster and produced output rated 18 percent higher in quality.

that does not mean the optimistic story gets to ignore the painful one.

the world economic forum’s future of jobs report 2025 projects that by 2030, structural labor-market transformation will affect 22 percent of today’s jobs, with 170 million roles created and 92 million displaced.

a transition can be productive in the aggregate and still brutal for the people inside it.

this is the strongest counterargument, and it is real.

the printing press did not feel like liberation to the scribe.

the factory did not feel like progress to the artisan it displaced.

the long-run graph can point upward while a person’s life, in the short run, is thrown into disorder.

any serious view of technological change has to admit that cost.

it also has to admit something else.

adaptation is not evenly available.

it is easier to pick up a new lever when there is slack, savings, autonomy, and room to be temporarily bad at something new.

for a mid-career worker with narrow specialization, a mortgage, weak institutional support, or little control over workflow,

the lever does not arrive as an exciting option. it arrives as a demand.

still, the larger mistake is to confuse the existence of displacement with proof that the tool is illegitimate.

tools remove friction.

markets then reprice what remains scarce.

the hard part is that the repricing is uneven, and no one experiences “uneven” from the outside.

they experience it as risk, loss, humiliation, and uncertainty.

the work moves up, not out

when writing gets cheap, clarity becomes rare.

when analysis gets cheap, interpretation becomes rare.

when prototypes get cheap, taste becomes rare.

when execution gets cheap, discernment becomes rare.

notice the pattern.

the human contribution does not vanish.

it migrates.

it moves from the thing being produced to the judgment behind its production.

from the artifact to the intent. from the how to the why.

this is not a sentimental claim that humans will always matter.

it is a claim about scarcity.

when a system can generate competent drafts in seconds, the scarce thing is no longer draft production by itself.

the scarce thing becomes knowing what should be made, what is true, what is worth trusting, what should be discarded, and what consequences follow from getting it wrong.

a concrete version of this shift is easy to see in modern software work.

a full-stack engineer who once spent weeks building a feature mostly by hand can now work through a small fleet of agents.

the job becomes less about typing every line personally and more about designing the system around the work: writing markdown specifications, defining structure and guardrails, sequencing tasks through an orchestration layer, reviewing outputs, tightening the loop when the agents drift, and making sure the result still reflects real product judgment.

timelines that once lived in weeks can collapse into days. the leverage is real. but it does not eliminate the human role.

it raises the premium on decomposition, taste, sequencing, and responsibility for the final result.

that is why the work moves up, not out.

this does not mean everyone gets promoted automatically.

it means the center of gravity shifts upward. people rewarded mainly for mechanical execution have to develop higher-order judgment faster than they expected.

people who already possess that judgment gain leverage.

the transition is not fair merely because it is logical.

if work is moving toward judgment, context, and tool fluency,

then institutions that still train people mainly for repeatable production are training them for a world that is receding.

the self-deception cycle

the cycle usually begins quietly.

first: ai is overhyped.

second: there is no need to engage seriously.

third: a widening gap opens between those who experimented and those who performed skepticism.

then the gap hardens into reality.

by the time this becomes visible, it often feels, from the inside, as if the world has become irrational.

but the world is usually reflecting back a choice made earlier, when self-protection was chosen over contact with change.

some skepticism is rational.

hype is real.

bad tooling is real.

layoffs are real.

weak retraining systems are real.

but that is different from treating one shallow interaction with a fast-moving technology as a verdict on the whole curve.

early tools are uneven. leverage still compounds for the people who learn by contact instead of commentary.

a vivid example is hiring itself.

for years, polished resumes and prestige markers were treated as reliable proxies for capability. then AI made polished language cheap.

the first response was often dismissal: more slop, more noise, more reasons to complain about the applicant pool.

but the more serious response was procedural. employers began shifting toward skills-based filters, work trials, and portfolio-style evidence because the old narrative surface no longer separated people cleanly.

what looked at first like a problem of lower quality was, underneath, a problem of degraded signal.

self-deception is rarely loud at first. it begins as comfort. then becomes habit.

then identity. once identity is involved, truth starts to feel like an insult.

that is when curiosity dies. that is when bitterness enters. that is when a once-open mind starts sealing itself shut.

the person is not stupid. the person is attached. and attachment to an old self-image, in a world that has moved, is one of the most sophisticated forms of self-sabotage there is.

signals….

resumes are weakening as signals, not because experience stopped mattering, but because the document captures less and less of what matters.

business insider reported this month that some companies now explicitly deprioritize or skip resumes, that recruiters say ai-polished resumes increasingly “all read the same,” and that the national association of colleges and employers found 70 percent of employers using skills-based hiring.

that shift is not abstract.

a person can change jobs three times, do multiple freelance projects, learn entirely new tools, and still be carrying around the same untouched resume they used to get a first job out of college, complete with internships that matter less than the work done since.

the narrative can stay frozen while the capability has changed completely.

that is why evaluation moves toward demonstration.

what has been built.

what decisions have been made. what can be shown. what tradeoffs can be explained.

what survives contact with scrutiny.

in practice, many founders now care less about polished pedigree than about signs of builder disposition,

a personal website, side projects, visible curiosity, proof that someone makes things without permission.

reporting has captured the same shift.

business Insider quoted employers and recruiters arguing that titles, years, and prestige are weak substitutes for deeper evidence of projects, skills, context, and scale.

this is not a rejection of skill.

it is a repricing of signal.

the world economic forum reports that employers increasingly value analytical thinking, resilience, flexibility, leadership, creative thinking, motivation, self-awareness, technological literacy, and curiosity toward lifelong learning. That list is not mystical.

it is what rises when routine production gets cheaper and judgment remains difficult to synthesize under real conditions.

this shift is uncomfortable for people who optimized for the narrative.

it is liberating for people who optimized for the thing itself.

surface became cheap. substance did not.

what remains?

the people who thrive in this environment will not be the ones who defend every legacy task with wounded pride.

they will be the ones who tell the truth early, even when that truth is inconvenient to their self-image.

they will stop romanticizing the grind. they will stop confusing friction with value.

they will stop treating effort as sacred proof of seriousness.

and they will go where the human work still lives: judgment, context, trust, taste, responsibility, synthesis, and the kind of pattern recognition that remains entangled with experience and consequence.

the question is not whether ai can do some part of what a person currently does.

in many domains, it plainly can.

the deeper question is what kind of contribution remains valuable when parts of production become cheap, fast, and abundant.

that is not a smaller question.

it is the first serious question many people have been forced to ask about their work in a very long time.

and it deserves a serious answer.

the answer will not be painless.

some workers will be displaced. some skills will be repriced downward.

some identities built around friction will crack under the loss of it.

that is part of the truth, not a reason to avoid it.

but the existence of that pain does not make the lever less real.

it makes the responsibility greater.

if part of the work is now cheap, the task is not to worship the old friction.

the task is to find the deeper thing one is here to contribute, and to build a life, a practice, and an economy around that truth.

“the impediment to action advances action. what stands in the way becomes the way.” — marcus aurelius

the stoics understood something that the tech world is just catching up to: the obstacle is the advantage. for decades, the bottleneck was building

and that constraint shaped everything. now that AI has dissolved that barrier, we’re face-to-face with a harder, more human challenge: judgment. this is the most optimistic moment in technology.

not because building got easy, but because what matters now taste, vision, narrative is the stuff that makes us irreplaceably human.

the tools got godlike. the question is whether we rise to meet them.

most teams are sleeping on it.

the most underrated hire right now isn’t an engineer. it’s not a designer. it’s definitely not a traditional product manager.

it’s someone i don’t have a great name for yet. maybe “product thinker.”

someone with an intuitive grasp of the product as it actually exists where it’s soft,

where it sings, and how to iterate it toward something sharper.

this person holds in their head where the product should be two years from now and works backwards from that.

not a roadmap person. a vision person with taste.

why now

when building was hard, engineering was the bottleneck.

the status hierarchy reflected that. engineers were (rightly) the most valued people in the room because shipping was the constraint.

building is no longer hard.

which means the variance in outcomes has shifted almost entirely to judgment.

what to build, how to sequence it, and

this is the part people miss

how to talk about it.

narrative is load-bearing

the story matters as much as the thing. internally, it organizes the team around a shared model of why.

externally, it shapes the interpretive frame users bring to their first experience.

you can’t retrofit narrative onto a product and expect it to land. it has to be structural from day one.

this is why so many technically impressive products feel flat.

the engineering is great, the narrative is an afterthought.

and in a world where everyone can build, the frame is what differentiates.

the rarest version

the rarest version of this person sits at the intersection of culture and deep technology.

genuinely bilingual.

they know what’s technically possible and they know which cultural currents are real vs. ephemeral.

that combo is what separates products that feel inevitable from products that feel assembled.

but wait — aren’t PMs already this?

someone will say: this is just a good product manager. and yeah, there’s overlap. nikunj kothari made a compelling case that PMs are actually uniquely suited to thrive right now:

1. they’re constantly generating ideas

2. they build articulate plans (critical for long-horizon agent tasks)

3. they rapid-context-switch across domains

4. they have a sense for outcomes vs. feedback, and can price work

5. they talk to customers and convert insights into action

these folks were always bottlenecked by the pace of development.

now that gap between idea and execution has collapsed, they’ve been set free.

here’s the thing though

what i’m describing isn’t a PM who got upgraded.

it’s a different orientation entirely. the PM role, especially at scale, drifted toward coordination.

status updates, ticket management, stakeholder alignment. the “product thinker” i’m pointing at is someone whose primary output is judgment on taste, sequencing, and narrative. not process.

the coordination-only PMs were always on borrowed time.

but the ones who were secretly doing this deeper work?

they might be the most important people in tech right now.

what this means if you’re building

if you’re a founder or early-stage eng lead, here’s what i’d actually think about:

1. stop hiring for implementation speed as your primary filter. that’s a commodity now.

2. look for people who can articulate why something should exist, not just how to build it.

3. test for taste and sequencing instinct, not just technical depth.

4. treat narrative as a core product skill, not a marketing function.

the real question

i don’t think we’ve figured out what to call this role yet. “product thinker” is a placeholder.

but the skillset — vision, taste, narrative instinct, cultural fluency, technical literacy — is becoming the highest-leverage thing in a room full of people who can all build.

before anyone claps back with “this person has always been valuable” — i know.

i’m just saying their value compounds like never before. and most teams still don’t have one.

if you’re this person and you don’t realize it yet, pay attention. the window is wide open.

further reading & rabbit holes

the conversation around taste, judgment, and the shifting role of product people is everywhere right now.

here are some threads and reads worth your time:

sophie bakalar wrote a sharp piece on how taste is becoming the new differentiator in tech — and why VCs are particularly bad at recognizing it early

Sophie’s Notes

Tech vs. Taste

Silicon Valley spent February discovering (or perhaps, rediscovering) taste, like it’s a product we can ship by Monday…

Read more

8 months ago · 6 likes · Sophie Bakalar

shrivu shankar’s counterpoint is equally worth reading — arguing that taste itself might be extractable and therefore not a durable moat:

Shrivu’s Substack

Taste Is Not a Moat

I used to write the design while AI coded the software. Architecture decisions, API contracts, data models on my side; implementation on its side. Fast forward a few months and more and more the model now handles both, because it’s more right than wrong. The “outer loop” of system design, the thing that engineers would do while AI wrote the the code, tu…

Read more

8 months ago · 20 likes · 7 comments · Shrivu Shankar

nikunj kothari’s piece on how PM is becoming prototype management is the clearest articulation of this shift:

Balancing Act

Product management → Prototype management

"Can I get a referral?" That's how most Product Manager (PM) conversations start these days. Then I ask what they've built using the company's tools. Silence. Incredulous stares. As if building something was an unreasonable ask…

Read more

2 years ago · 55 likes · 2 comments · Nikunj Kothari

and some threads from the timeline that hit on the same nerve:

https://x.com/thisiskp_/status/2029749589134229767

https://x.com/_EricHu/status/2024473858388922702

https://x.com/nikunj/status/2029931283728719994

and if you want to go deeper on the techno-optimist ethos that underpins all of this, marc andreessen’s manifesto is the canonical text:

https://a16z.com/the-techno-optimist-manifesto/

here’s a good video walkthrough of the manifesto:

read this before diving into projects, and if you wanna go deep ready philip’s book, a goldmine in taking you from dummy to expert

inference engineering, running models in prod, making them fast, keeping costs sane. all the cool kids on the block are doing it

so first of all…….

tokens

tokens are chunks of text.
sometimes a whole word, sometimes a piece of one.

“unhappiness” might become three tokens.

a tokenizer is just a lookup table that converts text to numbers the model understands.

why care? fewer tokens = faster and cheaper responses. different models tokenize differently, so the same sentence can cost more in one model than another. this is weirdly underrated when people compare model pricing.

the two phases that actually matter

every time you hit an llm with a prompt, two things happen:

1. prefill -- the model reads your entire input at once and produces the first token. think of it as the model thinking before it speaks. this is limited by raw compute power.

2. decode -- the model generates the rest of the response, one token at a time. this is the model talking. limited by how fast it can read from memory.

this is the single most important concept. if your model is slow, you need to know which phase is the bottleneck. otherwise you’re just throwing hardware at the problem and burning money. someone will say “just get a bigger gpu” -- and yeah, but here’s the thing: if decode is your bottleneck, more compute doesn’t help. you need more memory bandwidth.

the kv cache: your model’s short-term memory

when the model reads your input during prefill, it builds a cheat sheet called the kv cache. instead of re-reading the entire conversation for every new word it generates, it checks its notes.

the catch: this cheat sheet lives on your gpu’s memory and gets huge fast. managing it -- storing it, reusing it across requests, freeing it up -- is one of the core jobs of inference engineering. terms like flashattention and pagedattention? just clever ways to make this cheat sheet smaller or faster to access.

here’s what actually matters for builders: if you’re running multi-turn conversations or long system prompts, prefix caching lets you reuse the kv cache from shared prompt prefixes. that means your second message in a chat is way cheaper than the first. context engineering -- putting the novel stuff late in your prompt -- directly saves you money and latency.

dense vs. moe: two kinds of brains

dense models like llama 8b use all their parameters for every question. simple, predictable, expensive at scale.

mixture of experts models like qwen3-235b have 235 billion parameters but only activate 22 billion per request. it’s like having a building full of specialists but only paging a few for each question.

sounds like a cheat code, right? not quite. at scale with many concurrent users, different requests activate different experts, and most of the building ends up awake anyway. moe is a different tradeoff, not a free lunch. but for single-user local inference? it’s genuinely great.

why your gpu choice matters………

every gpu has two key specs: compute power (math speed) and memory bandwidth (data reading speed). the ratio between them determines your bottlenecks.

more reading than math needed? memory-bound. typical during decode. more math than reading? compute-bound. typical during prefill.

batching multiple requests together helps because you squeeze more math out of each memory read. this is why inference providers obsess over batch sizes -- it’s the easiest lever to pull.

how the model picks its words

the model doesn’t choose words. it scores every possible next token, turns scores into probabilities, and rolls a weighted dice. you can tweak the dice:

1. temperature -- lower = predictable and boring. higher = creative and chaotic.

2. top-k -- only consider the k most likely tokens.

3. top-p -- only consider tokens until probabilities sum to p.

when your model outputs garbage or broken json, the fix is often here -- not in the model itself, but in how you’re rolling the dice. this plus structured output tools like logit biasing are how you get reliable tool use and function calling.

when one gpu isn’t enough

big models don’t fit on one gpu. a billion parameters is roughly 1 gb of memory in fp8. a 671b parameter model needs 671 gb just for weights -- and the biggest single gpu has 192 gb.

the solution is splitting work across gpus: tensor parallelism (split each layer), expert parallelism (split experts across gpus), or pipeline parallelism (split layers across gpus). each has tradeoffs in latency vs throughput vs communication overhead.

practical rule: if your model is under 8b parameters on a modern gpu, you probably don’t need to worry about this yet. if you’re running something bigger, tensor parallelism within a node is the default starting point.

so what does this mean for you

if you’re a builder shipping ai-powered products, you don’t need to become a cuda kernel developer. but you do need to understand these fundamentals the same way a web developer needs to understand http even if they never write a tcp stack.

knowing whether you’re prefill-bound or decode-bound changes what hardware you pick. understanding the kv cache changes how you design your prompts. knowing how token sampling works saves you from blaming the model when the problem is your inference config.

the gap between “i can call an api” and “i can run a model well” is where a lot of value is hiding right now. and most people are skipping straight past it.

if you’re just getting into this -- start with the two phases. everything else builds on top of that.

this one’s been sitting in my head for a while......

jack dorsey just cut block’s workforce nearly in half. from over 10,000 to under 6,000.

my read: this wasn’t a rescue cut. it was an operating model change.

is the business struggling? nope. $2.87 billion in gross profit last quarter. $0.65 adjusted EPS. profitability improving. the stock popped over 24% after the announcement. this wasn’t a desperate move -- it was a calculated one.

but let me be clear about something: 4,000 people lost their jobs. that’s real people, real families, real disruption. i’m not celebrating layoffs. i’m trying to understand the signal underneath them.

he read a signal and acted on it before he was forced to.

in his own words:

“we’re already seeing that the intelligence tools we’re creating and using, paired with smaller and flatter teams, are enabling a new way of working which fundamentally changes what it means to build and run a company. and that’s accelerating rapidly.”

he had two options: cut gradually over months or years as this shift plays out, or be honest about where things are and act now. he chose the latter.

and block isn’t alone. amazon cut 16,000 roles. salesforce cut 4,000. wisetech cut 30% of its workforce. the world economic forum’s 2026 survey found 41% of employers expect to reduce headcount due to AI by 2030. this isn’t one company making a bet. it’s the beginning of a structural shift.

from what i know of jack, he has a good head on his shoulders. i don’t think he’s jumping the gun here. part of it is because AI made leaps in 2026 that weren’t expected for years. the models got better. the agents got real. and the economics flipped faster than anyone’s org chart could keep up with.

block built an internal AI tool called goose. it handles code review, support ticket routing, marketing asset generation, development cycle acceleration. the people who survived the cut are the ones who, paired with tools like goose, can do the work of three. that’s not speculation -- that’s what dorsey said in his memo.

every big tech exec has already recognized the same insight. they just haven’t had the confidence to do something this audacious. block getting rewarded -- even if the market’s reasons are more complex than pure validation -- will embolden them to take swift action.

expect more. roles are going to shrink. not because companies are failing. because the math changed.

shopify’s tobi lutke said the quiet part out loud months ago:

his internal memo to shopify employees was blunt: before requesting new headcount, teams must now prove that AI can’t do the job first. AI proficiency isn’t a nice-to-have -- it’s a baseline expectation for every role at the company.

the networking advice is good. but it’s not enough.

lindsay casale wrote a piece this week called “never apply to another job again” that went viral. her advice is solid: stop sending applications into the void. tap your inner circle. reconnect with recruiters. activate your soft network. prep before you ping.

she’s right. the hidden job market is real. most jobs are filled through referrals and warm introductions, not job boards. this isn’t a knock on her advice -- plenty of career writers talk about skill relevance alongside networking.

but here’s what the broader conversation misses:

it doesn’t matter how warm your introduction is if your skills are outdated.

the market shifted not just because networking is broken. the ground moved underneath what companies actually need. the roles that survived dorsey’s cut -- and the ones that will survive what comes next -- look fundamentally different than they did even a year ago.

so what actually works now?

here’s the thing everyone’s getting wrong: the move isn’t to “learn how to build AI agents.” that’s the shiny object.

the real move is to learn how to build with agents -- integrate them into your workflow, speed up your development cycle, and multiply what you can ship as a single person or a small team.

at this point development cycles should be hours, not days , not weeks, learn how to run agents 24/7.

you need to upgrade how you work. not in the way you’re thinking -- not a new framework or a new language. i mean fundamentally rethinking your operating system as a builder.

here’s what that looks like in practice: spec > agent draft > human edit > agent test > ship. that’s the loop. i talked about this in my last post -- the bottleneck is no longer coding speed. it’s the rate at which you can generate ideas, write specifications, and validate outputs.

speed up your development. if you’re not using AI to accelerate your build process, you’re already behind. the people who survived the block cuts are the ones who, paired with intelligence tools, can do the work of three. jack said it himself -- smaller and flatter teams, enabled by intelligence tools. that’s not a future prediction. that’s a current job requirement.

learn to be creative. yes, i said it. creativity isn’t a soft skill anymore -- it’s a survival skill. when AI can handle the rote execution, the human who can think laterally, connect dots no one else sees, and imagine new products from existing primitives becomes the most valuable person in the room. creativity is the job now.

expand your skill set beyond just building a product. design. marketing. strategy. distribution. customer insight. the lines between these roles are dissolving. the people who thrive will be the ones who can wear multiple hats and actually perform in each one.

you know the saying -- “a jack of all trades is a master of none.” we’ve all heard it. but that’s only half the quote. the full version goes: “a jack of all trades is a master of none, but oftentimes better than a master of one.” that’s the new job market in a single sentence.

now -- a nuance that matters. i’m not saying specialists are dead. elite specialists in security, ML research, compliance, infrastructure -- the ones who use AI to deepen their domain advantage -- they win too. what’s vulnerable is routine specialization: the mid-level, narrow role doing repeatable work that an AI-augmented generalist can now cover. dorsey didn’t just keep generalists. he kept people who can operate across a flatter, intelligence-first organization -- whether that’s through deep expertise amplified by AI or broad capability multiplied by it.

the new resume: proof-of-work

honestly never like making a resume, while writing this i found my old one, last updated 2023……..

i’ve switched multiple jobs since then , never needed it

proof-of-work is a leading indicator. here’s what actually replaces the resume in an intelligence-first hiring market:

a one-page portfolio of shipped outcomes. not job descriptions -- actual things you built and what happened because of them.

a “systems i built with agents” walkthrough. show someone your workflow. show them the loop. that’s more impressive than any bullet point on a resume.

before/after metrics. “i used AI to cut this process from 2 weeks to 2 days. here’s how.”

a public build log. write about what you’re building in public. substack, github, twitter -- doesn’t matter where. the artifact is the proof.

a targeted product teardown. pick a company you want to work at. tear down one of their features. show how you’d improve it using AI-augmented workflows. send it to their team. that’s how you bypass the ATS entirely.

the hiring channels that matter now aren’t ATS funnels. they’re founder networks, open-source contributions, community hiring, trial projects. lindsay’s networking advice gets you into these channels. the proof-of-work artifacts above are what make you undeniable once you’re there.

the bottom line

lindsay’s networking advice will get you in the door. but what keeps you in the room -- what makes you the person who stays when 4,000 people are asked to leave -- is whether you’ve evolved how you work.

layoffs aren’t a perfect merit filter -- timing, cost structures, product line cuts all play a role. but they do reveal what organizations think is leverage. and right now, the signal is clear.

the defensible position isn’t your resume. it’s not even your network.

it’s being hung, your ability to adapt, build fast, think creatively, and operate across disciplines with AI as your co-pilot.

dorsey saw it. the market responded. the rest of the industry is watching.

the question isn’t whether this is coming. it’s whether you’ll be ready when it does.

if you’re rethinking how you work right now -- or trying to and struggling -- hit reply and tell me where you’re at.

i read every response.

many developers today have a love-hate relationship with agile

me? well…..

usually i’ve seen people often loving the “agile” mindset

but hating the rigid, bureaucratic, and micromanaging “Agile-in-name-only” practices often implemented by management

i am people

sprints, story points. two-week cycles. plan, design, develop, test, deploy, review,repeat.

after years of rigid waterfalls and heavyweight processes, agile promised a better way: smaller batches, faster feedback, continuous iteration. and for a while, it delivered.

instead of one giant waterfall that took months to crash, you got lots of small ones. each sprint was its own mini-lifecycle.

but here’s my thought: agile was still ceremony.

sprint planning, story points, PR review cycles, estimation rituals. the steps were smaller, but they were still steps. still discrete. still sequential. still full of handoffs and waiting.

and for a tinkerer like me who just wants to hack stuff together, ship, see what breaks, and iterate, it was just a faster version of the same straightjacket.

if your goal in life is to babysit documents, agile is heaven. if your goal is to hack stuff together, ship, see what breaks, and iterate

i truly believe it’s a straightjacket with better branding.

the agile sprint cycle: still sequential inside each sprint, but at least you iterate between them

before agile, there was something else

the V-model is where it all started.

there’s a picture that still lives rent-free in my head:

Vision → Requirements → System Architecture → Detailed Design → Implementation → Unit Tests → Integration Tests → System Tests → Acceptance Tests. design flows down the left side, testing climbs back up the right.

the economic bet was simple: think hard early, avoid expensive mistakes later.

a defect caught in requirements is cheap; the same defect in production can be 10–1000x more expensive.

so we created ceremony to force thinking upfront—requirements documents, architecture reviews, design specs, formal test plans mapped to each requirement.

if your iteration speed is measured in months, this is rational. when every release is a mini military operation, you can’t afford to learn by shipping.

i hated it.

i’ve always been a fan of hacking stuff together ,get a scrappy version working,

slap it in front of users, tighten the screws, repeat.

the V-model turned all of that into a smell: undisciplined, insufficiently designed, needs more documentation.

it’s not just outdated. it’s boring.

the SDLC is dead or dying depending on whom you ask

you know i’m gonna say ai is the reason so gonna spare you that

i think the software development lifecycle, as we were taught it, should step aside.

not because rigor doesn’t matter, but because it was optimized for constraints we no longer have.

boris tane put it sharply: AI agents didn’t make the SDLC faster—they killed it.

the framing that AI is a “10x developer tool” is wrong because it assumes the workflow stays the same and the speed goes up.

that’s not what’s happening. the stages aren’t getting faster.

they’re merging. requirements, design, implementation, testing, review, deployment—they’re collapsing into a single fluid loop.

the agent doesn’t know what step it’s on because there are no steps. there’s just intent, context, and iteration.

every stage is caving in. testing used to be a separate phase,

agents write tests alongside the code now, not as an afterthought.

TDD isn’t a methodology anymore, it’s just how agents work by default. code review?

the pull request flow needs to go.

an agent generates 500 PRs a day.

your team can review maybe 10.

that review queue isn’t a bottleneck worth optimizing—it’s a fake bottleneck,

one that only exists because we’re forcing a human ritual onto a machine workflow.

deployment? agents are already writing deployment pipelines more intricate than what most teams would build by hand

feature flags, canary releases, progressive rollouts, automatic rollback triggers.

there’s a whole generation of engineers who will start their careers after Cursor launched.

they don’t know what the software development lifecycle is.

they’ve never sat through sprint planning.

never estimated story points. never waited three days for a PR review.

they just build things.

you describe what you want, agent writes the code, you review it, you iterate, you ship.

everything simultaneously. they aren’t worse for skipping the ceremony.

they’re unencumbered by it.

from software engineer to agent engineer

as AI gets better, a lot of traditional boundaries blur.

when agents can handle much of the mechanical implementation,

roles reorganize around responsibility, not syntax.

the shape that makes sense to me is an “agent engineer”

side note- i like to call myself the agentic head or head of engineering agents

but thats just me

a person who understands intent -what are we trying to achieve and why?,

encodes constraints -what must stay true even as we move fast?,

shapes context -what structure and information do agents need to be useful?, and

curates feedback loops -how tests and production signals flow back into the system.

you still need taste, judgment, and some scar tissue.

but the leverage moves from “i can type fast” to “i can design systems where agents and humans can tinker safely and ship constantly.”

i’m seeing this firsthand.

what used to take weeks—from idea to deployed feature—now happens in days,

sometimes hours. (wish i was talking about me , but i’m getting their)

we’re shipping code to production at a pace that would have been unthinkable two years ago.

not because we skipped testing or cut corners,

but because agents handle the scaffolding, the tests, the deployment config,

and the iteration loop so fast that the human bottleneck is no longer typing or reviewing—it’s deciding what to build next.

the only stage that survives: observability

if every other safeguard has been absorbed or eliminated

the design review, the code review, the QA phase, the release sign-off—what’s left?

monitoring.

observability is the only stage of the old SDLC that survives intact.

and it doesn’t just survive—it becomes the foundation everything else rests on.

when agents ship code faster than humans can review it,

observability is no longer a nice-to-have dashboarding layer.

it’s the primary safety mechanism for the entire collapsed lifecycle.

the observability layer becomes the feedback mechanism that drives the whole loop—not a stage at the end,

but the connective tissue of the entire system.

the future isn’t dashboards that humans stare at.

it’s closed-loop systems where telemetry feeds directly back into the agent that shipped the code, so it can detect regressions and fix them.

the new cycle…….

the SDLC was a wide loop: requirements to design to code to test to review to deploy to monitor.

linear. sequential. full of handoffs and waiting.

the new lifecycle is a tight loop:

intent, build, observe, repeat.

no tickets. no sprints. no story points. no PRs sitting in a queue.

just a human with intent and an agent that executes.

and the quality of what you build is directly proportional to the quality of context you give the agent.

not the process. not the ceremony. the context.

the new skill isn’t lifecycle management—it’s context engineering.

the new safety net isn’t code review—it’s observability.

startups will keep winning not because they plan less, but because they learn faster.

and for the first time, the tools match that instinct.

the tinkerers don’t have to apologize anymore.

the V-model was someone else’s game.

agile was a step closer.

but this new one

intent, build, observe, repeat

i love it. truly for the hackers, builders, tinkers!

just ship. then ship again.

it’s finally the era of the tinkerer.

bear with me. i have a lot of thoughts……

last week, matt shumer’s “something big is happening” reached millions of people

one of the lines that stayed with me the most was:

“a year ago, AI could barely write a few lines of code without errors. now it writes hundreds of thousands of lines that work correctly. there will be far fewer programming roles in a few years than there are today.”

the debate started immediately. and it’s understandable.

but it’s asking the wrong question.

i’ve been a hobbyist developer and a tinkerer most of my life. i’ve been fortunate to be in a position where what i do every day is exactly what i’ve unconditionally enjoyed doing for years — building things with incredible people. and i honestly think teams should be ignoring the discourse and focusing on one thing:

if implementation is getting cheap… what becomes scarce? and what kind of engineering team is built to operate under that scarcity?

not one person. the team. the culture. the system that produces software.

the paradox

boris cherny, head of claude code at anthropic, says 100% of his personal output is now AI-written — 22 PRs one day, 27 the next. across anthropic, the company-wide figure is between 70% and 90%.

that sounds like “engineers are done”… until you look at their careers page and see dozens of open engineering positions." boris’s response to that

then there’s openai’s harness engineering team. three engineers used codex to build a product from an empty repo to a million lines of code in five months. zero lines written by hand. averaging 3.5 PRs per engineer per day. and throughput actually increased as the team grew to seven — the inverse of what usually happens when you add headcount.

outside the AI labs, the numbers are more grounded. satya nadella said 20–30% of code in some microsoft repos is AI-generated. a peer-reviewed study in Science analyzing 30M GitHub commits found 29% of U.S. Python functions are now AI-written.

the thesis

it’s worth acknowledging the jevons paradox, one of the most interesting dynamics in this whole debate. when a technology makes a process dramatically cheaper, demand for that process often increases. as AI lowers the cost of building software, organizations may tackle bigger initiatives they never would have greenlit before. whether that means “far fewer roles” or “different roles for the same number of people” is genuinely unresolved.

what is resolved: AI makes implementation cheap. it does not make decision-making cheap.

kailash nadh, CTO of zerodha, recently wrote about this exact inversion — flipping linus torvalds’ famous “talk is cheap. show me the code” into “code is cheap. show me the talk.” his argument: for the first time, good articulation — the ability to imagine, define problems, architect, and engineer — is exponentially more valuable than the ability to type code line by line. the bottleneck is no longer biological. it’s cognitive.

fewer engineers writing code. more engineering teams designing the systems that produce correct code.

what the surviving engineer actually does

the old loop: think → code → test → ship.

the new loop: think → specify → delegate → verify → ship.

the human stays in the loop but at a different layer of abstraction.

the engineer becomes five things:

intent translator. messy requirements → constraints an agent can’t misread. acceptance criteria that can’t be gamed.

environment designer. the repo becomes the operating system for agents + humans. structure, docs, linters, CI, observability — all designed as surfaces agents can read and verify against.

verifier. throughput spikes make “knowing it works” the expensive part. mechanical architecture constraints, fast test feedback, security scanning earlier than you’re comfortable with.

orchestrator. once you’re running parallel agents, the limiting factor is delegation. systems thinking. management. not prompting.

taste-keeper. someone has to define what “good” means for this codebase, capture it in tooling, and enforce it continuously. review comments become linter rules. PR feedback becomes documentation. human judgment gets encoded once and applied everywhere.

for engineering leaders: this is why your best early engineers now look like platform/infra/product hybrids. your next hire might be a “verification + tooling” engineer, not another feature dev.

the stages of agent throughput

“using AI to code” is not a binary. it’s a progression. most teams are around stages 2–4 without realizing how far the frontier has moved.

that’s fine — most teams shouldn’t be at stage 7. the question is whether you know where you are, and whether that’s a conscious choice.

beginner- autocomplete. tab-complete, chat Q&A, but writing everything yourself. (p.s. — this is where most engineers are right now. there are people who don’t use any of the above, but they’re also the devs who use light mode……)

amateur:agent-in-IDE. running an agent in the IDE (cursor, antigravity — take your pick) but with permissions on, approving every change.

semi pro: autonomous agent, human review. the agent operates autonomously. developers review, not write.

pro: diff-native. moving beyond IDE territory. code is mostly diffs. the repo is the interface, not the editor.

legendary: CLI single agent. everything in CLI. only verifying output.

god: CLI multi-agent. running multiple agents in parallel. the only bottleneck is the developer’s ability to specify and verify.

highest level: agent orchestrator. custom (or off-the-shelf) orchestrator handling task assignment, context sharing, feedback loops, merge coordination. humans review final output.

the jump from stage legendary to god isn’t incremental. it’s a phase transition. the models are capable enough. what’s missing — and what separates teams at these stages — is the orchestration infrastructure: the context systems, verification loops, and coordination layers that let agents work reliably in parallel.

a critical enabler from IDE to CLI : markdown-based knowledge systems.

• CLAUDE.md / AGENTS.md — project-level instructions. onboarding docs, but for agents.

• obsidian-style vaults — linked markdown files where agents follow [[wiki links]] to build understanding.

• repomix / ai-kb — tools that package codebases into single AI-friendly files for full project context.

the underlying pattern: externalize knowledge as plain-text files with explicit relationships. give agents a way to navigate and load what’s relevant.

context engineering: what actually works?

if your team’s decisions live in people’s heads, in slack threads, or in a wiki nobody reads — they don’t exist to the agent. openai’s harness team was explicit about this: “from the agent’s point of view, anything it can’t access in-context while running effectively doesn’t exist. knowledge that lives in Google Docs, chat threads, or people’s heads are not accessible to the system.”

context engineering is the discipline of making a team’s decisions, preferences, and constraints legible to agents at the point of execution.

here’s what converges from research and real-world results:

give agents a map, not a manual. a giant AGENTS.md fails once it’s too large — context rot sets in. openai’s harness team treats theirs as a ~100-line table of contents. real knowledge lives in a structured docs/ directory. write an ARCHITECTURE.md — a codemap that answers “where is the thing that does X?”

use boring technology. stable, well-documented packages are better represented in training data — agents can reason about them more reliably. the harness team took this further: rather than pulling in a generic p-limit-style concurrency package, they had the agent reimplement a map-with-concurrency helper tightly integrated with their OpenTelemetry instrumentation, with 100% test coverage, behaving exactly the way their runtime expects.

enforce boundaries mechanically. agents replicate existing patterns — even bad ones. the harness team uses strict layer-dependency rules (types → config → repo → service → runtime → UI), enforced by CI, with custom error messages that inject remediation instructions directly into agent context. if you find yourself leaving the same PR comment twice, write a linter.

you don’t make agents better by giving them more freedom. you make them better by constraining their workflow and externalizing their state.

garbage-collect continuously. teams ship 10x faster, then spend friday cleaning “AI slop.” the harness team used to spend 20% of their week on this. the fix: background agents that scan for deviations, update quality grades, and open targeted refactoring PRs.

make testing + observability a product. the harness team made their app bootable per git worktree so parallel agents run isolated, wired chrome devtools protocol into the runtime, and gave agents access to logs, metrics, and traces directly. prompts like “ensure service startup completes in under 800ms” become tractable when agents can actually measure.

an existence proof: gas town. steve yegge’s gas town coordinates 20–30 claude code instances in parallel — six specialized roles (mayor, polecats, witness, deacon, crew, refinery) with all state in git-backed “beads.” when an agent crashes, the next picks up exactly where it left off. it’s polarizing — “100% vibe coded,” weeks old, and a memecoin controversy damaged credibility — but maggie appleton’s analysis concluded the patterns it sketched will show up in the next generation of dev tools. dolthub’s experience included 100 USD/hour token burn and agents deleting code unpredictably — a reminder that orchestration is infrastructure, with all the same failure modes as any distributed system.

the 2025 DORA report reinforces all of this: AI is an amplifier. strong systems get leverage. weak systems get amplified dysfunction.

a side note on token anxiety

nikunj kothari’s “token anxiety” essay captures something real about this moment — the compulsion of watching agents run, the pressure of capability itself becoming a source of stress. “every week some new benchmark drops that makes last month’s workflow feel prehistoric. none of it reduces the pressure. it multiplies it.” if you’re running claude code on the max plan and want visibility into where you stand, claude-code-meter is a macOS desktop widget (built for Übersicht) that shows your 5-hour and 7-day usage windows in real time. might ease the anxiety. might fuel it.

where agent-first teams might blow up

being honest about failure modes is what separates engineering culture from marketing copy.

instability. the DORA report found AI improves nearly every metric — except system stability. “speed without stability is just accelerated chaos.” invest in deployment safety and rollback discipline before you crank throughput.

security + “looks correct” bugs. a veracode study found LLM code introduced OWASP Top 10 vulnerabilities in 45% of test cases. java hit a 72% security failure rate. treat AI output as higher-risk on auth, payments, and data access. scan earlier (IDE → PR → pipeline).

review overload. if generation goes up 5–10x and review stays the same, your best reviewers drown. the harness team pushed almost all review to agent-to-agent, with humans stepping in only for judgment calls. smaller PRs, AI pre-screening, explicit “definition of done” checklists.

orchestration chaos + runaway cost. orchestration is infrastructure. monitor it like infrastructure. or it’ll blow up like infrastructure. instrument cost and quality from day one.

practical starting points

if you’re an eng lead or IC — here’s what moves you forward without turning your repo into an experiment nobody trusts:

1. pick one “agent lane.” new endpoints, internal tools, or data migrations — low-risk, high-rep work.

2. write an AGENTS.md map, not a bible. 50–150 lines. “how we work here” + pointers to deeper docs.

3. add an ARCHITECTURE.md codemap. answer: “where is the thing that does X?” — in under 60 seconds.

4. mechanically enforce one boundary. layer rules, auth boundaries, logging standards. one custom linter.

5. add one verification loop that doesn’t need a human. contract tests, smoke tests per worktree, or a “golden flows” suite.

6. track 3 metrics weekly: PR throughput, stability (rollbacks, incidents, flaky tests), and human review time. if throughput goes up and stability stays flat, you’re compounding. if stability drops, slow down.

7. if you’re an IC wondering what this means for you: the engineers who thrive will learn to specify clearly, design constraints, and build verification systems. start by writing the AGENTS.md for your team’s repo. you’ll learn more about your codebase than you have in months.

the real bottleneck

the bottleneck is migrating from coding speed to something else entirely: the rate at which you can generate ideas, write specifications, and validate outputs.

if that’s truly the limiting factor now, what does an engineering organization optimized for idea throughput look like rather than one optimized for code throughput?

everything downstream changes.

the teams figuring this out first aren’t just going to be faster. they’re going to be playing a different game entirely.

if you’re building an agent-first workflow right now (or trying and failing), hit reply and tell me what stage you’re at.

i read every response.