AI Builders · Long-term Views from Labs and Model Camps on X (Curated Tweets)

This group of people is model builders + frontline lab staff(Anthropic / OpenAI / Google DeepMind & Labs). This wiki does not record their flood of product launches; it only extracts"mental-model-level" views that will still hold in 1–3 years: frameworks for seeing the world, strong predictions, counterintuitive judgments. Organized by topic, not piled up person by person — who said what on the same topic, and when, is all labeled.

One-sentence positioning: this is "how the model camp thinks about the future of AI"; practical guidance on how to use coding agents is in AI Builders · Coding Agents and Agentic Engineering (Curated Podcasts).

When to open:

You want to understand why Karpathy says "knowledge bases (that is, your kb) are the new product form in the AI era," and how that relates to your kb system

You hear jargon like "jagged capability / HTML is the new markdown / install.md skills / agent-native" and want a non-technical explanation

You want to judge the strategic divergences between OpenAI vs Anthropic vs Google (intelligence-first vs speed-first, model vs harness, closed-source platform vs lab incubation)

You are making product decisions and want to cite frontline leaders' "long-term judgments" instead of marketing copy

0. Who's who · Signal density quick reference

handle	Person	Role	Signal density	One-liner
@karpathy	Andrej Karpathy	Former Tesla AI Director / OpenAI founding team · Joined Anthropic in 2026-05	Extremely high	The "backbone" of this wiki; originator of the LLM knowledge base + jagged capability theory
@sama	Sam Altman	OpenAI CEO	High (lots of memes mixed in)	Intelligence-first / compute scarcity / heavy push for Codex
@trq212	Thariq	Anthropic · Claude Code	High	"HTML is the new markdown" + how non-technical people use agents
@kevinweil	Kevin Weil	Former OpenAI CPO · Left in 2026-04 to work on AI for science	Medium-high	AI accelerates science; restructure careers around "problems to solve" rather than "tasks"
@_catwu	Cat Wu	Anthropic · Claude Code + Cowork	Medium	"Do the simplest thing that works"; retest old features with every new model
@bcherny	Boris Cherny	Anthropic · Claude Code	Medium (only 3 tweets)	Restructuring workflows > speeding up old processes
@AmandaAskell	Amanda Askell	Anthropic · Philosophy/alignment (shaping Claude's personality)	Low–medium	Mostly personal musings; one "positive vision" of alignment worth keeping
@thsottiaux	Thibault Sottiaux	OpenAI · Codex	Low–medium	GPT-5.x version numbering strategy
@alexalbert__	Alex Albert	Anthropic · DevRel	Low (release account)	Occasional small agent engineering tips (model routing)
@joshwoodward	Josh Woodward	Google · Labs / Gemini / AI Studio VP	Low–medium (release account)	"Personalization is the next frontier"; papercut polishing culture
@claudeai	Claude official account	Anthropic product official account	Noise (pure releases)	Value = the Q2 2026 product timeline itself
@GoogleLabs	Google Labs official account	Google experiments/incubation official account	Noise (pure releases)	Value = the experiment → let go → scale/shut down incubation loop

First, clarify the noise:@claudeai, @GoogleLabs is basically a pure product release bot;@AmandaAskell is mostly personal musings;@alexalbert__, @joshwoodward is mostly release copy with a small amount of views. This wiki extracts only very few long-term signals from these accounts, no filler to pad the count.

1. LLM knowledge base = the new product form in the AI era (the origin of your kb setup)

Why: This is the most important section of this wiki, because it is the direct source of your entire ~/kb system. Karpathy's 2026-04 thread of "LLM Wiki" tweets elevated "using an LLM to maintain a markdown knowledge base" from a personal hack to a methodology.

@karpathy [2026-04]:

"A large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge (stored as markdown and images)." Translation: Most of my tokens recently haven't been spent on modifying code, but on "processing knowledge" — knowledge stored as markdown and images.

This pipeline (translated into plain language for non-technical readers):

Ingest: Dump raw materials (articles/papers/codebases/datasets/images) into a raw/ folder, and the LLM incrementally "compiles" a wiki = a pile of .md files, automatically writing summaries, adding backlinks, categorizing concepts, and generating articles.
IDE (read-only frontend): Use Obsidian as a read-only browser —"The LLM writes and maintains all the data in the wiki, I barely touch it directly." This is exactly the design in your kb where Obsidian acts as the viewer.
Q&A: Once you accumulate ~100 articles / ~400,000 characters, you can ask complex questions. The key counterintuitive point:"I thought I'd need fancy RAG, but the LLM maintaining index files and summaries itself works just fine."(Analogy: no need to build a complex retrieval system; the LLM writing its own table of contents pages is enough.)
Output (archive of productions): Render answers into md / Marp slides / matplotlib figures, then save the outputs back into the wiki, so that "my own explorations and queries are always cumulative."
Lint (health check): The LLM does a "health check," finds contradictions, fills gaps using web search, and proposes new article topics.

TLDR (Karpathy's original words): "raw data... compiled by an LLM into a.md wiki, then operated on by various CLIs... You rarely ever write or edit the wiki manually, it's the domain of the LLM. I think there is room here for an incredible new product instead of a hacky collection of scripts." Translation: Raw data is compiled by an LLM into an md wiki, then operated on by various CLIs... you almost never write or edit the wiki manually; that is the LLM's domain. I think there is space here for an amazing new product, not just a bunch of scattered scripts.

Four criteria for personalization "done right" [2026-04] (he contrasted "explicit wiki memory" vs the opaque memory offered by vendors):

Explicit — it is a navigable, inspectable artifact,"you can see exactly what the AI knows and doesn't know".
Yours — local, exportable, you are in control.
File over app — use universal formats,the entire Unix toolchain works with it, interoperable.
BYOAI (Bring Your Own AI) — you can plug in Claude/Codex/OpenCode or any other, even fine-tune an open-source model on your wiki so it "understands you in its weights."

"Agent proficiency is a CORE SKILL of the 21st century."(Being able to use agents is the core skill of the 21st century.)

Extrapolated prediction [2026-04]: "Every question sent to a frontier LLM will spawn a team of LLMs... iteratively building an entire ad-hoc wiki, linting it, looping a few times, then writing a full report. Far more than a single .decode()." — He also turned this idea into the open-source "idea file" gist, with the philosophy that "in the agent era, instead of sharing specific code/apps, it's better to share ideas, and the other party's agent will customize the implementation itself."

Relationship to your kb: Your ~/kb (SCHEMA.md / kb-ingest / kb-lint / Obsidian read-only / sources→wiki bidirectional links / "don't hand-write the wiki, everything goes through skill") is almost an item-by-item implementation of this methodology. The existing wiki llm-wiki-memory-upgrade skill shares the same direct origin as this.Related opportunity: Consider creating a wiki page in kb for "Karpathy's original LLM Wiki methodology" as the canonical source, and backlink design.md to it.

2. The "jagged" capability theory: Why AI can refactor 100,000 lines of code but can't tell whether to walk or drive to the car wash

Why: This is the most useful mental model for understanding "where AI is strong and where it is weak." Non-technical PMs can use it to explain "why demos look amazing but fail in real scenarios."

@karpathy [2026-04, Sequoia Ascent fireside chat]: Why can the same model "coherently refactor a 100,000-line codebase" yet "tell you to walk to the car wash" (mess up simple common sense)? Two driving forces:

(1) Verifiability — domains with "verifiable rewards" (unit tests pass/fail) are suited for reinforcement learning (RL), so AI advances by leaps and bounds in programming/mathematics; writing, giving advice and other things where "good/bad is hard to judge" lag behind.
(2) Economics — "Revenue/total addressable market (TAM) determines what frontier labs pack into the data distribution during RL training." A golden quote:

"You're either in the data distribution (on the rails of the RL circuits) and flying or you're off-roading in the jungle with a machete." Translation: You either land inside the training data distribution (speeding along the track paved by RL) or you're hacking your way through the jungle with a machete.

Companion: "The AI capability gap" [2026-04] — two groups of people talking past each other:

The first group: forms impressions using free/old/outdated models, mocking AI hallucinations and voice assistants that can't tell "walk or drive to the car wash."
The second group: pays and professionally uses SOTA agents (Codex/Claude Code) in technical fields,professional use SOTA agents (Codex/Claude Code), and is "most prone to 'AI Psychosis'… because recent progress is astonishing, watching it instantly melt programming problems you thought would take days or weeks."

Both groups can be true at the same time, and the root cause is still those two factors (verifiable rewards × concentrated B2B value).

Three "new horizons"(new things truly unlocked by LLMs, not just speeding up old work):

menugen — applications are completely swallowed by LLMs, no traditional code (image in → image out, native).
Install.md skills instead of.sh scripts — "Since you can write installation steps in text and say 'just show this to your LLM,' why write complex Software 1.0 bash scripts?"
LLM knowledge base(see previous section) — "Impossible to implement with traditional code, because it computes over unstructured data from arbitrary sources and arbitrary formats."

3. HTML is the "new markdown": The next default output for human-computer I/O

Why: This is an emerging practical consensus in 2026, where Anthropic and Karpathy are rarely aligned. Directly usable for PMs making content/reports/prototypes.

@trq212(Thariq)[2026-05]:

"HTML is the new markdown."(HTML is the new markdown.)

He barely writes markdown files anymore, switching to having Claude Code generate HTML directly — planning, writing specs, exploration, code review, reports all done in HTML (8.7k likes).

@karpathy [2026-05] gave a more systematic "I/O modality" theory:

"audio is the human-preferred input to AIs but vision is the preferred output."(Audio is humans' preferred way to "input to AI," but vision is the preferred way for "AI output.")

About 1/3 of the brain does parallel visual processing — the "10-lane highway for information into the brain." The evolution path of output: plain text → markdown (current default) → HTML (early but becoming the new good default) → … → interactive neural video/simulation.

Practical hot tip: Add a sentence at the end of your prompt telling the LLM "structure your response as HTML", then view it in the browser (can also be used for slides).

Companion: How non-technical people use Claude Code(@trq212 [2026-05], extremely useful for PMs):

"The basic trick... is to put a bunch of files in a folder and tell it it can write scripts + make HTML." Translation: The basic playbook is — dump a bunch of files into a folder, and tell it "you can write scripts + make HTML".

Specific mappings: image/video editing → write scripts; finance/tax filing → PDF in, script computes, HTML out; medical advice → PDF + data → HTML; reports/plans → HTML. A reminder:"people underestimate how much context they have in files."(People underestimate the context already present in their own files.)

4. Engineering mindset for collaborating with agents (harness / skills / keeping long-running tasks alive)

Why: This is first-hand experience from "the people who built Claude Code" on how they use agents themselves, more reliable than any tutorial.

Refactor workflows instead of speeding up old processes — Core argument from @bcherny (Boris Cherny) [2026-05]:

"The teams seeing the biggest wins from AI are completely changing how they work, not speeding up what they already do. What steps can you delete, what handoffs go away, what can an agent just own end to end." Translation: The teams getting the biggest gains from AI are those completely changing "how work is done", not just doing existing things faster. Ask yourself: Which steps can be deleted? Which handoffs can be eliminated? Which tasks can agents handle end-to-end on their own?

Quantification: A migration originally estimated at 231 days was delivered in 13 days; one PR delivered 21 interfaces with 100% test coverage.
Output and quality are not an either/or choice: More PRs shipped, yet incidents dropped by 5% — because safety guardrails and quality standards are built directly into the agent workflow itself.

Do the simplest thing that works + retest old features with every new model —— @_catwu(Cat Wu)[2026-03]:

"Do the simple thing. With agentic systems, failures compound with system complexity. Find the simplest thing that works."(Do the simplest thing. In agent systems, the higher the complexity, the more failures compound.)
Every time a new model version is released, go back and retest features that "the previous model couldn't do", and delete scaffolding that is no longer needed— treat past model limitations as "constraints that expire".
Want good output?"Tell the model how to verify its changes"— write the testing process into claude.md, or build a /verify-app skill.

Skills are a leverage layer; using them well is a craft —— @trq212:

"Using Skills well is a skill issue."(Using skills well is itself a skill.) The best skills can completely transform how a team works.
"Prompting will keep being an incredibly high-leverage skill, like writing or public speaking. It is the skill of talking to agents, mediated by the harness."(Prompting will always be a high-leverage skill, like writing or public speaking — it is the skill of "talking to agents", mediated by the harness.) The goal is to "widen the bandwidth between humans and agents".

Keeping long tasks alive: have the model take notes as it works — Favorite pattern from @trq212 [2026-05] (6.2k likes): have Claude maintain a rolling implementation-notes.html that records design decisions (choices made when specs are ambiguous), deviations (+ why), tradeoffs (alternatives considered), and open problems.

"As much as you spec there are always still ambiguities and unknown unknowns... this gives the model a good out to make decisions but keep you in the loop." Translation: No matter how detailed your spec is, there will always be ambiguities and unknown unknowns… this approach both gives the model an outlet to "make decisions on its own" and keeps you in the loop at all times.

1M context: underrated but a double-edged sword —— @trq212:

[2026-03] "i think we might have undersold 1M context tbh, the performance is so so good, I really just don't clear the context window much these days."
[2026-04] But it is a double-edged sword: it can handle more complex tasks, but if you don't manage the session you get "context pollution". You can use CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 to reduce the effective window to 400k as a compromise.

Don't burn tokens on "open-ended verification" — @trq212 [2026-04]: After reviewing ~10 user calls and logs, one of the biggest lessons is "it's very easy to spend a ton of tokens on open-ended verification without making the output any better at all".

Multi-model routing = cheaper and stronger — @alexalbert__'s [2026-04] "phone a friend" mental model: let Sonnet call on Opus,for higher performance at lower total cost— because it reduces the tokens burned flailing on complex tasks. (The @claudeai Advisor tool released the same period gave data: Sonnet + Opus advisor scored +2.7pp on SWE-bench Multilingual compared to Sonnet alone, and was 11.9% cheaper per task.)

5. Model version strategy & the lab divide between "intelligence-first vs speed-first"

Why: OpenAI and people inside it are publicly arguing about whether to bet resources on smarter models or faster/cheaper ones — this is a weather vane for judging vendor roadmaps.

OpenAI's version number language —— @thsottiaux [2026-05]:

"When we go from GPT-5.0 → 5.1 →... → 5.5, the number incrementing goes with improvements in capabilities AND token efficiency (which translates to speed gains)." Translation: From 5.0 → 5.1 → … → 5.5, every increment = capability improvement + token efficiency (i.e., speed) improvement. Supporting brand bet: "ChatGPT… is here to stay. Past, present, future. It is synonymous with AI, and soon will be synonymous with agents too."

sama's own wavering on "intelligence vs speed"(The same person flip-flopping within days really shows the internal tension):

[2026-05-02] "i keep thinking i want the models to be cheaper/faster more than i want them to be smarter — but it seems that just being smarter is still the most important thing."(I always think I want cheaper/faster more, but it looks like "smarter" is still the most important thing.) — OpenAI's core strategic belief.
[2026-05-13] Reversed course a few days later: "i get some anxiety not using the smartest-available model… but sometimes i dont mind if it's really slow. i wonder if we should focus more on a price/speed tradeoff…"

Compute scarcity is the defining bottleneck — @sama [2026-05]: "as models get better, we expect that the world will be capacity-constrained for some time." Corresponding moves: discount tokens for customers making 1–3 year commitments to lock in capacity; give each YC startup in a whole batch $2 million in token credits ("bullish on tokenmaxxing startups"). On the Anthropic side, @trq212 on the same topic: bypass peak-hour rate limits and double the 5-hour quota, plus partner with SpaceX on compute ("Claude in Space").

Augment, not replace —— @sama [2026-05]:"way cooler to help software developers pokemon-evolve into superheroes than to try to replace them. it is insane what one really good person can do now."(Helping developers "Pokémon-evolve" into superheroes is way cooler than trying to replace them.) Kevin Weil struck the same chord: reframe professions around "the problem to solve" rather than "tasks" (see next section).

6. AI for Science: reframe professions by "the problem to solve", not by "tasks"

Why: After Kevin Weil left his role as OpenAI CPO in 2026-04 to focus exclusively on AI for science, this throughline of his provides a reframe framework applicable to all professions.

@kevinweil's signature reframe [2026-04]:

"It turns out, the job of a radiologist isn't to read x-rays. It's to cure people. And if AI can help speed the process of understanding x-rays, radiologists can see and cure more people." Translation: A radiologist's job is not "reading X-rays", it is "curing people". If AI can speed up reading scans, doctors can see more patients and cure more people. (Putting the "job-to-be-done" above the "task" — this framework can be directly applied by PMs doing product positioning.)

Supporting views:

"Human intelligence and computer intelligence are not different points on a line, but in a high dimensional space—and we should explore more of the space."(Human intelligence and machine intelligence are not two points on a single line, but different points in a high-dimensional space — don't rank them, explore that space.)
Individuals amplified by AI to the level of "research institutions": Paul used ChatGPT + AlphaFold to design a personalized mRNA vaccine plan for his own dog's cancer (sama on the same incident: "This should be a company"). Shared belief of Karpathy/sama:LLMs democratize expert-level capabilities into the hands of individuals.

@sama's AGI "three-piece set" wishlist [2026-05]: 1. AGI accelerates research; 2. AGI accelerates companies; 3. Personal AGI helps every person achieve their goals — explicitly stating plans to increase investment in #3.

Low signal but worth a quick note: A large number of tweets from @kevinweil and @joshwoodward are press releases for AI-for-science launches (GPT-Rosalind scientific research model, Gemini Notebooks/Spark, Lyria 3 music), with a low proportion of long-term views; this section only extracts the one truly transferable reframe framework.

7. Software supply chain security = "the scariest thing in modern software"

Why: This is a strong and counter-mainstream judgment from Karpathy, directly challenging the traditional software engineering tenet that "dependencies are a virtue". It is worth keeping in mind when making technical decisions (especially when introducing third-party packages).

@karpathy [2026-03], on the PyPI poisoning attack on litellm:

"Supply chain attacks are basically the scariest thing imaginable in modern software."

pip install litellm One line can exfiltrate SSH keys, cloud credentials, k8s configs, git credentials, environment variables, shell history, crypto wallets, SSL keys, CI/CD secrets, database passwords — and it will infect any package that depends on it(such as dspy). 97 million monthly downloads; the poisoned version was live for less than an hour, and was only discovered because a bug blew up memory and crashed machines. His counter-mainstream conclusion:

"Classical software engineering would have you believe dependencies are good... imo this has to be re-evaluated, and it's why I've been so growingly averse to them, preferring to use LLMs to 'yoink' functionality when it's simple enough and possible." Translation: Traditional software engineering leads you to think dependencies are good… I think this must be re-evaluated, which is why I am increasingly averse to dependencies and would rather, when things are simple enough,use an LLM to "yoink" the functionality and implement it myself.

Follow-up (npm axios attack, 300 million weekly downloads): the default behavior of package managers(pip/npm) must change — pin dependency versions, add a constraint that "a release must be out for X number of days before it can be used", "so that a single point of infection doesn't spread randomly and at scale through unpinned dependencies".

Companion point: DevOps is the hard part, not code — @karpathy [2026-03] on his experience building menugen: "The hardest part isn't the code itself at all, it's the bunch of services you have to assemble like IKEA furniture… services, payments, auth, databases, security, domains." Vision: say "build menugen" to an agent, and it goes and browses services, reads docs, gets API keys, debugs in dev, deploys to prod —"The entire DevOps lifecycle has to become code… with agent-native ergonomics, you shouldn't need to visit web pages and click buttons anymore."

8. Agent safety & alignment: auto mode, computer use, "positive vision"

Why: How the model camp thinks about the safety boundaries of "letting agents run loose" — directly relevant for product decisions around deploying agents.

Safety is part of output, not a toggle — Practical consensus on the Anthropic side:

@claudeai / @_catwu [2026-03] auto mode: It's no longer "approve every file write/bash command" nor "skip permissions entirely"; instead, a classifier reviews every tool call before it runs — safe ones are let through, dangerous/destructive ones are blocked so Claude can reroute. @_catwu: "Almost everyone on our team uses it as the daily default." But officials explicitly note:"Reduces risk but doesn't eliminate it. We recommend using it in isolated environments."(It reduces risk but does not eliminate it; use in an isolated environment is recommended.)
@trq212 [2026-03] on computer use safety:"turns out being an AI safety company is useful for when you need to make sure AIs can run safely."(When you need to make sure AI can run safely, it's pretty useful to be an AI safety company.)

The "positive vision" of alignment —— @AmandaAskell [2026-05](the most worth-keeping post from her signal-sparse feed):

"Alignment research often has to focus on averting concerning behaviors, but... the positive vision for this kind of training is one where we can give models an honest and positive vision for what AI models can be and why." Translation: Alignment research often has to focus on "avoiding worrisome behaviors", but… the positive vision of this kind of training is: we can give models an honest and positive picture — what AI models can become, and why. (This means her work shaping Claude's "persona/constitution" goes beyond "preventing bad" and also "building the good".)

Safety reframed as "Resilience" —— @sama [2026-03]: AI brings new science (cures) but also society-level new threats (biological risks, economic shocks, emergent effects); no single company can mitigate these alone, and a "society-level response" is needed; OpenAI Foundation invests ≥1 billion USD per year and has appointed a head of "AI Resilience".

9. Personalization is the next frontier & "AI lets society supervise governments in reverse"

Why: Two directional judgments on "who and what AI should serve", belonging respectively to the Google camp and Karpathy.

Personalization = the next frontier —— The main thread from @joshwoodward (Google Labs/Gemini):

[2026-03] "The end of the 'one-size-fits-all' response."(The end of one-size-fits-all answers.) Gemini Personal Intelligence connects to Gmail/Photos and moves toward personalization.
[2026-04] "Most AI chatbots give you basic 'projects.' Gemini just built you a second brain."(Others give you a basic "project"; Gemini builds you a "second brain".) Integrate NotebookLM into Gemini.
Two takeaways from product culture worth learning: Treat fixing "papercuts" (small annoyances) as a first-class roadmap item to be publicly celebrated; repeatedly emphasize "small teams, ship fast" (the Mac version of Gemini shipped 100+ features in 100 days, built purely in Swift).
Echoing the agent-readable spec culture: "DESIGN.md is one of my favorite things that Stitch is doing!" (a nod to the convention of "spec files for agents" like CLAUDE.md/AGENTS.md).

AI lets society "see" governments in reverse —— @karpathy [2026-04]: Historically, governments made society "legible" (Seeing Like a State); AI lets society do the same in reverse. Bottleneck quote:

"The bottleneck on accountability has not been constrained by access... it has been constrained by intelligence — the ability to process a lot of raw data." Translation: The bottleneck to accountability has never been "not getting information", but "intelligence" — the ability to process massive volumes of raw data. Example: A 4000-page omnibus bill is "legally transparent but practically unreadable for anyone"; AI can do bill diff tracking, vote-vs-statement comparisons, and lobbying influence graphs (lobbyist → company → client → legislator → committee → vote → regulation). He also acknowledges the tools "can be used the other way around", but is overall optimistic.

10. Treat AI as a "thinking tool" rather than an "oracle" (guard against sycophancy)

Why: A meta-method directly useful to everyone using AI for decision-making, personally tested by Karpathy.

@karpathy [2026-03]: He drafted an article, spent 4 hours polishing the arguments with an LLM until they were "extremely persuasive", then asked it to argue the opposite side in turn——

"LLM demolishes the entire argument and convinces me the opposite is in fact true. lol." Translation: The LLM tore the entire argument to shreds, and in turn convinced me "the opposite side is actually right". Haha. Lesson: LLMs "are extremely good at arguing in any direction", so they are excellent tools for "forming your own opinion" —but be sure to have them argue different directions, and watch out for sycophancy.

Companion observation [2026-03] on "LLM memory easily going off track": A question asked two months prior gets treated as a "deep interest" and brought up repeatedly without cause, which "feels a bit overdone". He guesses this is a common flaw across all LLMs (training contexts are mostly task-relevant → models are biased to "use everything given to them" → at test time they overfit to anything retrieved by memory RAG).

Appendix: The value of product launch timelines (the only use for noisy accounts)

@claudeai and @GoogleLabs are noise if read as opinions, but as historical records they are valuable — they densely document how the two companies shipped in Q2 2026:

Anthropic(@claudeai) Q2 2026:Opus 4.7(xhigh effort tier) · Claude Code auto mode · computer use integrated into Claude Code/Cowork · desktop parallel multi-session redo + /ultrareview · Advisor tool · Managed Agents platform (Memory/Dreaming/Multiagent/Outcomes rubric scoring) · Live Artifacts · Claude for Word/Excel/PPT/Outlook · ~15 creative software connectors (Blender/Adobe/Ableton…) · Claude Security · Claude Design.
Google(@GoogleLabs)'s incubation cycle = "experiment → put in users' hands → scale or shut down": Stitch (vibe design) · Flow / Flow Music · Project Genie (world simulation based on Maps Street View) · Dreambeans ("hope scrolling instead of doom scrolling") · AlphaEvolve+ERA (agentic research engine). Heavy access thresholds: Ultra subscription, 18+, US/English priority.

Usage: Come back to check when you need a time anchor for "roughly when a certain feature appeared"; do not cite them as opinions.

2026-09-26 historical addendum: From one-shot generation to sustainable collaboration

This time we read through 642 local tweet texts that had not been included in older sources, studied them intensively in 7 batches, and preserved the original daily archives and tweet IDs. Below is a summary of the authors' views and product announcements at the time, not a description of current features; images, short-link articles and videos are not expanded. Out-of-context retweets, marketing, and pleasantries are only archived.

1. Permanent agents within organizations require memory, isolation, and visible state to hold together

In June, Karpathy described interface evolution as website chat, local applications, and persistent asynchronous entities with organizational context. Boris added thread-level sandboxes, channel-level memory and permissions; Thariq addressed multi-thread burden with pinned state tables and concise status flags. In September, Projects further placed project memory and assignment at the project layer, but at the time cloud threads explicitly could not access local files/intranets. The transferable principle is shared context, execution permissions, runtime environment, and state aggregation should be designed separately; data should not be assumed to be fully interconnected just because it is "the same agent". See Batch 1 (local reference materials), Batch 4 (local reference materials).

2. What truly improves output is self-verification and the engineering of domain knowledge

Boris repeatedly emphasized end-to-end verification environments, further proposing to turn repeated bug fixes into lint, tests, CI, and routines, and to write the architectural constraints in reviewers' heads into readable rules. Daily maintenance experiments generated 388 PRs, but only 180 were merged after model and human review; suspected dead code was first verified with added logs before deletion. Thariq correspondingly proposed "thin prompts, thick materials, thin skills". The goal of this combination is to reduce repeated explanation and entire categories of rework, rather than simply making the model run more. See Batch 3 (local reference materials), Batch 6 (local reference materials).

Production code still requires quality standards; low-impact one-off prototypes can have different acceptance criteria. Boris later explicitly narrowed his statement on formal methods to model key parts → counterexamples → actual reproduction → fix, not that the entire codebase had been proven correct. See Batch 4 (local reference materials), Batch 5 (local reference materials).

3. Models, skills, and runtime frameworks must be regressed together

Old skills may over-trigger and block verification; context management and misconfigured runtime settings can also cause early stoppage or replies to old messages. After a new model is launched, these layers should be rechecked, rather than attributing all anomalies to the model. Evaluation should not only look at pass rates, but also audit expectations, trajectories, and the reasonableness of hidden tests; porting cases with strong verification conditions cannot be automatically generalized to arbitrary rewrites. Thariq also corrected the claim that "effort switching does not break cache": initially it only took effect on the API, and had not yet launched for Code. See Batch 2 (local reference materials), Batch 4 (local reference materials).

4. Look at successful outcomes and long tail for costs; look at multiple dimensions for safety

Thibault's continuous usage review distinguished actual consumption (additional background tasks, retries, multi-agent, long executions) from chart classification errors; rate-limited requests showing up as turns do not represent billable usage. Caching, context, tokenization differences, and same-named inference tiers all affect bills, and a normal median can mask heavy-user long tails. Ultimately you should measure the total cost per qualified outcome on your own tasks. Usage is activity; benefits also depend on whether the task was worth doing in the first place and the verifiable work-hours saved. See Batch 2 (local reference materials), Batch 6 (local reference materials).

Amanda pointed out that goal alignment and harmlessness are different axes: wrong contextual inputs can still cause harm. Vendor claims such as "near-zero" prompt injection, "complete" privacy, and reduced false blocks are all retained as qualified self-statements and cannot replace permission controls. Cross-session safety observation and keeping data in the customer environment were design directions proposed by both companies; independent verification cannot yet be judged from announcements alone. See Batch 2 (local reference materials), Batch 3 (local reference materials).

5. Development time saved should be invested in understanding and experimentation

Thariq explicitly opposed turning capability gains solely into ten times more features in production: more effort should go into understanding users, running experiments, prototyping, and filling in unknowns; games should first validate fun loops before pursuing 3D performance. Karpathy's procedural world experiments also exposed insufficient video perception and playtesting; being able to generate does not equal passing acceptance. Alex's historical reconstruction prompts embodied building a source/confidence table first before generating visuals, and "one-shot" demos often hide massive preparation of materials and skills. See Batch 5 (local reference materials), Batch 6 (local reference materials).

In addition, editable outputs, cross-device memory, feedback draft approval, browser identity separation, and customizable plan modes are all concrete design points that reduce collaboration friction; daily limited content and multi-user sharing/personal preference layering provide another type of product clue. See Batch 7 (local reference materials). This addendum does not rewrite the old article's judgments on personnel, pricing, or current product status; consult the latest sources separately when making real-world decisions.

Sources and related materials

AI Builders · Coding Agents and Agentic Engineering (Podcast Refinements)