I Built a Utility Tools Website Using 4 Different AI Coding Agents. Here’s What Nobody Tells You.

Cursor, OpenCode, GitHub Copilot, and Codex all wrote code for the same project. It worked — but only after I stopped treating AI like a mind reader.

https://utilitieshub.in/

A few months back, I decided to build a small utility tools website. Nothing fancy — the kind of site with a JSON formatter, a color picker, a unit converter, maybe a dozen small tools people use once and forget about. The kind of project every developer has in their “someday” folder.

That project turned into UtilitiesHub — live, working, and built almost entirely with the help of AI coding agents.

But this time, I had a different goal. I wanted to see how far I could push AI coding agents to actually build production-level features, not just autocomplete a function here and there.

So I used four of them. Cursor. OpenCode. GitHub Copilot. And Codex.

Here’s the thing nobody tells you when you start doing this: the coding part is the easy part. The hard part is making sure four different AI tools understand what you’re actually trying to build — without you repeating yourself twenty times a day like a broken record.

Let me walk you through what actually happened.

The Honeymoon Phase

The first few days were great. I’d open Cursor, type a prompt, and watch a working component appear in seconds. Switch to Copilot for inline suggestions while editing. Fire up Codex for a quick script. It felt like having a small team of developers on call 24/7.

But somewhere around day four, cracks started showing.

Problem #1: Every AI Agent Has Amnesia

Here’s what I mean. I’d spend twenty minutes explaining the project to Cursor — the folder structure, the design philosophy, why I wanted tools to load instantly without a backend call, the whole vision.

Then I’d switch to OpenCode for a different task, and it had no idea what I was talking about. Blank slate. I’d explain everything again. Then Copilot would suggest something completely inconsistent with what Cursor had already built, because it didn’t know the “why” behind the decisions — only the code in front of it.

Multiply that across four tools, multiple sessions a day, and you start losing hours just re-explaining context instead of building.

This is the part junior developers don’t expect. You assume the AI “remembers” the project like a teammate would. It doesn’t. Every new session, every new tool, every new chat — it’s a stranger walking into your codebase for the first time.

How I fixed it:

I stopped explaining the project verbally every single time. Instead, I created two files that live at the root of the repo:

• **vision.md* — the big picture. What the product is, who it's for, what "good" looks like, what the site should feel* like when someone uses it. Design principles. Tone. Non-negotiables (like "no tool should ever need a backend unless absolutely necessary").
• **instruction.md** — the practical rulebook. Coding conventions, folder structure, naming patterns, what libraries are allowed, how components should be structured, how errors should be handled.

Now, before I ask any AI agent to write a single line of code, the workflow is simple:

1. Point it to instruction.md first — this sets the ground rules.
2. Point it to vision.md next — this gives it the why.
3. Only then does it start coding.

It sounds almost too simple. But this one change cut my re-explaining time by more than half. The AI agents stopped guessing, and I stopped repeating myself like a parrot.

Problem #2: Four Cooks, One Kitchen, No Recipe Card

Here’s where it got messier. When multiple AI agents touch the same codebase, you get four different “opinions” on how things should be done — even for something as small as naming a function or structuring a component.

Cursor might build a tool one way. A day later, Codex generates a similar feature using a completely different pattern. Copilot autocompletes something that technically works but doesn’t match either style. Suddenly your codebase looks like it was written by four developers who never talked to each other — because, in a way, it was.

This is exactly the kind of mess a senior developer has seen a hundred times, just with humans instead of AI. New team member joins, doesn’t read the style guide, and two weeks later you’re doing a painful refactor.

How I fixed it:

Same principle, different file. I created an **issue.md** approach — basically a running log of decisions, patterns, and "gotchas" that any AI agent needs to check before generating code for a feature that touches existing work.

Whenever one AI agent built something that another agent needed to extend or fix, I’d note it down: what pattern was used, why, what NOT to do, and any bugs that came from inconsistency. Before generating new code, the agent reviews this file the same way it reviews instruction.md.

It’s basically a shared memory layer that the AI tools themselves don’t have — I built it manually, and it works better than I expected.

What This Actually Taught Me

None of these AI tools are “smarter” than the other in some magical way. They’re all good at writing code. What separates a smooth project from a chaotic one isn’t the tool — it’s the process you wrap around it.

A senior developer doesn’t just write code faster. They set up the guardrails so that anyone — human or AI — walking into the project understands the vision without a thirty-minute onboarding call every time.

Turns out, managing four AI agents isn’t that different from managing four junior developers on your team. Give them clear docs. Give them context up front. Keep a shared log of decisions. And don’t assume they remember anything you didn’t write down.

The utility website is live now. It’s fast, it’s clean, and honestly, it works better than I expected for a project built with four different AI tools stitched together. But the real lesson wasn’t about the tools at all.

It was this: AI doesn’t remove the need for good process. It makes good process more important than ever.

If you’re building anything with AI coding agents right now — even solo — do yourself a favor. Write your vision.md and instruction.md before you write a single prompt. Future you will thank present you.

👉 Curious what actually got built? Check it out here: **utilitieshub.in**

If this helped you think differently about working with AI coding tools, give it a clap 👏 and follow for more real-world lessons from building with AI — no hype, just what actually works.