Claude Sonnet 5 Hands-On: Full Process for Optimizing Oversized Astro Chunks

The Key Point: This Is a Solution-Level Test, Not Direct Production Code Changes

I didn’t use Claude Sonnet 5 to run a demo, nor did I have it directly modify the production branch of XBSTACK. A truly valuable test should be conducted on an already live site with historical baggage and conversion goals. The Astro build for XBSTACK is currently running smoothly, but there are still a few obvious frontend issues: large chunk sizes, a heavy CompoundCalculator component, and room for further splitting in the Search component’s loading strategy. For this round, I’m conducting a solution-level test: I’m only checking whether Claude Sonnet 5 can read the build logs, narrow down the problem scope, propose low-risk code-splitting strategies, and flag areas that shouldn’t be touched carelessly.

Why Test on a Real Website Instead of a Demo?

Many AI coding tools look impressive in demos: create a new project, generate a few components, run the tests, and everything looks great.

But real projects aren’t like that.

Real projects contain legacy code, page conversion goals, SEO requirements, SSR setups, search indexing, utility pages, and compromises made just to get things launched. Just because an AI can write code in a demo doesn’t mean it understands which parts of a real website can be safely modified and which parts must not be touched.

XBSTACK is no longer just a simple blog; it’s a personal brand site and a long-term asset system. The site hosts AI content, utility pages, a compound interest calculator, an AI financial report assistant, Lunest, a search page, topic pages, and future conversion paths for ads, affiliate marketing, and tools. Therefore, when testing Claude Sonnet 5, I’m primarily concerned with three things:

First, can it understand the existing project structure?

Second, can it distinguish between “technically optimizable” and “business-critical areas that cannot be changed”?

Third, can it provide actionable, verifiable, and roll-back-able plans?

This isn’t an official release analysis, nor am I trying to prove which model is “the best.” I’m simply using the real-world Astro project at XBSTACK to evaluate engineering judgment, seeing exactly how far an AI coding Agent can assist with frontend performance optimization.

Current Issues at XBSTACK

The context for this test is that XBSTACK has recently completed a round of AI-driven frontend SEO content structure enhancements, implemented Pagefind search indexing, and enabled static generation for AI article detail pages. The build runs successfully now, but several frontend performance issues remain.

In the last build log, the largest frontend bottlenecks were concentrated in three areas: index JS at approximately 1.08MB, CompoundCalculator at approximately 350KB, and Search at approximately 72KB. While these don’t necessarily block the initial paint, they create technical debt affecting mobile experience, utility page load times, and subsequent conversions.

Especially for a tool page like the compound interest calculator, it’s not just a single page; it’s the entry point for future search traffic, internal linking from investment content, and tool conversions. When optimizing it, we can’t just look at bundle size; we also need to ensure users can use it properly, that the page remains understandable by search engines, and that it doesn’t slow down on mobile devices.

Therefore, my task for Claude Sonnet 5 wasn’t to “minimize my bundle size,” but rather:

Analyze the large frontend bundle issues in XBSTACK and propose low-risk optimization strategies without breaking Astro SSR, SEO, Pagefind search, or the utility page conversion paths.

This task is much closer to real-world development than simply “writing a component.”

Record of This Real-World Test

Test Round	Input Material	Claude Sonnet 5 Output	Adopted?	Current Result
Round 1	Build logs and large bundle size info	Split the issue into categories: homepage entry, CompoundCalculator, Search, and heavy dependencies	Yes	Clarified that this is not a single-point error, but a loading boundary issue
Round 2	Astro / React / Node SSR project context	Provided low-risk, medium-risk, and high-risk code-splitting paths	Partially	Prioritized lazy-loading for Search and on-demand loading for tool pages
Round 3	Business constraints for Search, Compound Calculator, and Pagefind	Warned about risks related to dynamic imports, client:idle, client:visible, hydration, and SEO	Yes	Temporarily refrained from letting AI directly modify production code
Round 4	Pre-release verification requirements	Suggested using npm run build, page regression, tool page regression, and Pagefind index confirmation to verify	Yes	Deferred code-level changes to a follow-up Builder Log post-mortem

This table also defines the scope of this article: this is not about “AI has already finished modifying production code,” but rather verifying whether it is suitable as a problem-identification assistant, solution-design assistant, and risk-review assistant within a Claude Code / AI Coding Agent workflow. Actual code modifications should only occur after working on an isolated branch, committing in small steps, and passing build verification.

Testing Boundaries: Read First, Don’t Rush to Change

I do not recommend asking AI to modify code right away.

For its first round of tasks, I gave it only three instructions:

1. Read the build logs to identify abnormally large chunks.
2. Analyze which components and dependencies these chunks might originate from.
3. Output optimization directions, but do not modify the code yet.

There are two benefits to this approach.

First, we can check if it misjudges the situation. For example, would it see a large file size and suggest dynamically importing everything? Or would it see React components and, ignoring the actual page interaction flow, suggest splitting them indiscriminately?

Second, it places the AI in the role of a “reviewer” rather than an “automated construction crew.” In real-world projects, the most valuable contribution of AI is often not writing the first line of code for you, but helping narrow down the scope of the problem.

Claude Sonnet 5 performed steadily in this round. It did not immediately suggest a massive refactoring; instead, it categorized the issues: whether the initial screen must load everything, whether interactive components can be delayed, whether tool-page components can be split by route, and whether search can wait for user triggers before initializing.

These judgment directions were correct.

Astro projects differ from standard React SPAs because they inherently follow an island hydration strategy. Not all React components need to be loaded initially, nor must all interactions be part of the initial screen load. The fact that Claude recognized this indicates it wasn’t just applying generic optimization templates.

Round 2: Let It Propose a Code-Splitting Plan

In the second round, I asked it to refine the plan further, but still prohibited direct code modifications.

This time, I required it to output plans graded by risk level:

Low Risk: Can be done immediately; easy to roll back if issues arise.

Medium Risk: Requires page regression testing.

High Risk: Do not attempt now; just document.

It identified three main low-risk directions.

First, lazy-load the Search component. Search should not be tightly coupled with the homepage’s initial screen load. Especially before the user clicks the search entry, there is no need to preload the full search logic.

Second, split the CompoundCalculator by page. The compound interest calculator is a core component of the tool page, but it should not impact the initial screen load of other pages. This component can remain fully loaded within the tool page, but should not be prematurely pulled in by the homepage or other non-tool pages.

Third, load heavy dependencies only on the pages that use them. Dependencies like charts, calculations, and search indexes should be evaluated based on whether they actually serve the current page. If they are only needed for a specific tool page, they should not pollute the global entry point.

These directions aren’t flashy, but real-world projects need exactly this kind of stability.

I don’t need an AI to give me a refactoring plan that looks impressive but actually breaks the site. I need it to tell me: where to start, why there, how to verify after the change, and how to roll back if something goes wrong.

Round 3: Pick a low-risk point to test, but first confirm business boundaries

When I actually modify code, I only start with one low-risk point.

Take the Search component, for example.

The search entry is usually not the most critical content on the initial screen, so it’s a good candidate for lazy loading. A safer approach isn’t to overhaul the search system immediately, but to adjust the loading timing: initialize the heavy resources only when the user clicks the search bar, focuses on the input field, or navigates to the search page.

This step is something Claude Sonnet 5 can provide clear guidance on, including dynamic imports, component boundaries, fallbacks, loading states, and error handling. However, this also reveals a point that requires human judgment:

It tends to push for more thorough optimizations.

For instance, it might suggest splitting the search component, search index, and search UI entirely. Technically sound, but for the current XBSTACK project, search isn’t the highest-traffic entry point, so there’s no need to overcomplicate things for just a few dozen kilobytes.

This is a typical issue with AI programming agents: they can propose far-reaching solutions, but they may not know which step is most valuable for the project at its current stage.

Independent developers using AI to modify their projects most often fall into the trap of being attracted by “more complete solutions,” ultimately turning a small optimization into a half-day refactoring effort.

Round 4: Building verification matters more than the answer itself

After the AI provides a solution, the real criterion isn’t how logical it sounds, but whether the build passes, whether the page loads normally, and whether the core paths remain intact.

My usual verification order is:

npm run build

Then look at:

A previous attempt failed validation: short-output:4->13. Correct those issues while preserving all content.

1. 构建是否成功
2. chunk 是否变小
3. 首页是否正常
4. 工具页是否正常
5. 搜索是否正常
6. Pagefind 是否还能索引
7. SEO 页面是否没有被破坏

If I were to continue with code-level optimization, I would focus on the Astro build “chunk too large” warnings, changes in Vite bundle analysis, and the impact of client:idle, client:visible, and dynamic imports on real-page user experience.

This step is non-negotiable.

Claude Sonnet 5 can help you analyze build logs and provide further fix suggestions based on errors. However, you must ultimately verify whether your changes affect page rendering, tool pages, or subsequent search traffic.

Especially for a site like XBSTACK, technical optimizations are tightly bound to operational goals. For example, the compound interest calculator component has a large footprint and might seem like a candidate for splitting; however, it also serves as a conversion entry point for future tool pages. You shouldn’t sacrifice actual user functionality just to make Lighthouse scores look better.

What It Does Well

Based on this test, Claude Sonnet 5 has several areas that fit well into real-world projects.

First, it is good at reading build logs.

Often, we don’t lack the ability to fix issues; we just don’t want to spend time tracing through logs line by line. AI can help list suspicious chunks, components, and dependencies first, allowing you to move faster into the decision-making phase.

Second, it is good at stratifying solutions.

It can categorize tasks into “can be changed now,” “needs testing before changing,” and “should not be changed yet.” This capability is more valuable than simply generating code.

Third, it is good at providing risk alerts.

For instance, it will warn about potential loading states, error boundaries, SSR differences, and hydration issues associated with dynamic imports. These alerts may not always be complete, but they reduce the risk of overlooking critical problems.

Fourth, it works well as a code review partner within Claude Code.

Before modifying a component, you can have it review the scope of changes and ask whether it will affect page rendering, SEO, tool page functionality, or user paths. This approach is much safer than simply asking AI to make major changes directly.

Where It Is Unreliable

However, I would not treat Claude Sonnet 5 as an autonomous developer.

There are several areas where it is unreliable.

First, it may over-optimize.

AI tends to escalate a local issue into a system-wide refactoring. For example, if a search component loads heavily, it might suggest refactoring the search state, index loading, UI structure, and routing strategy. While these changes aren’t inherently bad, they may not be worth the effort at this stage.

Second, it may not understand your business priorities.

It knows that large chunks are bad, but it doesn’t know how important the compound interest calculator is for driving traffic to XBSTACK’s future tool pages. That judgment must come from a human.

Third, it may ignore real-world release workflows.

AI can generate code, but it won’t proactively remind you to maintain small commits, use separate branches, perform page regression testing, or prepare rollback plans. You need to include these requirements in your prompts.

Fourth, its solutions often appear overly comprehensive.

This is actually dangerous because the more complete a solution looks, the more likely you are to let your guard down. In real projects, comprehensiveness does not equal correctness; what matters is verifiability, rollback capability, and deployability.

Why Test Claude First Instead of GPT-5.5, Gemini, or GLM?

The goal here wasn’t to prove that Claude Sonnet 5 is the strongest, but rather to establish a workflow for an AI programming agent within a real project.

GPT-5.5, Gemini, and GLM are all worth testing, but they are better suited for a comparative review in a follow-up article. A proper comparison requires unified tasks, prompts, code repositories, and validation standards. Otherwise, it easily devolves into impression-based comparisons: who gives longer answers, who sounds more confident, or who seems more familiar with the project.

In the next article, I will use the same XBSTACK build records, the same set of prompts, and the same optimization goals to run GPT-5.5, Gemini, and GLM side-by-side, to see which one acts most like a true programming partner capable of taking over the project.

I prefer to compare them using the same XBSTACK task benchmark:

1. Can it understand the project structure of an Astro / React / Node SSR application?
2. Can it identify the causes of oversized chunks?
3. Can it propose actionable code-splitting strategies?
4. Will it break SSR, SEO, or hydration?
5. Can it control the scope of changes?
6. Will it proactively flag risks and suggest rollback plans?
7. Can it continue fixing issues based on the results from npm run build?
8. Is it suitable for Claude Code, Cursor, CLI Agents, or other programming toolchains?

So today’s article only answers one question:

Can Claude Sonnet 5 help independent developers reduce the time spent on problem identification and solution design in a real-world Astro website performance optimization task?

GPT-5.5, Gemini, and GLM will be covered in separate comparative reviews using the same task benchmark to ensure the conclusions remain focused.

How can independent developers safely use AI coding agents?

My advice is: don’t treat AI as an outsourcing partner, and don’t treat it as autonomous driving.

A more stable approach is to place AI in three specific roles.

First, as a problem identification assistant.

Feed it build logs, error messages, and project structures, and let it help narrow down the issue scope.

Second, as a solution design assistant.

Have it provide low-risk, medium-risk, and high-risk options, explaining the trade-offs of each.

Third, as a code review assistant.

Before you commit, have it check whether your changes break SSR, SEO, routing, utility pages, search functionality, or the build process.

However, the final decision to deploy must always come from a human.

Especially for personal websites, not every optimization is worth doing immediately. Saving a few dozen kilobytes on a single page may not be as valuable as publishing another article that drives search traffic. Technical optimizations should serve operational goals rather than becoming yet another time-sink.

Conclusion: Worth using, but don’t hand over full automation

Based on this test, my assessment of Claude Sonnet 5 is:

It is well-suited for reading code in real projects, analyzing build logs, troubleshooting frontend performance, designing refactoring strategies, and providing risk warnings.

It is not suitable for directly modifying production projects without test commands, rollback plans, or human judgment.

For independent developers, the most valuable aspect of Claude Sonnet 5 is not “writing code for you,” but helping you shorten the time spent identifying problems and designing solutions. It allows you to quickly figure out where to start, but it cannot decide what is most worth doing.

This is also the most realistic role for AI coding agents today:

Not fully autonomous programmers, but technical partners who help you avoid detours.

FAQ

Is Claude Sonnet 5 suitable for directly modifying production projects?

Directly modifying the production branch is not recommended. A safer approach is to first have it read the logs and code structure, generate a modification plan, then make small incremental changes in a separate branch, and verify them through builds and page regression tests.

What is the relationship between Claude Sonnet 5 and Claude Code?

Claude Sonnet 5 is the model, while Claude Code is one of the tool scenarios that uses this model for coding tasks. The experience is influenced less by the model name itself and more by the combination of model capabilities, context, tool calling, project structure, and verification workflows.

Must oversized Astro chunks always be optimized?

Not necessarily. It depends on whether they affect the initial render, mobile loading times, interactive experience, or conversion rates on utility pages. If large chunks only appear on low-traffic backend pages, the priority can be lowered; if they impact the homepage, search pages, or utility pages, they are worth addressing.

What are the risks of using AI coding agents to optimize frontend projects?

The main risks include over-refactoring, breaking SSR, impacting SEO, introducing hydration issues, and disrupting conversion paths on utility pages. AI-generated solutions require human judgment and shouldn’t be accepted just because they look complete.

Why doesn’t this article directly compare GPT-5.5, Gemini, and GLM?

Because the core purpose of this article is to first validate the AI coding agent workflow using a real Astro project, rather than determining which model is the strongest. GPT-5.5, Gemini, and GLM are better suited for a separate horizontal comparison later using the same task benchmark.

Continue Reading

• Kimi K3 Real-Project Test: Strong Cross-File Analysis, but Final Decisions Still Need Human Review
• GPT5.6 Real-world Project, Content Creation, and Data Analysis Case Study
• AI Tool Benchmarking
• Engineering Practice Cases
• AI Agent Engineering Series
• Compound Interest Calculator
• Off-site Distribution UTM Tracking Loop