AWS Builder Center Article

Build an AWS Exam Practice Room with Vibe Coding Dev Tips

This article shows how a rough prompt trail became a working AWS Exam Practice Room through vibe coding. It explains how to turn intent into a contract, shape a fast static prototype, keep the UI simple, and use every prompt as a product decision. The focus is practical: build small, verify behavior, preserve context, and let the next prompt refine the system without losing momentum.

Disclaimer

Purpose: This platform serves as an independent project constructed exclusively for the advancement of educational exploration and dedicated artificial intelligence research. It aims to foster a deeper understanding of modern technology without any external influence. Users can utilize this secure environment to study complex systems, test innovative ideas, and learn safely.

Non-Commercial: There is absolutely no underlying business model associated with this independent project. It is strictly not intended to generate financial revenue, monetary profit, or any tangible commercial value. Our core focus remains purely on academic development, ensuring that access remains completely free from hidden costs, corporate sponsorships, or advertising schemes.

No Guarantees: Because this platform operates as an educational tool utilizing experimental artificial intelligence, generated outputs may occasionally be inaccurate, misleading, or entirely incomplete. All provided content is strictly offered on an as is basis, completely without any express or implied warranties, guarantees of factual correctness, or promises regarding overall reliability whatsoever.


Table of Content

Part 1: Start With The Product Contract The first section explains how the demo moved from raw exam content and scattered ideas into a stable product contract: JSON data, static HTML, query-string routing, and visible learner feedback.

Part 2: Use Prompts As Product Deltas This section shows why the best prompts were small product deltas instead of broad commands, and how each instruction changed a surface the builder could inspect immediately.

Part 3: Shape Trust Before Decoration This section explains the dark AWS-style landing page, giveaway messaging, exam library cards, article links, and metadata as trust signals rather than ornamental design work.

Part 4: Keep The Demo Static Until It Hurts This section argues for static files, simple JavaScript, reusable JSON, and no framework until the product proves where complexity must actually enter the system.

Part 5: Turn The Prompt Log Into A Build Map This section shows how the prompt trail became a record of intent, design decisions, corrections, and future blog material for teaching vibe coding practice.


Start With The Product Contract

Goal

Build a learning product that can grow from one AWS Certified Data practice set into a reusable exam room without rebuilding the UI for every new topic.

Prompt

The prompt trail began with content conversion: keep the original content, change the output to a template format, then follow the question guide and upgrade the JSON to a more professional level.

Result

The system settled on a JSON contract with exam metadata, chapters, questions, options, answers, answer summaries, and option explanations. That contract made the HTML player simple.

Tips

  • Define the data shape before polishing the UI.
  • Make the first JSON file the template for every future bank.
  • Preserve answer explanations because feedback is the learning product.
  • Use chapter and question numbers as stable navigation anchors.
  • Treat every content file as an API, even when it is just static JSON.

Folder signals

  • Landing page: index.html, a dark AWS-style educational homepage with Open Graph metadata, a hamburger navigation, a standalone language selector, a hero section, a giveaway message, an exam library grid, AWS Builder article cards, and responsive behavior.
  • Practice player: practice-room.html, a simple dark-mode multiple-choice and multiple-select app that reads the exam, chapter, and question from the URL query string and loads the matching JSON file.
  • Language layer: 20 translated index pages plus English index.html. Every selector option points to an absolute deployed index_{lang_code}.html style path.
  • Exam-bank contract: each JSON file uses exam, title, source, chapters, questions, number, question, options, answer, answer_summary, and explanations. That contract lets one front end load many practice sets.
  • Question-guide material: the guide emphasizes validity, reliability, fairness, plausible distractors, active voice, role alignment, cognitive complexity, and rationales that prove why a key is correct.
  • Prompt trail: the iterative build notes record instructions for template conversion, mobile layout, submit and next behavior, exam cards, screenshots, language localization, and absolute language URLs.

Exam-bank scale

  • AWS AI Development Exam: 20 questions in 1 chapter.
  • AWS Generative AI Dev Organization Exam: 80 questions across 4 chapters.
  • AWS Networking Core Exam: 98 questions divided into 2 chapters.
  • AWS FSI Trading Desk Design Exam: 680 questions distributed across 34 chapters.
  • AWS Certified Cloud Operations Exam: 520 questions spanning 5 chapters.
  • AWS FSI Macro Trading Exam: 380 questions across 23 chapters.
  • AWS Certified Machine Learning Exam: 460 questions divided into 4 chapters.
  • AWS Certified Data Exam: 82 questions in 5 chapters.
  • AWS Certified Data Exam (Version 1): 82 questions in 5 chapters.

Use Prompts As Product Deltas

Goal

Keep momentum by asking for one visible change at a time while preserving the working demo after every iteration.

Prompt

The strongest prompts were concrete: add a mobile responsive practice room, make the question buttons larger, add an exam card, move the language selector outside the card, use absolute URLs.

Result

The final demo reflects many small changes that stayed coherent because each prompt named a file, a surface, a target behavior, or a working style to reuse.

Tips

  • Say which file owns the change.
  • Use existing UI as the style source.
  • Give exact query strings when links matter.
  • Separate layout requests from data requests.
  • Review the result before adding another feature.

Prompt excerpts that shaped the build

  • Create the multi choose exam practice mobile responsive html page.
  • Desktop layout: left list of questions, right question and answer select area.
  • Mobile layout: top question and answer select area, down list of question buttons.
  • Submit should show correct and wrong answer explanation; next should go to the next question.
  • Use URL query string exam name, chapter, and question to go to the related question.
  • Create a brand new page name index.html as a startup educational tech company official website.
  • Highlight giveaway and show exam topics available on the HTML page.
  • Use navbar hamburger menu and make entire cards behave as links.
  • Add hero image to AWS Exam Library section and use screenshot2.png for mobile.
  • Add new exam cards by following the AWS Certified Data Exam Questions style.
  • Add select language navbar, move it outside the card, translate all pages, and use absolute language URLs.

Shape Trust Before Decoration

Goal

Make the landing page feel credible before adding heavy visuals or complex application architecture.

Prompt

The prompt asked for a startup educational technology official website with modern AWS style, social metadata, a giveaway highlight, exam library entries, and AWS Builder article cards.

Result

The landing page became a trust layer: hero positioning, language selector, giveaway message, exam cards, full-card links, screenshots, article links, and a concise footer.

Tips

  • Use metadata early because sharing is part of the product.
  • Turn cards into links for mobile discoverability.
  • Use one clear highlight message rather than many competing claims.
  • Keep dark mode simple and readable.
  • Let screenshots explain the library faster than copy can.

The key insight is that trust can be engineered. The page does not need animation to feel real. It needs consistent typography, predictable links, clear status labels, and proof that the practice sets are available now.


Keep The Demo Static Until It Hurts

Goal

Avoid unnecessary backend work while validating the learning flow, catalog, localization, and content model.

Prompt

The prompts never required accounts, registration, payments, or server sessions. They asked for links, static HTML, JSON loading, and direct access for AWS builders.

Result

The product stayed deployable as static assets. The browser loads JSON by name, updates the query string, renders questions, checks answers, and shows explanations.

Tips

  • Static first is not simplistic when the state model is clear.
  • Query strings are excellent for shareable learning states.
  • Avoid login until there is a real reason.
  • Do not introduce a build pipeline just to render cards.
  • Let the content files carry the scale.

This is a classic vibe coding win: the prototype ships because the architecture refuses to become more interesting than the user journey.


Turn The Prompt Log Into A Build Map

Goal

Use the prompt history as documentation for what the product became and why each decision exists.

Prompt

The prompt trail records decisions about templates, mobile layout, card links, hamburger menus, language names, translations, absolute paths, exam additions, and practice-room behavior.

Result

That prompt trail is now reusable as onboarding material, QA notes, blog source, and future prompt seed. It explains both the finished demo and the path taken to reach it.

Tips

  • Keep prompt logs near the demo while the idea is still evolving.
  • Summarize each prompt as an intent, not merely a command.
  • Use the log to identify repeatable patterns.
  • When the demo grows, move rough notes into a dev folder.
  • Convert the best prompt patterns into a checklist.

For vibe coding, the log is part of the product. It is not a private accident. It is a record of human direction, AI execution, correction, and shipped behavior.


Field Note 1: prompt compression

Background

The early notes contained long desires: a practice room, a landing page, a giveaway, exam banks, and mobile behavior. The useful move was compressing each desire into one instruction that named the file and the visible change.

Goal

Turn broad intention into a prompt that a coding agent can execute without guessing ownership or scope.

Prompt

Use short deltas such as “index.html add AWS Certified Machine Learning card” or “practice-room.html make mobile buttons larger.”

Result

The product advanced without losing the existing working state because every prompt had a small target and an obvious review point.

Tips

  • Name the file first.
  • Name the expected UI element.
  • Give the exact link or query string.
  • Avoid mixing unrelated layout and content changes.
  • Review before sending the next prompt.

Evidence from the demo

The product advanced without losing the existing working state because every prompt had a small target and an obvious review point. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For prompt compression, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 2: schema-first thinking

Background

The exam content began as template text and PDF-derived material, but the app needed one stable shape before it could scale across topics.

Goal

Make the JSON contract the center of the product so every exam bank can be loaded by the same renderer.

Prompt

Follow the AWS Certified Data question JSON as the template for new exam sets.

Result

The schema became predictable: exam metadata, chapters, question number, question text, options, answer array, answer summary, and explanations.

Tips

  • Treat JSON as an API.
  • Keep answers as arrays.
  • Use option-keyed explanations.
  • Store titles in the data.
  • Reject one-off content formats.

Evidence from the demo

The schema became predictable: exam metadata, chapters, question number, question text, options, answer array, answer summary, and explanations. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For schema-first thinking, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 3: mobile-first review

Background

The first desktop idea was simple: question buttons on the left and answer area on the right. Mobile required a different reading order.

Goal

Make the practice flow usable on small screens before adding visual polish.

Prompt

Mobile version: top question and answer select area, down list of question button area, larger submit and next buttons.

Result

The practice room uses responsive ordering and larger touch targets, which makes the quiz feel intentional rather than merely squeezed onto a phone.

Tips

  • Test the thumb path.
  • Move primary content above navigation on mobile.
  • Increase tap targets.
  • Keep the current question visible.
  • Do not bury the submit button.

Evidence from the demo

The practice room uses responsive ordering and larger touch targets, which makes the quiz feel intentional rather than merely squeezed onto a phone. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For mobile-first review, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 4: dark-mode restraint

Background

The user asked for dark mode and simple design without decoration. That constraint protected the demo from over-styled output.

Goal

Use a restrained visual system that supports focus, long reading, and quick answer review.

Prompt

Page design: dark mode, simple without any decoration.

Result

The final pages use muted borders, readable contrast, compact cards, and AWS-like orange accents without unnecessary animation.

Tips

  • Use color sparingly.
  • Make text contrast the priority.
  • Prefer borders over heavy shadows.
  • Keep forms calm.
  • Let content carry the page.

Evidence from the demo

The final pages use muted borders, readable contrast, compact cards, and AWS-like orange accents without unnecessary animation. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For dark-mode restraint, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 5: marketing hooks

Background

The official page needed to explain why a visitor should care before they clicked a practice link.

Goal

Turn the giveaway and exam library into a clear hook without hiding the product behind registration.

Prompt

Highlight Giveaway: Free access to AWS Certified Data, Generative AI, Machine Learning, Cloud Operations, Networking, Financial Service Trading Desk on AWS.

Result

The hero makes the value obvious, and the exam grid immediately shows available practice sets.

Tips

  • Say what is free.
  • List recognizable topics.
  • Put the call to action near the hook.
  • Avoid vague platform language.
  • Let direct links prove the claim.

Evidence from the demo

The hero makes the value obvious, and the exam grid immediately shows available practice sets. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For marketing hooks, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 6: card consistency

Background

Every new exam card could have drifted in style, wording, and behavior. Reusing the Data card prevented that.

Goal

Make catalog growth boring: add new topics without redesigning the library.

Prompt

Add AWS AI Development Exam Questions, follow AWS Certified Data Exam Questions style, with link aws_ai_development_exam_questions&chapter=1&question=1.

Result

New exam topics entered the grid as available cards with consistent status labels, descriptions, and tap cues.

Tips

  • Copy the proven card shape.
  • Change only title, description, and link.
  • Keep status language identical.
  • Use full-card links.
  • Verify the target JSON exists.

Evidence from the demo

New exam topics entered the grid as available cards with consistent status labels, descriptions, and tap cues. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For card consistency, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 7: iteration logs

Background

The prompt trail shows many small corrections: change text, move elements, add cards, translate pages, and convert URLs.

Goal

Use the build history as a product map, not as disposable chat residue.

Prompt

Keep refining by naming the latest behavior that needs adjustment.

Result

The notes became a reliable source for writing technical explanations and reconstructing product decisions.

Tips

  • Record intent, not just output.
  • Group related prompts mentally.
  • Look for repeated instruction patterns.
  • Turn corrections into rules.
  • Use the trail for QA.

Evidence from the demo

The notes became a reliable source for writing technical explanations and reconstructing product decisions. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For iteration logs, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 8: no-build static deployment

Background

The project never needed a backend to prove the learning loop. Static files were enough for the landing page, localized pages, JSON banks, and quiz player.

Goal

Ship a useful demo with the smallest deployment surface.

Prompt

Create HTML pages and JSON files inside the exam-practice-room folder.

Result

The demo can run as static assets: the browser handles fetching, rendering, answer checking, and navigation.

Tips

  • Prefer static until state demands a server.
  • Keep filenames meaningful.
  • Use query strings for deep links.
  • Avoid build tooling for simple pages.
  • Let static deployment simplify debugging.

Evidence from the demo

The demo can run as static assets: the browser handles fetching, rendering, answer checking, and navigation. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For no-build static deployment, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 9: question-guide grounding

Background

The question guide introduced validity, reliability, fairness, plausible distractors, active voice, and cognitive complexity.

Goal

Use exam-writing standards to keep AI-generated practice questions from becoming shallow trivia.

Prompt

Follow question guide and upgrade the practice set to professional level.

Result

The content model preserved option-level rationales and made each explanation part of the learning value.

Tips

  • Write plausible distractors.
  • Avoid trick wording.
  • Use active voice.
  • Match role and cognitive level.
  • Explain why the key is right.

Evidence from the demo

The content model preserved option-level rationales and made each explanation part of the learning value. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For question-guide grounding, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 10: direct access

Background

The marketing brief said no credit card, no registration, and direct website links for builders.

Goal

Remove friction between the reader and the practice experience.

Prompt

Directly provide the website link for every AWS builder; no credit or registration needed.

Result

Every available card links straight into a practice-room query state.

Tips

  • Do not over-gate free value.
  • Make the first click useful.
  • Open on a real question.
  • Avoid modal interruptions.
  • Use links that can be shared.

Evidence from the demo

Every available card links straight into a practice-room query state. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For direct access, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 11: hero image discipline

Background

The exam library needed visual proof, but the original social banner section became unnecessary noise.

Goal

Use screenshots to explain the product surface while removing decorative sections that do not help users act.

Prompt

Add hero image to AWS Exam Library section: screenshot.png; for mobile use screenshot2.png.

Result

The library section gained responsive imagery while unrelated banner copy was removed.

Tips

  • Use product screenshots as evidence.
  • Optimize for desktop and mobile aspect ratios.
  • Remove duplicated visual claims.
  • Keep alt text meaningful.
  • Do not let images replace clear links.

Evidence from the demo

The library section gained responsive imagery while unrelated banner copy was removed. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For hero image discipline, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 12: hamburger navigation

Background

The page needed the same compact navigation pattern on desktop and mobile, rather than separate mental models.

Goal

Make navigation predictable and compact across viewports.

Prompt

Use navbar hamburger menu; change to mobile navbar on desktop and mobile version.

Result

The header uses a menu button that toggles section links and closes after a link is selected.

Tips

  • Use aria attributes.
  • Keep nav labels short.
  • Close menus after selection.
  • Avoid separate desktop-only nav logic.
  • Make the brand remain visible.

Evidence from the demo

The header uses a menu button that toggles section links and closes after a link is selected. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For hamburger navigation, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 13: language selector placement

Background

The selector first lived inside the hero card, but that made it feel like card content instead of global navigation.

Goal

Move language choice to a standalone control before the hero message.

Prompt

Change the select language out of card as standalone element.

Result

The selector now sits above the card, clearly acting as a page-level control.

Tips

  • Global controls should not look like article body content.
  • Place language choice early.
  • Keep labels simple.
  • Preserve selected state.
  • Test one localized page after moving it.

Evidence from the demo

The selector now sits above the card, clearly acting as a page-level control. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For language selector placement, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 14: absolute path instruction

Background

Relative language links worked locally, but public pages need predictable destinations from any route.

Goal

Make language redirects reliable after deployment.

Prompt

For all language options, use absolute path index_{lang_code}.html style deployed URLs.

Result

Every language option uses a deployed target, while the blog avoids naming the public domain directly.

Tips

  • Use one base URL pattern.
  • Update every page, not only English.
  • Verify selected values survive.
  • Search for remaining relative values.
  • Keep English in the selector too.

Evidence from the demo

Every language option uses a deployed target, while the blog avoids naming the public domain directly. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For absolute path instruction, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 15: translation audit

Background

The first translated pages still contained English in body sections. The user asked to double check the whole page.

Goal

Treat localization as content QA, not only generation.

Prompt

Double check all localized pages; the entire content page is translated.

Result

Visible sections, card descriptions, research notes, and footer text were updated across language pages.

Tips

  • Search for English leftovers.
  • Inspect RTL pages separately.
  • Translate body copy, not only menus.
  • Keep product names recognizable.
  • Review representative scripts.

Evidence from the demo

Visible sections, card descriptions, research notes, and footer text were updated across language pages. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For translation audit, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 16: exam library scale

Background

The folder includes large banks like FSI trading desk, cloud operations, machine learning, networking, AI development, and generative AI.

Goal

Make the landing page communicate catalog breadth without overwhelming the hero.

Prompt

List exam topics on the HTML page and add cards following the existing style.

Result

The catalog became a scan-friendly grid where every available topic has a consistent entry point.

Tips

  • Group topics in a grid.
  • Use three cards per desktop row.
  • Keep descriptions parallel.
  • Mark future topics clearly.
  • Avoid mentioning raw JSON to users.

Evidence from the demo

The catalog became a scan-friendly grid where every available topic has a consistent entry point. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For exam library scale, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 17: founder-to-instructor wording

Background

The page originally used co-founder language, then shifted toward course instructor positioning.

Goal

Align personal branding with the learning experience rather than startup biography.

Prompt

Change co-founder to course instructor.

Result

The trust card now supports the educational product without distracting from practice access.

Tips

  • Match identity to user intent.
  • Keep the profile card tappable.
  • Avoid overlong biography.
  • Use role language consistently.
  • Let articles provide depth.

Evidence from the demo

The trust card now supports the educational product without distracting from practice access. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For founder-to-instructor wording, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 18: prompt specificity

Background

The best prompts had exact words to replace, exact links to use, or exact layout behavior to implement.

Goal

Reduce AI ambiguity by supplying measurable details.

Prompt

Change Explore Exam JSON Library to Explore AWS Exam Library; change AWS Learning Forge to Exam Practice Room.

Result

Text changes became fast and low-risk because the desired output was explicit.

Tips

  • Quote exact strings.
  • Provide replacement text.
  • Avoid “improve copy” when a term matters.
  • Check UI text after edits.
  • Keep naming consistent.

Evidence from the demo

Text changes became fast and low-risk because the desired output was explicit. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For prompt specificity, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 19: small correction loop

Background

Several requests corrected previous placement, wording, or link behavior rather than asking for a rewrite.

Goal

Use correction prompts to steer a working system without losing progress.

Prompt

Move the language selector, add English, remove domain mentions, remove direct dev-note filename mentions.

Result

The files evolved in place and preserved the working demo while matching new publishing constraints.

Tips

  • Prefer patching over rewriting.
  • State the forbidden phrase.
  • Run a search after removing terms.
  • Preserve useful structure.
  • Keep final files publication-safe.

Evidence from the demo

The files evolved in place and preserved the working demo while matching new publishing constraints. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For small correction loop, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.


Field Note 20: reader-first outcome

Background

The final product is not just code; it gives builders direct study links, clear feedback, multilingual access, and visible trust signals.

Goal

Judge vibe-coded work by reader outcomes instead of tool novelty.

Prompt

Create tech blog posts to show vibe coding dev tips based on the demo.

Result

The article series can explain how prompts became product decisions and how each shipped detail helped the learner.

Tips

  • Tie every tip to a user behavior.
  • Use the demo as proof.
  • Avoid private implementation details.
  • Share repeatable prompt patterns.
  • End with checks builders can reuse.

Evidence from the demo

The article series can explain how prompts became product decisions and how each shipped detail helped the learner. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.

Review check

For reader-first outcome, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.