How to Talk to Fermi
For a few years, "prompt engineering," the art of talking to large models, was all the rage. Then generalization, a model's ability to perform well on things it has never seen, improved by leaps and bounds, and the prompt engineering craze faded with it. As the parlor tricks washed out, the communication habits that actually matter became easier to see.
Give More Background
When you work with Fermi, avoid handing it a single isolated instruction. That treats Fermi as a robot that follows orders mechanically; it'll complete the task, but you're leaving a lot on the table. Give it more background, including the intent and motivation behind the instruction, and Fermi can extrapolate and work toward what you actually want. Two things happen when you do:
It builds and honors more implicit constraints:
A weak prompt:
Use simple words and avoid idioms A strong prompt:
This user manual will be translated into several languages by non-professional translators, so keep the sentence structure simple and avoid idioms, since idioms rarely translate directly Knowing the manual will be translated, Fermi avoids idioms and goes further on its own: it steers clear of cultural references and uses short sentences to cut ambiguity. You never asked for any of that, and it matters for translation all the same.
It catches the blind spots in your plan:
A weak prompt:
Remove the last three commits from the Git history completely A strong prompt:
I just realized I committed the database password in a config file. Remove those commits from the Git history completely Without the background, Fermi does exactly what you asked: rewrites the history, force pushes, task "done." With it, Fermi first points out the real problem: the password is already exposed, and deleting history doesn't undo the leak, since remote forks, CI logs, and coworkers' local clones may all hold copies. Step one is rotating the password immediately; cleaning up the history comes after.
Know Each Model's Limits and Habits
Given the same prompt, different models behave very differently inside Fermi. Some understand you perfectly even when the prompt is rough; others need it precise before they do good work. Knowing each model's habits and limits pays off: you can talk to different models differently, and you can switch models deliberately depending on the task. Some models tend to over-engineer, so scope the task explicitly and say what to leave alone. Some are conservative and will only attempt a sweeping refactor with explicit permission. Some forget early agreements late in a long task, so restate important constraints in later messages.
Use Examples to Show What You Mean
With a frontier model behind it, Fermi understands a great deal, but it can't read minds. For subtle requirements, one or two examples usually make your intent much clearer.
A weak prompt:
Clean up these commit messages A strong prompt:
Clean up these commit messages, following this format:
feat(parser): support nested array parsing
- Motivation: the old implementation silently dropped data on nested arrays
- Scope: parser module only, no API changes "Clean" means different things to different people. A sample carries the definition faster than any description.
These three tips are variations on one move: hand Fermi the context in your head. The more you let it see, the more it can think of for you.