How We Actually Use AI in Our Development Workflow
Article Takeaways / TL;DR
- We use AI every day for production work: writing and refactoring code, debugging, first drafts, documentation and quick prototypes.
- We don’t hand AI the decisions that determine whether a site works: information architecture, CMS structure, design systems, integration logic and accessibility.
- A senior developer or designer reviews everything AI produces before it reaches a client.
- The result isn’t a cheaper project. It’s a faster one, with more of the budget spent on judgment instead of production.
We use AI to speed up the production work in every project, and we keep the decisions that shape a project with experienced people. That’s the whole policy. Everything below is what it looks like in practice, because “we use AI responsibly” doesn’t tell a client or an agency partner anything they can act on.
In a working studio, AI has quietly removed a lot of the repetitive labor that used to fill the hours between a decision and a finished page. It has not touched the decisions themselves. Knowing where that line sits is the difference between using AI well and getting burned by it later.
Where does AI save us time?
The honest answer is that AI is good at the parts of development that are mechanical, bounded and easy to check. Those parts add up to real hours, and handing them to a tool frees a senior person to spend their attention where it matters.
Writing and refactoring code is the clearest case. An AI assistant in the editor handles boilerplate, repetitive markup and the kind of routine refactor that is tedious rather than hard. A component that might take twenty minutes to write by hand can take five, and the fifteen minutes saved go into reviewing it against the rest of the codebase. The newer tools go further and draft changes across several files at once. We use that too, and we read every line before it merges, because a change that looks reasonable in isolation can still be wrong for the architecture it’s landing in.
Debugging is the second case. Describing a bug to a capable model, with the error and the relevant code pasted in, is often faster than retracing the problem through documentation or old forum threads. It is especially good at the class of bug that comes from a misread API or a typo.
Then there is the supporting material that every project generates and nobody enjoys writing. First drafts of placeholder copy, handoff notes, test cases and technical documentation. What used to be a two-hour writing task becomes a thirty-minute editing session, and the editing is where the quality comes from. The same goes for prototypes. When we want to know whether an interaction idea actually feels right, a rough working version in minutes beats a paragraph describing it, and most of those prototypes get thrown away once they’ve answered the question. AI is also a fast way to get oriented in an unfamiliar API or library, as long as the details get checked against the official documentation before anyone relies on them.
What do we keep away from AI?
The decisions we protect have one thing in common. They depend on understanding the client’s business, and they are expensive to get wrong because the cost shows up months after launch.
Information architecture is the first. How a site is organized for its audiences, what lives where and how a specific visitor moves toward the thing they came to do. Those choices come out of conversations about the business, its priorities and its customers. A model can propose a sitemap, but it is pattern-matching against other sites, not reasoning about this one. We don’t lean exclusively on it for discovery or strategy, because that is where the real decisions are made.
CMS structure and content modeling is the second, and it is the one that quietly breaks AI-built sites. A content model that works cleanly for ten pages and falls apart at fifty is an expensive mistake, because by the time it shows up the whole site is built on it. Getting it right means knowing who will edit the site, what they will publish, how often and how the thing will grow. That is judgment, not generation.
Design system architecture sits in the same place. AI can produce a single component on request. Deciding which components should exist, how they relate and how the system holds together as it scales is a design decision that the components depend on, not the other way around. Integration logic is similar. A tool can scaffold the connection between a site and a CRM or a booking system, but the edge cases, where data is missing or a service fails or two systems disagree, are exactly where integrations break, and handling them takes someone who understands both ends.
Accessibility is the last and the one we are most careful about. AI-generated code can pass an automated check and still fail a real person. A scan will confirm that a modal has the correct ARIA role and say nothing about whether focus returns to the right place when it closes, or whether the tab order makes any sense. Automated tools catch only part of the problem, so we test keyboard navigation, focus handling and screen reader behavior by hand. Accessibility is structural, which means it has to be designed in from the start, not patched on once the automated report comes back clean.
Why does the distinction matter to clients?
Because the problems AI introduces don’t announce themselves on launch day. A site built on AI-generated architecture can look finished and behave perfectly in a demo. The trouble arrives six months later, when the team tries to add a section the content model didn’t anticipate, or connect a system the integration layer wasn’t built for, and discovers that the foundation won’t take the weight.
The industry data lines up with this. Most developers now use AI tools in some form, but according to Stack Overflow’s 2025 developer survey only about a third trust the accuracy of what those tools produce, and nearly half actively distrust it. That gap is the whole reason review exists. The people who use these tools most are also the most skeptical of taking their output at face value, because they have seen where it goes wrong. Everything AI generates for us is reviewed by an experienced developer or designer before it reaches a client, and that review is not a formality. It is where the tool’s speed gets turned into something a business can actually depend on.
What does this look like on a real project?
Discovery and strategy are human-led work: conversations with the client, their audiences and their team, and the architecture and design decisions that come out of them. Research across industries and competitors where AI shines, but the output is still human reviewed.
Production is where AI tools really come into play. AI accelerates the build, and a review step sits between every AI-assisted change and the site that ships. Then testing, accessibility checks and launch get a final human pass, because those are the steps that decide whether the work holds up.
The effect isn’t that projects get cheaper. It’s that more of a project’s time and budget go to the parts that determine whether it succeeds, and less to the production grind that used to consume them. If you want the wider picture of how AI-built and AI-assisted work differ, Vibe Coding, AI-Assisted Development, and No-Code covers it, and our development services describe how we run projects start to finish.
Common questions
Do you use AI to build client websites?
We use AI to speed up production work like code, drafts and debugging. People make the architecture, design and integration decisions, and a senior developer reviews everything AI produces before it ships.
Does using AI make projects cheaper?
It shortens some production work. Strategy, architecture and design drive most of a project’s cost, so the time saved mostly turns into more attention on those parts rather than a lower invoice.
Which AI tools do you use?
AI coding assistants in our editor, chat models for drafting and debugging, and AI features inside our design tools. The specific tools change often, so we choose them per task and review whatever they produce.
How do you make sure AI-assisted work is good quality?
Every AI-generated change is reviewed by an experienced developer or designer, and accessibility, performance and integrations are tested by hand before launch.
Should I be concerned if my developer uses AI?
Not if experienced people make the decisions and review the output. The useful questions to ask are who reviews AI-generated work and how accessibility gets tested.
Author:
Jeremy Bokor
Founder, Nifty Inc
