We tested AI models on a real project work and wrote down what worked and where it's worth using.
.png)
New AI models show up every month, and each one claims to be the best. We wanted a straight answer to a simpler question: which tools actually help in day-to-day development, and where. So we tested them on real project work and wrote down what worked, where it worked, and why. This article walks through each category, shows how we used it, and gives you enough context to figure out what fits your own setup, without spending weeks running the same experiments yourself.
Why We Went Looking for Answers
We're a consulting agency, so variety is the default. One week it's a marketing site with pixel-perfect Figma designs, the next it's a rapid prototype built from a napkin sketch and a deadline, and sometimes it's an SEO project that needs to process data and produce actionable reports.
Clients pay for quality and speed. AI promised to help with both, but the space is crowded: coding agents, chat models, design plugins, automation platforms, editors with AI built in, with plenty of overlap and no obvious winner. The hard part wasn't finding tools, it was figuring out which one belongs where without losing weeks to trial and error. Where nothing off-the-shelf quite fit, we stitched the pieces together into our own workflows, covered near the end.
Which AI Code Editor Is Worth It? Cursor vs Devin Desktop vs Zed
Most of our developers now use code editors with AI built in directly. These editors understand project context, offer inline suggestions, can refactor across files, and let you chat with the model about your codebase without leaving the editor.
Cursor and Devin Desktop are the most popular picks on our team. Both are VS Code forks with deep AI integration. Zed takes a different angle, focusing on performance and multiplayer editing alongside AI features.
Some developers skip the IDE route and work with Claude Code or Codex directly from the CLI. It's a more stripped-down workflow, but for people comfortable in the terminal it removes a layer of abstraction and gives full control over how the agent interacts with the codebase.
Different developers on our team land on different tools, and that's fine. What matters most is that the AI has access to your project context. An editor that knows your codebase gives better suggestions than a generic chat window, whichever one you pick.
Claude Code vs Codex, and What AI Coding Agents Get Right (and Wrong)
These are CLI-based agents that read your codebase, edit files, run commands, and iterate based on feedback, closer to a tireless pair programmer than a chatbot.
What works well:
- Multi-file implementation: building full page sections from a design reference, touching templates, styles, and configuration in one pass.
- Generating project documentation that stays consistent with the actual code.
- Working with CLI tools (WP-CLI, Git, build scripts) as part of the implementation flow.
- Following structured plans where each step builds on the last.
What doesn't work as well:
- Agents tend to generate more code than needed: unnecessary validations, fallbacks for edge cases that won't happen, defensive patterns that add complexity without a reason.
- Content escaping in CMS environments can be an issue. AI-generated content sometimes introduces encoding artifacts that break rendering.
- Without clear instructions, agents tend to over-engineer. A well-written playbook is the difference between useful output and a mess.
We use models at least as capable as Opus 4.6 for this work. The latest Opus or Codex versions don't perform dramatically better for agent-driven WordPress development, and the drop in quality only becomes noticeable once you go to significantly weaker models. Mid-to-high tier models all get the job done here. Optimizing for a slightly lower-end model starts to matter once you're running dozens of agent tasks a week: a cheaper model that's fast and consistent enough for the task often beats a top-tier model billed at a premium on every call.
The upfront investment in documentation pays off on every task after the first. Give the agent a clear playbook and it performs like a reliable junior developer. Skip it and you'll spend more time reviewing than you saved.
ChatGPT vs Claude vs Gemini, and When to Use Each
Conversational AI is the daily tool for brainstorming, code review, debugging, and quick questions, but not everyone on the team reaches for the same one.
Our frontend developers gravitated toward ChatGPT and Claude for prototyping and proof-of-concept work. Both, on their current top-tier models, handled component structure and React patterns well, and translated rough descriptions into working UI code.
ChatGPT and Gemini became the go-to for natural language tasks: naming things, writing user-facing copy, and reading intent from vague client descriptions. Both consistently produced natural, context-aware output. For drafting technical documentation, Claude worked best – it kept structure and terminology consistent across longer documents.
The lighter GPT and Gemini models found their niche as an API inside automated pipelines built with tools like n8n and Make. They aren't the most capable in conversation, but they're cheap and reliable for workflows that run on a schedule with no one watching.
Matching the model to the task works better than standardizing on one. The output is what matters here, not the brand behind it.
How AI Turns Figma Files Into Code (Figma MCP Explained)
MCP lets AI agents read Figma designs directly, extracting components, design tokens, and layout structure, so the agent generates code from the actual design file rather than from a screenshot or a verbal description.
What works well:
- The AI references real design data, not a developer's interpretation of a screenshot.
- Design tokens flow directly into theme configuration.
- The gap between what the designer intended and what gets built shrinks significantly.
- A well-structured Figma file, a coding agent, and a base component library together got surprisingly close to pixel-perfect on the first pass.
What doesn't:
- Large design files can exceed AI context limits, so you end up working section by section.
- Extracting variables and tokens from an entire file at once isn't supported yet, so you iterate view by view.
- CSS is still a weak spot. Even the best models available today struggle with precise styling, spacing, alignment, and responsive behavior. Structure and logic usually land well, but the visual polish almost always needs manual developer adjustment.
Design quality matters more than ever here. Poorly structured Figma files, with inconsistent naming, ungrouped layers, or mixed component patterns, produce equally messy code. Design system hygiene is now a development concern, not just a design one. Clean Figma files are a direct input to code quality.
Testing WordPress Sites in the Browser With No Server Setup
WordPress Playground is a newer addition to our toolkit. It spins up a full WordPress instance directly in the browser, no server required, so anyone on the team, or a client, can test themes, plugins, and block configurations without setting up a local environment.
We started using it for quick demos and prototyping. When we need to show a client how a block will behave, or test a plugin interaction before committing to it in a real project, Playground is the fastest path. It pairs well with our AI workflow too: the agent generates a block or template, and we drop it into Playground to verify behavior without touching the staging environment.
It's not a replacement for proper local development or staging, but for validation and communication it saves a lot of back-and-forth.
Automating Recurring Work With n8n, Make, and AI APIs
AI models connected to automation platforms can run scheduled or triggered tasks without anyone pressing a button.
Our automation specialist built morning briefing workflows that pull data from project management tools, filter what changed overnight, and produce a concise summary of what needs attention that day, so nobody has to open three dashboards and piece the picture together manually.
Other workflows handle data processing pipelines, connecting AI to tools like email, calendars, and issue trackers. These run on schedule using cost-effective models that don't need to be the smartest, just consistent. For recurring tasks, consistency matters more than raw capability.
When to Build a Custom AI Tool Instead of Buying One
When off-the-shelf solutions don't fit, we build what we need. One example is an SEO analysis tool that connects AI models to crawling and data processing pipelines. It pulls site data, runs it through models for content analysis and keyword evaluation, and produces structured reports that would otherwise take hours to compile manually.
We've also built custom MCP servers, agent skills, and internal CLI tools tailored to specific workflows, including tools for WordPress block markup generation and project scaffolding.
Using AI tools daily tends to surface gaps that only your own team will notice. Off-the-shelf solutions cover most of the work; the last stretch is usually where custom tooling makes the real difference.
Which AI Tool Should You Use for Which Task?
New AI models show up every month, and each one claims to be the best. We wanted a straight answer to a simpler question: which tools actually help in day-to-day development, and where. So we tested them on real project work and wrote down what worked, where it worked, and why. This article walks through each category, shows how we used it, and gives you enough context to figure out what fits your own setup, without spending weeks running the same experiments yourself.
Why We Went Looking for Answers
We're a consulting agency, so variety is the default. One week it's a marketing site with pixel-perfect Figma designs, the next it's a rapid prototype built from a napkin sketch and a deadline, and sometimes it's an SEO project that needs to process data and produce actionable reports.
Clients pay for quality and speed. AI promised to help with both, but the space is crowded: coding agents, chat models, design plugins, automation platforms, editors with AI built in, with plenty of overlap and no obvious winner. The hard part wasn't finding tools, it was figuring out which one belongs where without losing weeks to trial and error. Where nothing off-the-shelf quite fit, we stitched the pieces together into our own workflows, covered near the end.
Which AI Code Editor Is Worth It? Cursor vs Devin Desktop vs Zed
Most of our developers now use code editors with AI built in directly. These editors understand project context, offer inline suggestions, can refactor across files, and let you chat with the model about your codebase without leaving the editor.
Cursor and Devin Desktop are the most popular picks on our team. Both are VS Code forks with deep AI integration. Zed takes a different angle, focusing on performance and multiplayer editing alongside AI features.
Some developers skip the IDE route and work with Claude Code or Codex directly from the CLI. It's a more stripped-down workflow, but for people comfortable in the terminal it removes a layer of abstraction and gives full control over how the agent interacts with the codebase.
Different developers on our team land on different tools, and that's fine. What matters most is that the AI has access to your project context. An editor that knows your codebase gives better suggestions than a generic chat window, whichever one you pick.
Claude Code vs Codex, and What AI Coding Agents Get Right (and Wrong)
These are CLI-based agents that read your codebase, edit files, run commands, and iterate based on feedback, closer to a tireless pair programmer than a chatbot.
What works well:
- Multi-file implementation: building full page sections from a design reference, touching templates, styles, and configuration in one pass.
- Generating project documentation that stays consistent with the actual code.
- Working with CLI tools (WP-CLI, Git, build scripts) as part of the implementation flow.
- Following structured plans where each step builds on the last.
What doesn't work as well:
- Agents tend to generate more code than needed: unnecessary validations, fallbacks for edge cases that won't happen, defensive patterns that add complexity without a reason.
- Content escaping in CMS environments can be an issue. AI-generated content sometimes introduces encoding artifacts that break rendering.
- Without clear instructions, agents tend to over-engineer. A well-written playbook is the difference between useful output and a mess.
We use models at least as capable as Opus 4.6 for this work. The latest Opus or Codex versions don't perform dramatically better for agent-driven WordPress development, and the drop in quality only becomes noticeable once you go to significantly weaker models. Mid-to-high tier models all get the job done here. Optimizing for a slightly lower-end model starts to matter once you're running dozens of agent tasks a week: a cheaper model that's fast and consistent enough for the task often beats a top-tier model billed at a premium on every call.
The upfront investment in documentation pays off on every task after the first. Give the agent a clear playbook and it performs like a reliable junior developer. Skip it and you'll spend more time reviewing than you saved.
ChatGPT vs Claude vs Gemini, and When to Use Each
Conversational AI is the daily tool for brainstorming, code review, debugging, and quick questions, but not everyone on the team reaches for the same one.
Our frontend developers gravitated toward ChatGPT and Claude for prototyping and proof-of-concept work. Both, on their current top-tier models, handled component structure and React patterns well, and translated rough descriptions into working UI code.
ChatGPT and Gemini became the go-to for natural language tasks: naming things, writing user-facing copy, and reading intent from vague client descriptions. Both consistently produced natural, context-aware output. For drafting technical documentation, Claude worked best – it kept structure and terminology consistent across longer documents.
The lighter GPT and Gemini models found their niche as an API inside automated pipelines built with tools like n8n and Make. They aren't the most capable in conversation, but they're cheap and reliable for workflows that run on a schedule with no one watching.
Matching the model to the task works better than standardizing on one. The output is what matters here, not the brand behind it.
How AI Turns Figma Files Into Code (Figma MCP Explained)
MCP lets AI agents read Figma designs directly, extracting components, design tokens, and layout structure, so the agent generates code from the actual design file rather than from a screenshot or a verbal description.
What works well:
- The AI references real design data, not a developer's interpretation of a screenshot.
- Design tokens flow directly into theme configuration.
- The gap between what the designer intended and what gets built shrinks significantly.
- A well-structured Figma file, a coding agent, and a base component library together got surprisingly close to pixel-perfect on the first pass.
What doesn't:
- Large design files can exceed AI context limits, so you end up working section by section.
- Extracting variables and tokens from an entire file at once isn't supported yet, so you iterate view by view.
- CSS is still a weak spot. Even the best models available today struggle with precise styling, spacing, alignment, and responsive behavior. Structure and logic usually land well, but the visual polish almost always needs manual developer adjustment.
Design quality matters more than ever here. Poorly structured Figma files, with inconsistent naming, ungrouped layers, or mixed component patterns, produce equally messy code. Design system hygiene is now a development concern, not just a design one. Clean Figma files are a direct input to code quality.
Testing WordPress Sites in the Browser With No Server Setup
WordPress Playground is a newer addition to our toolkit. It spins up a full WordPress instance directly in the browser, no server required, so anyone on the team, or a client, can test themes, plugins, and block configurations without setting up a local environment.
We started using it for quick demos and prototyping. When we need to show a client how a block will behave, or test a plugin interaction before committing to it in a real project, Playground is the fastest path. It pairs well with our AI workflow too: the agent generates a block or template, and we drop it into Playground to verify behavior without touching the staging environment.
It's not a replacement for proper local development or staging, but for validation and communication it saves a lot of back-and-forth.
Automating Recurring Work With n8n, Make, and AI APIs
AI models connected to automation platforms can run scheduled or triggered tasks without anyone pressing a button.
Our automation specialist built morning briefing workflows that pull data from project management tools, filter what changed overnight, and produce a concise summary of what needs attention that day, so nobody has to open three dashboards and piece the picture together manually.
Other workflows handle data processing pipelines, connecting AI to tools like email, calendars, and issue trackers. These run on schedule using cost-effective models that don't need to be the smartest, just consistent. For recurring tasks, consistency matters more than raw capability.
When to Build a Custom AI Tool Instead of Buying One
When off-the-shelf solutions don't fit, we build what we need. One example is an SEO analysis tool that connects AI models to crawling and data processing pipelines. It pulls site data, runs it through models for content analysis and keyword evaluation, and produces structured reports that would otherwise take hours to compile manually.
We've also built custom MCP servers, agent skills, and internal CLI tools tailored to specific workflows, including tools for WordPress block markup generation and project scaffolding.
Using AI tools daily tends to surface gaps that only your own team will notice. Off-the-shelf solutions cover most of the work; the last stretch is usually where custom tooling makes the real difference.
Which AI Tool Should You Use for Which Task?
After months of testing, here's where we landed:
What We'd Tell You to Keep, Even When the Tools Change
Half the tools in this article will likely look different in a year, whether through acquisitions, pivots, or simply disappearing. That's fine, because what actually holds up isn't a particular tool. It's a handful of habits: write things down, keep designs clean, agree on naming conventions, plan before building, and review everything. Those habits make whichever tool you're using at the time work better, and they'll still matter when the next tool shows up.
If you adopt these tools yourself, expect a similar shift on your team: less code written from scratch, and more time spent reviewing what the agent produced, catching where it drifted, and making calls that need context the model doesn't.
What We'd Tell You to Keep, Even When the Tools Change
Half the tools in this article will likely look different in a year, whether through acquisitions, pivots, or simply disappearing. That's fine, because what actually holds up isn't a particular tool. It's a handful of habits: write things down, keep designs clean, agree on naming conventions, plan before building, and review everything. Those habits make whichever tool you're using at the time work better, and they'll still matter when the next tool shows up.
If you adopt these tools yourself, expect a similar shift on your team: less code written from scratch, and more time spent reviewing what the agent produced, catching where it drifted, and making calls that need context the model doesn't
About the author
