Elegant

Where AI actually fits in the frontend development lifecycle

The Elegant team 5 min readai-and-frontend
Where AI actually fits in the frontend development lifecycle

AI is not a single feature you bolt onto the end of development. It shows up at every stage of the lifecycle — scaffolding, implementing, reviewing, testing, documenting — and it has a very different competence profile at each. It is excellent at generating boilerplate and terrible at deciding whether behaviour is correct; strong at drafting a component and weak at holding your architecture in mind. Using AI well is not “adopt AI”; it is knowing, stage by stage, where to lean on it and where to keep it on a short leash. Get that map wrong and you either leave value on the table or ship confident-looking bugs.

AI's competence varies by lifecycle stage Stages across the lifecycle — scaffold, implement, review, test, document — each marked as a strength (green) or a caution (orange) for AI. scaffold✓ strong implement✓ with a spec review⚠ assist only test⚠ no oracle document✓ good draft
Same tool, different competence per stage: lean on it to scaffold, implement (with a spec) and document; keep it assistive for review and testing, where "correct" is a human call.

Where to lean on it: scaffold, implement, document

At the front of the lifecycle AI is a genuine multiplier. Scaffolding — a component shell, a reducer skeleton, a test file’s structure — is repetitive and low-risk, exactly the model’s strength. Implementation is strong when you hand it a boundary: a precise spec produces good code, a vague ask produces plausible mush. And documentation — a first-draft README, JSDoc, a changelog — is a solid starting point you edit rather than write from scratch:

"Scaffold a FormField molecule in src/ui/molecules/: label + input + error,
 takes { label, id, error, ...inputProps }, no store access, no fetch."
→ a strong first draft, because the boundary was drawn in the prompt

Where to keep it on a leash: review and testing

Two stages are dangerous to hand over, and for the same reason: they require a notion of correct the model does not have. In review, AI can flag surface issues but cannot judge whether an abstraction is right or a boundary was crossed — treat it as a second pair of eyes, never the deciding one. In testing, the trap is sharper: ask a model to write tests for existing code and it will assert that the current behaviour, bugs included, is correct, because it has no oracle for what the code should do:

// AI "test" for buggy code — it enshrines the bug as the expected value
expect(discount(100, "SAVE10")).toBe(100);   // should be 90 — but the model asserts the bug

You supply the oracle; the model supplies the scaffolding around it.

The map is the skill, and the guardrail is the safety net

Knowing this competence map — lean on scaffold/implement/document, stay in control of review/test — is most of using AI well, but it is not enough on its own, because the map tells you where the risk is, not how to catch it when you’re moving fast. That is what the guardrail is for: encode the architecture and quality rules as checks so the “dangerous” stages have a machine backstop. A model that erodes a boundary during implementation trips a lint rule; a test suite that would pass a broken component fails a real assertion you wrote. AI across the lifecycle plus a guardrail is the combination that lets you move at the model’s speed without shipping at the model’s error rate. The harness-skill-eval and harness-a11y-gate exercises build exactly the backstops the review and test stages need, which is where the map becomes a working process.