Who changes what, once the site is live

A migration usually ends with a promise: marketing edits the content, developers own the code, and nobody waits for anybody. Then the first week happens. Somebody wants to change the order of three sections on the pricing page, and it turns out that is neither content nor code, or it is both, and the promise was not specific enough to say.

The division that survives is not content against code. It is who has to look at a change before it reaches a visitor.

Three kinds of change, not two

Sort the work by review instead of by storage and the boundaries stop moving. Almost everything a marketing site needs falls into one of three groups.

The first is a change that is safe on its own. New copy, a new blog post, a swapped image, a price in a table, a member added to a team listing. One person writes it, one person checks it reads well, and it goes out. Nothing else on the site can break because of it.

The second is a change that is safe because the options are fixed. Reordering sections on a page, choosing which of four layouts a case study uses, turning a banner on. Somebody is assembling from parts that were built and reviewed already, so the result is new but the pieces are not.

The third is a change to the parts themselves. A new section type, a change to how the navigation behaves, a component that every page uses. These are reviewed differently because the blast radius is different: the person making the change has to know what else consumes it.

Where the second group usually goes wrong

The middle group is the one teams get wrong, and they get it wrong in both directions.

Lock it down and marketing files a ticket to move two sections, which is the exact outcome the migration was supposed to end. The request is trivial, the queue is not, and within two months the team has gone back to asking rather than doing.

Open it up without constraints and the site drifts. Give people a free-form page builder and within a quarter there are four heading sizes that were never in the design, six spacing values, and a page nobody wants to show a client. Nothing broke. The site is just no longer the thing that was built.

What holds is a fixed menu. A page is assembled from a named set of sections, each with a small number of settings, and the settings are the ones that were designed to vary. A section can be reordered, removed, and given its copy and images. It cannot be given an arbitrary typeface.

That constraint is a modeling decision and it is made during the rebuild. It is cheap then and expensive later, which is the main reason to think about this before the site is built rather than after the first complaint.

Agents do not change the answer

A coding agent is a fast contributor, not a new category. It belongs in the third group: it can make a change to the parts, and the change still has to be reviewed by somebody who can say what else consumes it.

What an agent does change is the cost of the third group. Work that used to need a developer with context now needs a reviewer with context, which is a smaller ask. That only holds if the repository states its patterns and the checks catch the mistakes, which is a property of the project rather than of the model and is covered in what makes a site safe for an agent to change.

It does not move anything out of the first group. Nobody needs an agent to publish a blog post, and routing editorial work through a code review is how you end up back where you started.

Write the split down

The failure mode is not choosing wrong. It is never choosing, and letting each request be argued on its own. Six weeks of that and the rule is whatever the last argument decided.

What good looks like after six months

The test is not whether the team can change the site. It is which changes still involve a conversation.

If copy, posts, images and page assembly are going out without one, and the conversations left are about new section types and shared behavior, the split is working. Those conversations are worth having, and there are a handful of them a quarter rather than several a week.

If the team is still asking for section reordering, the middle group was drawn too tight. If the site has quietly stopped looking like itself, it was drawn too loose. Both are fixable, and both are much cheaper to fix in the content model than in the habits people have already formed around it.