🚧 Loop limits

New here? One screenshot is a still photo of the screen at an exact moment—frozen pixel by pixel. It’s the basis of the loop you learned in module 5.3: the agent takes the photo, compares it with what should be there, and adjusts the CSS until they match.

Imagine asking someone to judge whether a dance looked good by comparing two photos: one from the start of the movement, and another from the end. You’ll see the two arm positions — but you won’t see the trajectory, the speed, whether the motion was smooth or choppy, and whether the timing matched the music. That’s exactly the limitation of the screenshot loop: it shows states, never the transitions between them.

Caption: the two photos (beginning and end) are all the screenshot loop can see. Everything that happens between them — the motion curve — remains invisible to an image comparison.

Before talking about what’s missing, let’s reinforce where the loop works well—because the lesson in this module isn’t “don’t trust the loop,” it’s “know where it stops.” Everything that is static visual state (the appearance of the screen at a single frozen moment, without considering what came before or after) the loop compares pixel by pixel.

New here? CSS animation is a gradual change in a visual property (position, color, size) over time, controlled by the browser. Hover is an element's state when the mouse passes over it — usually triggering a transition. Parallax it’s the technique of moving background layers at different speeds from the scrolling, creating a sense of depth.

There are two families of things that escape the loop:

Caption: the moving dot (pulsing cyan point) follows a smooth curve — but the two cameras capture only the beginning and the end. The “middle” of the motion, where the easing happens, never becomes an image.

It’s not a lack of effort from the agent—it’s a tool limitation. The automated screenshot captures the screen at a single instant (a frame, a still frame). To actually “see” motion, you’d need to capture a sequence of frames over time and then interpret the differences between them — much more expensive, slower, and still harder to judge as “good-looking” or “ugly” than comparing two images.

When the piece is about movement, the solution isn't to insist on more screenshots — it's to change methods: ask the agent (1) to read the exact CSS values that control the movement (duration, easing, delay), (2) to explain what each value does in simple terms, and (3) to open the actual browser so you can watch the movement happen live, instead of relying only on automatic image comparison.

Preciso que você ajuste a animação do botão ""
no arquivo .

Antes de mexer, faça isto:
1. Leia o CSS atual da transição/animação desse elemento e me diga, em português simples,
   qual é a duração, o easing e o delay usados hoje.
2. Não confie só em screenshot pra validar o resultado. Depois de editar, abra o navegador
   de verdade (ou peça pra eu abrir) e descreva o que observou no movimento ao vivo:
   ficou suave? ficou rápido demais? travou (jank) em algum ponto?
3. Só then ajuste o valor - o objetivo é .

Ao final, me diga exatamente qual linha de CSS mudou e por quê.

Let’s end with the number that will follow you through the rest of this learning path: the screenshot loop takes a front end from generic a solid — something like the first 60% of the way to “professional.” The last 40%—motion, timing, “feel,” the difference between looking like an expensive product and looking like a template—still depends on someone looking at the screen and making decisions. That boundary isn’t a flaw in the loop; it’s where AI’s work on its own ends and human judgment begins.

Caption: the bar shows the 60% the automated loop handles well (visual state) and the final 40%, where motion and timing require someone to actually look at the screen.