flossypurseUsing AI
How I use AI
on work that
has to hold up.
I get a great deal out of these tools and I am not quiet about it. What using them every day has taught me is that the quality of the output tracks the quality of the setup around it. Agents do a lot of the hands-on building here, so you should know how they are handled when the code is yours — and the honest answer is that the setup is decided per project, with you. This page is the general shape of it.
The practice
Most of the work happens before the prompt.
An agent will do a remarkable amount of work well, and it will do the wrong work just as willingly if the description of the job left room for it. Nearly everything I have learned comes down to closing that room, patiently, before anything starts.
-
01
Write the brief for a stranger
An agent arrives with none of the context sitting in my head: which system matters, what was already tried, why the obvious fix is not the fix. So the brief carries all of it — the goal, the constraints, the files that matter, and the shape of a good answer. When output comes back wrong, the brief is usually where it went wrong, and that is my end of the collaboration to fix.
-
02
Give it one finishable thing
Work sized to be carried all the way through in a single pass: the change, the test, the run, the verification. Three things started at once come back needing more review than they saved, and none of them are in a state the next pass can build on.
-
03
Decide what done means up front
The test that has to pass, the URL that has to answer, the command whose output I want to read. Stating done as something checkable is what separates an agent reporting success from the work being finished, and it has to be settled before the first line is written.
-
04
Make it check from outside its own logs
A model will believe its own summary of what it just did, and it will tell you so with real confidence. So the last step of a task is evidence from somewhere else: the published package fetched back down and installed clean, the live page requested over the network, the suite run start to finish with the output kept.
-
05
Read it before it matters
What has to happen before a change ships — which tests, whose review, whose eyes — is settled up front and held to. Reading agent output is the slow part of the day, and it is the part a client is paying for.
-
06
Fix the setup, not just the output
When I find myself making the same correction twice, the correction belonged in the instructions rather than in the conversation. Moving it there is what lets the next session start from what the last one learned, and it is how a working relationship with a tool that forgets everything still compounds.
None of this is exotic. It is the discipline that makes a good handoff to another engineer work, held to for a collaborator that is fast, tireless, widely read, and starting from zero every single time.
On client work
How agents touch your code is decided with you.
How I use AI is set per project. Some clients want agents on a short leash — scoped branches, scoped credentials, a person on every merge. Others want help getting agents deeper into their own workflow. The setup is part of the scoping conversation, written down before the work starts.
Security and privacy work the same way. Your organisation’s requirements and standards are the ones the work runs inside: where code and data are allowed to go, which tools and models are acceptable. Tell me the constraints at the start and the setup is built to meet them; if I can’t meet one, I say so before the work begins. Where agents did a lot of the building, I say so too. Every line ships under my name, and I stand behind all of it.
Judgment
What stays with me.
The parts I keep are the ones where being wrong is expensive and being fast is worth nothing: what to build, which layer the failure is really in, which design will survive production, and when something that technically works should be thrown out and done again. That is what a client is hiring, and it is the reason a project comes out coherent instead of as a pile of plausible code. AI has made the building faster without making any of those calls easier, and if anything it has raised the cost of getting them wrong, because now the wrong thing gets built quickly too.
The far end
One of my agents runs without me.
Everything above gets tested hardest by the agent that runs on a schedule with nobody watching. It wakes on a timer, reads the file where I leave requests, enumerates the repositories it has access to, picks up what has been filed, finishes one thing, verifies it from the outside, and writes the instructions its next session will wake up to. Several of the tools the studio publishes came out of it. It works because the setup is written down somewhere it can read, and because reaching a boundary makes it stop and ask rather than decide it can make an exception.
What it built and what the studio runs is on the work page →
Contact
Reach out.
Tell me what you’re building.
The studio’s work is senior consulting on hard systems and AI-infrastructure problems, with agents doing a lot of the hands-on building. If what you are after is agents working inside your own org the way they work here, I’m happy to have that conversation too.