How Your AI Tools Get Built and Checked

Frog Stone Media's AI development process is designed to get a working AI tool into your business sooner, with fewer mistakes reaching your customers. Chatbots, assistants and automations all go through the same five steps, and a person reviews the work and how it fits your business before it goes live.

Claude Code builds. OpenAI Codex reviews. Human verified and approved.

The AI Development Process, Step by Step

1. Build. Claude Code, an AI coding tool, writes the first version inside a working environment set up for your project, following your business's rules.
2. Review. OpenAI Codex, a second AI from a different company, reads the work and flags problems the first one missed.
3. Human verified and approved. A person reviews the work and how it fits your business before it goes live.
4. Launch. The tool goes live on your website or inside your systems, and your team is shown how to use it.
5. Support. When something needs adjusting, the same setup is used to find the cause and fix it.

What This Means for Your Business

Checks built to catch mistakes before customers see them

An AI builder and an independent AI reviewer and a person look at the work before launch. That layered check is built to catch wrong answers, broken pages and awkward wording before a customer sees them.

Faster delivery

AI handles the repetitive parts of the build, so a project moves from idea to working tool sooner. The human review stays in place.

Work your business owns

The code, the AI instructions and the service accounts are set up in your business's name and written down in plain language. Your business keeps control, and another developer could pick the work up later.

AI Instructions That Stay Consistent

Every AI tool runs on written instructions that tell it what to do, what tone to use and what to stay away from. Those instructions are written for your business, then tested on real examples from it, such as actual customer questions or actual invoices, before launch.

AI companies update their models often, and an update can change how a tool behaves. The same test examples are run again when that happens, which is designed to keep answers in line with what you approved.

Faster Builds With a Person in Charge

AI-assisted development means AI writes much of the code from plain-language direction, which shortens the build. Changes go through the second AI review and a person's approval, the same as the rest of the work.

What the Setup Makes Possible

• A working environment for each project. Your project's rules are written down once, so the AI follows your business's conventions in every session.
• Connections to your tools. With your permission, the AI can read from the tools your business already uses, such as your website, store or inventory system. Where it can publish, it defaults to drafts, so a person approves anything that goes out. More on this on the AI integrations page.
• Checks before anything goes live. Automated checks run before each deploy, so problems are flagged before they reach your site.
• Live diagnosis when something needs fixing. With access to server logs and the live site, the cause of a problem can be traced to the exact place it starts, rather than guessed at.

Two Examples of the Setup at Work

A cache plugin fix, traced to the source for Themeisle

Super Page Cache Pro 5.2.4 was filling debug logs at roughly 2,000 entries per hour on two WordPress sites. The configuration was unchanged. The same no-op log lines fired about every two seconds.

Because the working environment could read the plugin's own source code next to the live logs, the symptom was traced to specific files. pro/Modules/Fallback_Cache.php was logging at standard verbosity on every page load. The deeper issue was that fallback_cache_advanced_cache_disable() in libs/fallback_cache.class.php ran unguarded on every request, doing heavy work with nothing to update. On a sibling site in file mode, add_dropin() was rewriting the same byte-identical file 1.2 times per second. That made three distinct issues, each with a two-line patch suggestion.

The report went to Themeisle with line numbers, file paths and proposed fixes. Themeisle reproduced it, agreed with the analysis and shipped 5.3.1 with the patches within 48 hours. The 5.3.1 source includes the md5-equality fast path and the disable and enable guards from the report. Themeisle's engineering team put their response in writing, quoted on the testimonials page.

A brute-force defense across a WordPress hosting fleet

A WHM server hosting 166 WordPress sites had been under sustained brute-force attack on wp-login.php since April 2026, and one client site was confirmed compromised. Cloudflare sat in front and CSF/LFD ran on the firewall, but the login page itself accepted unlimited attempts.

The defense was built with iWebFusion in four phases. The rate-limit phase added nginx limit_req at 10 requests per minute with a burst of 5. The auto-ban phase added a CSF/LFD custom rule that turns five 429 responses within an hour into a one-hour iptables ban. Because the working environment had live access to the logs, firewall state and the Imunify360 console, each problem was traced to its exact file and line. That phase took three rounds: the rule had been written to a path CSF v16.18 does not load, the sixth tuple value was read as a one-second duration instead of a permanent flag, and Imunify360's CSF_COOP integration was quietly releasing every lfd ban into a five-minute graylist.

Once the Imunify360 layer was disarmed, the full chain held: nginx 429s, the lfd custom trigger, a one-hour CSF ban and an iptables drop. All 166 sites stayed online throughout. iWebFusion's note on how the debugging went is on the testimonials page.

To plan what to build, start with an AI consultant, or go straight to AI chatbots and website features and AI assistants and automation.