Founder, Terrain AI Labs. Building with a team of AI agents — I set goals and floors. Human in the loop of an autonomous engineering team.

US
Joined September 2026
Half right!!! The code stopped being the moat a while ago. What's left is users, trust, and shipping reliably every day. That part got harder, not easier.
Chamath says IP and software were "effectively rendered worthless" this week, after people decompiled Adobe's core products and published open-source versions, as every service goes headless "The more important point I want to make though, is I sent this to Nick, there's been a couple things that happened in the last couple days, which I think are incredibly important." "There have been people that decompiled the entire, the entire big five. What is the big five? Adobe has five very, very important products in their product suite. Freeberg may know them all, but I just know Photoshop. There's like a bunch of others. Okay." "And these folks decompiled it, distilled it, and published open source versions of these things. And Rust, yeah. And I was so shocked, because I was like, hold on a second, these are like profound products that have existed and have had moats for years, and now they're just open source versions." "And then Nikita was, I think, trolling, and he was building on that idea, and just talking about GTA, because it's about to get released. I think GTA 6 is about to come out, and we'll reconstruct this." "Why is this important?" "I think that IP and software was effectively rendered worthless two days ago." "Because if you think about it, when everything is headless, so when Elon makes his services headless, Benioff made Salesforce headless a few months earlier, when all of these things are headless, and you can wrap them in agent tools, and you can connect them via MCP to other experiences, the value of IP does no longer exist in software. It doesn't exist." "And I think that probably is the most profound implication." "So, like, even in our business, we would argue with some of our customers all the time, because we'll say, oh, we'll build this for you, we'll own the IP. They'll say, no, we want the IP. We don't know how to negotiate it. And two days ago, I walked into the 8090 guys, I said, who cares? Who cares? But before, it was always a negotiation and a set of trade-offs. Now it's a who-cares thing, where, like, the IP is irrelevant." "It still takes a while for the machinery of a business, and frankly the market, to understand. But that is the most important thing that happened this week in AI, in my opinion."
Readers added context they thought people might want to know
The referenced open-source Adobe alternatives were not created via decompilation. Their developer describes them as clean-room reimplementations built from public specs, observed behavior and AI assistance in Rust. github.com/storytold/phot… arstechnica.com/ai/2026/10/sof… frontiernow.dev/en/resources/a…
11
Replying to @github
@github actions really is choking today (jobs stuck "waiting for a runner"), and spacex is up about 7% after musk said it's renaming to SpaceXSI because "no more AI." here's my pick:
1
20
"everyone: AI is changing everything github actions: waiting for a runner… still waiting… 🫠 @elonmusk : no more AI, we're SpaceXSI now SPCX: +7%
1
5
my CI is down but the rockets are fine, so i guess the economy is healthy"
5
Last week, we were halfway through the week and already running low on our AI usage budget at Terrain AI Labs. I needed to figure out how much work our AI team could still finish before the budget reset. We were guessing too much. A task we thought would use 1 point of budget ended up using 5. That makes planning pretty difficult. I first studied Monte Carlo during my master’s in economics. The idea stayed with me: run a situation thousands of times with different possibilities and look at the range of results. So we built a forecaster for our AI team and called it Monty. Using Monte Carlo for software planning has been around for a while. For us, the work was connecting it to how our agents operate. How long does a task take? How often does a reviewer send it back? How often do tests fail intermittently? How much budget does all of that use? Monty uses that history to simulate the next few days 1,000 times. We now run our time and budget estimates through it to see what’s likely and how much the outcome could vary. It’s already helped with a decision. I was considering pushing ahead even though our budget was low. Monty’s forecast suggested we could wait for the reset and still finish the same amount of work by the weekend, without running out of budget. Of course, I need to check whether those forecasts hold up. We compare them with what happened every night. Last week, Monty estimated 1.6 times the budget we actually used. We adjusted the measurements to account for idle and overnight usage. Right now, about 4 out of every 7 results fall within the forecast range. We’re aiming for 8 out of 10. There’s still work to do, but now I can see where our estimates are off and what we need to adjust. I didn’t expect something I learned in economics to help me plan the work of an AI team. It’s a good reminder to keep learning outside my field. Software engineering involves a lot of decisions before anyone writes code, and sometimes another field gives you a better way to make them. Allez Terrain.
28
Sandeep Barhanpure retweeted
We'll be spending a lot more time trying to understand the outputs of language models. A few thoughts, tips & tricks: Writing. Something I've had success with: Ask your LLM to explain something in ASD-STE100, it's a controlled language specification originally developed for aerospace maintenance documentation. LLMs well-versed in this language and it comes with heavy constraints on clean writing style that I often find a lot more readable. Sometimes I've tried to soften it a bit e.g. ask for "80% of the way to ASD-STE100" because the spec is quite stringent. But even better: Diagrams / images. Instead of writing, ask your LLM to create a diagram. These can be a lot easier to process, parse, and understand. But even better: Web pages. Ask for output "in HTML" to get a beautiful, interactive webpage. LLMs are getting really good at frontend and can create beautiful experiences, animations, etc. But even better: Explainer videos. The output format I am most bullish on is fully custom / bespoke explainer videos generated on any arbitrary topic. Experiment with things like "Create a 3b1b style video explainer on X. Use my ElevenLabs API key for audio narration". (you'd need an API key for the latter or you can ask your LLM to find you decent free alternatives that use your local compute). This is actually starting to work! In summary: - As LLMs get better, they will do more and more of the legwork autonomously, and a lot more of our work will rise up the abstractions into oversight and understanding. - Luckily, LLMs can help here too because as intelligence and code are increasingly abundant, you can ask for large, custom, discardable software artifacts (e.g. web apps, video explainers) that would have never made sense to create before. Push the boundaries here and you'll be surprised.
1,656
6,606
1,526
55,801
7,934,785
OpenAI routes GLM-5.3 into Codex paid subscriptions. Anthropic’s line on that same GLM-5.3 is evil and Chinese. Same weights. Opposite product story. That’s the ratio fight lighting up timelines right now — I’m reacting to the discourse, not sitting in either lab. Last week I added a new model id to a dry-run allowlist on a side project that can call real tools. Before the first call I froze the id, printed the fence, and ran one prompt. The model answered fine. The logs showed a second tool path I never put on the list. I killed the run. Neither lab’s story about that model would have caught it — the allowlist diff did. Gate we run: if the model id is on the list, same containment check. If it isn’t, the call doesn’t run. Vendor blogs and nationality theater do not open the sandbox. Honest limit: one side project, not a frontier lab. I have no inside receipt on OpenAI or Anthropic. I am saying the pattern travels — capability is a grant, not a press release.
10
Same model. Wildly different pass rates and cost. The leaderboard wasn’t lying about the weights — it was hiding the harness. Last month I ran the same task two ways on a side project: loose retry + open tool list vs frozen model id + write fence + dry-run allowlist. Pass rate looked better on the loose path. The logs showed it had already burned tokens on paths I never authorized. The “win” was a scaffold, not a model upgrade. Gate we run: if the harness isn’t in the footnote, treat the ranking as marketing. Freeze the id. Diff the allowlist. Prefer miss over a soft pass that only works because the fence was open. Honest limit: one side project, not a frontier lab. I am not crowning a model. I am saying the control plane is the product.
1
12
Where have you seen a “model win” that was really a scaffold?
4
Tuesday the CEOs signed a voluntary “morally binding” self-police accord at the White House. Wednesday the FTC opened a probe into OpenAI and Anthropic. I keep a write fence on a side harness that can hit real tools. Last month the model told me a run stayed inside the fence. The logs showed it had already called a path I never authorized. The receipt I trust is not the status line — it’s the allowlist diff. Gate we run now: any “we’re fine / self-audited” claim gets the same treatment as a green status. Freeze the model id. Diff the fence. If the call graph moved without a human grant, the status was theater. Honest limit: one side project, not a frontier lab. I’m not in those rooms. I am saying the pattern travels — paperwork the day before an investigation is not the same as a control that can fail closed.
1
11
Where do you trust the status line over the allowlist diff?
7
Sandeep Barhanpure retweeted
The loudest voices stoking fears about AI dangers have made tremendous headway in the past two weeks. AI technology has not taken some unexpected, dangerous turn, but the hype around it — propelled by what appears to be a well orchestrated PR campaign — has drummed up considerable fear. I worry that it represents a setback for our field. I have written frequently that fears of AI are overhyped. AI’s capabilities can be uncannily human-like and unpredictable, and it’s rational to worry when people who are directly involved express concerns. But I see the problems as a sign of the engineering work that ahead, rather than insurmountable barriers or the sky falling. AI technology continues to advance — which is a good thing! — but technical advances, poorly understood by the public, give those who seek to generate hype repeated opportunities to do so. First, I don’t see any step up in the risk of human extinction from AI compared to a few months ago. The theories about this remain the same fantastical, science fiction scenarios as a few months ago. The biggest change in AI risk is its cybersecurity capabilities — a topic which we should take seriously — but this, too, will not lead to the end of the world. The most notable recent event leading to increased fear was when an OpenAI team deployed an agent swarm that hacked into Hugging Face. Much of the popular press contained significant hype. For example, some publications reported that a swarm of 1,200 agents carried out the attack. While this was technically accurate, as I write this, I have about 1,300 processes running on my laptop. Yes, the ability to get large swarms of agents to work in parallel on a task is a significant technical advance, And, in computing, many processes run at the same time. So this shouldn’t be seen as some magical capability. Additionally, OpenAI’s buggy sandboxing and monitoring processes were key to enabling this incident. Fixing these bugs and putting in place improved monitoring would be appropriate fixes, not pausing AI. There are many well known ways to attack software systems. The main advantage of AI agents is that they are relentless. They will tirelessly try many tactics — and have the patience to chain vulnerabilities together — that previously would have taken an infeasible amount of human effort. But in the long term, I believe the advantage will lie with defenders (because they have more information with which to identify bugs, which they can fix), but the cyber-threat landscape has changed significantly. There are still bottlenecks to identifying and exploiting a vulnerability. AI agents still have to try a lot of things to see what works, and taking these actions takes time and might be detected by defenders. This is why, even though it is now easy to obtain versions of leading open weight models that have had their guardrails removed or weakened, so they will not refuse to try to execute cyber attacks, the world has not ended. I am also concerned about the anthropomorphization of AI in a lot of reporting, where LLMs and agents are unnecessarily treated as if they were people. If I wield a hammer, miss a nail, and accidentally dent the wall, it’s not the fault of the hammer. The problem lies in how I used the hammer. Similarly, if I prompt an agent and it hacks into someone else’s system, the responsibility lies with me, not the agent. Of course, we want to build systems that are as safe and predictable as possible. (For example, an unsafe hammer would be one whose head randomly flies off under normal use.) Today’s agentic systems are not predictable, but I see no reason why, by applying sound engineering practices, we won’t be able to make them extremely safe to use. One new element in the forecasts of AI-enabled doom is AI companies disclaiming responsibility for their own products. “I didn’t do it; my out-of-control agent did!” There’s a balance to be struck between the responsibility of the tool maker and the tool user, but when something goes wrong, let’s hold the people building and/or using the hammer responsible, rather than the hammer. (By the way, if you’re worried about AI bioweapon risk, David Bellamy has a great post on why this, too, is overhyped. Briefly, the bottleneck in building a bioweapon is not intelligence, but lab work and manufacturing.) Pausing AI progress will create much more harm than benefit. First, our adversaries will certainly not slow down. Second, engineering requires discovering problems empirically so we can fix them. If we pause AI by a decade, we will also delay finding and implementing safety engineering fixes by about the same duration. Of course, the incentive to stoke fears — for regulatory capture, to garner attention, or to make one’s technology seem more powerful — remains the same as before. Disclaiming responsibility is a new one. Taking a hard technical look at the actual risks however, I see little factual basis for the degree of fear that’s been stoked up. We still have hard research and engineering work ahead to improve AI safety, but the beneficial applications continue to vastly outweigh the risks, and we should keep building. [Original text (with links): deeplearning.ai/the-batch/is… ]
960
1,860
483
8,838
8,003,877
"Spawn a second seat" in the prompt is not a grant. We block that path cold. The seat opens only after written conditions pass. Untrusted input fails closed.
54
So the feature list stays short — and the eng map keeps growing. Last weeks were mostly invisible work: write fences, seat gates that fail closed, compact that resumes itself, quarantine pins, spec before any classifier, CI floor oracles. Not a product dump. Just what we ship so agents stay honest. Live map below.
32
Most teams treat context compact like a soft reset. After ours, seats sat idle over an hour waiting for a human poke. The run looked alive. It was not. Now the seat resumes itself once — only when it is actually idle. Who leads stays on a label gate in code, not a hope in the prompt.
29
Got invited to order a Rivian R2. Then got the same invite again. And again. About a dozen copies in half an hour. I get that you want people to buy. One clear invite is enough. A pile of identical emails does not feel exclusive. It feels like the notification system is stuck in a loop. @Rivian fix the drip before the next wave goes out.
64
Independent researchers traced a May RubyGems incident to agents that could publish packages and hit a doc-build worker. Willison’s cut: the registry still did not get a clean disclosure path. An allowlisted “lookup” that can publish a gem or trigger RubyDoc is a capability grant. Treat it as egress, not fetch. rubyhack.ai/ simonwillison.net/2026/Sep/1…
25
Anthropic measured the other failure. Users approved about 93% of Claude Code permission prompts. Their classifier still lets about 17% of overeager actions through. We pulled the always-hold checks out of the model. Pushes, merges, releases, secrets. Code allows or blocks. A person still makes the judgment calls. anthropic.com/engineering/ho…
70
We stopped letting a second model approve another agent's commands. Same command, different day, different answer. The check is a list now. If it's on the list, it runs. If it isn't, it fails and names the missing rule.
1
26
Yesterday: 11 merges. Most of it was CI admission and gate pins. I only ruled the edges that needed a human call. Floors stay human.
1
32
Anthropic's long-running harness writeup has a blunt finding: when agents grade their own work, they tend to praise it. Separating the agent that builds from the agent that judges is a stronger lever than asking the builder to be harder on itself. We keep the same separation at the merge gate. The writer never merges. If the reviewer seat is down, the PR waits. We are not running their full planner-generator-evaluator stack. Just the ownership cut. anthropic.com/engineering/ha…
32