This is a theme-driven collection: it reorganizes hundreds of scattered tweets from 7 AI investors / ecosystem observers (the president of YC, several VCs, and the founder of the AI Engineer community) on X by thesis rather than piling them up person by person. It centers on just a few core questions:What still counts as a moat in the AI era? How does a startup become "worth investing in"? When building capabilities for an Agent, which layer should the work live in? What kinds of businesses automatically get better as models get stronger? It does not chase time-sensitive hot takes; it only retains long-lasting judgments.
When to open this:
- You (a product manager / entrepreneur) want to know how top VCs currently judge whether an AI company is "solid" and worth investing in
- You have heard claims like "moats are gone / SaaS is dead / momentum is a barrier" and want a calmer, cross-corroborated set of judgments
- You are building "capabilities" (skills / tools / memory) for AI Agents and want to know where experienced practitioners place the work across layers
- You want to understand what people actually mean by the 2026 conversations around "the harness wars / agent labs / taste as a moat"
0. Who's who
A quick glossary of terms first.VC / GP / Partner All of these people are venture capitalists (they invest in early-stage companies, take equity, and join boards), differing only in seniority and stage focus.seed / Series A / B These are funding rounds; seed is the earliest, and rounds become progressively more mature as you go later.ARR= Annual Recurring Revenue (how much subscription-based companies can reliably collect in a year).
| Account | Person | Role | Main viewpoints contributed in this piece |
|---|---|---|---|
| @garrytan | Garry Tan | President and CEO of Y Combinator (the world's leading startup accelerator), writes code himself and builds open-source tools | The "thin harness / fat skills" engineering philosophy, personal AI and data sovereignty, "filling gaps vs. disrupting incumbents" |
| @nikunj | Nikunj Kothari | Partner at FPV Ventures (seed/Series A), and a highly active hands-on user of Claude Code | "Momentum is not a moat, retention is", "default fundable", fundraising frameworks, "position yourself on the model's inevitable path" |
| @mattturck | Matt Turck | VC at FirstMark Capital, host of the MAD Podcast, organizer of Data Driven NYC | Calm skeptic: questions TAM, moats, and the enterprise implementation gap; "taste is a moat" |
| @swyx | Shawn Wang | Founder of the "AI Engineer" professional movement, advisor to Cognition | "Agent labs / businesses that get stronger as models improve", power-law betting, agent composition/recursion |
| @adityaag | Aditya Agarwal | GP at South Park Commons (SPC), former Dropbox CTO | Hard tech (atoms + bits), agents as "a shell for tool calls", the Series A/B death spiral |
| @lennysan | Lenny Rachitsky | Product/growth/career advice (Lenny's Newsletter) | Nearly all captured posts from this account were noise (4 posts, mostly podcast spoken ads), with only 1 usable entry (see §7) |
| @stevenbjohnson | Steven Johnson | Editorial Director at NotebookLM / Google Labs, author of 14 books | Only 1 post was captured this time, with no long-term viewpoints(see §7) |
1. Momentum is not a moat, retention is — and the "end of momentum"
Why (this is the first section you should read): From 2023 to 2025, a large number of AI companies grew quickly and raised funding off "flashy launch videos + channel distribution", but failed to retain users. Multiple VCs now agree on one point:That kind of flash-in-the-pan momentum no longer constitutes a barrier; the real barrier is users staying and using the product continuously. The implication for product managers: don't be fooled by "viral launches" — look at retention and real paid usage.
The core judgment nikunj has repeatedly made [2026-03~05]:
"momentum is no longer a moat"(Momentum is no longer a moat)
His diagnosis is very specific [2026-04]: when doing due diligence,the first thing he does is pull up the changelogs / feature release records of those "viral companies" — often there are barely any updates for weeks on end. His conclusion: focus your energy on paid users, not on viral launch videos — "the VCs follow!"(investors will naturally follow).
From this he derives his judgment on the "seed to Series A gap":
"never been easier to raise to start, never been harder to scale"(It has never been easier to raise initial funding, but it has never been harder to scale)
mattturck applies the same logic to the question of "defensibility" [2026-03]:
"Network effects create massive long-term staying power... Unclear yet if the AI era can build its own strong flywheels (data loops etc)." Translation: Network effects can create enormous long-term stickiness… but it remains unclear whether strong flywheels (such as data loops) can be built in the AI era.
mattturck also points out a more stinging problem of "nothing to inspect" [2026-04]: software first became serverless, and now it is becoming headless — "there's not much left to look at"(there is not much left to look at), which makes due diligence on AI startups harder and harder, because the inspectable "substance" is shrinking.
Companion point: M&A (mergers and acquisitions) will accelerate. nikunj [2026-04] predicts M&A will reach a "frenzy" (potentially even exceeding the frequency of funding announcements), driven by: the widening seed→Series A gap + 2021's "zombie unicorns" starting to pay their dues + the "big token factories" (referring to leading model companies) hoovering up talent + bearish public markets. adityaag's corresponding portrait of the "death spiral" can be found in §6.
2. Thin harness, fat skills, fat code — which layer to put work in when building capabilities for Agents
Why: When you build "abilities" for an AI Agent, there are three places you can put them:harness(the orchestration shell that strings models together to run),skills(the "work instructions" written in Markdown for the model to read),code(deterministic program code). garrytan laid out a widely shared set of layering principles that directly shape how personal AI / tools should be built. For product managers, this is the engineering-version answer to "where should requirement docs, SOPs, and hard rules each live".
garrytan's most condensed line [2026-04]:
"Push smart fuzzy operations humans do into markdown skills. Fat skills. Push must-be-perfect deterministic operations into code. Fat code. The harness? Keep it thin... Everything else is architecture astronomy." Translation: Put "the kind of smart but fuzzy work that humans do" into skills written in markdown — skills should be fat. Put "deterministic operations that must be exactly correct" into code — code should be fat. As for that orchestration shell (the harness)? Keep it thin. Everything else is "architecture astronomy" (over-engineered fancy scaffolding).
Several supporting points all point to the same belief — memory / capabilities / the brain should outlive the shell:
- "Memory is markdown, skills are markdown, the brain is a git repo; the harness is just a thin conductor that reads those files but does not own them" [2026-04]. If your memory dies along with the harness, that means the harness is too thick.
- "Markdown + LLM is the new code": For high-value, complex, high-context, intelligence-requiring tasks, it is far better than any deterministic language [2026-03/04].
- The 3-file personality stack(high value) [2026-04]:
SOUL.md= who this agent is (tone/values/principles, "a constitution, not a system prompt");USER.md= a deep model of you yourself (~4000 words: how you think, strengths, blind spots, family, trigger points);AGENTS.md= operating rules. One warning:"Write 'be helpful and concise' and all you'll get is a ChatGPT" — generic instructions produce generic outputs. - Few, thick skills beat many, fragmented ones [2026-04]: Let adjacent skills "DRY themselves out" (deduplicate) and merge into one large skill with branching parameters; short parsers are better than long ones (less context bloat).
- Use LLMs as judges for self-evolution [2026-05]: Have the agent use 3 frontier models to score a skill's input/output on a 0–10 scale, ask "why isn't this a 10? How do we get to a 10?", and run several rounds — because it is written into skill files + code + evals/unit tests,"it gets better permanently".
Connection to users' own KB/memory systems: This entire line of thinking — "markdown as capability, git repo as brain, memory must be portable" — is the same core idea behind users' own KBs (the Karpathy LLM Wiki Pattern) and memory wikis. garrytan's open-source GBrain(see §8 below) and nikunj's LLMwiki(§8) are concrete implementations along this line.
swyx adds the "composition/recursion" dimension from another angle [2026-04]: "this is the year of subagents" is mostly an optimization problem; the real capability problem is agents being able to compose with each other and "manage" other agents. He points out a counterintuitive design pattern — the "smart friend" subagent: usually subagents are dumber than the main agent, but a smarter "critic" subagent (similar to "sleep on it and look again", reviewing with fresh, critical eyes) is a design that others are only just catching on to.
3. Agent labs / businesses that get better as models get stronger
Why: One of the most critical questions for entrepreneurs — what businesses get to "free-ride" on the gains from model progress? The answer is: your product's value is positively correlated with the underlying model's capability; every time the model levels up, you automatically get stronger without having to change much. swyx named this category long ago as Agent Labs. This is the core lens for judging how high an AI company's ceiling is.
swyx [2026-05]: sama (Sam Altman)'s "mythical" framework ("business that gets better when models get better" / businesses that get better as models get stronger) corresponds exactly to what he earlier called Agent Labs; he observes that there is a direct correlation between model performance and agent-lab revenue, with a discontinuity (jump upward) appearing in Q4 2025.
Related long-term judgments:
- "Coding agents breaking containment" is this year's theme [2026-05]: This is the year all knowledge workers (not just programmers) get their "AGI enlightenment". He himself uses a "Tiny Team" to serve roughly 1 million independent developers per month via agent-based services.
- Every evals / analytics startup is going through a one-time generational upgrade in 2026 to become a "continuous learning platform" [2026-05]: "Many will fail, but as always, the ones with taste will win."
- Enterprise CIOs have unusually high appetite for AI-native startups [2026-03]: Redpoint research shows roughly 46% of enterprise CIOs are willing to choose AI-native startups over existing big vendors— "an astonishing market opportunity"; and CIOs are currently "hungrier rather than more conservative… this won't last forever" (implying the window is limited).
- But the "last mile" of enterprise implementation is the real moat [2026-03]: "On Twitter people may be happy to use
--dangerously-skip-permissions(dangerously skipping permission confirmations), but to roll this out across tens of thousands of engineers at a company, you have to take compliance/IT security seriously." — the real barrier-defining work lives here.
swyx also offered a piece of betting philosophy(applicable to anyone making choices) [2026-03]:
"Carefully bet on a very small set of things. Don't hedge, but keep reversibility. Set triggers/levels to monitor if you are wrong. Set tests to DOUBLE DOWN EARLY if you are more right than you thought." Translation: Bet carefully on very few things. Do not hedge, but preserve reversibility. Set trigger points/watermarks to monitor whether you have bet wrong. Also set up tests so that once you find you are more right than you thought, you double down as early as possible.
He argues that "false equivalence" — treating things of unequal importance as equally important — is a trap: power laws compound, and most systems (schools, managers, curators) are not designed at all to "let one single thing matter 50 times more."This mistake killed his first devtools startup.
4. Default fundable — How a startup becomes "worth investing in"
Why:nikunj reframed "what to pursue" away from "high valuation" to "default able to raise the next round(default fundable)". For founders: this is a health check to judge how well you are doing; for product managers: this explains why investors fixate on certain unobtrusive metrics.
nikunj's core thesis [2026-04]:
"Be default fundable."(Achieve "default fundable.")
Optimizing valuation above fundability is a trap — just look at the batch of "zombie unicorns" from 2021–22: even after recaps (recapitalizations) and >1x liquidation preferences, they can now neither raise capital nor sell because of "bloated cap tables + non-AI-native talent."
He also shared a set of"funding advice VCs won't tell you" [2026-03]:
- Never monologue at length — "VCs have worse attention spans than a toddler";
- Backchannel your investors — "You can't fire a board member, so you can spend a day confirming this is the right one."
At a higher level of judgment, nikunj laid out the "ingredients of success" plainly [2026-06]: the best founders treat AI/timing, funding, distribution, market, product, revenue all as necessary components, not the entire business — too many pitches hype only one of them. The bar from seed to Series A has never been higher;narrative + ambition + understanding a VC's opportunity cost all matter.
And a sharp line about "founder vs entrepreneur" [2026-06]:
"There are a lot of founders but very few entrepreneurs. Don't become a founder for the sake of being one — do it because you literally can't do anything else." Translation: There are many founders, but very few real entrepreneurs. Don't become a founder just to "be a founder" — do it only because you truly can't do anything else.
Companion point — whose money to take: nikunj [2026-05] revealed an "unwritten VC rule": funds with large AUM (assets under management) "can't afford to lose any sector," so they will invest in competitors at the same time / let portfolio companies pivot into each other — "You only have one company; the fund has an entire portfolio." He also criticized many GPs for "capping downside rather than maximizing upside," justifying deals with "at least some big token factory will acquire them" — that is "AUM farming," not building a fund that returns 5–10x.
Pitfall to avoid — paper wealth from the employee perspective: nikunj [2026-05] warned employees of newly minted unicorns that they face a "triple whammy": tiered valuations push exercise prices to >2x the lead preferred price → high 409A valuations → "the equity package looks good on paper, but it is heavily watered down."Do the exit math yourself; join for learning/mission, not for paper compensation.
5. Taste is the new moat; as execution becomes free, the bottleneck moves up
Why:When AI makes "writing code/doing execution" nearly free, what becomes scarce is no longer execution, but judgment and taste — knowing what to build and what is good. This is a rare point of consensus among several observers, and it directly answers non-technical product managers asking "where is my value."
mattturck [2026-05]:When execution becomes free, the bottleneck shifts to taste / judgment(he repeated this across multiple threads, and there is also a joke mocking VC value "YOU. HAVE. TASTE.").
garrytan framed it as the new rule of startups [2026-05]:
"High agency, high taste is the unlock these days."(Today's breakout formula is: high agency + high taste.) "If you can make the agents do magic for you and you have taste and agency, then you could be 16, 20, 30, 45 or 60 and it doesn't matter. All the old rules are gone, there is only making something people want." Translation: As long as you can make agents do magic for you, and you have taste and agency, it doesn't matter if you are 16, 20, 30, 45, or 60. All the old rules are gone; only one thing remains: make something people actually want.
garrytan also offered a set of "startup mindset calibrations":
- "Money is gasoline, not fire" [2026-05]: Money is not fire; it is gasoline you pour on a "fire that is already burning." "You don't have a funding problem, you have a 'people don't want it yet' problem. Go light the first fire first."
- "Play the new game" [2026-05]: Don't use 2026 technology to build 2010s businesses — don't rebuild Foursquare/Yelp, don't rebuild Basecamp with $10/month SaaS pricing,don't underprice(if it actually works, it is worth much more), and don't become a "tech-wrapped PE shop" living off revenue gimmicks.
- "Boil the ocean, don't cut costs" [2026-05]: Directed at Ken Griffin / Citadel — "The ceiling just got raised. Some twenty-something will build a 'human-machine symbiosis' crack team that outperforms his entire book, simply because he got distracted cutting costs."
adityaag grounded the same optimism in "meaning" [2026-05]: Write code with AI on Friday, watch humans play ball and dance on Saturday — "I'm not worried we'll lose meaning and purpose."
6. Series A/B death spiral + "Back to Minus One"
Why:nikunj's "end of momentum" (§1) covers the early stage; this thread from adityaag covers the most dangerous spot in the middle stage — companies that have raised A/B rounds but have stalled growth. For founders this is the most realistic warning; for product managers, it explains why some "decently sized" companies are in fact slowly dying.
adityaag's sharpest VC judgment [2026-05]:
"The hardest spot in venture is a Series A/B company that is not growing." Translation: The worst position to be in, in venture capital, is a company that has raised an A/B round but is not growing.
Concrete profile: ARR of $10–20 million, 20–50 people, growth below 25% = "ngmi"(not gonna make it).You cannot iterate your way out of this hole. His "brutal solution":
"return back to Minus One."(Go back to "Minus One.")
It means stepping back to the moment before the product existed, taking stock of the real core assets you actually have, and rethinking "what can we build that hits a much bigger target." Most founders lack the courage to do this; the alternative outcome is slow decline and death. (Minus One is SPC's signature framework, referring to the incubation stage before "product zero.")
Companion point — four iron rules for early-stage hiring [2026-05]:
- If an engineer is torn between "pre-B startup vs big tech/big lab" → stop talking to them immediately; they are not ready to join a startup;
- If they are unwilling to accept a 70% cash pay cut compared to big tech → stop; they will be unhappy;
- "You can tell a lot about a candidate during negotiation/closing; don't be afraid to walk away";
- "Startups have zero work-life balance."
7. A few independent but worth-keeping judgments + note on low-signal accounts
7.1 mattturck: a few calm "anti-hype" judgments
- Product roadmaps are collapsing [2026-03]: "2022: plan 1 year / 2024: 6 months / 2026: 1 week" — things change too fast in AI to plan far ahead; you can only "ship → evaluate → iterate."
- "Software was never just the product; it has always been a solution" [2026-03]: When you buy software, you are also buying (1) insurance that "someone will keep iterating on this problem," (2) a team to help you install it, (3) someone you can call when it breaks.Implication: one-click AI-generated software throws all of that away.
- Sharp critique of the claim that "TAM = the entire human labor market, replaced dollar-for-dollar" [2026-04]: "Like every labor automation technology in history, the price of AI services will fall to marginal cost plus normal profit." The trillion-dollar TAM claim is baffling.
- The perception gap between enterprises and Silicon Valley is the largest he has ever seen [2026-04]: Silicon Valley says "AI is self-accelerating, agents run everything"; Global 2000 enterprises say "I spent a fortune on your AI chat two years ago and got zero productivity gains; engineers like the coding AI, but nobody else cares; agents are scary."
- Agent pricing will not be purely usage-based [2026-05]: Token costs matter, but enterprise agents need identity, roles, auth, budgets, audit logs… "Does this weirdly sound like 'per seat'? It's just not 'human seats.'" (a very sharp pricing prediction)
- The most "anticlimactic" scenario [2026-05]: "The most mind-blowing scenario in AI is: actually not that much changes. Both the doomers and the accelerationists are wrong. We all become more productive, agents deliver automation in enterprises, some important scientific discoveries are made. All good. But, that's it."
- Also a judgment quoted from Yann Dubois (OpenAI) [2026-05]: even if you froze existing models and only worked on the harness, "people would genuinely feel AGI in every domain" — the current frontier is the harness, not the base model(consistent with nikunj §3 and swyx's judgment).
7.2 adityaag: hard tech + "agents are just a shell over tool use"
- Hardware startups win by "telling a story," not by specs [2026-03]: "Nobody cares about your actuator resolution; they care what it means." The best hardware companies sell "a future people want to live in"; the struggling ones lead by piling on specifications.
- You should bet "head-on into models" [2026-03]: "Everyone wants to avoid going head-to-head against models; shockingly few people do the opposite. Run toward the risk, but bet on capabilities that will mature in 12–18 months" — bet that models that are bad today will be "good enough" X months from now.
- Agents are a shell over "tool use + code generation," not a shell over 'generative AI' [2026-04]: Most work is iterative tool calling. He also said current agents are far from consumer-grade — running OpenClaw "feels like running Linux in the early 2000s," requiring manual assembly everywhere.
- "Always-on" (persistent, adaptive/learning/state-maintaining) agents are far more compelling than one-off chats [2026-04]; the difference between a "real agent" and "an LLM in a loop" is long-term memory management for intelligence; he singled out Claude Code's three-layer memory architecture as the most interesting.
- "First you shape the tools, then the tools shape you" [2026-04]: He has the entire SPC team write code every week, and the effect is an automation mindset, lower latency, and exploding ambition — "If your company isn't doing this, you are genuinely missing a beat."
7.3 Low-signal accounts (honestly labeled, no padding)
- @lennysan(Lenny Rachitsky): This crawl captured 4 posts, almost all noise(podcast sponsored ad reads + procedural content). The only usable one [2026-03-15]: Product/engineering/design people are the "worst negotiators" in tech, and "most product people leave at least 20% on the table" (from a career/salary negotiation perspective).
- @stevenbjohnson(Steven Johnson): This time only 1 post was captured, with no long-term framework or viewpoint — a quote-retweet praising someone's "extraordinary ability as a technical explainer". It is recorded only because it was the only one.
These two accounts have very thin signal on this topic,which does not mean they have nothing valuable to say, but that no long-form durable content was captured in this crawl window. If volume picks up in the next sync, a separate supplement can be added.
8. Things these people open-source/built (tangible artifacts you can reference directly)
Why: These are not product ads, but runnable implementations of the viewpoints above — especially directly useful for users currently building personal KB / memory / agent systems.
- garrytan · GStack: His open-sourced Claude Code CLI toolset (including
/qa/plan-eng-review/review/shipand other slash commands), 70k+ GitHub stars, claimed to be used daily by tens of thousands of agentic engineers, runs in Claude Code / OpenClaw / Hermes, and ships with built-in Chromium. - garrytan · GBrain: MIT-licensed open-source personal AI knowledge/memory system — "8 layers, layering graph search + vector search on top of a grep-based knowledge wiki", designed specifically for "Karpathy-style markdown knowledge wikis" (he himself has 100,000–120,000 markdown files)."It is not boxed RAG", unifying memory + code tools + search under a single graph/query interface. Published evals claim it is 38% stronger than Vector RAG.(Shares the same root as user KBs, worth comparing.)
- nikunj · LLMwiki(Open source, vibe-coded with Opus 4.5): A personal LLM wiki generated from tweets/bookmarks/iMessage/writing, inspired by Karpathy and Farza — "Throw the repo at Claude Code and it will walk you through it." Directly corresponds to users' own KB/memory systems.
- nikunj · Other vibe-coded small projects: Lenny's Roundtable (an "AI persona debate based on content" site built in 75 minutes), Prompt to Chip (a visualization of how a prompt runs down to the chip and back), DeployGraph (scraped the SOC II subprocessors list of 417 companies to reverse-engineer what infrastructure AI-native companies use), flight and hotel points CLI (reverse-engineered airline/hotel points APIs).
- nikunj's high-frequency practical tips:Reverse-engineering APIs via network requests [2026-05] — Point Claude Code at the browser, sniff network requests while clicking around, and let CC infer the API structure + authentication (mostly cookies) + rate limits; he predicts there will emerge "tools.txt" for agents (analogous to llms.txt). There is also a widely shared custom instruction for "model execution units": Have the model estimate workload in "model execution units" (seconds/tool call counts/iteration rounds) rather than "human-days", and separately mark "human upfront blockers" (registration, credentials, deployment) as gating steps.
- swyx · AI Engineer community: Global expansion (London/Singapore/India), published his 2026 Mac configuration as a Claude skill. There is also a fun benchmark — the "PewDiePie benchmark" [2026-06]: PewDiePie vibe-coded an opencode wrapper in one day (email/docs/calendar, >10k stars). "If your 'knowledge work Agent' startup can't beat PewDiePie, you might as well pack it in — he is the baseline for 'what you can DIY'."
9. One-page quick reference (for you, the decision-maker)
| The question you are wrestling with | These people's long-term answers | Source |
|---|---|---|
| Whether an AI company is reliable | Look at retention / paid conversion / changelogs, not launch-post spamming ("momentum is not a moat") | nikunj §1 |
| Whether my own company is healthy | Whether it is "default fundable"; no growth at Series A/B = death spiral, need to "go back to Minus One" | nikunj §4 · adityaag §6 |
| Where is my value as a non-technical person | taste/judgment is the new moat; execution becomes free, taste becomes scarce | mattturck/garrytan §5 |
| What kind of AI business to build | Agent labs that "get better as models get stronger"; filling gaps > disrupting giants | swyx §3 · garrytan §5 |
| Which layer to put agent capabilities on | thin harness / fat skills (markdown) / fat code (deterministic) | garrytan §2 |
| Is it AGI now | The frontier is in the harness, not the base model; "maybe it hasn't changed that much" is also a real scenario | mattturck/swyx §3,§7 |
| Whose money to take / how to fundraise | Don't deliver long monologues, do reference checks on investors, understand VCs' opportunity cost; big funds will invest in competitors | nikunj §4 |
History
- 2026-06-05 v1.0 created — follow-builders subproject · builders-investors topic bucket. Synthesized from pre-built digests of 7 accounts (adityaag/garrytan/lennysan/mattturck/nikunj/stevenbjohnson/swyx). Organized by thesis rather than stacked per person; lennysan/stevenbjohnson are low-signal accounts, honestly labeled with no padding.
2026-09-26 supplement: From runnable to sustainably usable
This round read through 1,152 previously unarchived local tweet texts one by one, retaining twelve batches of notes and per-item IDs. Covers historical material from June–September 2026; full text in short links, images, videos, or show catalogs was not expanded. The following is a cross-author synthesis of viewpoints; publishers' self-reports, fundraising promotions, predictions, or personal usage impressions are not elevated to independent facts.
Validate the work first, then crystallize skills
Zara repeatedly emphasized: do real work and iterate first, then package skills, rather than writing abstract skills first and looking for uses. Peter added more specifics: provide good output examples, trigger conditions, pass/fail evals for common mistakes, and a small amount of experience notes, then clean up outdated and duplicate rules. Self-updating skills may solidify one-off preferences or introduce drift, so versions and replayability must be preserved; the number of automatically created items is not a measure of completion quality. (Batches 01, 02, 06, 09)
A paraphrase from the Linear interview breaks implementation down into four questions: where work starts, where context lives, what counts as done, and where human judgment is needed. Start with one high-frequency task, first use a strong model to establish a quality baseline, then test smaller models; when failing, distinguish between "the tool exists but behaves incorrectly" and "a necessary tool is missing" — the former becomes an eval, the latter becomes a product requirement. Reporting a problem later does not equal having fixed it. (Batch 05)
Unattended operation is more sensitive to initial assumptions. Examples of software factories, fourteen-hour goal execution, and periodically edited videos all require accounting for requirement definition, human feedback, total time spent, and cost. "First-version one-shot generation" cannot replace final acceptance. Independent agent reviews help find blind spots, but still require clear scoring rubrics and human verification. (Batches 03, 07, 11, 12)
Measure quality and cost with real tasks
Swyx, Zara, and Nikunj respectively emphasized real-code maintainability, personal eval sets, and regular retesting. Industry benchmarks must specify samples, person-hour estimates, quality rules, and run traces; personal tool choices should use recurring real tasks, not just leaderboards. Models becoming faster, cheaper, or better at conversation may change choices, but a single experience is not a universal ranking. (Batches 01, 03, 08, 10, 11)
Cost comparison should look at total cost to complete tasks of equal quality, retries, and human review, rather than only input/output unit prices or how many tokens were burned. Subsidized subscriptions, pay-as-you-go APIs, and local deployments have different constraints; first judge whether a task is worth doing, then decide on multi-model and parallel scale. Design similarity, runnability, and real user outcomes should also be evaluated separately. (Batches 02, 03, 05, 08, 11)
Context, entry points, and portability
The continuous accumulation of personal and organizational materials can become context shared across different models. Markdown skills, clear data locations, and on-demand search aid migration, but file copyability does not guarantee automatic compatibility of tools, permissions, and runtime behavior. The more information there is, the more indexing, versioning, and cleanup are needed; you cannot directly set the "ten thousand files" mentioned by an author as the threshold for all knowledge bases. (Batches 01, 05, 08, 10, 11)
What authors repeatedly complain about is not a single intelligence problem, but inability to correct course mid-run, inability to find connected plugins, disconnect between voice and desktop tools, no visibility into task progress, and inability to navigate threads by pending approval/running status. Unified products must also accommodate lightweight queries, neither forcing users to over-select modes nor turning every simple question into a long task. (Batches 03, 04, 08, 10, 11)
New products that require rebuilding accounts and context increase trial costs. Zara's bookmark injection into daily information feeds, reading-list calendar booking, and team collaboration tool entry points provide examples of "entering existing behaviors". Whether something is reused requires sustained observation: a runnable personal app may never be opened again. (Batches 07, 09, 10, 12)
Organizational collaboration cannot be replaced by individual efficiency
On one hand Zara sees the efficiency brought by personal closed loops, on the other she worries that everyone only chatting with agents will weaken team communication. Public-channel agents can support shared learning, but visibility scope must be limited; meeting transcripts are context, not automatically equivalent to decisions and execution authorization. Professional teams packaging brand and design judgment into skills usable by other teams can reduce repeated handoffs, but cannot replace professional maintenance. (Batches 02, 03, 08, 10)
Aditya reminds that shared work history and team culture also matter; culture is co-shaped by founders, early teams, and products. Peter and Matt's experiences remind that process automation may compress a day into continuous decision-making and increase attention interruptions. Judgment quality, peer collaboration, and rest remain part of organizational design. (Batches 08, 11, 12)
Taste, distribution, and brand come from real-world feedback
The common requirement for content and products is substance, a specific audience, and one's own judgment. Zara suggests starting from frequently asked questions and real work; Peter and Swyx advocate writing aesthetic examples and design specifications clearly. More context can reduce generic expression, but three to five times input length and fixed iteration counts are merely personal heuristics. (Batches 02, 08, 09, 10, 11)
Swyx's speaking experience can be summarized as one clear argument, concrete examples, reliable audio, memorable points, and traceable data. Teach the audience to understand the problem first, then introduce the product; frontline technical content cannot be judged solely by play counts or stagecraft. Creators' social distribution, community relationships, and long-term corporate brands deserve attention, but buy attention only after retention exists; short-term buzz cannot be treated as a moat. (Batches 01, 04, 08, 10, 12)
Commercial materials retain framing and time boundaries
Nikunj repeatedly distinguishes GMV (Gross Merchandise Volume) from ARR (Annual Recurring Revenue), and also reminds that fundraising headlines may include special-purpose vehicles, tranche conditions, and different prices. High valuations, brand-name investors, and high paper option value do not equal safety or final returns, and internal support does not equal a formal commitment. Financing structure cannot be judged directly from a low dilution percentage. (Batches 02, 05, 07, 09)
Customers want outcomes and need customization, which may increase the importance of services and implementation, but this does not prove that pure software has become obsolete. Piston's integration of driver identity, transaction information, settlement, and cashier systems demonstrates one case of embedding into real business workflows; figures on growth, retention, and cost reduction are all self-reported by the investee and lack complete measurement standards. The entry costs of contracts and relationships may bring advantages, but meaningless overtime and long delays do not in themselves constitute advantages. (Batches 06, 10, 12)
Specially retained counterexamples and corrections in this round
- Peter once praised Instinct's onboarding experience, and later withdrew his recommendation due to allegations regarding data retention and deletion issues; both segments are preserved together. The complaints have not been independently verified, and only the first half must not be excerpted.
- Garry clarified that Paxel does not upload code file content, which does not mean that no user data is uploaded at all.
- For health-related content, only administrative information, care logs, and authorized collaboration needs are extracted; disease efficacy, nutrition ratings, or diagnosis and treatment advice are not extracted.
- Program catalogs are only indexes; model scores and user volumes are historical statements; future revenue and takeover years are forecasts; content related to politics, sports, private life, and context-free reposts are only stored in their original text.
Batch notes
- Historical supplement 01 (Local reference materials)
- Historical supplement 02 (Local reference materials)
- Historical supplement 03 (Local reference materials)
- Historical supplement 04 (Local reference materials)
- Historical supplement 05 (Local reference materials)
- Historical supplement 06 (Local reference materials)
- Historical supplement 07 (Local reference materials)
- Historical supplement 08 (Local reference materials)
- Historical supplement 09 (Local reference materials)
- Historical supplement 10 (Local reference materials)
- Historical supplement 11 (Local reference materials)
- Historical supplement 12 (Local reference materials)