🖼️ Interfaces: the agent that can see

"New here? The front end is the visual part of a website or app — the buttons, colors, text, and layout that appear on screen. The opposite is the back end, which runs hidden on the server." The agent writes both, but the front end is what the client/user judges first.

Without this clear term, the rest of the learning path (“design skill,” “screenshot”) doesn’t make sense—front end is the target of everything that follows.

Front end, back end, what the user sees versus what runs behind the scenes.

The agent learned by seeing millions of pages on the internet. Without specific direction, it reproduces the most common pattern — which tends toward the average, not the exceptional.

Understanding the cause helps avoid frustration: it’s not “the agent is bad at design,” it’s “it needs direction, just like a new intern.”

Regression to the mean, lack of direction, “AI feel” as a symptom.

Light gray on dark gray, generic shadows, overly rounded corners, a rocket/star icon on everything, purple-blue gradients—the “visual signature” anyone can recognize from a distance as AI-generated without curation.

Knowing how to recognize the symptom helps you ask for a specific fix instead of saying “make it prettier” (which doesn’t help the agent decide anything).

Recognizable patterns, specific vs. vague feedback.

By default, the agent reads and writes text (code); it doesn’t open the page in a browser to “look at” the result unless you — or an extra tool — explicitly ask it to.

It's this gap that modules 5.2 and 5.3 close: giving the agent taste instructions (a design skill) and vision (a screenshot loop).

Writing code blind, with no visual feedback by default.

Without anything, the result gets about 40% of the way to “looking professional.” With a design skill and a screenshot feedback loop, it gets close to 60%. The final 40% requires human taste—it isn’t a bug to fix; it’s your job.

Realistic expectations help you avoid two pitfalls: giving up too soon ("you can’t make it look good") or trusting too much ("the agent will handle it on its own").

Partially automatable gains, structural limits, and the role of human judgment.

Design skill → screenshot loop → loop limits → visual reference/rebranding → brand folder → published landing page build → publishing rules.

Seeing the complete path helps you understand why each module exists before you get to it.

Progression: shape taste, provide vision, test limits, apply branding, publish with rules.

One skill is an instruction file that the agent loads when your request matches it (covered in Track 3). A design skill stores your visual preferences for every front-end project.

Without this, you rewrite “use muted colors, clean typography” in every new conversation—the skill eliminates that repetition.

Skill, reuse across projects, preference memory.

Preferred color palette, approved fonts, spacing rules ("never crowd elements together"), visual tone (serious, playful, corporate), and what to avoid (purple-blue gradient, rocket icon).

The more specific the instruction, the less likely the agent is to fall back on the generic average from module 5.1.

Palette, typography, spacing, list of "don’ts".

A "global" design skill lives in a folder that applies to all your projects; a "project" skill lives only in that specific repository (covered in depth in Track 3.5).

Your personal taste (such as the typography you like) is global; a specific client's brand is project-specific.

Global scope, project scope, when to use each.

Objective: generate the skill file with your design preferences. Copyable block: "Crie uma skill global chamada 'meu-design' com estas preferências: paleta <suas cores>, fonte <sua fonte>, tom <sóbrio/divertido>. Evite gradiente genérico e ícones de foguete." How to verify: ask the agent to list the contents of the skill file it created and check that they match what you requested.

This is the practical example that brings together the theory from the previous topics in a result you can use today.

Skill creation prompt, verification of the generated file.

Each time you correct something that went wrong, it’s a good idea to go back to the skill and add that rule — "never use this background color with this text," for example.

The skill gets better with each project; without this habit, you repeat the same mistake every time.

Iteration, accumulated learning, incremental editing.

The skill gives guidance on style, but the agent still writes blind — it can’t see the result. It’s missing the visual verification step, which is the subject of the next module.

Understanding this gap helps you avoid thinking the skill solves everything—it’s half the solution.

Instruction and verification, the two halves of the solution.

One local server is a little program that displays the page only on your computer (an address like localhost)—like a rehearsal before you publish it for the world to see.

This is the first step in the loop: without starting this server, there’s no page to take a screenshot of.

Local server, localhost, a testing environment.

One screenshot is a photo of the screen at that moment. With the right tool (an automated browser), the agent takes this photo of the page it just built.

It's this snapshot that turns “writing code blindly” (module 5.1) into “seeing the result before delivering it to you.”

Screenshot, automated browser, visual feedback.

The agent compares the screenshot against a "target": it could be the design skill (module 5.2), a reference image (module 5.5), or a descriptive checklist ("readable text, aligned buttons, space between sections").

Without a clear target, “compare” becomes a vague opinion—the target is what makes the correction objective.

Comparison target, objective criteria, visual checklist.

After making a correction, the agent starts the server again, takes another screenshot, compares again — repeating until it meets the criterion or runs out of a reasonable number of attempts.

This repetition is what separates a result that’s "first try, no review" from one that’s "checked before being delivered to you."

Iteration, the build-test-fix cycle, attempt limit.

Objective: have the agent build and visually verify a page on its own. Copyable block: "Crie uma landing page para <seu produto>. Suba um servidor local, tire um screenshot, compare com a skill de design e corrija até ficar consistente antes de me mostrar." How to verify: ask the agent to send you (or describe) the final screenshot and check that it matches the request.

This is when the theory from modules 5.1 and 5.2 turns into action—the loop running from end to end.

Full-loop prompt, verification of the delivered result.

The skill (taste) + loop (vision) together catch major errors: clipped text, misplaced buttons, poor contrast — but they can't decide on their own whether something is truly "beautiful."

Prepares you for module 5.4, which explains exactly what the loop doesn’t solve.

Gross errors vs. fine judgment, automatable gains.

Text clipped from the box, overlapping elements, a button without enough space to click, color contrast that makes reading difficult—things you can check objectively in the image.

Knowing the loop’s strengths keeps you from dismissing it — it really does solve a large share of annoying errors.

Objective, rule-checkable error; structural break.

"Does this color fit the brand?", "does this spacing look elegant or empty?", "does this text sound trustworthy?" — subjective questions that depend on context, audience, and human sensibility.

This is exactly the slice left for you—the “final 40%” mentioned in module 5.1, explained here in detail.

Subjective judgment, brand context, human sensitivity.

Without a clear target (module 5.3), the agent may get stuck trying to satisfy a vague criterion and never stop—that’s why it’s always worth agreeing on a maximum number of attempts.

Avoids wasting time and money on a loop that never converges.

Loop without a stop condition, attempt limit, or cost control.

A page may look good at the tested screen size and break on a phone or a large screen — the loop only checks what was actually captured.

Leads you to explicitly request screenshots at more than one size when the result really matters.

Responsiveness, multiple screen sizes, test coverage.

Even after the loop runs and “approves” its own result, the verdict on whether it’s “good to publish” is still yours—the agent reduces the work, but doesn’t replace your final decision.

Wraps up the track’s honest standard: automation helps, but it doesn’t remove your responsibility to review the result yourself before publishing (direct connection to module 5.8).

Final human approval, with automation reducing effort rather than replacing judgment.

One way to reduce the subjectivity of module 5.4 is to show, rather than describe, what you want — by giving the agent a reference image.

This is the lead-in to the next module, which teaches this exact technique.

Showing vs. describing, reference image.

"Minimalist and elegant style" means different things to different people; a reference image removes that ambiguity all at once.

It's the fastest way to reduce the gap between what you imagine and what the agent delivers.

Language ambiguity, visual reference as an anchor.

Most coding agents accept an image attached to the conversation or the path to a PNG/JPG file saved in the project — the agent "reads" the image along with the request.

Without knowing the mechanism, the technique of “showing” remains just theory.

Attach an image, file path, multimodal reading.

Design gallery sites, a competitor you admire, or even a screenshot of your own older material — any real image that captures the desired style.

Having a set of ready-to-use references speeds up any future design request.

A collection of references, personally curated.

"Rebranding" means updating the visual identity of something that already exists — the same visual reference works here: show the new direction and ask for it to be applied to what's already done.

You rarely start from scratch — most of the time, you're updating something that already exists.

Rebranding, an update based on what already exists.

Objective: guide the result with an image instead of just words. Copyable block: "Anexei uma imagem de referência (<caminho da imagem>). Recrie o layout dessa referência para <seu conteúdo>, mantendo a mesma sensação visual — cores, espaçamento e tom." How to verify: compare the final screenshot side by side with the attached reference.

It's the direct application of the “show, don't tell” technique with a verifiable result.

Prompt with attachment, side-by-side comparison.

A style reference (“this visual vibe”) is different from copying another brand’s content, logo, or identity—asking for inspiration is different from asking for a clone.

Protects you from a legal and ethical problem before you publish anything.

Inspiration vs. copying, third-party identity.

A folder inside the project (or a global one) with the logo files, exact color palette, and fonts used — the single source of truth for your visual identity.

Without it, every new project reinvents the logo or brand color from memory—and gets it wrong.

Single source of truth, brand assets, consistency.

Save the exact color code (like #0d9488) instead of “that teal-ish green” — the agent uses the right value without guessing.

A “close enough” color subtly but visibly breaks brand consistency for anyone who knows the brand.

Hex color code, precision vs. approximation.

Exact font name (and where to download it), plus ready-to-use logo versions (light background, dark background, icon only) so you don’t have to recreate them.

Avoids the agent “making up” a similar source or distorting the logo while trying to recreate it from scratch.

Exact font name, ready-to-use logo variations.

The design skill (module 5.2) can point directly to the brand folder — that way, personal taste (skill) and a specific client’s identity (folder) work together without conflict.

Wraps up the architecture: the global skill provides the "how to do it," and the brand folder provides the "what to use."

Skill referencing a folder, separating taste from identity.

Objective: organize your brand assets in one place you can consult. Copyable block: "Crie a pasta 'marca/' com um arquivo marca.md listando: cor primária <hex>, cor secundária <hex>, fonte principal <nome>, e onde estão os arquivos do logo." How to verify: open the generated file and check that all the values match yours.

Turns the theory from previous topics into a folder you use in the next build module.

File marca.md, checking values.

With a design skill, screenshot loop, visual reference, and brand folder ready, you have everything you need to build and publish a real landing page.

Marks the transition from theory to the hands-on project that wraps up the track.

Tools ready, transition to the build.

"Landing page" is a single presentation page (for a product, service, or personal project): typical sections include a header, what it is, how it works, and a call to action.

Defining the scope before asking avoids back-and-forth — the agent knows exactly how big the project is.

Landing page, typical sections, defined scope.

Before requesting the build, check that the design skill (5.2) is active, the brand folder (5.6) is ready, and you have a visual reference (5.5) on hand, if you want one.

Bringing the inputs together first prevents asking for the build “halfway” and having to fix it later.

Inputs checklist, preparation before the request.

Objective: build the entire landing page in a single well-formed request. Copyable block: "Usando a pasta 'marca/' e a skill de design, crie uma landing page para <seu produto/projeto> com seções: topo, o que é, como funciona, chamada para ação. Suba servidor local, tire screenshot, compare com a skill e corrija antes de me mostrar." How to verify: look at the final screenshot and check that all 4 sections are present and the branding has been applied.

This is the exercise that brings together everything the learning path has taught so far in a tangible result.

Complete request, verification with a section checklist.

After the agent approves its own loop, it's your turn: review the result carefully and ask for specific adjustments based on your taste (not “make it better,” but “this background color feels too heavy”).

It's the practical application of the limit explained in module 5.4—fine judgment is yours.

Specific feedback, final human review.

Deploy is the process of taking the page from "rehearsal" on the local server and putting it live at an address anyone can access — a topic covered in more depth in Track 4.

The landing page only serves its purpose when someone outside the project can access it.

Deploy, public address, connection to Track 4.

The build is ready when it’s live, has no major visual errors, has the brand applied, and you—not the agent—sign off that it’s good.

Without a stopping criterion, perfectionism stalls the project—and module 5.8 details the rules before you actually publish.

Completion criterion, to avoid paralyzing perfectionism.

Even if you can delete a page later, someone may already have seen, saved, or shared it—publishing is, in practice, a one-way action.

Explains why this track ends with explicit rules instead of leaving things to common sense.

One-way action, caution before the irreversible.

The same technique as Track 0.4: write "nothing goes live without my explicit approval" in the project’s CLAUDE.md so the agent reads it every time, in every new session.

A rule spoken once gets lost; a written rule is read in every new conversation.

Persistent rule, CLAUDE.md, explicit approval.

Before approving: review the final screenshot, check spelling and links, confirm that no personal or sensitive data appears by mistake, and test at least one other screen size.

An objective checklist keeps you from approving something with a quick glance.

Review checklist, sensitive data, multiple sizes.

Confirm that no password, API key, or private information was visible in the code on the published page (the topic "Secrets," Track 4.4).

A beautiful page with a leaked secret is worse than an ugly page without a leak — security checks come before aesthetics.

Secret leak, priority over aesthetics, connection to Learning Path 4.

Objective: permanently establish the approval rule in the project. Copyable block: "Adicione ao CLAUDE.md a seção: 'Publicação — nunca fazer deploy ou publicar qualquer página sem antes me mostrar o resultado e receber minha aprovação explícita.'" How to verify: open CLAUDE.md and confirm that the section was added, word for word.

This is the final exercise that permanently locks in the learning path’s most important rule.

Permanent rule in the file, literal text verification.

With a visual interface built, verified, and published under clear rules, Track 6 shifts the focus from “what the agent builds” to “when the agent works on its own, without you asking.”

Wraps up the track with a clear next step — scheduling and loops.

Track transition, from "building" to "scheduling".