Look Under the Hood Without Opening the Hood

Why this matters

You will never need to read the code your AI wrote, but knowing the NAMES of the parts it built makes you a dramatically sharper director. When you know that an app is made of pages, components, styling, and hosting, you can aim your change requests precisely — 'change the styling on the header component' instead of 'make the top part look different'. The fastest way to learn this vocabulary without cracking open code is to ask the AI to describe its own build in plain language, which it does happily. Picking up these words now is what makes the later modules of this course — where you steer more complex apps — feel like giving directions instead of guessing.

Demo

You do not open a code editor. You ask the AI to explain itself. Paste this into your builder's chat: 'In plain language with no code, describe the parts you built for this app: what pages or screens exist, what the main reusable pieces (components) are, how the styling and colors are handled, and where the data is stored. Keep it to a short list a non-coder can understand.' For the habit tracker it answers something like: 'PAGES: there is one page, the main tracker screen — no other screens. COMPONENTS (reusable pieces): a HabitRow that shows one habit with its checkbox and note, reused for every habit in your list; a Header showing the date and the done-counter; an AddHabit button and input. STYLING: colors and spacing are set with a utility styling system (Tailwind), with your teal for checked habits and navy for the header defined in one place so they stay consistent. DATA: your habits are saved in the browser's local storage on your device, which is why they persist when you reload but are not yet shared across devices. HOSTING: the whole app is published to a Lovable server at your .lovable.app address.' Now you have the map: PAGES (screens you navigate between), COMPONENTS (repeated building blocks like a row or a card), STYLING (the colors, fonts, spacing rules), DATA (where information is stored), and HOSTING (the server that serves it). With these five words you can direct future changes like a pro: 'the data should be stored in a shared database, not just my browser' or 'make the HabitRow component taller with more padding'. Same tool, far sharper aim.

Try it yourself

1. Paste the 'describe your build in plain language, no code' prompt into your app's chat and read the answer.
2. From the answer, list the five parts — pages, components, styling, data, hosting — and write one sentence for each about how YOUR app handles it.
3. Find where your app stores its data (browser local storage vs a real database) and note the practical consequence — for example, whether your data would survive on a different device.
4. Rewrite one vague change request you made earlier ('make the top look different') using the correct part name ('restyle the Header component').
5. Save this five-part summary of your app in your notes — it is the vocabulary you will use to steer bigger builds in later modules.

References

• MDN — HTML, CSS, and JavaScript explained
• MDN — Web storage / local storage
• Lovable docs — how projects are structured