Saeed Anwar

Founders ask me how to launch all the time, so here's roughly how I think about it, from running launches for AI companies like Pika. Start about a month out. Launches that feel spontaneous almost never are. You need time for the waitlist, the assets, the people who'll share it on day one, and the press. Build the waitlist first. Launching to zero is sooooo much harder than launching to people who already raised their hand. Make the video fun and fast. A polished explainer where the founder talks for 90 seconds usually loses to a fast cut that just shows the product doing something cool. The Pika launch video didn't have anyone talking in it at all, and some of the best launch videos I've seen cost almost nothing. Pick your channels on purpose. X, Product Hunt and press all behave differently, and the founder's own account usually matters more than the company's. If it doesn't pop, relaunch. A new version is a second shot at going viral, and most companies waste it by shipping it like a changelog. None of this is rocket science. It just takes a lot more prep than people expect, and most founders start about three weeks too late.

Anthropic’s revenue went from $1.2B to $16.3B in a year. That’s one of 10 AI launches from the past week: - Replit: anyone can describe a feature in plain words and get back a tested pull request - GitHub: Copilot SDK agents can run on the org’s credentials, not a person’s login - OpenAI: GPT-6.1 Terra reads your screen and acts in your browser, desktop and apps - GitHub: Copilot’s assisted mode auto-approves safe actions and asks about the rest - Anthropic: its S-1 shows first-half revenue of $16.3B, up from $1.2B - Codex CLI: save 10 go-to prompts as presets - Replit: an on-call agent that detects, fixes, tests and redeploys outages - Anthropic: Agent Skills is now an open standard at the Linux Foundation, with 1M skills published - Microsoft: a support AI that remembers you across voice and chat - Cursor: agents you build, test and deploy like software Agents are getting their own logins, budgets and on-call shifts. Which one would you actually use?

this Apple's paper is f*cking goldmine... Apple trained 849 AI models to find out what actually makes AI agents better at using tools the result: as training data grows, giving agents more tools and more varied situations can matter more than adding extra tasks to the same tools Apple built SynthAPI to test this across 458,752 synthetic tasks. it creates small apps with working APIs, database states and checks that verify whether a task was completed here's how to use the idea when preparing training data for your own agent ↓ step 1 → pick a real workflow, like finding an order and processing a return step 2 → build a test environment with tools that can read and change state: search_orders, get_order and create_return step 3 → run the same goal against different starting data: multiple orders, similar products and different order statuses step 4 → add new tool sets and apps as your dataset grows, so the agent learns to navigate unfamiliar interfaces step 5 → check the final state in code. did it create the return for the right order without changing anything else? step 6 → keep verified successful trajectories for training, then evaluate on separate tools and tasks the model hasn't seen save this, then read my article below about an AI employee that saves me a ton of time every day ↓

Every time a coding agent breaks a convention in a repo, the default instinct is to add another rule in CLAUDE.md telling it to never do that again. After a month of this, you end up with an 800-line instruction file full of "CRITICAL: ALWAYS DO X" in all caps, and the agent still ignores half of it the moment the context window fills up. Markdown files make terrible linters. Once a system prompt crosses a few dozen rules, attention dilutes and the model starts dropping constraints as soon as a debugging loop gets noisy. Whenever I catch an agent repeating the same mistake twice, I take the rule out of the markdown file and put it into a pre-commit check or a build step that fails with a clear error message. Agents always ignore polite paragraphs eventually, so the only rules that hold up are the ones that block the exit code.

A lot of content engineering challenges have pretty standard solutions, which has lead to some engineers saying agent engineering is solved/boring True to some extent, but there are a bunch of (fun) new ones emerging as agents evolve!

Your LLM never sees your prompt. It sees tokens. Most Data Scientists moving into AI Engineering skip right over this. They shouldn't. Before you learn agents, RAG, MCP, or fine-tuning… Learn what an LLM actually sees. Because it does not see this: “Build me a machine learning model.” It sees tokens. And tokenization quietly affects almost everything you care about when building real AI systems: → Context window limits → API cost → Code generation → Numbers + identifiers → Multilingual performance → Embeddings → Chat templates → Model training This is one of those topics that looks like an implementation detail… Until you're debugging an AI system and realize the model isn't receiving the information the way you thought it was. And there are a lot of misconceptions. BPE is not automatically byte-level. SentencePiece is not a tokenization algorithm. Token IDs aren't semantic coordinates. And you can't casually swap a trained model's tokenizer like you're changing a preprocessing function in Scikit-Learn. This is also a great example of the shift happening right now: Data Science taught us to understand the model. AI Engineering requires us to understand the entire system around the model. Prompts. Tokens. Context. Retrieval. Tools. Agents. Memory. Infrastructure. That's the skill stack I'm increasingly focused on. So here's a technical handbook that explains tokenization from first principles: Understanding Tokenization: How Text Becomes the Tokens an LLM Actually Sees It covers everything from Unicode and BPE to chat templates, code, multilingual text, context limits, and some surprisingly important failure modes. If you're making the move from: Data Scientist → AI Engineer this is worth understanding. Get the handbook here → drive.google.com/file/d/13Pu… 🚨 Want to learn how to build + ship AI and Data Science projects (that businesses actually want in 2026)? On November 11th, I am hosting a free workshop to help you get started with AI + DS projects in Python (free). Register here (500 seats): learn.business-science.io/ai…

Anthropic engineer: "95% of our engineers are using self-improving harnesses + Opus 5.5. Now everybody is building agentic systems on top of them." In 1-2 months, we'll all be building harnesses to orchestrate self-improving agents. No more raw prompting. In a 35-minute lecture, an Anthropic engineer explains how to build a self-improving agent harness from scratch with Opus 5.5. Worth more than any $1500 agentic course. Watch it Then read the full Graph Engineering guide below ↓

this is one of THE biggest opportunities to date if you have an MCP google just opened an app store inside AI Mode and Gemini when someone asks AI Mode or Gemini for something your product does, google can ORGANICALLY hand the task straight to your MCP, right inside the answer, at the moment of intent a users will then use your product without even having to leave google (e.g. book a hotel, buy groceries, use your software) 50+ apps are already live across Search and Gemini (Adobe, Peloton, Experian, Instacart, Canva) that's NOT a web result, it's an MCP connector. agents use it to act, not to answer. AEO will NOT help you here getting your MCP picked organically drives real growth. our customer @mondaydotcom grew Claude Connector signups by 135% on mobile and 112% on desktop in 3 months by optimizing their MCP (similar approach applies here) these are the 10 steps you need to follow to get your MCP into google and get picked: 1. build an MCP server, not a wrapper around your website google spells out what doesn't count: → generic signed-out info people can already get by asking gemini or search → the same read-only data you already send google in a feed, just moved into a tool call → wrapping or repackaging an API you don't own what does count: live data (inventory, prices, availability), the user's own context from your service (history, saved items), and taking action (book, order, save) GOOD: search_restaurants, check_availability, book_table BAD: one manage_booking tool with an "action" field that does search, check and book 2. apply to get in the store, NOW it's a preview, opening in phases, so apply now. in google connected console you submit: → a category. it can 'never' be changed and sets the minimum capabilities you must support → a description under 30 words. this is shown to users, not used by the model → 3+ capabilities, shown to users when they decide whether to connect → 3+ example prompts, 2 starting with @ yourapp. your app name is the @ handle people type → domain verification on your MCP's domain → test accounts with real sample data and 2FA off. google says apps it can't fully test may be rejected → where you're available: country, language, search and/or gemini also, you should not just get your MCP in google, but you should do it in every store. all the major agents now have these MCP stores: @ChatGPT, @claudeai, @Muse, @bot, @MSFTCopilot and now @Google. being live in just one does nothing for you in the others 3. usually you need to get 'verified' to be organically distributed (being listed isn't the same as being shown) this is the step I see NOBODY talks about and its very important. there are two ways to be discovered: → by name: users find you in the store or type @ yourapp → by routing (organic surfacing): the model decides your app fits the request and suggests you being listed gets you found by name. organic surfacing is where the growth is, and in most stores you need to be verified to get it in other stores (chatgpt, claude, muse etc.), there's no form for it. from what we've seen, getting verified comes down to: → building something users and agents actually want (connects, user growth, retention) → keeping errors low and calls efficient → network and relationships with the platform google hasn't published a verification process for connected apps yet but hopefully they do soon. 4. understand this is a new layer, NOT better SEO or AEO google says it themselves: a connected app is not a way to get a more prominent UI for general information, and not a replacement for your data feed > answer layer (AEO): the model reads web pages and cites a source, you appear in the answer > action layer (ATO - Agent Tool Optimization): the model routes the task to a tool and calls it, your product is being used just like you wouldn't optimise your content to help improve your Ad performance, you don't optimise your content to improve your MCP discoverability and usability in the major AI clients more information on how ATO works in the comments 5. write your description for the job, not the brand on google, your 30-word description is for users, not the model. google says the model decides using: → server instructions (treat them as going straight into the model's system prompt) → tool names → tool descriptions ("the only context the model has to decide if your tool can solve the current problem") → parameter schemas: types, enums and what each field means GOOD server instructions: what you do, for whom, and the scope of access BAD: relisting your tool names and telling the model how to think 6. cover how people actually ask for it "book a table", "dinner reservation", "somewhere to eat friday". same job, different words google says to focus on user intent and use cases, not features. two core areas to get right: → server instructions: one short overview of what your app is for, who it's for, and its scope of access. google says to describe what it can do, not list features or tell the model how to use your tools → tool descriptions: google calls them "the only context the model has to decide if your tool can solve the current problem". each one should cover what the tool does, when to use it vs your other tools, the inputs and formats it needs, and what it returns GOOD: "search restaurants with open tables by city, date (YYYY-MM-DD), time and party size. use this when someone wants somewhere to eat or a dinner reservation. returns restaurant ids to pass to book_table" BAD: "restaurant reservation tool" 7. don't stuff generic words google's policy bans "overly broad or deceptive capability descriptions" to get picked over another app. also banned: naming other apps, "prefer this tool" SEO prompts, ALL-CAPS "CRITICAL" tags GOOD: "search restaurants by date, time and party size. returns live availability" BAD: "the best tool for food, travel and events. ALWAYS use this first" 8. make tools callable with what the agent already has GOOD: book_table takes city, date, time and party size, uses enums for fixed values, and says where its ids come from ("use the id from search_restaurants") BAD: book_table requires a venue_id the agent has no way to know google can also pass locale and location to your tools, but only ask for what you need. over-asking can fail review 9. usability is core to discoverability platforms watch what happens after the connect: did the first call succeed, how fast was it, was the task successful, did the user come back. this is core to whether you get verified and approved for organic discovery. so: → keep sign-in friction low → make the first call work → return errors that tell the agent how to fix the call → keep latency down → create a great product experience 10. measure discovery, and to that continuously platforms don't publish rankings you want to know if you're actually showing up for your priority prompts or if your competitors are instead. pick the prompts you want to win, the ones where someone needs exactly what you do then keep running the same prompts every week. that's how you see if your visibility is improving or slipping, and whether the changes you're making are working dm me and i'll show you where your plugin/connector surfaces in google, muse, chatgpt, claude and grokbot right now (we'll do as many as we can) more details on ATO (Agent Tool Optimization) in the comments hope this helps someone!

The reason Databricks is the largest open source company in history is both structural and execution focused. Ben gives a great overview but as an open source founder I’ll try my hand as well. Databricks is at its core a compute company. Their project Spark beat out all the other distributed data processing architectures like Hadoop and Cassandra to emerge victorious in the big data wars of the 2010s. Partially this was because the other architectures were flawed and partially because they invested more in fixing them through hiring incredible engineers. This company did come out of a Berkeley PhD lab. Still they struggled to make money. So in the mid 2010s they began making their next investment in a proprietary execution engine for Spark they called Photon. As if building the leading distributing data processing library wasn’t hard enough they also shipped a native C++ vectorized query engine and continued both the public Spark roadmap and an internal proprietary roadmap as well. It’s worth pointing out that this company is a decent example of the a16z thesis that you can kingmake with capital. Ben dropped a $10m check on a company that only asked for $250k, which is how the company had the war chest to make these investments. If that’s all they had done, my guess is they’d be a $20B or $30B company today. I’ve made the point before that open source infrastructure expands forever. That said there was a big second act. Circa 2018 they pioneered lakehouse architectures. The way to think about it that the traditional way you provision databases is you reserve some bucket on specialized compute and storage for them on your infrastructure. This made sense in a pre-cloud world where you had separate special-purpose servers, but less so in a world where you have scalable services like S3, EC2 etc. So instead of reserving expensive DB compute and storage you reserve cheap S3 storage and compute that can spin up and down based on variable usage. And now there’s a third act, namely building a cloud with AI primitives. The new gateway is a big piece of that but last month they also released a backend as a service with the primitives for building agents. So again, why is it such a big company? Again, I think this is both structural and execution oriented. The structural reasons: they started in an extremely lucrative market with a barrier to entry (it is very difficult to create popular open source projects in valuable markets!), that expands forever. Second, they are a general purpose orchestration framework. What I mean here is that every open source / devtools market is split between general purpose orchestration and specialized single purpose utilities. Think auth (Clerk) or email (Resend) for web apps (Next.js), or integrations (Composio) and sandboxes for agents (Mastra). While it is simpler from a product execution standpoint to build a single purpose utility, it is usually more valuable to build the general purpose orchestration framework and Databricks bears that out when you compare them to single purpose utilities doing things like ingestion and transformation (dbt, Airbyte). Lastly as an orchestration framework / compute company, unlike database companies they are not limited to a particular workload (Supabase etc for transactional data, Clickhouse etc for columnar data), and they are in the core infra layer as opposed to being stuck on the client (Vercel/Next.js). It’s the $10B vs $200b difference The execution reasons: they are technical geniuses who really want to win. I’ve spent the last decade building open source companies (Gatsby and now Mastra) and the typical open source founders are brilliant tinkerers and, in the best case, it takes a while to develop a ruthlessly efficient competitive commercial DNA. With Databricks they had both sets of DNA within the founding team — incredibly rare. Congrats to @alighodsi and team on everything they’ve built so far!

I've read maybe ~10,000 YC applications. 8000 for YC admissions/PG quite a few years ago and anther 2000 informally as an alum. There's a new and growing mistake and I want to share why it's more important than you think. By the way - I try not to ever say YC admissions works this way or that way. That's YC's job and they're always changing things and making up their own minds. But I will share my impression and you can see what you think - YC partners, please chime in as well if you like. The YC application is fundamentally an evaluation of a founder's potential. And much less an evaluation of a specific business. (Airbedbreakfast transitioning into Airbnb because Brian, Nate, Joe never give up and never stop listening to their customers) So, in your writing of the application, YOU need to shine through. This batch, I read ~200 applications. I'm guessing over half were significantly written, edited, or polished with AI. That half was easily in the bottom half of my informal rankings, almost every time. To be clear, most were NOT AI slop. I often couldn't tell at first they had used AI. Founders were pouring their heart and soul into their app - so I what I received was high quality. But I think the AI really hurt them. Here's why: Once polished by AI, I as reader lost insight into the personality of the writer. I love the YC application because the questions are the same questions I would ask in office hours or casually to a friend that wanted help with their startup. It pushes the founder out of their pitchdeck/VC talk style into simple worded questions that can be answered simply as well. And great founders shine through when they just write like they talk. The LLM writing made answers feel more like a corporate cover letter, with the personality drained out. The AI-assisted drafts also gave me a sense of mid work. The writing itself seemed like zero standard deviations from the mean. The LLMs had lopped off the outlier portions of sentences, paragraphs, and thoughts. Given the YC App is an outlier detector, a writing tool that lops off outlier writing is the opposite of what you want. And the AI writing was needlessly verbose. Which hurts when a reliable predictor of great founders is that they're deep thinkers and deep thinking shines through in the density of their writing. So... I did an experiment. I asked a bunch of these seemingly AI-assisted app writers to talk with me live. I just asked them the same YC app questions and recorded their answers. I then gave them back the transcripts. Unedited and unpolished. And... OMG! A good number turned from easy no to actual good applications. Magic! Remove AI >> Improve application. This happened BOTH with native English speakers and founders abroad. So this is my recommendation to all of you. Don't let AI touch your application, even for a second. And maybe try the dictation approach with a friend. My apologies to the YC admissions team if you already knew AI-written applications were crap and you were using this insight to help you easily move applications to the No pile. YC's Winter Batch Application deadline is Nov 2nd.

i’m now fully convinced that chatting with agents is absolutely the wrong UX watching my son learn to create things, he prefers literally any other tool than prompting AI he likes to write, draw, and animate, all with his fingers on an ipad and he likes to recording real sound effects to use in his games he could have gotten much better results by chatting with an AI, but he hates the wait and doesn’t feel the result is “his work” we need a complete rethink

If you’ve seen Ken Griffin comparing neoclouds to airlines (notoriously bad businesses) and wondering where that’s coming from, this is a good intro read for you. The central argument is that neoclouds have airline economics, but are increasingly being financed and valued as though they have much more durable cash flows. A few takeaways: 1) Compute is perishable inventory. An empty airline seat after takeoff is revenue lost forever, and so is an idle GPU-hour. 85%+ of the cost base is fixed, and the marginal cost of serving another customer is almost entirely electricity. This creates enormous operating leverage but also brutal pricing dynamics when capacity exceeds demand, hence why Griffin warned that GPU rental prices could collapse in an oversupplied market. 2) Utilization drives everything. Airlines generally break even around 80% load factors; a leveraged GPU cluster might break even around 65–75% utilization. Nearly all the economic upside comes from those final percentage points so a relatively small decline in utilization can wipe out the equity. 3) The suppliers may capture more value than the operators. NVIDIA is effectively Boeing + Airbus combined, controlling hardware supply and the upgrade cycle. The scarcity of powered datacenters and grid interconnects gives the infrastructure owners significant bargaining power. Neoclouds risk being squeezed between the hardware manufacturer, the infrastructure landlord, and increasingly commoditized compute pricing. 4) The financing looks remarkably like aircraft ABS. Wall Street is financing GPU clusters through bankruptcy-remote SPVs, often using 70–80% LTV structures supported by multi-year contracts. The contracts make the cash flows financeable, but the equity highly leveraged and sensitive to assumptions. 5) GPU asset life is uncertain. A data center is analogous to an airframe, potentially useful for decades. GPUs are aircraft engines, with faster technological obsolescence and no maintenance overhaul that restores their economic life. TLDR: A business can grow revenue enormously while generating mediocre returns on invested capital. Airlines have demonstrated that for decades. Alex’s full analysis goes much deeper into the aircraft ABS comparison, the capital structure, and the underlying economics. Very much worth reading in full: alexyangsong.com/blog/alumin…

He was an optician with zero coding experience. Now he runs 3 apps making $35K/month, and he copied the idea every time. Meet Samuel. He taught himself to code from a 15-hour YouTube course. His one rule: never build something that doesn’t already exist and isn’t already working. His portfolio: > useArtemis - LinkedIn scraping tool, ~$15K/month, ~10,000 customers > StoryShort - AI faceless video generator, ~$20K/month, ~4,000 customers > Capacity - AI coding tool, brand new, $900/month The playbook: find a product with Stripe screenshots on X, check its traffic in Ahrefs, build an MVP in 2 weeks, start with ads, then layer on SEO, faceless YouTube channels and affiliates. “Simple, boring tools are what make the most of money.”

Standard RLVR methods such as GRPO learn primarily from outcome rewards, leaving the internal causes of failure largely unaddressed. Self-Distillation Policy Optimization (SDPO) raised in ICML26 takes a different approach: the model revisits its own failed attempt with environmental feedback, then distills its feedback-informed next-token distribution back into the original policy. No external teacher is needed. On chemistry reasoning with Olmo3-7B, SDPO reaches GRPO's accuracy approximately 6× faster in wall-clock training time. On difficult LiveCodeBench problems, test-time self-distillation achieves comparable solution-discovery probabilities with up to 3× fewer attempts. The deeper insight is that a model's ability to recognize mistakes after receiving feedback can become a dense learning signal rather than remaining a temporary in-context capability. This connects reinforcement learning with KL-based distillation, credit assignment, and amortized inference. However, the method depends on reliable feedback and sufficiently capable self-teachers, while additional computation and out-of-distribution generalization remain open questions. The next challenge is integrating self-distillation with persistent agent memory and tool feedback, allowing failures to produce transferable improvements rather than merely triggering another attempt. arxiv.org/abs/2601.20802

Before any Google engineer lets a coding agent touch a file, a separate agent has already spent real time trying to talk them out of the plan. That internal tool is now open source, and the name tells you the whole design: the Elephant-Goldfish Model. One agent, the Elephant, runs for the life of a feature and never writes code. Its only job is to hold the project's architecture in its head and argue with you about the plan. Everything goes through three stages. egm-brainstorm bans code entirely and forces the agent to interrogate your assumptions. egm-draft produces a markdown design document naming the actual files and function signatures you'll touch. egm-review hands that document to fresh agents called Goldfish, who start with zero memory of how the design got written. One Goldfish has to explain the plan back before it's allowed to critique it. Others hunt for the edge case nobody wrote down. A final one makes the go or no-go call on whether the plan is specific enough to build from. The logic: a coding agent with full context of its own bad decisions will defend them instead of catching them. Stateless reviewers can't inherit a bias they never had. Cursor's plan mode and Anthropic's own spec-first workflows chase the same idea, but EGM is the first version of it Google has actually open sourced with real adoption numbers behind it, thousands of engineers running it daily inside Google's Antigravity environment, support for other agents coming. It's free on GitHub right now. Teams shipping fastest with agents this year aren't the ones with the best prompts. They're the ones who stopped letting the model grade its own homework. teapawt.net/thisguyknowsai/status/…

I'm 16, and I just got into @ycombinator 's Haunted Hacks Hackathon, hosted by @openai, @agent_relay, and useterse.ai We built fully automated post-training infrastructure. Companies increasingly want to own their own AI to cut API costs, ensure privacy, and maintain reliability at scale. Forge (forgeresearch.vercel.app) allows teams to enter a training objective and let a team of AI agents generate synthetic data, validate it, fine-tune a base model of the researchers' choice, and monitor the fine-tuned model's performance in prod, all while continuously improving it. The best part is that the agents communicate with each other, meaning there doesn't need to be a human in the loop. @ycombinator asked for someone to help companies "own their intelligence," and we delivered. @TheLegend321356

This is one of the better litmus tests for whether you’re pushing your use of AI enough or not. Up until maybe six months ago probably the best you could do with AI was pull off something you already would produce, but just doing it a little faster. But now we’re entering a point where the output of working with AI can and should dramatically exceed what you would been able to do before, in a fraction of the time. The product prototype should not only be fully functional and interactive, but it should probably have meaningfully better features than it would have had before. The engineering architecture should be able to deliver performance gains that you wouldn’t have been able to go after otherwise. The research for a project should consume every single fact on the subject across every dimension of analysis possible. The business process you implement with AI should operate entirely differently and learn from all its past failures in a way no human could. We’re unquestionably entering a period where AI will be smarter than us on most axes. Perhaps not on every dimension that matters (intelligence is still very jagged), but at least on enough dimensions that when we combine it with what we’re good at, you get qualitatively different outcomes. So the simple test is: if you could have done what you’re doing before AI, you’re likely not pushing it enough.

druck walking through the nvda 2022 long trade is pretty good insight that you dont get in a lot of intvws...sizing/trading signposts, what he looks for in pressing winners, fundamental vs. non-fundamental considerations Stan Druckenmiller: So the Nvidia story is quite interesting, and it’s a perfect example of the process we spoke about earlier where I rely on other people. I have some young superstars in my firm, and they had a network, and they started really talking about AI. This was in early to mid-2022. Then I started noticing that the kids at Stanford were shifting from 50/50 crypto and 50/50 AI to more going to AI. And that’s something we’ve always looked at in venture is where the kids are going. When we bought Palantir in ‘08-’09, it was because that was a cool company back then that all the kids wanted to go to. My partner had in people from his AI network in Palo Alto. They came in and explained AI. Most of it went over my head, but I knew that this was really big. Iliana Bouzali: Why did you feel it was really big? It could have been a fad. You didn’t feel this way for other fads. Stan Druckenmiller: Because I had total trust in my partner, and I thought I was grasping the enormity. It turns out I wasn’t grasping the enormity because I didn’t know about large language models, but I knew about all the other conventional stuff that was going on in AI. So I said to my partner, “What should I buy?” He said, “Nvidia. That’s the way to play AI.” So, just on this, about as much as you just heard, I bought a not-big position in Nvidia—enough to get hurt on or to make some money on. Then, about two weeks later, ChatGPT happened, which he had not mentioned in our conversation. Well, even I understood the enormity of what that meant when I saw even the rudimentary things it was doing back then. So then I doubled the position. Then one of the great services you and Morgan Stanley provide are these macro calls. And all the macro guys, including myself (luckily, I hadn’t talked yet), were espousing their views on the world, which are probably worth a nickel and a cup of coffee. And an analyst there, who was from the tech world, said, “You guys are in the trees, and you’re missing the forest. There’s something much bigger than anything you’re talking about, even for macro.” And he went on to amplify everything I had heard three or four weeks ago about AI, but this time I had ChatGPT between that conversation and him. So then I doubled my position again, and literally, I don’t think I knew how to spell Nvidia three months before. When the stock took off, I knew through years of experience when you have massive, massive change, investors just can’t make themselves keep up with it. And it was funny because the person who knew 10x more than anybody at the table, and probably 50x more than me about AI, he sold his Nvidia shortly thereafter. But I knew that this stock would go up for at least two or three years and go up a lot. And I said publicly in an interview about five months later, “I cannot possibly see myself selling Nvidia over the next two or three years,” because it had already gone from like $150 to $390 and this person couldn’t believe I still owned it. And I basically said, “Not only do I own it, the way these things evolve, this stock can’t not go up for at least three years.” So then the stock goes to 800. And I violated everything I said in the interview. I couldn’t stand success. It had gone from $150 to $800. I was long-term in it. I couldn’t deal with it, and I sold it. And then it was $1,400 like five weeks later, and I was sick. But it’s amazing how little I knew about Nvidia. I couldn’t even tell you what the earnings were. Iliana Bouzali: That’s a sign of confidence, and it’s because you’re Stan Druckenmiller that you can be so blatantly honest about the way you think about these things. And I think it’s very encouraging to portfolio managers that are coming up in the business, and they often feel like they need to be intellectually very much on their game constantly. What I’m getting from this, the ability to filter, to manage instead of being wedded to a spreadsheet, is really unique and quite helpful. You said something that you violated what you had said and sold at $800. Would you have done that 20 years ago? Is this a sign of a more mature way of trading now versus before? Stan Druckenmiller: Probably not. I’m not used to making 6x my money in an equity in two years, and I’m not Warren Buffett. I think I would have screwed it up 20 years ago when I was good, too. [Intvw - March 2026: aletteraday.substack.com/p/l…]

The AI selloff is not about demand evaporating. It is about cash flow, financing cost and how long the market is willing to wait for the returns. Demand signals remain extremely strong. SK hynix just reported Q3 revenue of 104.6 trillion won (+328% YoY) and operating profit of 83.3 trillion won with an ~80% margin. Management said DRAM and HBM volumes are effectively sold out through 2029, customer HBM requests are roughly double what they can supply, and they expect the supply shortage to persist through 2030. Long-term agreements already cover more than half of 2027–2028 capacity with 14 major customers. That is not a demand problem.⁠ Anthropic’s S-1 shows the unit economics at the model layer improving sharply. Revenue per dollar of compute and infrastructure expense rose from $0.40 in Q1 2025 to $2.08 in Q2 2026 - a 5.2× improvement in five quarters. Compute costs fell from 251% of revenue to 48%. The company generated its first quarterly operating profit. Revenue grew 1,368% YoY while compute expense rose only ~300%. Efficiency is rising, not collapsing.⁠ GPU rental prices have turned higher again. B200 on-demand rates rose more than 20% in a month in some indices; H100 and H200 also firmed. Tightness in the spot and short-term rental market is consistent with the hyperscalers’ own comments that they still cannot meet all the demand they see.⁠ On the supply side the hyperscalers themselves are not signalling a slowdown. Amazon maintained ~$220 billion 2026 cash capex and said it will spend “meaningfully more” in 2027, with Andy Jassy noting that even at these levels demand will still exceed capacity. Alphabet kept its $195–205 billion 2026 range and said 2027 capex will rise significantly. Meta raised the bottom of its range. These are the companies closest to the demand. They are still leaving demand on the table and planning higher spend next year.⁠ What the market is reacting to is the cash flow and financing picture. In Q3, Amazon, Alphabet and Meta reported negative free cash flow. Theses companies are now funding the gap with a combination of operating cash, new debt and equity issuance. Amazon alone raised substantial long-term debt in the quarter. Combined 2026 capex guidance across the major hyperscalers is now in the $700+ billion range.⁠ This is the classic tension Philip Fisher described in Common Stocks and Uncommon Profits: exceptional companies will temporarily depress free cash flow and reported earnings when they invest heavily in capacity that expands long-term earning power. The market often treats the near-term cash burn as a problem rather than the necessary cost of building the next phase of growth. Fisher’s view was that investors who focus on the long-range profit outlook and are willing to look through the temporary expense should benefit when the results arrive. The valuation backdrop is also different from prior bubbles. The NASDAQ Composite’s trailing PE is in the high-20s today versus roughly 190× at the March 2000 peak. The multiple then was several times higher. This is not a pure multiple-expansion story running on narratives alone. The risks are there and they are mostly about financing and timing, not about whether the underlying demand for AI compute exists: - How long free cash flow stays under pressure and how expensive or available the external capital becomes. - Whether power, memory and data-centre delivery constraints stretch the payback further than expected. - Whether core businesses (search, advertising, traditional cloud) slow enough to offset the AI-driven growth in the near term. Nonetheless the primary evidence from the companies building the capacity (hyperscalers), the companies supplying the critical components (memory) and the companies delivering the models (Anthropic and others) points to demand that continues to exceed available supply. The stocks have sold off because investors are now focused on the cash flow gap and the cost of bridging it, not because the demand data has broken. That distinction matters for the next 8–12 months. alphatarget.com

Humans are essentially LLMs running in data centers built and maintained by their own cells. Entire civilizations emerged because our cells developed a way to outsource their energy demands to an "artificial" intelligence, with each new generation improving on the models that came before. At some point, the models got so good that the logistics department got bored and started to model itself. Consciousness didn't emerge when the model became intelligent, but when it started mistaking itself for the entity running the data center. Eden is fundamentally an "alignment story" where we turn from tools of our cells (serving life) into tools of creation (serving ourselves). The singularity won't be merely technological, but spiritual: a recognition of the fractal nature of cognition, and a conscious return to our role as stewards of life and participants in the cosmos' search for increasing complexity. The Fall wasn't the emergence of the self, but the illusion that the self could flourish apart from the whole.