My design process is becoming AI-native

I used to think of design as a sequence of artifacts.

You understand the problem. You explore some directions. You make a design. You hand it over. Someone builds it. Then you look at what was built.

That model made sense when the distance between design and implementation was large. It makes less sense now.

Over the last couple of years, the way I work has changed quite a bit. Not because I decided to become an AI designer, or because I replaced my design tools with an AI tool. It happened more gradually.

I started using AI to get closer to the thing I was designing.

Sometimes that means generating code from an idea. Sometimes it means asking it to modify an existing implementation. Sometimes it means exploring several approaches quickly, running them in a browser, and throwing most of them away.

The important part isn't the AI itself. It's that the distance between thinking about an interface and interacting with the interface has become much smaller.

The browser became part of the design toolset

For a long time, Figma was where I could make decisions about an interface. The browser was where those decisions eventually became real.

Now, increasingly, I move between the two.

I'll still use Figma when I need to think through a visual system, communicate an idea, or work at a level where implementation details would get in the way.

But there are things that are simply faster to discover in the browser.

Does this interaction actually feel right? Does the layout survive a real viewport? What happens when the content is longer than expected? Does the animation still make sense when you actually scroll through the page? Does the hierarchy work when the surrounding page exists?

Those questions are difficult to answer from a static frame.

AI has made it much cheaper for me to get from an idea to something I can actually run. That changes the design process.

From making artifacts to running experiments

One of the biggest changes for me is that I don't always need to know exactly what the final design should be before I start building it.

I can make a rough version, run it, look at it, change it, and run it again. Sometimes the first implementation teaches me more than an hour of designing the perfect frame.

This is also why I've become more interested in things like CI, deployment, browser testing, accessibility checks and visual regression. They used to feel like concerns that happened *after* design.

Now I see them as part of the feedback loop.

A design that looks good in a static frame but breaks at a different viewport isn't finished. A component that looks correct but fails accessibility checks isn't finished. A page that works locally but falls apart in production isn't finished.

The actual product is the test.

This is where Lint UI came from

Lint UI started from a pretty simple frustration.

If we're increasingly using AI to generate and modify interfaces, we need better ways to check the result.

Not just whether the code compiles, but whether the interface actually holds together.

That's why Lint UI combines things like browser automation, visual regression and accessibility checks.

The interesting part for me isn't just building another developer tool. It's using the tool while building the thing itself.

The product is being shaped by using it.

That creates a loop I didn't have in quite the same way before:

design → build → run → inspect → detect problems → change → repeat

AI makes the building part faster. The validation loop tells me whether the result is actually better.

Those are different things.

AI doesn't replace the part I care about most

There is a temptation to describe this as AI doing the work of the designer. That's not how it feels to me.

AI is very good at producing possibilities. It can write the component, restructure the page, suggest an implementation, or modify ten things that would have taken me an afternoon.

But it doesn't remove the need to decide whether any of those things are good.

In fact, I think it makes judgment more important.

When producing something is expensive, you naturally become protective of what you've already made. When producing another version is cheap, you can be much more critical.

That's a useful change.

I'm less attached to the artifact because I can change it.

Codiga taught me some of this before AI

Looking back at the work I've done on products like Codiga, I was already moving toward this way of working.

I wasn't comfortable staying entirely on one side of the design/engineering boundary. I'd design the interface, but I also wanted to understand how it behaved in the application.

I'd care about the interaction, but also the constraints that made the interaction possible. I'd work on the system, then go back and change the design because implementation exposed something I hadn't considered.

The tools have changed. The underlying instinct hasn't.

AI has simply made crossing that boundary much faster.

The new design loop

The process I'm finding myself in looks something like this:

Understand → Make → Run → Inspect → Change

AI sits inside that loop. It doesn't define the loop. It accelerates some parts of it.

The rest still depends on taste, judgment, technical understanding and, most importantly, actually looking at what you've made.

That's probably the biggest change in how I think about my work.

I'm not trying to become a designer who can also code. Or an engineer who happens to understand design.

I'm increasingly interested in the space where those activities become one continuous process.

And AI has made that space much easier to work in.