How I helped build our website with AI, without an engineering background
Some time ago Valentin, our Head of Internal IT, wrote a post about how his day-to-day has changed now that pull requests come from us in Marketing and HR too, not just from the developers. Here is the same story from my side.
I work in Marketing at Posedio. Writing code was never part of my job. In March I was still asking what a feature branch was, and whether main was up to date. Since then I have opened dozens of pull requests for our new website: the design unified across the whole site, the hero images optimized for mobile, our Design Document as a Service page, a newsletter landing page, an SEO pass over the main pages.
Almost none of that came from learning to code. What changed is how I ask for things, how I check them, and where I stop and hand over. That is the order this post follows.
What AI could not build for me
My share of this was only possible because the dev team had built the foundation before I started. They picked the tech stack (Astro, Strapi, Google Cloud), set up the CI pipeline, configured preview environments, designed the i18n architecture and wrote the coding conventions into a CLAUDE.md.
AI helped me work inside what they had built. It could never have built it for me. Everything below only makes sense with that in place.
How I ask: from one-liners to instructions that work
My early instructions were one-liners. "Set the h1 to 36 px." "Get rid of the white bar." They worked whenever the AI guessed right about what I meant, and often it guessed wrong: the wrong file, the wrong language version, the element next to the one I was looking at. I also did not know yet that "I checked it in the browser" often means it looked at the page structure rather than at what the page looks like. Twice I went to look myself and nothing had changed at all.
The one I still think about was a heading. "Set the h1 on the blog detail page to 36 px, desktop only." We edited CSS for a while with no effect whatsoever, because the blog pulls its body through the main page component, so the file I had picked never applied to anything. An engineer would have seen that in seconds. AI cheerfully kept editing exactly what I had pointed at.
Two things came out of that stretch. My instructions got longer and duller, because what comes back depends on how precisely the question is put. And I learned to push back: "I think we are talking past each other." "What did you just change?" That sounds too obvious to mention, and without it you end up with a result that looks plausible and is quietly wrong.
Later I started stating the frame before the work instead of during it. Answer in German. Keep DE and EN in parity. No commits without my approval. Mobile only unless I say otherwise. Those four lines save us both an enormous amount of back and forth.
The same curve shows up in my commits. My first ones went into the repository in March, and looking at them today is mildly painful. One is called "Mobile & design refinements: text clipping, colors, logos, button styles", four unrelated changes bundled up for Valentin to review as a single lump. Back then I also just typed "create a PR" without actually knowing what a pull request was. I typed the words because I was told to do so in the beginning, not because I understood what happened between them and my change showing up on the site. Nearly eighty commits later, mine look like "fix: keep sticky TOC clear of the site header". One thing each, and I could tell you what is in every one of them.
How I check: from fixing symptoms to planning work
For a good while everything I did was a reaction to something visible. Lighthouse flags an image, someone spots a misspelled name, a heading looks too small. The hero image was one of those: AI showed me how to bring the cloud image down to 1600 px, generate an 800 px mobile variant, set up a <picture> element with srcset, and add imagesrcset to the <link rel="preload">. I had no idea any of that existed, but I could check the result myself. Unifying the design was the same mode stretched out, page by page, until the whole site felt like one thing again.
Then it shifted. For the SEO work I stopped fixing single pages as I noticed them: an audit of the main pages first, then priorities, then one pull request. I also started asking for opinions instead of dictating details. Which keywords are worth having, is this meta description any good. Roughly how I would work with an agency. On the newsletter landing page the first version was up in ten minutes, and then I iterated five or six times on the details.
The page where that way of working got its real test was a bigger one.
The page I spent the most time on
The Design Document is what a customer or potential customer gets from us before we write any code: the planned architecture, the phases, a fixed price, a risk table with an owner for each entry. Describing that in one sentence on the services page never did it justice, so we built a page that shows one. It is live here: Design Document as a Service.
The page does two jobs. It explains how the document comes about, as a sequence of workshop, stop-or-go decision, first draft, review session and approval. And it walks through a complete worked example: the architecture, the phases on a timeline, non-functional requirements rated across categories like reliability and maintainability, the maturity levels from internal tooling up to something public and customer-facing, the cost implications with a payback period, the risk table, a glossary. It ended up at roughly 2,000 lines across seven files.
What worked well was the division of labour. The content came from Sales and Technology, because they are the people who write these documents for customers and know what belongs in one. My part started after that: turning it into a page that reads well. I had no idea how to build a sticky table of contents, a phase timeline or ratings with tooltips, and I did not need to. I described what a section should do, and the first version usually came back close enough to react to.
What did not work well was phones. The desktop version came together in two days. On the phone the sticky table of contents slid underneath the site header and the hero icon escaped the viewport on short screens, and none of that had come up while we were building it. AI will build you a layout that works at the width you happen to be looking at. It does not think about a 375 px screen unless you say so.
The first version was also not the last. In a review with Sales and Technology we went through the example document again, and the notes and the architecture section came back rewritten. My job was getting the new content into the page. Around each round, Valentin and the pipeline regenerated the visual regression baselines, the reference screenshots our CI compares every page against so an unintended layout change shows up before anything gets merged.
Where I hand over
Our site exists in DE and EN, and mixing those up is by far my most common mistake. I change something on one page and forget that the counterpart in /en/ exists too. It happens in the other direction as well: I edit a shared .astro file without noticing that the English site imports it too, so fixing one language breaks the other. On the Design Document page I shipped the German version with the chapter titles, the navigation and the section chips still in English, and only noticed afterwards. AI handles this reliably once you point it out, but it rarely thinks of it on its own.
Then there is the category I deliberately do not touch alone. GDPR questions, connecting the contact form to the API backend, the Turnstile integration. AI will give me an answer for all of those, and I do not want to be the only person who has looked at it. That is the same argument Valentin makes about human oversight, only from the other side of the review.
Review is the part that has not changed. Valentin still reads through every pull request in detail. When something does not fit he points it out, I fix it and update the PR, and once it is right he merges. Lint, the build and our visual regression tests catch a part of it before he even looks, and none of that replaces the step. I have never merged anything into main myself, and I do not want to.
What changed for the rest of us
Our old site ran on Wix, and every change on it was a ticket for internal IT. Fixing a line of copy, adding a tag, adjusting a button, and each one went into someone else's queue. Those tickets do not get filed anymore. The ones that really need an engineer still do, and there is more time to do them properly.
The quality bar did not move to make room for that. Without the review step my pull requests might have been functional, but not what Valentin calls "senior frontend engineer quality."
Website changes used to be something I requested and then waited for. Now they are something I do, and they sit on my to-do list.
What I learned, and what I did not
I did not turn into a developer. I know now when you need to rebase, but not because I understand what Git does under the hood. I still ask when I am unsure, and I still refuse to hand over a pull request I have not looked at myself.
What I can do is take a change from an idea to a pull request that is ready for review, without blocking anyone, in hours instead of weeks.
This only works as a team thing. AI on its own would never have made me a PR author, and the engineers on their own would never have had the time for all these small changes, or known what to do about SEO or a brand guideline.
And like Valentin writes at the end of his post: honestly, I think that is pretty cool.
