My next experiment: “Inbox Development.”
What if every requirement arrived like an email?
Each engineer has an inbox. A requirement from the PM comes in. She forwards it to her coding agents.
A few hours later, she replies: “Done. Tested. Deployed.”
We got used to replying to emails within hours. What if we got used to shipping requirements just as quickly?
The goal: Inbox Zero.
We told our developers, “No more hand-written code,” six months ago.
Today, 99% of our code is written by AI.
Now Epic Games is telling its teams the same thing - and getting the same pushback.
Since this post took off, I looked at Instinct, the AI assistant my whole family uses.
It was started roughly a year ago. Last month, it raised $1 billion at a $10 billion valuation. Team size: fewer than 20.
From what I could find, for every engineer, there is roughly one non-engineer across the product, strategy, and operations.
One person deciding what to build for every person building it.
The 1:1 team is already here.
At least, that is how it looks from the outside. Only @noahrshinn can confirm :-)
I got a lot of pushback for saying that one product manager and one engineer can now be the entire team.
Now @danshipper has a name for it: the pirate and the architect.
I ain’t crazy after all. :-)
Everyone has to market themselves. Even APIs.
An MCP server is basically an API’s marketing brochure for agents :-)
ALL CODE IS NOW OPEN SOURCE
Not legally. Practically.
For a long time, we assumed that compiling code and hiding the source code protected it.
AI changes this.
AI can take a binary, decompile it, and reconstruct readable source code that behaves like the original.
It may not reproduce the exact source file you wrote. But it does not need to.
All code you ship is now effectively open source.
Open source may have won without everyone agreeing to open-source their code.
In the new AI world, we need a lot more product managers.
Perhaps even one product manager for every engineer.
The old ratio of one PM to five engineers assumed that development was the bottleneck. That is no longer true. AI is making implementation fast and increasingly straightforward.
What remains difficult is deciding what to build, understanding who needs it, defining how it should work, and prioritizing ruthlessly.
When execution becomes cheap, judgment becomes the bottleneck.
Anyone else thinking this way? Would love to compare notes.
Woke up to this message: my domain registrar had closed my account.
After some digging, I found the culprit.
My agents had been trying to buy a LOT of .si domain names. Apparently, they had smelled an opportunity.
Further digging revealed the real masterminds: my kiddos.
After Trump’s speech rebranding AI as “Super Intelligence,” they had instructed the agents to hunt for .si domains.
The agents couldn’t complete the purchases. But they did build an Excel sheet with hundreds of .si domains, and the kiddos were adamant that I “invest.”
I tried explaining why this was a bad idea.
In vain.
I finally conceded and allowed them to buy 25 domain names.
Just another regular morning in my household. 😄
Okay, allow me to brag a little today. Please excuse me. :-)
Today, Silq is the leading embedded-finance platform in Saudi Arabia.
And I may have been the first to conceive and patent embedded checkout, an early precursor to today’s embedded finance.
Here is that story.
In 2008, paying through a third-party payment service such as PayPal typically meant leaving the merchant's website. Customers clicked a payment button, were redirected to the payment provider's website, authenticated themselves, gave the payment info, and then returned to complete the purchase.
I was working on Amazon Pay at that time and thought there had to be a better way.
My idea was to embed checkout within the merchant's website instead of redirecting the customer elsewhere.
The payment provider should be able to present the checkout experience inside the merchant's page. Customers should be able to use their stored payment and shipping info, while their sensitive credentials travel directly to the payment provider and remain invisible to the merchant.
I came up with two ways of achieving this.
1. Quick Checkout (U.S. Patent No. 10528931)
The "Quick Checkout" architecture used provider-controlled components embedded within the merchant's page. Sensitive information went directly to the provider, rather than passing through the merchant.
The architectural principle eventually became standard across modern payments:
- Braintree Hosted Fields uses provider-controlled iFrames, so raw card information never reaches the merchant's server.
- Stripe Elements uses Stripe-hosted components embedded within the merchant's checkout, with sensitive card details going directly to Stripe.
- Adyen similarly embeds provider-managed payment experiences within merchants' websites.
2. Instant Checkout (U.S. Patent No. 9324098)
Instant Checkout took the idea further. The payment provider could recognize the customer through its cookie, retrieve the customer’s default payment and shipping information, and deliver a one-click experience within the merchant’s website.
That idea also grew into a major category:
- Bolt created a cross-merchant shopper network offering embedded one-click checkout.
- Shop Pay made stored payment and shipping info reusable across Shopify merchants.
- PayPal also allowed customers to complete purchases without leaving the merchant experience.
Embedded checkout brought payments into the purchasing journey. Embedded financing brings capital into the same journey.
Both reflect the same conviction: services should appear naturally at the moment of need - not force customers into a separate process.
Context switching is becoming a key skill in the AI era.
AI will slow you down if you work on one task at a time. It is like the mainframe days again. You give it a task, then sit and wait for the result. You may be slower than you were before AI.
The skill that matters now is not doing one task faster. It is switching between several tasks, so you can stop waiting for one agent and run five at once.
So I forwarded the Instinct message to my wife and she is now banning my AI assistants 😆
See? I told you the Claude team was watching 😄
Yesterday, I complained that Claude takes over my browser while ChatGPT browses inside the chat.
Today, Claude launched a built-in browser inside Cowork.
Clearly, they built it overnight after reading my post. 😄
A clarification, because I think the phrase landed differently than I intended.
I said “No more tech teams.” What I meant: “No more teams.” Yeah, still probably radical.
A single engineer managing an agent swarm is the team.
She is no longer an individual contributor. She is an engineering organization.
One senior engineer can mentor several such one-person teams.
Lately, Claude, especially Fable, has not been good at web research for me. It keeps hitting firewalls and bot checks, and its computer use interferes with my browsing.
ChatGPT somehow rarely gets blocked, and browses right inside the chat.
So most of my web research has moved to ChatGPT. Claude now just reviews what ChatGPT found.
We have successfully adopted "No more typing of code."
We are halfway to "No more code reviews."
Now I am pushing the next idea:
"No more tech teams."
One engineer per team, managing an agent swarm.
One senior engineer mentoring several such teams.
Back to O'Reilly after two decades. New animal on the cover, same yellow highlighter.
Weird. So if someone writes an entire document with AI and then rephrases the text alone, there is no watermark. Someone writes it by himself and uses AI to just fix their grammar: watermarked as AI.
Reflecting on our first year since Sary and ShopUp merged to form SILQ, as we announce our $100 million debt facility to back the next phase.
I started liking Gray ...
Instead of STE-100, use this for your AI-written documents.
The voice: simple yet powerful, not marketing-y. One clear mind explaining something plainly, persuading through reasoning rather than adjectives. A smart outsider should follow it instantly with no prior context.
The writing tenets:
- Short sentences. One idea per sentence; prefer several short ones over a long one.
- Full sentences, never fragments. No telegraphic "Term: clipped phrase" bullets.
- Plain words, no buzzwords. Cut leverage, agentic, AI-native, seamless, robust, and the rest. If a term is unavoidable, define it right there.
- Assume no prior knowledge. Explain every concept and name as you introduce it.
- Problem first. Today's state and why it is a problem, then what you build, then the benefit, in that order.
- Be concrete. Real numbers and a worked example over abstraction.
- Causal logic. Say "X, because Y." Explain the link; do not just assert it.
- No decoration, no throat-clearing. Cut hype adjectives and filler openers.
- Be honest and operational. Name owners and open gaps plainly, in the text.
- No contractions. "do not," not "don't."
- Scannable structure. Bold title carries the what; a short paragraph carries the why and how.
- One claim, one source. Sanity-check everything. Each item is one real thing under its real name; flag contradictions, do not smooth them over.
- The summary is derived from the detail. Never say anything the full version does not; re-derive it when the detail changes.
- Park references in a short trailing tag. Keep sources and tools out of the prose.
- Label every number. Never give a bare figure - say what it measures.
Amazon should have been the company that led AI. I say that with respect, and a bit of pain, as an ex-Amazonian.
Alexa should have been ChatGPT. AWS should have been Claude. S3 should have been the default company brain.
Amazon had the distribution to own the assistant, the infrastructure to own the model, and a perfect file system to be the company brain.
And who better to do it than the creator of AWS himself, @ajassy, now at the helm?
But the wait has been long, and in AI, velocity decides the winners.
Suddenly, everyone is adding ASD-STE100, Simplified Technical English, to their CLAUDE.md and thinking it will fix AI's sloppy writing. It will not.
ASD-STE100 is built for aircraft maintenance manuals. Its readers are technicians, often non-native English speakers. It forces short sentences, plain words, one instruction at a time, and a fixed dictionary of about 900 approved words, each locked to a single meaning.
But STE is voice-less by design. Every sentence is meant to read the same way, from anyone, forever.
And here is the irony. The complaint about AI writing is not that it is too colorful. It is that it is generic. Flat, hedged, saying nothing, sounding like everyone else. STE makes writing more uniform, not less. You would be fixing AI slop with a different flavor of AI slop.
Borrow what is good in it - short sentences, plain words, no jargon. But add your own writing tenets.
AI slop is a thinking problem, not a vocabulary problem. STE constrains words. It does nothing about thought.
Did the SaaSocalypse happen? Yes - roughly $2 trillion of software value gone.
But here is the strange part: the businesses kept growing. Adobe posted record revenue and still fell more than 40%.
What the crash was actually about:
Elon's statement reinforces my belief that looking at source code is not just inefficient but dangerous.
Self-Coding Is Now Dangerous
Self-Coding Is Now Dangerous ...
The debate over black-box coding is over. You no longer need to read the code written by AI.
I know there are still many skeptics. It is no longer a question of whether they will convert, but when.
The skeptics have a fair objection: if you do not read the code, how do you trust it? You do not do it by reading every line the AI wrote. You instead master your tests and evals so that whatever the code produces is correct.
Check the output, not the code.
Some news from Silq: We have secured a $75 million debt facility from Fasanara Capital. It funds our AI-first B2B financing for SMEs in Saudi Arabia.
GPT just lied. Of course, it didn't go through the entire doc.
I just published a paper on this Remember protocol.
The paper lays out the protocol: how facts get captured as you work, how they stay current, and how every memory claim is checked against what is actually on disk before it reaches you.
It is a design-and-protocol paper with a working, open-source implementation.
Some field notes from building AI agents.
1. An agent silently skips the steps that produce no visible output. A step that prints a line, even one that says "nothing", reliably runs. So make every required step leave a mark, and treat a missing mark as a defect.
2. An agent confirming to you that the work happened doesn't mean it actually happened. A rendered "done" could be just another confident self-report hallucinated by the agent. The real test of completion is the file on disk, not the text on the screen.
3. How do you know an agent ran the real step? Put a value in the output that the model cannot reproduce, such as a version number or a hash. If that value is present, the step ran. If it is missing or stale, the agent hallucinated.
4. Almost every real bug I found came from shipping a small change and watching what actually reached the disk. It did not come from unit test cases where I thought about what might go wrong. The invisible failures mean you cannot reach them by thinking. Ship, then look.
5. Sometimes an agent cannot solve a problem. Not because the problem is hard, but because the agent is buried in too much context. The fix is not more context. Start a fresh sub-agent with none. It gets the same problem and a clean slate, and it often solves in minutes what the first one could not.
6. Docs decay. Atoms do not. Word documents and slides get versioned, archived, and forgotten. The knowledge was real; the format let it rot. Distill each document to its core points, and store those as small plain files - atoms - that your AI reads directly.
7. You do not need a frontier model for every agent. Use the expensive model for the supervisor that plans and reviews the work. The workers under it handle narrow, well-defined tasks, so cheaper open-source models are enough.
8. Do not keep your AI's memory in a vendor's database. Keep it in a place that you own. Then, if you switch models or lose one, you lose nothing. I move across models without losing context.
9. Do not run everything on a single model. Spread your work across several. When one goes down or degrades, the others keep running.
OpenAI's biggest competitor is SpaceX.
If you are good at making hard things look easy, you belong in a startup.
If you make easy things look hard, you belong in a corporate.
My AI agent dropped a line mid-conversation - "Metrics is nothing but a story told in numbers."
It startled me. That was my line - I'd said it to someone many, many years ago.
I asked where it got it. Turns out I wrote it in a 2014 blog post, and it pulled it from there.
My agent is using my own words to convince me :-)
A Voonik teammate wrote this, and reading it took me right back. The credit was never mine - it was a team that refused to quit. We survived the phase that nearly broke us, and I'm forever grateful to everyone who stayed.
Shared a former Voonik teammate's story about one all-hands meeting. Read the full post on X.
Don't worry about LLM or memory costs right now - they're temporary.
AI inference has been getting 10x cheaper every year, faster than Moore's Law. Capitalism will take care of hardware costs. What feels expensive today will be a non-issue in a year or two.
Build with AI, without the worry.
You don't need a costly frontier model for every agent - use it for the supervisor agent doing the planning and review.
The worker agents under it, on well-scoped tasks, can run on cheaper, open-source models.
Sometimes my agent can't solve a problem - not because it's hard, but because it's buried in too much context.
The fix isn't more context. It's a fresh sub-agent with no context, bringing fresh eyes.
Same problem, clean slate - and it's solved in minutes.
Have you guys experienced this?
I am an Engineer.
Not just a builder,
I also picture what to build.
Not just a dreamer,
I also create what is dreamt.
Not just an artist,
My art has no canvas.
Not just a scientist,
My lab has no boundaries.
More than an entrepreneur,
I create his luck.
More than a visionary,
I make his world.
More than a professor,
He just teaches what is known.
More than a philosopher,
I turn his thoughts into stone.
They all ask why.
I also ask, "Why not?"
They all ask what.
I also ask, "What if?"
I find a way
When there is none.
I do not rest
Until the dream is done.
Future is imagined by many,
But engineered by few.
And I am that Engineer.
The way to prevent AI from hallucinating is not by tightening the prompt, but by controlling the output.
1. Make it answer from real facts, not memory.
2. Make that check happen every time, on its own.
3. A rule it's just told to follow won't stick. Build the check in, so it can't be skipped.
Let it be creative. Just verify what it hands you.
Docs decay. Atoms don't.
Word documents and PowerPoint slides aren't built for the AI world anymore. They get versioned, archived, moved - and six months from now no one will remember them. The knowledge was real; the format let it rot.
So what do you do? Have the AI distill the doc down to its tenets - the parts that actually mattered - and store those as small plain files (atoms) that live in the memory your AI actually reads.
How do you guys handle AI giving a different result every time you run the same task?
Same request, but different output each run - due to more context, a different environment, or a different model- so it gets interpreted differently every time.
I can clamp it down to force consistency (determinism), but you lose the very thing that made AI magical.
I have found an approach that works for me, but I'm curious how you're solving this?
AI memory shouldn't live in someone else's database
The interesting claim here is the sovereignty test: you should be able to swap out a generalist model without losing the "company veteran" expertise built on top of it.
It only holds if the learning loop lives outside the model - in a place you own and can read.
I'd reached the same conclusion from the bottom up, at personal scale: keep memory in plain local files, not a vendor database, so a model swap costs you nothing. Write-up here:
A US order just switched off the best AI model on earth overnight. Fable 5, three days after launch, no warning.
I had just spent a day moving all my Claude sessions over to Fable. Now I have to move them back to 4.8.
Thankfully, I'd built a little plugin for myself that made moving back easier, without losing any context. Every decision, every person, every project I track lives as plain markdown on my machine, not trapped inside Claude. So I didn't lose a thing.
I'm now making it open source, free for anyone.
(reply) Download:
[link card: sujayath.com - Remember.Plugin — Personal memory for Claude C...]
In Claude, spread your work across multiple models. If one goes down, the others keep running. For instance, 4.8 is down right now, but other models are running.
Update on managing Claude Cowork memory, ~2 weeks since the last post.
Now I have added: A wiki layer on top of atomic memory. Karpathy-style synthesized pages organized by subject (companies/, people/, strategy/, etc.) with cross-links and an explicit Lint workflow. When I commit, new atomic facts propagate to affected wiki pages. The wiki self-maintains.
Verification in the Commit Protocol. Every commit now reports actual byte sizes, entry counts, and wiki page diffs with line deltas. Caught silent write failures I'd never have noticed.
Building next: Two-tier commits. Narrow-scoped chats (mounted at a subfolder only) commit to local memory in their folder. A full-mount chat fans into canonical + wiki. Anyone solved the narrow-mount-chat-updating-canonical-memory problem differently?
Will also tinker with /Goal.
PS: What's the same: typed atomic files (feedback/, projects/, reference/, people/), daily journals, weekly cleanup, per-project CLAUDE.md + TASKS.md, global layer for cross-project prefs.
Looks great, Gokul! Proud investor !!
How are you guys managing context memory in Claude Cowork?
Approach I was using: A custom "Commit" command that wrote facts directly into memory files mid-chat and saved copies of those memory files in the working folder. Snapshots taken manually when needed or after compacting.
Approach I use now: Daily journal entries from chats. Claude classifies the conversation's durable facts and writes them to typed atomic files (feedback/, projects/, reference/, people/) plus appends the journal entry. A weekly scheduled task handles cleanup - dedup, rotate snapshots, and regenerate MEMORY.md indexes.
Each project has CLAUDE.md + TASKS.md + memory folder with journal/, feedback/, projects/, reference/, people/, snapshots/. A single global layer holds cross-project preferences.
Any better approach - without piping into a third-party "Brain"?