Hello again! Long time no see =)

Are you tokenmaxxing? I’m not!

I use Cursor on the roughly €20 subscription tier, and I do basically 100% of my frontend work with AI: JavaScript, HTML, CSS, the whole thing. Still, I never hit the limits.

Most people overspend because they ask the model to regenerate boilerplate code. All the time. Especially if you are a vibe coder who has never coded before. They ask it to scaffold controllers, models, routes, forms, and migrations from scratch. Then do it again on the next feature. Of course the bill goes up.

Token cost scales with how much you send and how much you get back. If every request is a dump of files and a request to reinvent the same wiring, you are paying for noise.

This is where Rails changes the math.

Rails has been doing convention over configuration for decades. You do not negotiate where the model lives, how the controller is named, or how a form is wired every single time. The framework already decided a lot of that for you. You realize that when you sit down with an LLM and notice how many decisions you no longer have to explain. I know you can use agent skills / custom instructions for that, but it’s not the same.

Rails has generators! bin/rails generate scaffold and friends have been vibe coding since before vibe coding was a phrase. You ask Rails for a resource, and you get models, migrations, controllers, views, routes, the boring path already laid out. The LLM does not need to invent that structure. It can work on top of it.

That is the split that works for me. Rails handles structure and boilerplate. The LLM handles the custom logic, the polish, the edge cases, the UI details I actually care about. Fewer prompts. Smaller prompts. Less token waste.

I think this is also why LLMs tend to perform well with Rails. The structure is predictable. The conventions are strong. There is less random boilerplate floating around for the model to guess at. A friend who has mostly lived in PHP and Node said it better than I could: both can be great, but the amount of decisions you have to make before writing a single endpoint is exhausting. Structured code makes better predictions. Rails gives you that structure for free.

So if you feel like you are burning tokens for no reason, try this playbook.

Use the generators first. Let Rails create the skeleton. Then bring the LLM in for the interesting part.

Prompt for a targeted change, not the entire repository. The model does not need every file every time. More context is not always better. Sometimes it just gets lost in the middle and starts answering from the wrong place.

When you do use AI, ask for refactors, UI improvements, and edge case handling. That is where it shines. Asking it to rebuild what rails generate already knows how to build is an expensive hobby.

Of course this is not magic. Scaffolds are great for conventional CRUD. They will not design your complex domain for you. Frontend-heavy apps, or stacks without strong conventions, will probably eat more tokens no matter how careful you are. And I am not saying Rails makes AI free. I am saying it makes heavy AI use a lot more efficient.

High AI usage does not have to mean high token burn. Workflow design matters more than usage intensity. Strong framework conventions plus focused prompts are the real advantage. Rails figured out half of that problem years ago.

So, tired of tokenmaxxing? Go with Rails.