Our website design lives in one tool. Our live site is a HubSpot theme. For months, those two things drifted apart — and the reason turned out to be worth writing down, because it says something about where AI actually helps in a build workflow and where it does nothing at all.
This is an account of one working day rebuilding our own site with an AI in the loop. It includes the parts that went wrong, because those are the parts that taught us how to run it.
What were we actually trying to fix?
The complaint was vague in the way real complaints usually are: the live site didn't look like the design. Not one page — every page. The menus, the backgrounds, the animation, and the Hebrew version too.
Vague complaints are expensive. The obvious response is to work through the site page by page, comparing each one against the design and correcting the differences. On a site with dozens of pages in two languages, that is days of work, and it produces a long list of small fixes that never quite adds up to "it looks right now."
So the first job wasn't fixing anything. It was finding out whether there was one cause or fifty.
Why did the site look wrong on every page at once?
There was one cause. Two, strictly.
The design system used a single background treatment on every dark band across the site — a layered gradient with animated colour behind it. That treatment appeared in the design source 42 times across 27 files. It had never been ported into the theme. Every dark section on the live site was rendering a flat colour instead.
The same thing had happened at the other end of the palette: light sections used a soft vertical gradient in the design and a flat fill on the live site.
Two missing primitives. That was the whole thing. Every page inherited the gap, which is exactly why it showed up everywhere at once and why no individual page looked obviously broken — they were all consistently wrong together.
This is the part worth generalising. When something looks off everywhere, the cause is almost never everywhere. It's in something shared.
What did the AI get right?
Two things, decisively.
Finding the pattern. Reading an entire design codebase and counting how often a given treatment appears, then comparing that against a theme built in a different language with a different structure, is tedious and mechanical. That's the work that gets skipped when a person does it under time pressure — and skipping it is precisely what produces the page-by-page approach.
Porting faithfully. Once the gap was identified, translating the treatment from the design source into HubSpot's templating language was fast and exact. Same values, same timings, same layering.
Both of those are real gains. Neither is the interesting part.
Where did it go wrong?
Repeatedly, and this is the useful section.
The first attempt applied the background treatment to every dark section on the site. That was wrong — the design actually uses three different dark treatments, and applying the loudest one everywhere would have overridden the two quieter ones. Caught by comparing against the source rather than trusting the first plausible answer.
Fixing the backgrounds then broke something else. Two sections on our About page were built to read as one continuous block. Making one of them vivid while the other stayed flat turned an invisible join into a hard line across the page. The fix wasn't a fix — it created a new defect that only showed up visually.
A right-to-left bug got introduced into the Hebrew version by code written specifically to handle right-to-left. A CSS grid already mirrors itself in Hebrew; the "fix" mirrored it a second time and put a photograph on the wrong side.
An animation silently un-did a layout. An icon was centred with a transform, and a shared floating animation overwrote that transform on every frame — so the icon drifted off-centre, permanently, while the code looked correct.
And on the blog, a first pass at categorising posts produced 20 out of 34 identical covers, because it trusted tags that turned out to be applied loosely. It took three rounds against live data to get right.
None of these were caught by reasoning about the code. All of them were caught by looking at the running site.
So what actually changed in the workflow?
The verification loop became the product.
Every change went out, got measured on the live site, and got corrected. Not "does the code look right" — does the rendered page report the values we expect, does the Hebrew mirror, does anything end up invisible, did the thing we didn't touch stay untouched.
That last one mattered more than expected. One change would have wiped a dot pattern on the homepage by overwriting the property that drew it — and nothing would have looked broken. It would simply have been gone.
Three separate times, a deploy reported success in the terminal and hadn't actually reached the server. If we'd trusted the success message, we'd have spent the afternoon debugging code that was never running.
Eleven rounds of change went live that day, in both languages. The generation took minutes. The measuring, correcting and re-measuring took the day.
Should you put AI in your build loop?
Yes — provided you're honest about which half it's good at.
It is very good at the work humans skip: reading everything, counting, comparing, holding a whole codebase in view at once. That's where the root cause came from, and a human under deadline pressure would likely have started fixing pages instead.
It is not good at knowing whether its own work succeeded. It will produce a confident, plausible, wrong answer and move on. Every one of the failures above was found by checking the running system, never by re-reading the code.
So the question isn't whether AI can write the change. It's whether you have a loop that catches it when it's wrong. If you don't, you get speed without accuracy, which on a production site is worse than being slow.
We build HubSpot and Asana systems for B2B companies in Israel, and increasingly we build them with AI in the loop. The discipline that makes it work is the same discipline that makes any operations work: measure the thing that actually runs, not the thing you intended to build.
If you're adding AI to a workflow that touches production — your CRM, your site, your reporting — the loop matters more than the model. Book a 30-minute review and we'll look at where yours would catch a wrong answer, and where it wouldn't.
