you do not need a smarter model, you need to be smarter

Chapters

Let me start by confessing one of my vices: for months, every time a project got stuck, my first reaction was switching models. DeepSeek hallucinated? Let’s try Gemini Flash. Flash got dumb on long context? Test GPT 5.5. Did 5.5 eat my quota? There is Luna, there is a promo, there is a free quota here and there. I collected LLMs like someone collecting screwdrivers thinking the problem is the tool — when really I was trying to assemble furniture without reading the manual. Which I had never written myself.

This text is a rant, but a rant with love. Because I was exactly the person it applies to.

The symptom: switching models

Notice the pattern: the code comes out bad, and the conclusion is “I need a smarter model.” It is almost never “I need to think harder about what I am asking for.” A weak model with a well-thought-out project produces more than a strong model grazing on a directionless repository. I know because I tested both ways, several times, and the second scenario cost me more time than I would like to admit.

It works like this: without clear requirements, without architecture, without context, the agent — any agent, cheapest or priciest — fills the gaps with statistical guessing. And statistical guessing on top of a confused project generates confused code with great confidence. Then you switch models and get a different version of the confused code. It feels like progress. It is not.

The question that changed my game was simple: what if the bottleneck is not the model’s intelligence, but the quality of what I feed it to chew on?

Think before coding

Before opening the editor, I now force myself to answer in writing: what does this project solve, for whom, what is out of scope, which boundaries cannot be broken, and what is the smallest experiment that proves the idea. It sounds like bureaucracy. In practice it is the opposite: it is what lets me code fast afterward, because the hard decisions were already made with a cool head.

Each of my projects taught me this lesson its own way. In Petunia3D, I took too long to separate the 3D renderer from the interface — and every week without that boundary generated coupling that later cost days to undo. In HummTube, deciding “local-first, no mandatory account” before the code defined the database, the sync (which does not exist) and half the architecture for free. In TidyFlow, the requirements of “show what happened, what is running and what will run” became the entire interface. None of these decisions came from a smarter model. All of them came from thinking first.

Technologies get the same treatment. I compare the obvious option, one or two alternatives and something experimental — and I pick what fits this project’s constraints, not the “best” in the abstract. Stack is not religion, it is an answer to constraints. When you know your constraints, even a cheap model gets it right.

Documentation for two audiences

Here is the part that excites me most: good documentation is no longer just a favor to future-me. It feeds two audiences at once — humans and code agents. And the interesting bit is that what helps one helps the other: explicit boundaries, decisions with reasons recorded, small complete examples, clear contracts.

Prumo evolved on exactly this trail. The core idea — repository as source of truth, canonical state in Markdown and Git, adapters per tool — grew a lot when I studied Akita’s ai-memory. His project solves the same kind of pain from another angle: long-term memory for agents, handoff between different tools, a wiki in plain Markdown you can read with grep, no ceremony. Seeing an experienced person reach similar conclusions (source of truth in ordinary files, handoff as protocol rather than convention) gave me confidence I was heading the right way — plus several good ideas to steal proudly while citing the source, as I am doing now.

Project architecture and documentation architecture became the same discipline for me: deciding what exists, where it lives, who can change it, and how you find out without asking anyone.

Six months of Ori-lang

Nothing taught me “strategic planning first” like spending six months designing a programming language. In Ori, every syntax decision drags consequences into the parser, the types, codegen and tooling — erring early costs months late. I was forced to build the think-first muscle: open specification, manifesto, every feature justified in writing before existing.

The side effect was great: that muscle leaked into every other project. Today I find it strange to start anything without a one-page document saying what it is, what it is not, and how I will know it worked. Six months ago I thought that was fussiness. Today I think it is why I can run six projects at once without going crazy — well, without going too crazy.

Strategy manual of a broke AI dev

Now the practical part, because a rant without tactics is just venting. I develop spending the minimum possible, and it works — as long as planning does the heavy lifting. The manual, tested the hard way:

Weak model + strong context beats strong model + weak context. A DeepSeek Flash or a Gemini Flash with clear requirements, examples and defined boundaries delivers more than a top-tier model guessing away. Context is the multiplier; the model is just the base.

Use each model for what it does cheaply. Drafts and exploration on the cheap ones and free quotas; review and final decisions where spending pays off. I run the bulk on the cheap and save credits for moments that truly need brute force.

Take everything free without guilt. OpenCode quotas, freebuff, Antigravity, plan promos, free tiers — all of that is experimentation budget. The trick is experimenting cheap and deciding expensive: testing ideas on the free ones, consolidating on paid ones when (and only when) the idea proved value.

Documentation is direct savings. Every recorded decision is one back-and-forth fewer with the agent. Every canonical example is one prompt fewer to write. I pay minutes writing context and save hours — and dollars — of generation.

Disposable prototype before the official path. Before committing the architecture, a small playable experiment answers more than ten discussions. Cheap to run, cheap to throw away.

None of this requires the model of the moment. It requires thinking first — which, happily, is still free.

Akita already warned us

If any of this sounded familiar, it is because Akita has been hammering these ideas for years: learn to learn, do not outsource decisions, endure the discomfort instead of hunting magic formulas. The video below is his famous rant on the subject — an hour of necessary scolding (in Portuguese), and one of the inspirations for me to stop looking for shortcuts and start building foundation:

In the end, the whole rant fits in one sentence, and it is the title of this text: you do not need a smarter model. You need to show up to the model — any model — already smarter about your own project. Plan first, document always, decide with trade-offs on the table. The rest follows. And if it hurts a little at first, good: as Akita would say, if it does not hurt, you are not trying hard enough.