I've reviewed a lot of pull requests this year. The ones I didn't expect to be reviewing came from our marketing team.

We've recently relaunched our website posedio.com and used the project to launch our new blog (you're reading it right now!). We also used it to run an experiment I genuinely wasn't sure would work: could our marketing department, none of whom write software for a living, build most of the new site and blog with AI and no-code tools, and produce something that actually meets our quality bar?

Spoiler: it worked 🎉. But the interesting part is why - keep reading to find out.

How it was until very recently

Every web project I'd led before followed the same script. Marketing hands us the content and the design, usually prototyped in tools like Figma. The dev team turns it into a site.

In practice that meant a lot of back-and-forth. I'd tweak small things that weren't quite right, or requirements would shift mid-build. The changes themselves were usually minor (good acceptance criteria help a lot here). But posting a screenshot to a ticket, analyzing the issue, and shipping the fix just takes some time, and a few minutes here and there add up fast over the course of a project.

This time we tore up the script.

What we did differently this time

Our Marketing and HR built most of our new site themselves, on their own machines, in Claude Code with a live preview of the development system running while they iterated. When something looked right, they opened a pull request using Claude Code. I reviewed it, sometimes pushed a cleanup commit on top, and merged. I owned the GCP infrastructure, the architecture, and the review gate.

What surprised me almost as much as the code was how fast our non-developers got comfortable with the workflow around it. Within a couple of weeks, words like git, branches, pipelines, merge conflicts, and pull requests were just part of how they talked about their day. They'd mention they'd pulled the main branch before pushing, and ask when I was finally going to review their PR 😉. The technical surface I'd assumed would be the main source of friction turned out not to be friction at all.

I did not expect this to work as well as it did.

The PRs were good. Like, actually good.

Every PR came in with a real title, a written-out changelog, and a test plan. The diffs were scoped. If you stripped the author name off and showed it to me, I would have almost believed it came from a senior frontend engineer. Almost - because honestly, it was too thorough. No engineer I know writes test plans that detailed unless someone is making them. Still, I still have to say that the PRs were formatted in a very easy-to-read way, way better than than a lot of PRs I've reviewed from developers I've worked with over the years.

I still read every diff. We've written before about why we think that human oversight matters on every project (you should really read that post too!), and that doesn't get a pass just because the PR author isn't a developer - if anything, it matters more. But the review work was the easiest I've done in a while, because the descriptions told me where to look. I still verified each change against the test plan and the actual diff, but the descriptions made that genuinely fast and were very accurate. The only case where it did not work well is when changes were pushed to the same PR after it was opened - there, the descriptions were then not updated by Claude.

Where I still had to do actual engineering

Not all of it was clean. The most consistent failure mode was code duplication across languages. The site is multilingual, and when Claude added a new component or content section, it would sometimes copy the same markup into each language version instead of factoring out a shared component. Or when our marketing told it that line hyphenation was off on mobile phones, Claude fixed the mobile version but broke the desktop one - just to name two examples.

When that happened, I'd pull the branch, refactor the repeated or broken bits into something maintainable, push a commit on top, and merge. This took me at most five to ten minutes each time and it kept the codebase from quietly rotting under us as we shipped.

That became the rhythm. Marketing or HR open the PR. Claude gets most of it correct. I clean up the seams. Everyone owns a piece of the workflow, and it worked well for us - but the "I clean up the seams" part isn't optional. It's the part that keeps this from turning into tech debt we'd regret in six months.

What actually made it work

A lot of what made this workflow possible was decided before our marketing team ever opened Claude Code. The dev team picked the stack - frontend framework, CMS, styling library, the whole infrastructure foundation with terraform - choosing tools aligned with our standards and the ones we already use on other projects. This means a non-developer's PR lands in code the rest of the team can read and extend on day one, and the AI is operating inside a stack we know how to debug, not whatever it would have reached for on its own.

Same goes for the boring infrastructure underneath. The repo was set up cleanly. CI ran on every PR and performed various checks. Preview environments worked. GCP was wired up so a a deploy was instantly testable on the test stage in the browser. The non-dev side of this looks magical only when the dev side underneath is in decent shape - not before.

The other thing that made it work is that someone was actually paying attention. The PRs were good in part because a human was going to read them. The cleanups happened because someone was watching the long-term shape of the codebase. Pull any of those threads out and the whole thing falls apart.

So, did it work?

Yes - but I want to be careful about how I say that, because it's easy to over-generalize from one project.

This is one encapsulated example: a public marketing site and a blog, built by a non-developer team inside a stack and an infrastructure that our engineers had already set up, with a developer reviewing every change. Under those conditions, developing with AI was a real win for us. We shipped a faster, better-looking site and a blog we're proud of, with marketing and HR contributing actual code into the repo. That wasn't on the table a year ago.

But it's also abundantly clear that without a developer in the loop, we wouldn't have ended up with an outcome we can be proud of. The stack had to be chosen by people who knew our standards. The infrastructure had to be built. The PRs had to be reviewed by someone who could read the diff. The merge conflicts had to be resolved by hand. The architectural cleanups had to come from someone who knew how it should belong to adhere to our standards. Take the developer out of this story and you don't get a faster project - you get something that may look correct on first glance, but does not adhere to our standards in terms of engineering quality.

To be fair about where the line falls: for an MVP or a quick prototype, the code coming out of these PRs is genuinely solid on its own. For our standards - a public, multilingual site we're going to maintain and extend for years - the human is still required.

I went in skeptical. Now at the end of the project, I'm really excited to see our marketing team opening PRs like it's nothing, and honestly, I think that is pretty neat.