I have been coding since before I was a designer. When AI coding assistants arrived, I was skeptical. After eighteen months of daily use, I have changed my mind — but not in the way I expected.
My relationship with code started long before my relationship with design. I was writing HTML and CSS in the early 2000s because I wanted to understand how things worked on the screen, not because anyone told me to. That curiosity eventually led me to Angular, React, and a professional practice that lives somewhere between design and engineering — which means I watched the arrival of AI coding assistants with a specific kind of interest that most designers did not have.
I was not skeptical about whether the technology worked. I was skeptical about whether it would change anything that actually mattered in how I work. After eighteen months of using GitHub Copilot and Claude as daily tools in my prototyping and development workflow, I have a clear answer: it does change things that matter. But the changes are more specific — and more interesting — than the general conversation about AI and coding tends to suggest.
AI coding tools did not make me a better programmer. They made me a faster one — which freed up thinking time for the parts of the work where speed was never the constraint.
— Roy Villasana
The Part That Actually Saved Me Time
I want to be honest about what Copilot changed and what it did not, because I think the productivity claims around AI coding assistants are often imprecise in ways that create bad expectations.
What Copilot genuinely accelerated for me: component scaffolding, TypeScript type definitions, Tailwind utility class combinations, and the mechanical parts of React patterns I have written hundreds of times. The things that required attention but not thought — Copilot handles those. I estimate it eliminates around 35-40% of my keystrokes on a typical component, which sounds modest until you realize that those keystrokes were occupying mental attention that I can now direct somewhere else.
What Copilot did not improve: the part of the work that was never a speed problem. Deciding what component to build, how it should behave under different states, how it fits into the design system, what the accessible markup structure should be — none of that got faster. The cognitive work is still cognitive work. The tool handles the transcription; the thinking remains mine.
Where Claude Changed Something More Fundamental
Claude operates differently in my workflow, and understanding the distinction took me several months to articulate clearly. I do not use Claude for autocomplete. I use it as a thinking partner for the architectural and structural decisions that happen before I write code.
A practical example: I was building a complex multi-step form for an enterprise onboarding flow — the kind of component that has a lot of state management, conditional logic, and accessibility requirements that interact in non-obvious ways. Before I wrote a line of code, I described the component to Claude and asked what I was probably not thinking about. The conversation surfaced three accessibility patterns I would have discovered the hard way during review, a state management approach I had not considered, and a question about error recovery behavior that revealed a gap in the design spec.
That conversation took fifteen minutes. It probably saved two days of revision. That is not a productivity gain from faster coding. It is a quality gain from thinking more carefully before coding — with a partner that has broad knowledge and no stake in the outcome.
The Limitations Are Real and Worth Naming
I want to be direct about what these tools do not do well, because the honest limitations matter as much as the genuine benefits.
- AI-generated code tends toward verbosity. Left unchecked, Copilot suggestions produce code that works but is harder to read and maintain than what I would write manually. I have had to develop a discipline of reviewing and simplifying AI suggestions rather than accepting them at face value. The default output is correct code, not good code. Those are not the same thing.
- Claude can be confidently wrong. This is the most important limitation to internalize. Claude presents incorrect architectural advice with the same tone as correct advice. I have learned to verify anything structural against documentation and my own experience, treating Claude as a first-pass resource rather than a final authority.
- Context switching has a real cognitive cost. Moving between Copilot in the editor and a Claude conversation and back requires maintaining mental context across two modes of working. On complex problems, the overhead is worth it. On simple tasks, staying focused and writing the code manually is faster.
What This Means for Designers Who Are Learning to Code
The practical implication I think about most is what these tools mean for designers who are building coding skills. My honest assessment: they lower the activation energy for getting started and reduce the frustration of the mechanical parts. They do not lower the bar for understanding what the code does and why. If anything, they raise the importance of that understanding — because a designer who accepts AI-generated code without comprehending it is building on a foundation they cannot maintain or debug.
The most valuable thing a designer learning to code can do with AI tools is use them to learn faster, not to skip learning. Ask Claude to explain why a pattern works, not just what pattern to use. Read the Copilot suggestion before accepting it. The tools are genuinely useful as accelerants. They are not a substitute for understanding.
Keywords
GitHub Copilot, Claude AI, AI coding assistant, UX and code, designer who codes, AI-assisted development, product designer, React Tailwind, design systems, AI workflow, frontend development