Another framework, or a better conversation with AI?

It started with a small button

A theme toggle should be a small feature.

Click a button. Switch between light and dark. Remember the visitor’s preference.

This one lived on my marketing site, but the question it raised comes up in QuoteLogic all the time: does the solution fit the problem?

Working through it with Claude reminded me that building with AI involves more than getting code that works. The direction you give it matters, including when you step back and question the approach.

The framework worked. But did I need it?

My site uses Astro. When I needed a theme toggle, I reached for a Svelte component.

It worked. But it also introduced a framework runtime and supporting code for a feature that mostly needed to update an attribute and save a preference.

There was no complicated component tree to coordinate. No changing list to manage. The theme choice was already reflected in an attribute on the page.

Svelte wasn’t the problem. This particular feature just didn’t need much of what it offered.

A tool can be good at its job and still be more than the job requires.

Change the question. Change the solution.

“Build a Svelte component for this” gives AI a specific direction.

“What’s the simplest reliable way to handle this interaction?” leaves room to evaluate the approach.

That difference matters. When we name a framework in the request, we’ve already made an architectural choice. AI can help us work within that choice, but we can also invite it to examine whether the choice makes sense.

For my theme toggle, a small JavaScript implementation using browser APIs was enough. It could respond to a click, update the theme, and store the preference.

Replacing the component started with reconsidering what the feature needed. The implementation followed from there.

Less code. Same expectations.

A smaller implementation still had to do the whole job.

My site has theme controls in both the desktop and mobile navigation. Both need to reflect the same preference. The controls also need to keep working as visitors navigate between pages.

Then there’s the initial theme. A returning visitor may have a saved choice. A new visitor gets the dark default.

Those requirements didn’t disappear when I removed the component.

Neither did the responsibility for handling them. Without the framework component, I had to account for attaching event handlers and keeping them working through page transitions without duplicating them.

Simplifying was worthwhile only if the replacement preserved the behavior users needed.

Where AI made a difference

Claude helped me work through those details and verify the replacement.

That was valuable because the first successful click doesn’t tell you much about the other cases. Multiple controls, saved preferences, and page navigation all deserve attention.

I had to guide that process. I explained the intended behavior, questioned the approach, and reviewed the result.

AI made the checking more manageable. That helped me move beyond “it seems to work” and keep evaluating whether the simpler implementation was sufficient.

This is one of the most useful ways to work with AI: include it in the review of the solution, as well as its implementation.

Give it the requirements. Ask it to identify cases you may have missed. Have it help verify the behavior. Then evaluate the evidence it gives you.

Easy to add. More work to maintain.

The same speed that makes AI helpful can make scope harder to control.

Another feature is easy to request. So is another library or an abstraction for something the project might need later.

Each addition can sound reasonable on its own. Together, they can make a straightforward project take longer to finish and become harder to maintain.

Users can feel the consequences, too. Extra JavaScript delivered to the browser can add downloading and processing time. The impact depends on what ships and how it runs, which is why checking the output matters.

Building with AI still requires boundaries.

Explain what the project needs to accomplish, what performance expectations matter, and what counts as finished. When a proposed addition expands that scope, pause and decide whether the benefit justifies it.

Generating code quickly doesn’t make that code free to keep.

What the replacement left behind

Replacing the component didn’t finish the cleanup.

The old integration and dependency remained in the project until a later audit. The visible feature had changed, but some of the machinery supporting the previous version was still there.

Nothing about a working button tells you whether that cleanup is complete.

That takes a broader review of dependencies, configuration, and build output. It also means distinguishing between something that remains installed and something users actually download.

AI can help with that review, too. After replacing an implementation, include a follow-up task: identify what the old approach left behind, check whether anything still uses it, and verify what can be removed.

Cleanup belongs in the definition of done.

Sometimes the framework is the right choice

A theme toggle and a complex application have different needs.

When an interface involves coordinated state, changing lists, or forms with interdependent fields, a framework can make those responsibilities easier to manage.

Avoiding a framework at all costs can leave you building and maintaining your own version of the same machinery.

I know that tradeoff firsthand. QuoteLogic runs on its own state manager. That was a deliberate choice, and I maintain what it costs.

The question is whether a framework’s benefits justify what it adds.

For this feature, browser APIs were enough. For another, a framework could be the sensible choice from the beginning. Team familiarity and the work required to maintain the result matter, too.

A better conversation with AI should make room for those tradeoffs. The goal is a solution that fits.

Start your next AI conversation here

Before asking AI to implement a feature, describe the problem and its constraints. Then work through questions like these:

• What’s the simplest approach that meets these requirements?
• What would a framework help us manage here?
• What complexity would each option add?
• How could the choice affect loading and maintenance?
• How will we verify the behavior and clean up anything we replace?

You don’t need a lengthy architecture discussion for every button. But a brief pause before implementation can expose assumptions that would otherwise become code.

My theme toggle was a small example of that. AI helped me work through the change, but I still had to steer, evaluate, and decide when the solution was complete.

The same pause works on a quoting workflow in QuoteLogic as well as it does on a button.

The next time you reach for another framework, bring that decision into the conversation. AI can help you examine the choice before helping you build it.