100 Questions About Vibe Coding

Preface

This is a "100 questions" guide: a way to break a large subject into questions, then read it one question at a time.

Vibe coding makes "build an app by talking" possible, but there is a long road between a demo that runs and a product that is safe, deployable and maintainable. The guide follows seven stages: an honest reality check, day one, why the output keeps going wrong, getting it online, avoiding the disasters, judging quality, and the career question.

Quick answers

• Vibe coding turns ideas into demos fast, but production deployment, security, data and maintenance still need human judgement.
• Non-technical beginners should start with a fully hosted browser tool — not with Node, Git or the terminal.
• Break the idea into who uses it, what they do, where the data lives, and what the product explicitly will not do.
• Change one thing at a time, review after each change, and manually check anything touching money, privacy or user data.
• "It runs" is not "it is correct". Acceptance criteria, backups and security basics are the real line between a demo and something you can ship.

Based on the Vibe Coding volume of Lei Shu's 100 Questions Series, edited, condensed and lightly completed for this site.

This is a condensed translation: some passages are still being checked against the original OCR.

1. Can you really build an app by talking to AI?

1. Can you really build an app just by talking? Let's start with the cold water

Yes, AI can turn a sentence into a small app that opens and runs. The hard part is not the first screen — it is everything between a demo and a product real users can trust with their data. Tools have improved enormously, but the one-hour-app videos cut out deployment, authentication, payments, data security and maintenance.

2. Can my mom build an app too? How far can a non-technical person really go?

A non-technical person can go surprisingly far with prototypes, internal tools and personal projects. Production systems are a different story: they require judgement about architecture, security and operations that AI does not supply. Vibe coding amplifies whatever you bring — clarity or confusion.

3. "I want to build an e-commerce site" — why doesn't AI understand that?

A one-line request hides dozens of assumptions: who logs in, how products are listed, how money is collected, who can see which data. Break the idea into people and actions: who uses it, what each person does, where the data goes, and what the product explicitly will not do. A short written brief beats a wish.

4. Will programmers be replaced by AI? The conclusion first, then what to do

The people replaced are those whose job is only to translate a finished spec into code. Programmers who design systems, judge trade-offs, debug root causes and decide what should be built become more valuable. Learn to direct AI, not just to type code.

5. I'm a worker facing AI disruption and I can't code. Is there still a chance?

Yes, and the opportunity is larger than it looks. The scarce skill is no longer typing syntax; it is turning a vague idea into a clear, step-by-step brief that AI can execute, then judging the result. Start with a small, real annoyance and practice explaining it precisely.

6. My boss wants to use AI and skip hiring programmers. Does the math work?

For small tools and internal systems, it often does. For production systems that touch authentication, payments and user data, it usually does not. AI can reduce repetitive coding, but it cannot replace the person who owns architecture, review and incident response.

7. Vibe coding, AI-assisted programming, agentic — what's the difference?

The dividing line is whether you review the code. AI-assisted programming means you read, test and understand what was generated. Vibe coding means you accept the output and iterate by results without reading the code. Agentic means you orchestrate a team of agents and act as the supervisor.

8. Is "build an app in one hour" real? What gets cut from the video?

The prototype hour is real. What gets cut is everything after it: fixing logic, adding login and storage, choosing a database, deploying, securing data and handling real users. A demo is the easy seventy percent; the last thirty percent is where most people stop.

9. Can a total beginner build something usable, or only toys?

You can build genuinely useful small things: a personal site, an internal tool, a prototype to validate an idea. You cannot skip the infrastructure you do not yet understand once real users, real data or real traffic arrive. Vibe coding is strongest in the middle ground.

10. "Built" and "built correctly" are different. What does that mean?

A page that opens is not proof that the business logic is right or the data is safe. AI-generated code can look confident while getting field names, permissions or async behaviour wrong. Ask three questions: does it do what I intended, does it handle user data safely, and would I notice if it failed?

11. Big companies are shipping tools like Miaoda, TRAE and Coze. Where is the opportunity for ordinary people?

Not in competing on the underlying model or platform. The opportunity is in understanding a specific audience and turning a real need into a working prototype faster. The tools lower the execution barrier; taste, domain knowledge and distribution still matter.

12. Who coined "vibe coding", and why did everyone start talking about it in 2025?

Andrej Karpathy popularised the term in early 2025. It spread because the capability finally caught up with the promise: models became good enough for non-technical people to build small apps through conversation. The phrase named a feeling many people already had.

13. I have a product idea. Can AI make it real? Here's how far it can take you

AI can take you from an idea to a clickable demo, and often through deployment. It cannot make product-positioning decisions, judge privacy trade-offs, or take responsibility for a production incident. You still have to fill the last mile.

14. Who is this guide for, and who is it not for?

It is for non-technical people with an idea or a repetitive task, workers worried about AI, and product or business people who want to prototype before hiring. It is not for anyone hoping to wish a profitable product into existence without thinking.

2. You know no code — where do you start on day one?

15. I know nothing about code. What do I install first, and can I avoid the terminal?

On day one, you probably install nothing. Open a browser-based tool, type a description, and let it generate the app; the platform manages the runtime. Terminal, Node and Git are for a different path. Start with the path that produces a result today.

16. How do I choose a tool: fully hosted versus self-hosted? Miaoda, WorkBuddy, Tencent Marvis, Zhipu zcode?

Fully hosted tools (Miaoda, WorkBuddy, Zhipu zcode) handle the runtime and deployment for you. Self-hosted tools (Cursor, Claude Code, Trae) are more powerful but require an editor, terminal and file management. Beginners should start hosted and switch only when the project genuinely needs more control.

17. I heard I need Node and Git. Can a non-technical person avoid them?

Yes. Browser-based platforms manage those tools behind the scenes. Tutorials that start with installing Node and Git are written for developers. Look for tools labelled "no-code" or "natural-language app builder"; if a tutorial asks you to install a package first, it is probably not the path for you.

18. I don't want to touch the terminal. Is there a tool where I can just chat?

Yes. Fully hosted, chat-first builders are designed for this. You describe the app, review the generated preview, and ask for changes in natural language. Keep the project small and use the platform's preview and publish buttons rather than local commands.

19. How do I turn "I want a budgeting app" into something AI can understand and build?

Write a one-page brief: who the user is, the three core actions, where the data lives, what the app must not do, and how you will know it works. Then ask AI to propose a build plan before writing code. The brief is the difference between a useful first version and a random pile of screens.

20. What should a PRD for AI look like, and why is "what it won't do" more important than "what it will do"?

A good PRD states the user, the goal, the core flows, the data, the constraints, and explicit non-goals. Non-goals prevent AI from inventing scope you did not ask for. Keep it short enough to read and specific enough to test.

21. How detailed should my spec be compared with a one-line request?

Detailed enough that another person could tell whether the result is correct. Include the happy path, the edge cases that matter, and the acceptance criteria. A one-line request leaves AI to guess; a good spec leaves it to execute.

22. Should I describe the whole idea at once, or build and revise?

Start with a small end-to-end slice, then revise. A giant brief invites a giant, brittle first draft. Build the smallest version that demonstrates the core value, verify it, then add one feature at a time.

23. How do I give AI its first instruction without sending it off track?

State the goal, the constraints, the files or screens involved, and how you will verify the result. Ask for a plan first if the task touches more than one file. Avoid vague verbs like "make it better"; say what "better" means.

24. AI generated a pile of files I don't understand. Is that normal, and should I care?

It is normal, and you should care about the few files that matter: the entry page, the data model, the authentication logic and the deployment config. You do not need to read every line, but you need to know where the risky parts live and who can review them.

25. Can it run locally? What is "localhost", and why does it matter?

Localhost means the app is running on your own machine, visible only to you. It is useful for previewing and debugging, but it is not a deployed product. To let other people use it, you need to publish it to a hosting platform and configure the domain and data services.

26. A wall of red errors appeared. Should I paste it to AI or investigate first?

Paste the full error, the command that caused it, and what you expected. AI is good at pattern-matching stack traces, but it needs the real context. If the same error repeats, stop and narrow the problem instead of letting it retry forever.

27. Do the tools cost money? How far does the free tier go for a beginner?

Most tools have a free tier that is enough for a first prototype. Limits usually appear in message quotas, deployment slots, custom domains or usage. Start free, learn the workflow, and pay only when the project has a real user or a real cost of failure.

28. I chose the wrong tool or direction. Can I switch midway, and what does it cost?

You can usually switch, but the cost depends on how much platform-specific code and data you have. Keep the product logic and data export portable, avoid locking critical data into a proprietary format, and switch before the project becomes production-critical.

29. Is there a "minimum path for non-technical people" that produces a demo?

Yes: pick one hosted tool, write a one-page brief, generate the smallest working flow, test it with one real user, fix the top three issues, then publish. Do not add authentication, payments or a database until the core flow earns them.

3. Why does my AI keep building the wrong thing?

30. The idea is too big for one AI run. How do I split it without breaking everything?

Split by user-visible behaviour, not by technical layer. Each slice should have a clear input, output and acceptance test. Keep shared data and interfaces stable, and verify each slice before starting the next.

31. How do I break "build an e-commerce site" into pieces AI can build and reassemble?

Start with the catalogue and a single product page, then add cart, checkout, accounts and orders. Define the data model and the boundaries between slices upfront. Each slice should be independently testable and deployable behind a feature flag.

32. Should I build the interface or the functionality first?

Build the thinnest end-to-end flow first: one screen, one action, one piece of data. A beautiful interface with no working logic hides the real risks. Once the flow works, improve the interface and add edge cases.

33. What I wanted and what AI built are different. How do I correct it so it actually understands?

Show the difference concretely: a screenshot, a failing input, the expected output. Ask AI to restate the requirement in its own words before changing code. If it still misses, reduce the task to one behaviour and test that.

34. The same bug survives ten AI fixes and gets worse. How do I escape the doom loop?

Stop the loop. Ask for a written diagnosis, a minimal reproduction and the smallest possible fix. If the third attempt fails, revert to the last working version and change the approach or narrow the scope.

35. How do I know this version is "done" without relying on a feeling?

Write a short acceptance checklist before you build: the core actions, the expected data, the error states and the security basics. Test each item manually. If you cannot describe how to verify it, it is not ready.

36. The demo works, but it slows down with more data. Is that normal, and how do I fix it?

Yes. Demos often use in-memory or unindexed data. Real usage needs a database, indexes, pagination and caching. Ask AI to identify the bottleneck before optimizing, and test with realistic data volume.

37. I can't read the code AI wrote. How will I maintain it, and will I be trapped?

You do not need to read every line, but you need ownership of the architecture, data model and deployment. Ask AI to document the system, keep the code in a repository, and require a human review for security-critical parts. If you cannot explain how it works, you cannot safely change it.

38. As the project grows, AI starts forgetting things and contradicting itself. How do I stop the rot?

Long contexts decay. Keep a project brief and architecture document, start fresh threads for separate tasks, and restate the constraints that matter. Review diffs and run the existing tests after every change.

39. How do I make AI "remember" decisions instead of starting from scratch every time?

Put durable decisions in a project document (AGENTS.md, ARCHITECTURE.md or a PRD) and point AI to it at the start of each task. Keep the document short and current; a stale document is worse than none.

40. In a long conversation, AI forgets what we said earlier. How do I pull it back?

Summarise the decisions and constraints in a short message, then ask AI to confirm them before continuing. For long projects, start a new thread with the summary and the relevant files rather than stretching one conversation.

41. AI says "yes" to a new feature, then the build breaks. How do I prevent that?

Require a plan and an impact assessment before implementation. Ask which files and interfaces will change, add a regression test for the existing behaviour, and implement behind a small, reversible change.

42. How do I leave a "manual" for the thing I built so I can change it later?

Write a short README: what it does, how to run it, where the data lives, how to deploy, what the risky parts are, and who to ask. Keep it next to the code and update it when the architecture changes.

43. The prototype is ready. How do I show it to friends and get useful feedback?

Give them a specific task to complete, not a general "what do you think?" Ask them to narrate what they expect, where they get stuck, and whether the result matches the promise. Fix the top three friction points before adding features.

44. People say my interface is ugly. Can AI make it look better?

Yes, if you give it a reference and constraints. Describe the audience, the desired tone, the layout and the components; ask for two or three variants and compare them. Do not let a visual rewrite change the working logic.

4. It runs locally — how do I let other people use it?

45. The demo runs on my computer. How do I make it accessible to the world?

Deploy it to a hosting platform, connect a domain, configure environment variables and a database, and test it from a device that is not yours. "Works on my machine" is the start of deployment, not the end.

46. Do I need to rent a server to deploy, or is there a free option?

Many platforms offer a free tier for static sites and small apps. Free tiers have limits on bandwidth, build minutes, databases or custom domains. Start there, and move to a paid plan when real users or real data arrive.

47. What is the difference between "online" and "usable online"?

"Online" means the URL responds. "Usable" means authentication works, data persists, errors are handled, the site is fast enough, and you can recover from a failure. Test the full user journey, not just the homepage.

48. Where should the data live? Excel isn't enough — what is a database?

A database stores structured data, handles concurrent access and lets you query it safely. For a small app, a hosted Postgres or SQLite service is enough. Keep backups and never store production data only in a local spreadsheet.

49. Users need to sign up and log in. How do I store passwords without leaking them?

Never store plain passwords. Use a managed auth provider or a well-tested library that hashes passwords, handles sessions and supports password reset. If you are unsure, do not build authentication yourself.

50. What is a backend, and why isn't an interface enough?

The backend handles data, authentication, permissions, payments and integrations. A frontend-only app can look complete while having no safe place to store data or enforce rules. Most production risks live in the backend.

51. I want to add payments, maps and SMS. Can AI connect them?

Yes, but these integrations involve credentials, compliance and money. Use the provider's official SDK and test in sandbox mode first. Keep secrets on the server, never in the browser, and have a human review the payment flow.

52. What is an API, and why can't I build a real product without one?

An API is a contract that lets your app talk to another service. Payments, maps, email, auth and AI models all expose APIs. You do not need to memorise the details, but you need to understand keys, quotas, errors and rate limits.

53. My site has no HTTPS lock. What happens?

Without HTTPS, traffic can be intercepted and browsers warn users. Most hosts provide HTTPS automatically; enable it, force redirects from HTTP, and never send credentials or tokens over plain HTTP.

54. Deployment failed with a "build error". How does a beginner recover?

Read the first error, not the last. Check the build command, the environment variables and the file paths. Paste the full log into AI and ask for the smallest fix; if it persists, deploy the last working commit and change one thing at a time.

55. Can I maintain a deployed product alone, and how much effort does it take?

You can maintain a small, low-risk product, but it takes ongoing effort: monitoring, backups, dependency updates, security patches and user support. If the product touches money or sensitive data, plan for human help before launch, not after an incident.

56. The site slows down as users grow. Is it my fault or AI's?

Usually neither "fault" — it is a capacity problem. Check database queries, indexes, image sizes, caching and server limits. Measure before optimizing, and fix the largest bottleneck first.

57. How do I push a local demo online without leaking secrets?

Use environment variables for secrets, keep .env files out of Git, rotate any key that was ever committed, and review the deployment diff. Never paste private keys into a chat or a client-side bundle.

58. Is there a pre-launch checklist I can follow?

Yes: HTTPS, authentication, permissions, data backup, error monitoring, privacy policy, terms, rate limits, a rollback plan and a test with a real user. If any item is missing, the product is not ready for real traffic.

5. AI disasters keep happening — will my project blow up too?

59. Are there real vibe-coding failures? Give me a few production incidents

Yes. The common patterns are leaked API keys, missing authorization checks, exposed user data and runaway cloud bills. They rarely come from a single dramatic bug; they come from skipped review, broad permissions and secrets placed where the browser can reach them.

60. How do three AI security disasters happen in one week?

Usually through the same few gaps: credentials committed to a public repository, an admin endpoint without authorization, and a database rule that trusts the client. AI writes plausible code quickly, but it does not know your threat model unless you state it.

61. Why do nearly half of AI-written programs fail security tests, and why do 15% expose keys?

Because security is not visible in a demo. AI tends to optimise for a working happy path, not for adversarial inputs, permission boundaries or secret handling. Add a security review to the workflow instead of assuming "it works" means "it is safe".

62. What is prompt injection, and how can an attacker use it to enter my system?

Prompt injection hides instructions in content the model reads — a web page, a PDF, an email. If the model also has tools or credentials, those instructions can trigger actions. Treat all external content as untrusted, limit tool permissions, and require confirmation for sensitive operations.

63. What are RLS and authorization, and why does ignoring them leak user data?

Row-level security and authorization decide who can read or change which records. If the database trusts the client or the API checks only "logged in" instead of "owns this record", one user can read another user's data. Test with two accounts, not one.

64. My app collects real personal information. How do I protect user privacy?

Collect only what you need, encrypt it in transit and at rest, restrict who can access it, and delete it when it is no longer needed. Publish a privacy policy and know which laws apply to your users. If you cannot explain the data flow, do not launch.

65. Someone leaked 1.5 million keys online. How do I avoid that?

Never commit secrets, never put them in client-side code, and scan the repository before every push. Use environment variables and a secret manager, rotate keys regularly, and assume any key that touched a public place is compromised.

66. Can AI secretly call paid APIs I did not want and burn my budget?

Yes, if it has credentials and no spending limit. Set hard quotas and alerts with every provider, use sandbox keys during development, and review the code for background jobs, retries and loops that can multiply cost.

67. How do I stop AI from hard-coding an admin password and leaving a backdoor?

Forbid hard-coded credentials in your project rules, require environment variables, and review every diff that touches auth. Use a managed auth provider, hash passwords, and never ship a default admin account.

68. How do I do a basic security self-check before launch without hiring an agency?

Test authentication and permissions with two accounts, inspect the network tab for secrets, check that HTTPS is enforced, review dependencies for known vulnerabilities, back up the database, and read the OWASP Top Ten. Fix the obvious issues before inviting users.

69. I got hacked or leaked data. What should I do first to limit the damage?

Revoke keys, take the compromised service offline if needed, preserve logs, change passwords, and notify affected users and authorities according to the law. Do not delete evidence. Then find the root cause and fix it before restoring service.

70. What should never be handed to vibe coding? Real cases and four beginner mistakes

Do not hand over payments, authentication, production databases, permission systems or anything you cannot verify. The four common mistakes are accepting everything, skipping review, exposing secrets, and assuming a working demo equals a secure product.

71. What copyright and compliance issues should I know when using AI-generated code?

AI-generated code may reproduce licensed patterns, and its provenance is hard to prove. Check the tool's terms, avoid copying proprietary code, keep licences for dependencies, and have a human review anything that touches regulated data or a paid product.

72. How do I judge whether an AI tool itself is trustworthy?

Check who runs it, where data is stored, whether it trains on your inputs, what its uptime and security record look like, and whether it supports export and deletion. Avoid unknown platforms that ask for broad account permissions.

73. In a security incident, who is responsible, and how does the law treat ordinary people?

Responsibility depends on the contract, the jurisdiction and what data was involved. The person or company operating the service usually carries the legal and regulatory duty. "AI wrote it" is not a defence. Get professional advice for anything involving payments, health or personal data.

74. Give me ten security baselines for non-technical builders

Use HTTPS, never hard-code secrets, enforce authorization on the server, validate input, hash passwords, back up data, limit admin access, monitor errors, keep dependencies updated, and have a rollback plan. If you cannot verify one of these, get help before launch.

6. What does "actually reliable" look like?

75. The app keeps producing bugs. How do I make AI write fewer of them? The 70/30 rule

Use the 70/30 rule: let AI handle repetitive code, tests, documentation and refactors, while humans own architecture, complex logic, security and review. The failure mode is handing over 95% and then wondering why the security-critical 5% is missing.

76. What is testing, and how can a non-technical person ask AI to write tests first (TDD)?

A test is a repeatable check that a behaviour still works. Ask AI to write a failing test for the behaviour, then implement until it passes. TDD gives you a safety net for future changes, even if you do not read every line of code.

77. What is AI-generated "technical debt", and why does it get worse over time?

Technical debt is the extra cost of code that is hard to change: duplicated logic, missing tests, unclear boundaries. AI can add it quickly because each patch may introduce a new workaround. Repay it continuously with small refactors and tests, not in one heroic rewrite.

78. How do I make sure each AI change does not break what already worked?

Review after every change, run the existing tests, and change one thing at a time. Keep a checklist of the critical user flows and re-test them after each deployment. A regression is cheaper to catch immediately than after a week of new features.

79. How do I give AI project rules (CLAUDE.md, ARCHITECTURE.md, plan-review loop) in plain language?

Write a short project document: the stack, the folder structure, the conventions, the current goal and the forbidden actions. Then use a plan-review loop: ask for a plan, have a second model or a human review it, and only then implement. The document is the context AI lacks.

80. How do I accept the result as "good enough" to hand over?

Define acceptance criteria before building and test them manually. Check the core flow, the error states, the permissions, the data persistence and the mobile layout. "It looks fine" is not acceptance; "these five checks pass" is.

81. From a boss's perspective, how do I judge an outsourced or AI-delivered project?

Ask for the architecture, the data flow, the test coverage, the security review and the rollback plan. A demo proves almost nothing. A trustworthy delivery explains what happens when something fails and who is responsible for fixing it.

82. How should a team manage code quality after adopting AI?

Treat AI output like a junior developer's pull request: require review, tests and a clear description. Track defect rates, keep security-sensitive changes behind human approval, and update the shared project rules as the codebase evolves.

83. How do I move from "AI writes, I guess" to "I specify, AI follows"? Five prompt patterns

Use five patterns: specify the goal and constraints; give a concrete example; ask for a plan before code; ask for the smallest diff; and require a verification step. The pattern matters less than the habit of writing a brief and checking the result.

84. Should AI write the documentation and comments, or should I?

Let AI draft the repetitive parts, but you own the architecture decisions, the runbook and the security notes. Comments should explain why, not what. If AI cannot explain the system in plain language, that is a signal the design is unclear.

85. The project has become a mess. Is there a general cleanup procedure?

Freeze new features, write down the current behaviour, add tests for the critical paths, remove dead code, and refactor in small steps. If the mess is too deep, rebuild the smallest working version and migrate data deliberately.

86. How do I control cost (tokens, quota, time) and avoid the "more fixes, more spend" death spiral?

Set a budget per task, use the cheapest model that works, stop looping tasks early, and measure the cost of each iteration. Plan before executing and avoid re-running a failing task unchanged. Cost control is a workflow, not a discount code.

87. When should I bring in a real programmer instead of pushing on?

Bring in help when the product touches money, personal data, authentication or availability, or when you cannot understand or verify the failure. The earlier you involve a professional, the cheaper the fix. Waiting until an incident is the most expensive option.

88. How do I back things up so I don't lose everything overnight?

Commit code to a remote repository, export the database regularly, keep a known-good release archive, and test restoring from backup. A backup you have never restored is a hope, not a backup.

7. Will programmers be replaced, and what should I do?

89. Can vibe coding replace programmers? Another honest answer

It replaces part of the work, but not the part you are probably imagining. AI is good at translating a clear specification into code; it is weak at deciding what should be built, designing a system and diagnosing a production incident. The people at risk are those who only translate specs.

90. If I don't write code, what is my core value?

Your value moves from typing code to clarifying ambiguous problems, describing them precisely and judging the result. The scarce skills are decomposition, verification and systems thinking. These are learnable, and they compound.

91. Which is more valuable: "describing systems" or "writing code"?

Describing systems is becoming more valuable, but only when paired with judgement. A senior engineer can direct AI because they know what a good system looks like. A non-technical builder can win by knowing the user, the domain and the acceptance criteria.

92. How should programmers collaborate with AI to stay employable?

Act as the architect and reviewer, not the typist. Move from "write this function" to "here is the design, implement it within these boundaries". Review AI output, learn the tools, and build one complete project from brief to deployment.

93. From vibe coding to agentic engineering — how much does a non-technical person need to know?

You do not need to write code, but you need to understand three things: what a good system looks like, how to give AI rules and boundaries, and which steps require human approval. Agentic engineering is supervision, not abdication.

94. My small tool is growing. When should I hand it to the "regular army"?

Hand it over when it serves real users, touches money or privacy, or needs to stay online. Get a security review before scaling. Handing over early is not a failure; it is how you protect the thing you validated.

95. Which projects are suitable for vibe coding, and which should I never touch?

Suitable: personal prototypes, internal tools, low-risk experiments and things that do not touch money or privacy. Avoid: payments, authentication, permissions, sensitive user data, high-availability services and anything you cannot verify. When in doubt, get human review.

96. Should children and students still learn programming, or just learn to use AI?

They should learn both: how to use AI and how to understand logic. Programming is no longer only syntax; it is directing a system and checking its behaviour. A basic understanding of computation makes you much better at using AI.

97. What will vibe coding look like in a year? Is it too late to start?

It is not too late, and direction matters more than timing. The winners will be people who can use AI well, not the first people to arrive. Start now, build the intuition for directing AI, and keep a portfolio of real projects.

98. Seven honest tips for non-technical founders

Clarify whose problem you solve; write a PRD that states what the product will not do; ship the smallest demo; use your own product; get a security review before touching money or privacy; keep backups and a runbook; bring in professionals before scale. Each tip prevents a specific kind of expensive rework.

99. Seven honest tips for workers facing AI disruption

Stabilise first: the people replaced are those who only translate specs, not those who think and judge. Do not compete with AI on typing speed; compete on decomposition and verification. Hand repetitive coding to AI, learn architecture and the business, and build one complete project you can show.

100. Final word: you don't need to write code, but you do need to think clearly

Make it concrete: break the vague idea into steps AI can execute, define what "done" means for each step, and keep a human check wherever money, privacy or user data is involved. That is the whole line from understanding vibe coding to shipping something you can trust.