I Rewrote a Years-Old Java Blog with CodeBuddy and GLM-5.3-Flash

Ask the internet which AI coding tool to buy and every review measures the same thing: the flagship model tier. Almost nobody tests the question that actually decides your bill — can the budget model, given a strong agent, do real work? So this is a field report, not a vibe check. The target: a personal blog that had been running for years on Java, jQuery and Bootstrap. The job: rewrite it into a Rust backend serving hand-rolled HTML. The tool: CodeBuddy. The model: GLM-5.3-Flash. The time: one focused weekend.

1. The stack, before and after

Two things to notice about that table. First, the rewrite removed frameworks, not capabilities — every page the old blog served, the new one serves. Second, nothing here is exotic: a Rust HTTP backend rendering HTML templates is a boring, well-trodden design. That boringness is the point. A rewrite is mostly scaffolding, template plumbing and style discipline — exactly the work AI agents are good at, and exactly the work that made maintaining the old site feel heavier than it should.

2. What a weekend of agent work looked like

A rewrite has a property few software projects have: the acceptance bar already exists. The old site, page by page, defines what "done" means — same content, same links, and it should read better. That single fact changes everything about using a coding agent: you are not asking it to guess what you want, you are asking it to match something you can both see.

The work in CodeBuddy ran as a conversation over the repository. The agent could read the old code and the new tree in the same workspace, so most turns were: a directive ("set up the Rust server with these routes", "build the article template from this old page"), a pass of writes, then a review against the old page in a browser. Day one went to the skeleton — server, templates, the global stylesheet. Day two went to content pages and polish. Neither day had a long dark stretch of copying boilerplate around, which is what consumed the original build years ago.

The honest version of "it was fast": the speed did not come from the AI typing quickly. It came from skipping the parts of frontend work that are pure labor — scaffolding, template duplication, nudging CSS by three pixels until it looks right. Those went to the agent in bulk. What remained for me was judgment, which is the part I would have kept anyway.

3. Three things that surprised me

The first-pass rate

The working assumption most people carry from chatbots is that AI code is a draft you rewrite. With a full agent harness on a task this well-defined, that assumption flipped: most pages and modules arrived correct on the first pass — markup, template logic, even the Rust plumbing. Rework happened at the edges, not in the middle. The practical consequence is bigger than the time saved: when first passes are usually right, you stop micro-reviewing and start spot-checking, and that is what makes a weekend scale to a whole site.

The style consistency

This was the genuine shock. Consistency was supposed to be AI's weakness — every file written by a different mood. What actually happened: the agent holds its own conventions better than I held mine. It commits to a spacing scale, a type scale and a palette early, and then — because it re-reads the global stylesheet and shared templates on every pass — it applies them with a discipline I never managed across years of patching a Bootstrap theme. The old blog drifted because I was overriding defaults I didn't control. The new one can't drift the same way: there are no defaults to fight, and the convention lives in files the agent always sees before it writes.

The aesthetic result is hard to overstate for anyone who has fought a CSS framework: the site looks like one site. Not "Bootstrap with modifications", not a patchwork of vintages — one voice, in every page, because one system produced it.

The weight

The old stack paid a framework tax on every request, and the folder it lived in told the story: more than 20 MB of static assets — jQuery, Bootstrap, Font Awesome, a wangEditor build, assorted theme files, some of it possibly referenced by nothing. The new site's entire static footprint, measured live at publication time, is the HTML, one 15.5 KB stylesheet and a 4 KB favicon — about 22 KB in total — and the homepage document itself is 2.4 KB. Nothing arrives before the text, because there is nothing left to arrive first.

The server got the same treatment. The old Java process idled above 500 MB of RAM; the Rust backend serves the same pages from about 13 MB — under 3% of the memory for the same site, and a fraction of the deployment anxiety that comes with it. This is the same philosophy this site runs on, and after living on both sides, the lightweight side isn't a compromise. It's just the same site, minus the ballast.

4. Where it needed me

None of this means the agent ran unattended. My actual jobs were three:

• Define done. The old site was the acceptance bar, and holding the agent to it page by page was the difference between a rewrite and a mess. "Same content, reads better" is a checkable sentence; "make it nice" is not.
• Cut scope. An agent will happily implement everything you mention, and a decade-old blog mentions a lot. Deciding what the site no longer needed stayed human work — and mattered more than any prompt I wrote.
• Own the taste calls. Where two acceptable designs diverged, picking one took seconds and ended the discussion. That judgment isn't in the model's context and shouldn't be; the point of the tool is that it executes a decision, not that it makes it.

One habit solved most disagreements cheaply: instead of hand-patching a file I didn't like, I had the agent re-read the global stylesheet and redo the page against it. Fix the convention, not the instance — the agent then keeps the fix everywhere, which is exactly what hand-patching never does.

5. What this says about budget models

Three rules I'd carry to the next project:

• Rewrites and migrations are the budget model's home turf. Clear boundaries, an existing artifact as the acceptance bar, and verification you can do by eye. If you want to find out what a cheap model can do, this is the task shape to test it on.
• Test models by task shape, not by leaderboard. The question is never "is model X good" but "is model X good at this". It is the same logic we apply to API model tiers on the DeepSeek side — the Flash vs Pro decision rules there come from the same principle: run your own workload, keep what wins.
• Reserve the expensive model for the fuzzy parts. Architecture decisions, requirements still taking shape, design without a reference — that's where flagships earn their price. Turning an already-made decision into working code is not that problem, and paying flagship rates for it is its own kind of waste. How much that waste costs is measurable: the cost calculator shows what tier-vs-tier money looks like when it is priced per token.

6. FAQ

Sources

Tool and model facts on this page are traceable to these pages, checked 6 Sep 2026:

• CodeBuddy — official site — what the tool is, agent workflow, model options including the GLM tier used here.
• CodeBuddy — Pricing — Free plan promotional terms (all models selectable during the free period).
• Z.ai — the GLM model family; GLM-5.3-Flash is its lightweight tier.
• Novita AI — LLM model library — GLM-5.3-Flash hosted serverless: $0.075/$0.25 per million tokens, 1M context (launch discount, checked 6 Sep 2026).
• The rewritten blog — live — the artifact this report is about; every page-weight figure above is reproducible from your browser's dev tools.

Everything else on this page is first-hand experience, not a benchmark: one project, one tool, one model version, reported as it happened. Page weights were measured from the live site on 6 Sep 2026; the memory figures come from the author's own deployment records and are not independently re-verifiable. We publish it because reviews that only test flagship tiers leave the budget-model question unanswered — and because this site itself runs on the no-framework, content-first approach described above. Tool capabilities move fast; treat this as a data point and verify current behavior against the official docs.