Design engineering with AI

Design engineering is the work between a design and the software that ships. For years it meant handing over a picture and hoping it survived the build. With AI coding agents, a designer can describe the intent, let the agent write the code, and judge the result where it matters: in the browser, on a phone, with real states.

The speed is real, and so is the risk. An agent writes plausible code as fast as it writes good code. The craft moves from drawing to directing and checking.

Five rules I give to every coding agent I use, whatever the project.

--one-set-of-instructions

Every agent I use reads the same instructions and the same skills: my product principles, my design rules, my safety rules. Switching tools does not mean starting over.

--small-verified-steps

Small changes, each checked in the browser and saved, rather than a large rewrite checked at the end.

--never-trust-the-output

Whatever a model returns is validated: data checked against a schema, a timeout and a fallback on every call, prompts versioned like code.

--design-checks-in-the-loop

A design linter and a critical review run before anything ships, so speed does not slide into generic interfaces.

--test-like-a-user

Start from the screen people actually land on, then the keyboard, the phone, the empty and error states. Never a shortcut URL or prepared data.

Kawi

Kawi teaches Luxembourgish to children. I designed and built it with AI coding agents: the mobile app, its website and its videos. It is a real product with real users, which is the only honest test of a way of working.

This site

This site was designed and built the same way. The portrait beside this text started as a photograph; the turned poses and the helmet were generated, cut out on my own machine, then printed in characters by a small script. The page is checked by a design linter before each release.

The starting point is no longer always a mockup to hand over. I can build a first working version, test it in the browser, check the interactions and adjust the details before a developer is even involved.

That changes the nature of the collaboration. I arrive with something that already works, but also with sharper questions. The developer can focus earlier on what needs their expertise: architecture, data, security, robustness and integration with the existing system.

Generated code is not a deliverable in itself. It is a concrete starting point to discuss, test and decide together.

A prototype can look perfectly functional while resting on the wrong assumptions. That is exactly the point of working this way: making problems visible earlier, while they are still easy to fix.

An agent can produce code that looks clean, pass the main scenario and fail as soon as conditions change. It can mishandle an error state, forget an access check or introduce an inconsistency in a part of the product that seemed unrelated to the change.

I check the result in the browser, test the real journeys and ask for changes step by step. But these checks replace neither a thorough code review nor an architecture review.

I hand over to an engineer as soon as the problem goes beyond what I can seriously verify: security and permissions, data migrations, concurrency, complex integrations, performance at scale, or structural changes to the system.

My goal is not to replace technical expertise. It is to go further on my own, explore more options, and arrive with a better-understood problem, a testable prototype or a hypothesis already put to the test.

Speed is only worth something if you know what has been checked, what remains uncertain, and when to call on another kind of expertise.

• steven-lozach(1), who I am and what I do
• ai-designer(7), the job, in Luxembourg
• kawi(1), learning Luxembourgish for children