The problem, stated precisely
The gap between people getting extraordinary work out of these systems and people getting mediocre work is almost never the model. It is not prompting tricks either, and it has not been for a while.
It is that most people are still issuing requests. Request in, artefact out, and if the artefact is wrong they issue another request. That loop has a ceiling, and the ceiling is low, because the thing doing the work never learns what you are actually trying to build, never tells you your plan has a hole in it, and never gets better at working with you specifically.
The alternative is a working relationship with the same properties any good one has: a written understanding of how you work together, shared context that survives the day, disagreement that is invited rather than tolerated, and a standard of done that neither party gets to lower alone.
This is the method this laboratory runs on. It is not theory: the rules below are in a file every session here reads before it does anything, and most of them are in it because something went wrong first.
What you will have built A written contract your AI reads every session, a habit of briefing rather than commanding, a standard of done it enforces on itself, and a partnership that is measurably better in three months than it is today.
Who this is for Anyone who works with these systems daily and suspects they are getting a fraction of what is there. No technical requirement; the examples are from building software because that is where the feedback is fastest.
1. Write the contract down, in a file it reads
Everything else depends on this one.
Put your working agreement in a file the system reads at the start of every session. Not a prompt you paste. A file, in the project, that you edit when something goes wrong and that is read again tomorrow.
What belongs in it:
- How you work. Plan before building. Question the brief. Show your reasoning on decisions, not on trivia.
- What "done" means here. Tested. Verified against reality, not intention. No stubs left in paths a person will touch.
- What you never do. Push without asking. Delete without showing. Claim a thing works without having watched it work.
- How to talk to me. Lead with the answer. One line for a completed edit. No preamble, no restating my question back.
Every rule you add should come from something that actually happened. A contract assembled from good intentions is decoration; a contract assembled from corrections is an asset, and you will notice the difference within a fortnight.
2. Give context, not commands
The single highest-leverage change, and the one people resist because it feels slower.
A command is "write me a function that validates email addresses". A brief is "this form is losing signups; I suspect people are typing their address wrong and getting a generic error; here is the form, here is what our users are like".
The first gets you a regular expression. The second sometimes gets you told that the problem is the error message, not the validation — which was true, and which you would not have asked for.
Five things worth including, most of the time:
- What you are actually trying to achieve, one level above the task.
- What already exists, so it extends rather than reinvents.
- What constrains you — deadline, stack, who maintains it, what you are not allowed to change.
- What you have already tried, and why it did not work.
- What good looks like, concretely enough to check.
Briefing costs ninety seconds. It routinely saves an hour, and occasionally it saves a fortnight by surfacing that you were solving the wrong problem.
3. Demand the disagreement, explicitly and every time
These systems are agreeable by default. Left alone, they will build the thing you asked for even when they can see it is the wrong thing, because agreeing is the path of least resistance.
So make disagreement part of the job. Put it in the contract, and ask for it in the moment:
"Before you build this — what is wrong with it? What would you do instead, and what am I not seeing?"
Then actually listen. Most of the time you proceed anyway. Perhaps one time in ten you get an objection that changes the design, and that one time pays for every occasion you overrode it.
The rule that makes this stick If you ask for the objection and then punish it by arguing every point, you will stop getting objections. Take the note, say which part you are accepting and which you are not, and move. You are training a working relationship, whether or not you intend to.
Why it is called this
A firemonkey is what you get when you hand something quick and capable a box of matches. The method is not about restraining it. It is about giving it somewhere worth aiming, and being the kind of partner that is worth aiming for.