How can a marketing team ship website changes with AI agents without breaking things?

Short answer: an AI coding agent that gets a loose instruction like “make the site lighter” will often change one color and call it done, or rewrite half the page and lose track of what it was doing. The fix is not a smarter agent. It is writing down what should change, and why, before the agent touches any code, then reviewing that plan before it is allowed to build. We run our own website this way now, and it is the difference between a Saturday afternoon of frustration and a change that actually ships.

The problem: “make it lighter” became “change one line of CSS”

We run our own site’s development ourselves, without a dedicated developer on the team. For months that meant prompting conversationally: take a screenshot, describe what looks off, ask the agent to fix it. It worked for small things. It did not work for anything bigger.

The clearest example: feedback came in that the site felt too dark. A reasonable, vague brief, so we asked the agent to research what “too dark” usually means for a B2B site and apply it. It came back having changed the background color of one section. Technically correct, practically useless. On a different pass, asking for a sitewide lighter theme, the agent implemented about 80% of it and left the rest inconsistent, because it had quietly lost track of which pages it had already touched.

Neither failure was a one-off. It is what happens when an agent is given a goal but no plan: it fills in the gaps with its own assumptions, and those assumptions do not match what you had in mind.

What a spec actually is, and why it helps

The fix that worked for us is called spec-driven development, and the idea is simple: before any code changes, you write a short document, a spec, that states what should change, what counts as done, and what should explicitly not be touched. The agent has to work from that file instead of from your last sentence in the chat.

The reason this matters is that an agent re-reads the spec at every step. It cannot drift into rewriting a page it was never asked to touch, because the boundary is written down, not implied. The one rule that matters most: a good spec has almost no open assumptions. Every “it probably means” in a spec is a place where the agent will later guess wrong.

There are heavier versions of this (multi-agent orchestration, large skill libraries) built for full engineering teams. We tried looking at those and they were overkill for a marketing team doing this on the side. We picked a lightweight version instead: five steps, no extra tooling beyond what already runs in our editor.

The five steps we actually use

1. Specify. Describe the change in plain language. The agent turns it into a spec: intent, what success looks like, and explicitly, what is out of scope.
2. Clarify. The agent asks a short list of targeted questions about anything the spec left vague. This is the step we used to skip, and skipping it is exactly where the “one color changed” problem came from.
3. Plan. The agent turns the clarified spec into a technical plan: which files, which components, which decisions.
4. Tasks. The plan becomes a checklist of small, ordered tasks, each one small enough to verify on its own.
5. Implement. Only now does the agent write code, task by task, checking its own work against the plan as it goes.

The human job does not disappear in this workflow, it moves. Instead of reacting to a finished (and sometimes wrong) result, we read and correct the spec and the task list before any code is written. That is a five-minute read instead of a twenty-minute “no, not like that.”

A real example: shipping the blog without a mess

We used this exact workflow to add the mega menus and the blog section you are reading this on. Both started as a spec: what the navigation needed to support, which content types existed, what “done” looked like for the visual cards on the blog overview page. Each spec turned into a task list before a single component was built.

The difference from our old way of working was not speed, it was that nothing had to be redone. No section got half-changed. No color got touched that was not meant to be. The parts that took the longest were the spec and the review of the task list, which is exactly where we want the time to go, since that is where mistakes are cheap to catch.

What we deliberately did not build

One decision from the same process is worth calling out: we did not build a full content management system for the blog. A CMS means API calls for images, an asset pipeline, and ongoing complexity for very little gain when one person is publishing a handful of articles a month. Instead, each article is a single file, written directly into the codebase. The only real cost is that publishing a new article means a code change rather than a form submission, and for our volume that trade was an easy one.

Where to start

If your team is in the same spot, before you add any new tool:

• Write the spec before you touch the chat window again. One paragraph on what should change, one list of what should not.
• Read the agent’s own clarifying questions instead of skipping to “yes, go ahead.” They are usually pointing at the exact ambiguity that caused last time’s mess.
• Review the task list, not just the final result. It is far cheaper to redirect five tasks than to undo a finished implementation.

Frequently asked questions

Do I need a developer on the team to use this workflow? No. The whole point of writing a spec first is that someone without a technical background can review it and catch a wrong direction before any code exists, which is harder to do once a change is already built.

Isn’t writing a spec slower than just asking the agent directly? For a one-line color change, yes, it is extra overhead you do not need. For anything that touches more than one file or more than one page, the spec step is what prevents the rework that actually costs the most time.

What’s the difference between this and a full engineering spec process? Heavier frameworks add multiple nested skill libraries and an orchestration layer across many parallel workstreams, built for engineering teams running several changes at once. A lightweight version keeps it to five steps and no extra tooling, which is enough for a small team shipping one change at a time.

Why not use a CMS for the blog instead of files in the codebase? A CMS earns its complexity once you have multiple non-technical authors publishing frequently and need image uploads through a UI. At our volume, one file per article was simpler to build and maintain, even though it means a code change per post.

What happens when the agent’s plan still misses something? That is what the clarifying-questions step is for: it is cheaper to answer five pointed questions about the plan than to discover a missing piece after the code is already written.

Can this workflow handle a full redesign, not just small fixes? Yes, but a large change should be broken into several smaller specs rather than one giant one. A spec with too much scope starts to carry the same risk as no spec at all: it gets vague, and vague is where an agent starts guessing.

Sources

• GitHub Spec Kit: the open-source spec-driven development workflow (specify, clarify, plan, tasks, implement) this article describes.