The runtime · The loop
You describe the outcome. Perslis does the rest.
How a plain-language goal becomes a researched, verified, operational result — not a wall of code to review.
Most AI coding tools take an instruction and emit code. The human is left to judge whether that code is correct, safe, and right for the project. Perslis inverts this: you make the architectural decisions, and the runtime does the research, the building, and the proving. The loop is the mechanism that makes that division of labor trustworthy — every step is grounded in the real system, and nothing is called "done" until it's verified.
The problem with "generate and hope"
A language model is a brilliant guesser. Ask it to change a system it has never seen, and it will confidently produce something plausible. Plausible is not the same as right — right depends on how this system actually behaves, what it connects to, and what must not break. A model that hasn't looked can't know.
Perslis's loop exists to close that gap. Before it proposes anything, it goes and looks. Before it ships anything, it proves the result. You stay at the altitude of decisions; the runtime handles everything below.
A model is a head without a body
A frontier model has a staggering IQ and, on its own, can do nothing with it. Alone, it's a brain in a jar — like the preserved heads in Futurama: brilliant, conscious, and unable to so much as open a door. It can't read your files, run your code, check a result, remember yesterday, or touch the system you actually care about. Intelligence with no hands is just opinion.
What turns a head into a worker is a body: senses to perceive the system, hands to act on it, memory to carry what it learned, and a loop that keeps all of it moving toward a goal. Perslis is that body. It doesn't make the head smarter — it makes the intelligence useful. Point any model at any job, and Perslis gives it the eyes, hands, memory, and loop to actually get it done.
This is why raw model IQ stops being the thing that matters. A slightly less brilliant head in a great body outworks a genius in a jar every time. Real work — especially the repetitive, operational work a system needs every single day, the way a human does a job by hand over and over — is a body problem, not an intelligence problem. We don't sell you a smarter head. We bring the body the head was missing.
Research
Reads the system, discovers how it really behaves, maps the dependencies and constraints.
Plan
Turns the outcome you described into a concrete, ordered approach.
Analyze
Weighs options against the real project — trade-offs, risks, what fits.
Decide
Judges whether the code is right for this project. Verification-first.
Build
Creates the change against the real system.
Test
Runs it and proves the result holds — checked, not assumed.
Deploy
Ships the verified outcome and keeps it operational.
Connect
Wires legacy systems to modern API applications — the bridge from old to new.
Figure 1 — The loop. Each stage feeds the next; failures and new findings loop back into the plan rather than ending the run.
1 · Research — look before you touch
The loop opens by discovering how the target actually works: reading the code, tracing dependencies, mapping the interfaces, and learning the constraints nobody wrote down. For a modern codebase this is source analysis. For a legacy desktop binary it's reconstructing the import tree and call-graph. For a server or mainframe system it's mapping the interfaces — the APIs, terminal sessions, and data contracts — rather than the silicon. In every case, the runtime builds a real picture before forming an opinion.
2 · Plan — turn intent into an ordered path
With a grounded picture, Perslis turns your outcome into a concrete sequence: what to change, in what order, and with which checks. The plan is explicit and inspectable — you can see the shape of the work before any of it happens, and redirect it while it's cheap to redirect.
3 · Analyze — weigh it against the real project
Not every correct change is the right change. Perslis analyzes the options against the actual project: the trade-offs, the risks, the things that fit the existing design and the things that fight it. This is the step that separates "an answer" from "the right answer for you."
4 · Decide — the step that has to be right
This is the heart of the loop, and the one Perslis refuses to rush. It judges whether the code is genuinely right for the project — and it is verification-first: the first output is treated as a hypothesis, not a conclusion. Where a claim can be checked, it's checked. Where a symbolic rule applies, the decision must satisfy it. If the evidence doesn't hold, Perslis loops back rather than shipping.
5 · Build — and prove it
Only after a decision survives does Perslis build. And "build" doesn't end at producing an artifact — it ends at a checked, operational outcome. The result is run, tested, and verified against the goal you set. What comes back isn't a suggestion to review; it's work that has already been shown to hold.
Why the division of labor matters
The loop is what lets you operate at the altitude of an architect instead of a code monkey. You decide what should be true and whether a result is acceptable. Perslis handles the research, the typing, the running, and the proving. That's the trade that makes the whole system trustworthy: the human owns judgment, the runtime owns execution — and neither pretends to be the other.