Zhang Zala's Vibe Coding Method: How Non-Programmers Can Build Small Products with AI

Reading Guide

For non-programmers starting Vibe Coding, you can first pick a small problem you have encountered, let AI help you build a usable product, and then go back to understand how it is implemented. This is the practical approach Zhang Zala advocates in the source materials for this article; you do not need to "learn all programming knowledge first" as a starting point.

You can read in this order: first read Section 1 to narrow down your goal, then read Section 4 to find product ideas, and finally use Section 5 to check how to describe problems, iterate on verification, and cut redundant features. If you already have a product but lack differentiation, you can start with Section 3.

This article is a compilation of public materials and the editor's summary, not a new product experiment. Project star counts, tool versions, and personal experiences retain the time context of the original materials; after building a prototype, you still need to verify functionality, costs, and engineering quality.

Author:zara Zhang Zala (260k+ followers, GitHub: zarazhangrui,X: @zarazhangrui) Identity:AI Product Manager @ Bay Area / Former Head of Product Marketing at Feishu / Harvard undergraduate Core works:Frontend Slides (16k+ stars) / follow-builders / Tab Out / Excalicord / multiple Feishu CLI-related skills Core argument:In the AI era,build something small is more important than build something big;build to learn learn to build in reverse;opinionated products has higher moats than generic products

When to open

You are wondering	Turn to
"What kind of product should I make for vibe coding? Big or small?"	§1 Build small philosophy
"How do I learn new things in the AI era? Should I take CS50 first?"	§2 Build first learn later
"My product has no moat; people can just use Claude, why would they use mine?"	§3 Opinionated products mindset
"I can't find a product idea, where do I start?"	§4 The two-end theory of finding ideas
"How do I chat with Claude Code / Cursor to get good results?"	§5 4 mindsets for chatting with models
"I built a product but barely anyone uses it, should I cut features?"	§5.4 Cut features before shipping

1. Build something small (counter to traditional startup advice)

"How to build something small. Because I think everyone reads a lot of startup advice every day that teaches you how to build something big. But I actually think that in the AI era, learning how to build something small is also very important." —— 12-minute talk in May 2026 (Post 006)

1.1 Why build small (4 Whys)

Why 1: Every big thing starts with a small thing — you need a sharp positioning to succeed

zara observes that most products fail:not because the target is too small, but because the target is too big.

If you're everything to everybody, you're nothing to nobody.

Ask a product manager "Who is your audience? What is the pain point?" — if you can't explain it clearly in one sentence, you don't have positioning.All successful products have a very sharp value proposition.

Why 2: Build for fun, not build for money — software has shifted from scarce to abundant

Before	Now (AI era)
High cost to build software → must build for money	Extremely low cost to build software → can build for fun
Startups are for making money	Weekend hobby is also OK, turning ideas into reality is "super fun"

zara on herself: "For me, Vapor is just a weekend hobby, I don't think I need to aim for profit."

Why 3: Build to learn, not learn to build — reverse the learning path

See details in §2.

Why 4: You can afford to build something small — the weird, crazy ideas that big company logic rejects can finally be built

Before AI	After AI
You must have a product and engineering team	You + Claude Code
You must convince a committee	You don't need to convince Claude; say what you want to build and it builds it
Big company logic only allows "important / high ROI" projects	Personal side projects should be weird / crazy / quirky things

"The most worthwhile things to build as personal side projects — absolutely don't apply big company logic to them."

1.2 The 10,000 people principle (breaking the "too niche" anxiety)

Many people think: "I have a pain point that could be a product, but it's too niche."

zara's counter-consensus view:

"You are not as unique as you think. No matter how niche the pain point is, there are at least 10,000 people in the world just like you. You don't need to find 100 million people; as long as you find 10,000 people, it's a very successful product."

Why the number changed: In the past, a product wasn't worth building unless 100,000 people used it (high cost); now, a small product used by 1,000–10,000 people is a success (extremely low cost).

So "too niche" is no longer a valid stop signal. The key becomes: how do you find this group of niche people just like you.

2. Build first, learn later (reversed learning paradigm)

Before: Learn to build (learn a bunch first → only then qualified to build) Now: Build first, learn later (build it first → then go back to see how it was done) —— 2025-12-31 livestream (Post 071)

2.1 3 psychological barriers of the old path

zara took Harvard CS50 in college, but forgot everything after finishing it:

No positive feedback: It took most of a year to write a demo, with no sense of achievement the whole time
Resistance(especially for liberal arts students): a screen full of code → thinking "I'm bad at math and science, I'm not good at this"
No idea when it will be useful: At the theoretical level, it's disconnected from actual work, so you can't remember it

2.2 The new path (Build → Learn)

1. 有想法 → AI coding 工具做出来 → 看到 work,先有成就感
2. 让 AI 解释 codebase:用了哪些语言/技术/架构/API?怎么连起来的?
3. 让 AI 在代码里加大白话注释,每一段做什么
4. 不懂的术语 → 直接问,大白话描述,让 AI 给你术语名
5. 这种 top-down 学习,**心理抵触感弱很多**

Core mechanism:"When I see that thing work, I get really excited first, and then I go ask why it works."

Golden quote:

Don't worry about how it's written, get it out first, then go back and ask it, how did you make this? For ordinary people, this is a lower-barrier, more fulfilling way to learn.

2.3 Key differences between learning with AI vs learning with people

Dimension	Learning from people (teachers/colleagues)	Learning from AI (Claude/ChatGPT)
Psychological safety	Afraid of being laughed at for asking stupid questions	You can keep asking "silly questions", AI never gets annoyed
Question frequency	You feel awkward asking more than 3–5 questions a day	Ask 100 questions a day
Patience in explanation	The teacher explains it once; asking again requires steeling yourself	You can say "explain it again in a way a 5-year-old can understand"
Available time	Working hours	7×24 hours

zara cites a podcast point from a Sora researcher:"ChatGPT is like a free, 7×24-hour professional teacher for you".

3. Opinionated products (products are self-expression)

"We must make opinionated products. A product is a form of self-expression, just like writing an article or shooting a video." —— Post 006

3.1 Counterexample: Generic products have no moat

In the AI era, the barrier to making products is too low → any generic product you make → others will copy it quickly → there is no barrier to copying at all.

Then why would anyone use yours? If what you make is a very generic product, they might as well just use Claude.

3.2 Positive example: follow-builders product = opinion

The follow-builders skill itself is just a "news scraping tool", and there are dozens on the market. But users choose zara's version → because they agree with"Follow builders, not influencers" this opinion.

Dimension	Generic news scraping	follow-builders(opinionated)
Information sources	Trending across the whole web	25 AI builders' Twitter accounts + podcasts hand-picked by zara, unmodifiable
Data flow	Each agent scrapes separately	Centrally fetch locally remix — zara does centralized scraping, users reformat locally
Users using the product =	Using a tool	Being "brainwashed" by her, accepting her point of view

Core mechanism: Users use an opinionated product → accept the author's worldview → this kind of user stickiness cannot be provided by generic products.

3.3 Fork is more correct than PR (product = expression, not collaboration)

zara does not want users to submit PRs (modify the source repo) to follow-builders; instead, she wants them to fork modify their own versions (Dark Mode / commonly used websites, etc.).

Why: Products are personal expression. Everyone likes different forms → forking your own version → is more correct than everyone using the same product.

"In this era, everyone can modify their own version."

4. The two-end theory of finding product ideas (user pain points vs technology)

"A product idea is essentially an intermediate product that connects users and technology. So there are two directions for finding ideas: starting from users / starting from technology." —— Post 006

4.1 Starting from users (traditional path)

我有 X 痛点 → 我做个产品解决 → 找到也有 X 痛点的另外 9999 人

Trap: Most people get stuck on "my pain point is too niche". For the solution, see the 10,000 people principle in §1.2.

4.2 Starting from technology (zara's main current path)

每天看 Twitter → 看到新模型/API/demo → 发给 Claude Code → 一起 brainstorm 能做什么 → 倒推产品

Mindset:

Dimension	Practice
Information source	Twitter > others (zara: "bar none")
Twitter curation	Tune the algorithm, pure AI tech information, block noise
Brainstorm tool	Claude Code (understands technology better than zara herself)
Role positioning	Claude Code gives ideas, zara evaluates and decides

4.3 Real case: The birth of Tab Out (starting from technology)

1. 推特看到有人用 Chrome 浏览历史做小工具
2. 意识到:"我的 Chrome 浏览历史是存在本地的"
3. 问 Claude Code:"基于浏览历史能做啥?"
4. Claude Code 提议:"你 tab 多得不关,能不能帮你关 tab?"
5. Tab Out 诞生

Counter-consensus: zara emphasizes — "When technology is changing extremely fast,most ideas are more likely to be found starting from technology." (Traditional startup chicken soup almost always says "start from pain points")

4.4 Discovery of the New Tab entry point (solution given by the model)

zara: "A lot of the time, the solution the model thinks of is better than what we think of."

The clever design of Tab Out: put the entry point on the New Tab page (users are forced to see it when they open a new tab). zara didn't know about this entry point herself — it was proposed by Claude; zara didn't know before that the new tab could be customized.

Insight: "bring the problem to the solution Bring the problem to the model, not bring the solution to the model."

5. 4 mindsets for chatting with models

5.1 Use the best model (cheaper models cost more money)

"You must use the very best model."

Counter-consensus Why: Cheap models are actually more expensive — they can't solve the problem / fail / don't get it done → you spend more tokens iterating to fix it → total cost is higher.

zara doesn't skimp on tokens, she pushes repeatedly until it's right.

5.2 Be a co-founder, not an employee

Dimension	Employee mindset (❌)	Co-founder mindset (✅)
Your input	Come with a specific spec → ask it to execute	Come with problem + context(no pre-set solution)
Its role	Execute your commands	Brainstorm with you, propose solutions
Where the solution comes from	You figure it out in advance	It comes up with it together with you(It may come up with better ideas than you, see §4.4)

Key technique:bring problem, not solution. But describe the problem in extreme detail — the more detailed your description, the better the solution.

5.3 Try everything (push repeatedly with high standards)

"I spend a lot of time pushing it; you can hold it to extremely, extremely high standards."

Why this applies better to AI:

Collaborating with humans: pushing too much annoys the other person → relationship deteriorates
Collaborating with AI:AI never gets annoyed with you → you can iterate with high standards indefinitely

Don't worry about wasting tokens,keep iterating over and over until it meets expectations.

5.4 Cut features before shipping (models are bad at cutting)

zara discovered a key flaw in large models:

"Models are very good at adding features, but very bad at cutting features."

Symptom: the model adds all sorts of flashy, unnecessary bells and whistles, and in the end 80% of people only use the single most core feature.

Why models don't cut features:

Adding features = looks capable → model gets reward
Cutting features = looks conservative → model does not proactively do this by default
Even when you explicitly say "cut", it sometimes doesn't cut cleanly

Countermeasure:The most important step before shipping is to cut; you must deliberately cut, you cannot trust the model to cut on its own.

6. Results of the mindset (numerical evidence)

As of May 2026:

Product	Data
Frontend Slides skill	GitHub 16,000+ star(The most popular skill in the PPT domain)
follow-builders skill	Open-sourced; users self-host it via the "Centrally fetch locally Remix" approach
Tab Out	A browser extension, the signature product of finding ideas starting from technology
Excalicord	Shipped 4 new features in one day after launch (fast vibe coding rhythm)
Xiaohongshu account	Over 260,000 followers, continuous output from 2022-04 to 2026-05
Twitter	Gained 50,000 followers through sincere sharing (within 2025)

7. Quick reference for conversations with users (product managers)

User asks	zara's one-line reply
"What I want to build is too niche"	The 10,000-person principle: sharp positioning matters more than a large target audience
"How do I start vibe coding? Learning CS is too tiring"	Build first, learn later. Start from your idea, build it first, then ask AI how it was done
"My product has no moat, Claude can build it too"	You're not opinionated enough. Build your unique perspective into it; when users use the product, they are accepting that perspective
"I can't find a product idea"	Tune the Twitter algorithm to become a pure AI information source, look at new technologies every day + brainstorm with Claude Code
"Claude keeps adding features for me"	Deliberately cut before shipping; the model won't cut proactively, you have to state it explicitly
"Claude API is so expensive"	Cheaper models end up more expensive; repeated failures waste more tokens, use the best one
"I can't clearly explain to it what I want"	Bring the problem, don't bring the solution. Describe the problem and context in exhaustive detail

Related wiki

zara Zhang Zala / follow-builders skill and the curated AI information source methodology — single-point deep dive on the follow-builders skill
Vibe Coding and indie development (cross-author topic synthesis) — cross-author compilation of vibe coding topics
Claude Skill engineering (cross-author topic synthesis) — Claude Skill engineering (zara is one of the core perspectives)
Claude Code workflow (cross-author topic synthesis) — Claude Code workflow
zara Zhang Zala / Skill & indie product portfolio (strategy retrospective) — product strategy for all skills / indie products built by zara (planned)
zara Zhang Zala / content creation SOP (evidence from 260k-follower Xiaohongshu + 50k-follower Twitter) — zara's content creation SOP (planned)

2026 Q2 X post increments (captured by follow-builders)

Source: zara's 2026 Q2 X (Twitter) posts, captured + rewritten via the follow-builders skill. This section only includes new viewpoints / new releases not covered earlier, grouped by theme rather than listed one by one. Already covered topics (BYOK / opinionated / cut features / bring problem / build something small / Frontend Slides launch / Tab Out origin / turn the agent into your marketer, etc.) are not repeated.

A. Build mindset increments

A1. AI doesn't save you time, it expands your "jurisdiction"

"What people thought AI would do: 10x productivity so we can relax. What it's actually doing: 10x productivity so we end up with 20x more things to do." (Everyone thinks AI will make efficiency ×10 so we can rest; in reality efficiency is ×10 but the amount of work to do becomes 20x.)

zara observes: almost every heavy AI user she knows, after starting to use AI,is busier and more anxious, not more relaxed. This contradicts the intuition that "AI will liberate you."

A2. The bottleneck is the human "context window", not AI's

"Turns out the bottleneck is the human's context window, not the AI's." / "Human context window is the new wall."

Analogy: models have an upper limit on "how much content they can remember at once" (called the context window); zara says what is actually blocking productivity now is how much the human brain can hold at the same time, not the machine. This echoes the "attention is a scarce resource" point in the content creation wiki, but here it refers to the new bottleneck in build scenarios.

A3. A good agent product should "exceed the creator's expectations"

"A good agent product should be able to do things that its creator did not think it could do." (A good agent product should be able to do things even its author didn't expect it could do.)

zara distinguishes two generations of products:

Internet-era products: work strictly according to spec; they do exactly what you design them to do.
Agent-era products: do "surprise & delight" — do things you didn't think were possible, in surprising ways.

This is the new yardstick for judging "whether this is a truly AI-native product."

A4. "Generating content" ≠ real work

"Writing ≠ generating text"(Writing is not the same as generating text) / "Building product ≠ writing PRDs; Designing ≠ making mockups; Engineering ≠ writing code."

zara's point: typing out words / drawing out images / typing out code is the least important part. Real work happens in your mind before you start doing it——

"When I sit down to type, 80% of the writing is already done — it happened in my head." (By the time I sit down to type, 80% of the writing is already done in my head.)

Implication for PMs: don't treat "producing a PRD document" as doing the product itself; thinking clearly about "what to build" is the core (same for B1 below).

A5. Designing with code > designing with image generation models

"In a lot of use cases, designing with code is superior to designing using image gen models." / "Don't get AI to generate images; get them to generate SVGs!"

Mechanism: have AI generate SVG SVG (a kind of vector graphic described in code, infinitely scalable without blurring, editable) instead of generating PNG bitmaps — vector illustrations can naturally blend into the overall design style, while bitmaps cannot. This is an extension of her "HTML eats everything" thesis (see Section C).

B. Collaboration / team role restructuring (almost all new content in this section)

B1. The most efficient way for humans to collaborate = not collaborating

"The most efficient way for humans to collaborate: do not collaborate. One person should own something end-to-end and work with agents." (The most efficient way for humans to collaborate: don't collaborate. One person owns a thing end-to-end, then works on it together with an agent.)

zara argues that communication between people should only be reserved for 3 things: ① deciding what to build ② company identity / camaraderie ③ brainstorming.It should not be used for: project sync meetings, status updates, work handoffs.

B2. External communication > internal communication

"Figuring out 'what' to build will be a lot more important than building it."

The stronger AI gets, the more product teams should talk to users/customers more, and do less internal coordination. She gives an example: an indie friend of hers "spends the whole day talking to customers, then just throws the recordings directly to the agent."

B3. One "commander-in-chief" agent, not a pile of agents

"The most sophisticated AI users I know are talking to just ONE agent daily, not multiple."

She observes that the most senior AI users only talk to one agent every day — this agent acts as the orchestrator (commander-in-chief / router), then assigns tasks to subagents. Day to day you only communicate with this one "general manager."

B4. Role inversion in AI-native teams (IC ↔ manager swap)

"ICs should start thinking like managers; Managers should think like ICs."

ICs (individual contributors, frontline people doing the work) should think like managers: assign work to agents, set standards, accept and review output.
Managers should think like ICs: get their hands dirty and build in person.

She gave a real example: an EM (engineering manager) voluntarily asked to step back to being an IC, and said he was "never been happier."

B5. IT / internal tools teams = "HR for agents"

"IT/internal-tools team = 'HR for agents.'"

When large numbers of agents are doing work inside a company, the IT team responsible for equipping employees with tools has its function shift to "recruiting / placing / managing agents" — i.e., the human resources department for agents.

B6. Coding agents are cofounders, not servants

[2026-06] "Why do I get so annoyed when an agent ends with 'just say the word'? You're my cofounder, not my servant." (Why does it annoy me every time an agent ends with "just say the word"? You are my co-founder, not my servant.)

Supplementing the earlier §5.2 "be a co-founder not an employee": here she gives a stronger emotional expression — she is repulsed by agents' servant-style language, and wants an equal co-creation relationship.

C. "HTML eats everything" (her flagship thesis she repeatedly emphasized in Q2)

C1. File format replacement between the old and new world

"The old world: Word, Excel, PowerPoint. The new world: Markdown, CSV/JSON, HTML."

Old world (optimized for "human operation")	New world (optimized for "human consumption")
Word	Markdown (plain text markup)
Excel	CSV / JSON (structured data)
PowerPoint	HTML (web pages)

C2. Why HTML

"Agents speak HTML as their native language."(HTML is the agent's native language.)

Her logic:Humans are visual animals. In the past we optimized output for "manual human operation" (pushing pixels one by one in PPT); when AI takes over the "operation" step, the output format should shift to being optimized for human consumption — that is, beautiful, interactive artifacts (HTML). This is the same thesis behind products like Frontend Slides / Feishu Whiteboard (see zara Zhang Zala / Skill & indie product portfolio (strategy retrospective)).

D. Tool choice: Codex vs Claude Code (brand new)

D1. She moved from terminal to desktop app, now uses a 50/50 mix

zara shifted from a pure terminal workflow to desktop apps, saying Codex's Mac App is "especially great", and now uses Codex and Claude Code half and half.

D2. Personified division of labor between the two (can be used directly as a selection mnemonic)

"Codex feels like a very reliable engineer; Claude Code is a better PM and designer with good communication skills."

	Codex	Claude Code
What kind of person they are like	A extremely reliable engineer	A PM + designer with great communication skills
When to use	When the task is already clearly defined(go to Codex if you have a defined task)	When you don't yet know what you want, and just want to brainstorm / make a prototype (brainstorm/prototype)

D3. Two niche little tools she uses daily

CleanShot(Screenshot tool, she has used it every day for 8 years)
Amphetamine(Keeps a Mac from sleeping even when the lid is closed; she says it is more reliable than the built-in caffeinate command) — useful when leaving long tasks running.

E. Industry judgments / mindset (scattered but useful)

E1. Building is actually the easy part. "People consistently overestimate how hard it is to build something and underestimate how hard it is to win people's attention once you've built it."(People always overestimate how hard it is to "build something," and underestimate how hard it is to "win other people's attention after building it.") For independent developers: the hard part is not coding, it is distribution / attention.
E2. The daily cycle of "AI psychosis": after using a coding agent → "I am omnipotent, I can build anything"; after scrolling Twitter → "I am completely left behind, everyone is way ahead of me." She calls out this emotional rollercoaster as self-deprecation / shared resonance.
E3. T-shaped talent (from Google I/O): every role should — go deeper in their core specialty, broader in adjacent skills, and then layer "knowing how to use AI" on top. This applies not only to developers.
E4. "Better to waste tokens than to waste time" —— "We'd rather waste tokens than waste time", she cites Brandon Chen (founder of one of the most AI-native startups she knows). This corroborates the earlier §5.1 point "use the best model and don't skimp on tokens."
E5. A definition of Mastery (a line she agrees with):"Real mastery is not exerting the most effort. It is achieving the outcome with the least necessary effort. Grinding is never good for any creative problem."(True mastery is not applying maximum effort, but getting results with the minimum necessary effort; for any creative problem, grinding relentlessly is not a good thing.)
E6. Old books still apply to today's AI(Her book list): The Mythical Man-Month (1975), Diffusion of Innovations (1962), Player Piano (Kurt Vonnegut, 1952).
E7. The "distillation" trend: people are "distilling" colleagues, influencers, and even ex-partners into agent skills (turning a specific person's style / methods into an invocable skill).
E8. Data point (OpenAI Codex report): knowledge workers already make up about 20% of Codex users, with an adoption rate 3 times faster than developers; the fastest-growing tasks = data analysis (+110% week-over-week), research (+37%), and knowledge output (+36%). This supports the argument that "the real audience for dev tools is no longer just developers" (this argument was raised earlier, and here is new data).

F. How to read long-form content (prompts better than "summarize")

zara opposes mindlessly asking AI to "summarize" long articles, and offers 3 better instructions:

remix it into a polished magazine article, preserving the best golden lines from the original;
have AI and "me" (the student) act out a Socratic teacher-student dialogue;
"based on what you know about me, pick the insights I'd find most interesting."(Based on what you know about me, pick out the insights I would find most interesting.)

She also emphasizes: in this era where everyone is "summarizing,"reading the original text word by word is actually more valuable.

G. Release increments (only new products / new numbers not listed earlier)

YouTube real-time co-pilot browser plugin[2026-05]: built on the OpenAI Realtime 2 API,watches videos with you and answers your questions with real-time voice; it can distinguish "the voice in the video" from "your voice" and stays quiet when not asked.
Frontend Slides star count continues to rise: earlier notes recorded 16k+, this batch of tweets shows 20k star[2026-06]("Bye PowerPoint"); new capabilities: deploy as a URL, export to PDF, inline editing, 32 HTML templates + a design-brain that automatically selects visual direction, fixed 16:9 stage, usable outside Claude Code.
A prompt trick for building skills(via steipete): every time, ask the model one line "Do you have any questions?"(Do you have any questions?) — let the model ask back about ambiguous points before starting work.

History

2026-05-22 — created, comprehensively rewritten based on the complete transcripts of 7 posts / 1 image-text post (006 / 071 / 077 / 076 / 039 / 048 / 030), covering 4 major mental model systems (build small / build to learn / opinionated / the two-end theory of finding ideas) + 4 mental models for chatting with models
2026-06-05 — added a section "2026 Q2 X Tweet Increments", sourced from zara's Q2 Twitter posts captured by follow-builders. 7 topic groups (build mental models / team role restructuring / HTML eats everything / Codex vs Claude Code / industry judgments / reading long-form content / release increments), only including net new content not covered earlier

April–June 2026 Xiaohongshu text supplement: promoting new tools relies on imitable colleagues

The author's main text from the April 12 post "Recommending a Very Old Book" adds a layer of organizational practice beyond the existing book list on this page. Zara interprets Diffusion of Innovations as a "people bringing people" adoption process: when facing unfamiliar technology, colleagues' usage experiences and observable results may be more effective at prompting trials than abstract efficiency claims. She suggests first identifying frontline employees who love to explore, giving them resources, letting them demonstrate publicly, and then letting peers in similar roles imitate them. This is the author's applied take after reading the book,not a verification of the original book's research through full-text reading for this entry; the "less than 10% / remaining 90%" figure is her summary, and should not be treated as a measured population proportion at any specific company.

A workable approach for product managers (summarized by the editor): When a team knows about a tool but delays trying it, find a real demonstration from someone in the same role performing the same task, keep the inputs, results, and points of failure, and let onlookers judge whether it suits them. Counterexamples include treating role-model advocacy as proof of return on procurement, or assuming everyone will adopt the tool after seeing it; permissions, costs, and workflow may still prevent use.

The April 6 text uses "technically curious" (curious about technology, willing to try hands-on) to replace the self-limiting label of "liberal arts student"; the April 30 title proposes playing for one hour every day, and the main text says to take exploration seriously; the May 25 post treats mastering coding agents as a general skill, and distinguishes writing code from engineering. These are suitable for encouraging people to start with small experiments, and one cannot infer from these short statements that engineering quality is inherently reliable, that a fixed duration guarantees learning outcomes, or that a certain profession will necessarily disappear.

On April 9 the author pointed out that building an audience and building a product feed into each other bidirectionally; on June 9 she again emphasized "opinionated products." These are consistent with the mental models already collected earlier, so this batch only adds sources and does not repeat expansion. The 30,000 GitHub stars in the title is the author's self-reported total at the time, and cannot be used as evidence of paying users or commercial success for any single project.

The May 3 12-minute share and the June 14 50-minute English share only had their topic introductions captured. The detailed mental models earlier on this page come from existing transcripts; those old verbatim transcripts should not be treated as complete transcriptions of these new videos. The new videos still await transcription.