It’s easy to let a tool just do the thing. Ask it to write the copy, generate the layout, build the component, and take what comes back because it looks fine and it was fast. That’s the path of least resistance, and it’s also how control slips away from the person who was supposed to be directing the work in the first place, without anyone really noticing until it’s gone.
Directing a tool well requires actually understanding what it’s doing, not just what it produces. If a description can’t be turned into a specific instruction, the tool is guessing on your behalf, and you won’t know whether the guess was right until something breaks. Understanding is what turns “make it feel modern” into “use the brand’s CTA color only on the primary action, with the ghost variant for secondary, on a neutral page.” One of those a tool can execute correctly. The other is just hoping.
Twenty years of hands-on design and development work means I’ve watched a lot of platforms come and go. That’s the same perspective I bring to AI. Not just what’s current, but what actually holds up. Knowing how the code actually works, how a layout actually holds together, what a design decision is actually doing and why, means an AI tool becomes something you can direct with precision instead of something you’re subject to. Skip that understanding and every AI-assisted decision becomes a coin flip dressed up as progress.
Staying agnostic instead of getting handcuffed to a tool
There’s a version of working with AI that ties a person to whichever tool happens to be popular this year: whichever chatbot, whichever coding assistant, whichever generator. That version is fragile, because the moment the tool changes, so does the output, and nobody involved really knows why.
The alternative is understanding the fundamentals well enough that the tool becomes interchangeable. Building tool-agnostic systems means understanding how design and development actually connect, not just handing off a file and hoping for the best. If you actually understand color theory, typography, information architecture, and how code is structured, it doesn’t matter whether the tool in front of you is Claude, a different assistant, or something that doesn’t exist yet. You can direct any of them, because the understanding lives with you, not with the tool.
Treating my own understanding like a living system
The other thing I keep coming back to is that a foundation, whether it’s a design system or just someone’s own understanding of a new tool, isn’t a static thing you finish and file away. It has to stay agile. Living. Tested against reality instead of declared once and left alone. The systems that actually hold up are the ones someone keeps running real-time experiments on, checking what still works and what stopped working the moment something changed underneath it.
That’s exactly how I’m treating my own understanding of AI right now. Not a finished position. Not a framework I’ve locked into and am now just defending. Something I’m actively testing, breaking, and rebuilding in real time, because that’s the only way to actually stay in control of it instead of declaring a stance and hoping it still holds a year from now.
I’m not writing any of this because I have it figured out. I’m writing it because figuring it out, out loud, one test at a time, is honestly the actual work right now. Nobody has this fully solved. Anyone who says they do is probably the person you should trust the least.
The job that’s actually mine to do
I don’t think the job right now is resisting AI or pretending it’s not changing the work. It clearly is. I think the job is holding onto enough real understanding that I’m the one directing it, not the one being directed by it. That’s not a nostalgic position. It’s a practical one. The tools will keep changing, probably faster than they have at any other point I’ve watched. The understanding underneath them is the part that has to stay mine, and it has to stay something I’m actively working on, not something I decided once.
That’s the same argument as everything else I build on. The tools change, and the only thing that actually holds up is the understanding underneath them, kept current in a person who’s actually willing to keep testing it.
