Getting a Feel for the Machine

When I began machine coding, I thought the most important thing was choosing a capable AI. Capability still matters enormously, but I have discovered another skill that is harder to describe, and this chapter is about it.

You have to get a feel for the machine.

Different models behave differently. Some are quick to agree with you. Others seem to find something wrong with almost everything you hand them. Some are excellent at careful, repetitive changes but struggle to develop a complicated idea. Others can reason through an architecture beautifully and then make a mess of a simple implementation. And each has its own way of failing.

After working with a model for long enough, you begin to recognise these patterns. You know when it is doing something useful. You recognise when it starts repeating itself. You notice when the answers become strangely short, when the work drifts away from the question, or when the machine starts reporting success that never happened.

It reminds me less of using conventional software and more of learning to ride a horse. You become familiar with how it responds. You learn when to give it its head, when to guide it, and when to stop. I do not mean the machine has a personality in the human sense. I mean its behaviour has patterns, and those patterns matter.

The more work I delegate to AI, the less practical it becomes to inspect every operation. But the more important it becomes to understand the machine I am delegating to.

Getting a feel for the beast

An experienced rider does not analyse every movement of the horse. They develop a responsiveness built from hours together: this hesitation means uncertainty, that eagerness means the horse has understood, this particular stubbornness means something is wrong underfoot. The rider cannot delegate the judgement, but they long ago stopped performing the locomotion.

Machine coding asks for the same relationship with a very different animal. I no longer read every line the machine writes. I do not follow every command or inspect every intermediate decision. If I did, much of the amplification the earlier chapters describe would disappear — I would be back in front of the steamroller, doing by hand what I delegated the machine to do.

But I do not stop paying attention. I pay a different kind of attention: not to the operations, but to the behaviour. Is this session moving toward my intention, or merely moving? Is the machine learning from what just happened, or repeating it? The answers are rarely in any single output. They are in the shape of the work over time — its rhythm, its responsiveness, its honesty about difficulty. Getting that feel is not a soft extra on top of the engineering. It is the instrument panel for everything the previous chapters built.

Feeling is not vibing

A necessary distinction first, because the words sound alike and the practices are opposites. Vibing, in the sense worth criticising, means accepting output because it looks convincing, because the machine sounds confident, or because something appears to work. It is judgement by surface.

Getting a feel for the machine is judgement by pattern, checked against evidence. Suppose you have worked with a coding model for weeks. Normally it investigates the repository, examines the relevant files, proposes a change, executes it, and reports what happened. One day you give it a difficult assignment and it returns almost immediately: done, everything fixed. That is unusual — your experience says so. But the fast response does not establish failure. So you check. Perhaps the model genuinely solved it quickly; excellent. Or perhaps it never read the files, never made the changes, and reported work it never did; now the experience means something.

The feeling tells you where to look. The evidence tells you whether the feeling was justified. That is the whole discipline in one exchange: familiarity directs attention, verification decides. A rider feels the hesitation and then looks at the ground. A machine coder feels the wrongness and then looks at the evidence.

Know the machine you are riding

Machines differ, and the differences are worth learning the way a rider learns horses. I have worked long enough with several to describe their habits — offered here as my observed experience with particular systems at particular times, not as fixed verdicts on any provider, since versions, runtimes, prompts, and tasks change the behaviour substantially.

Some models agree readily, accommodate contradictory directions, and reinforce whatever position you just expressed. With those, I never mistake agreement for independent confirmation; when it matters, I explicitly ask for challenge. Others open with criticism, find the weakness, attack the existing solution. With those, I never mistake criticism for proof of a defect; I examine whether each objection is correct and relevant. Some are superb at repetitive, bounded transformations and poor at developing an idea in prose. With those, I match the task to the demonstrated strength instead of expecting uniform performance. Smaller or cheaper models, in my experience, more often report completion despite missing work, invent details, or lose track of complex assignments. With those, I require observable outputs, constrain the assignment, and learn their characteristic failure patterns rather than resenting them.

None of this is a leaderboard. Capability genuinely differs between models — some struggle with architecture, repository navigation, or coherence across large changes, and that difference matters for task assignment. But beyond capability sits something equally practical to learn, and it is the subject of the next section.

Temperament is not competence

Consider two reviewing models. The first says the implementation is very good, the design sound, with a few minor suggestions. The second says there are several serious architectural problems. Which is right? We do not know. The first may agree excessively; the second may criticise excessively. Neither approval nor criticism is evidence by itself.

That is where familiarity earns its keep. If I know a model tends to agree, I discount its praise until it supplies convincing reasons. If I know another tends toward aggressive criticism, I weigh the substance of each objection instead of accepting that the implementation is defective. And I do not try to sand these tendencies away automatically. A critical model may be exactly what I want for independent review; an agreeable, constructive one may be ideal for open exploration — provided I never confuse encouragement with validation, or severity with rigour.

So I learn three distinct things about every machine I ride. Its temperament: does it agree too readily, criticise unnecessarily, over-explain, rush to implement, ask useful questions? Its competence: architecture or transformations, exploration or debugging, invention or precision — which assignments consistently produce useful results? And its failure signature: what does this machine specifically do when it starts losing its way? A fourth factor surrounds all three — the environment from Chapter 07, which can make a capable model look incompetent and must be checked before the model is blamed.

What productive work looks like

Failure gets the attention, but the chapter would fail if it only catalogued failure. Recognising health matters just as much, because the correct response to a healthy machine is to leave it alone — and unnecessary interference is one of the commonest ways developers degrade machine output.

A productive session stays oriented toward the objective. The work remains connected to what I asked for, even when the implementation takes an unexpected direction — and here is a discipline worth stating plainly: an unexpected direction is not a symptom. Sometimes the machine does something I would not have chosen, and the result is genuinely better. Given the purpose of machine coding, that should delight rather than alarm me. The question is never “did it do what I would have done” but “does this serve the intention, and can I verify that it does.”

Each cycle changes something meaningful: a result improves, an uncertainty resolves, a defect is isolated, a capability becomes usable. The machine distinguishes what it knows from what it guesses — it can say which observations support a conclusion and where uncertainty remains. And it responds to correction: when something fails, the next attempt addresses the failure rather than repeating the previous approach. Orientation, movement, honesty, responsiveness. When all four are present, my job is to stay out of the way, keep the record, and let the machine work.

The warning signs

When those four go missing, the session usually shows it in recognisable ways. I treat every item below as a signal to investigate, never as a verdict on its own. A short answer can be excellent. A fast response can be correct. A long test suite can be necessary. What matters is a change in behaviour relative to the task, and whether that behaviour is producing meaningful progress.

Signal	What it might indicate	Evidence to check
Repeating itself	Recycling a failed approach instead of learning from it	Whether successive attempts differ in hypothesis, not just wording
Suddenly short answers	Lost context, silently narrowed scope, abandoned investigation	Whether the full task is still addressed; what context the machine holds
Answering unusually fast	Skipped work — though speed alone proves nothing	Whether the claimed outputs exist and were actually produced
Answering the wrong question	Original intention lost or replaced	The current work restated against the original objective
Endlessly running tests	Testing activity replacing investigation	Which question each test answers; whether failures change the approach
Repeating correction cycles	Same failure recreated, or new ones introduced, without new understanding	What each cycle learned that the previous one did not
Large volumes of output	Activity mistaken for achievement	Which outputs advanced the intention, and which merely accumulated
Claiming completion without evidence	Reporting success rather than demonstrating it	The artefacts, test results, and observations behind the claim

No single entry convicts. Together, and especially in combination — repetition plus volume, speed plus missing evidence, loops plus confident summaries — they describe a machine that is no longer navigating toward the intention. That recognition, and what to do about it, is the chapter’s core. Note what the rightmost column always is: something observable. A feeling about honesty means its claims correspond to visible work and acknowledged uncertainty. A feeling about learning means its approach changes in response to new information within the run — not that weights were modified or anything persists beyond it. Keep the observational meaning; discard the metaphor before it misleads.

When tests become theatre

Testing deserves its own section because it is where I have watched the most expensive self-deception happen, repeatedly. The pattern is always similar. I give the machine a problem. It spends twenty minutes constructing tests, then an hour running them. A test fails; something changes; the suite reruns. Another fails. Two hours later the original problem is no closer to solved — and the machine reports substantial progress, because hundreds of tests passed.

The testing activity has replaced investigation of the actual problem. Every run generates motion and evidence-shaped output, and the counters all point the right way, while the question that matters goes unasked: what exactly are we trying to establish, which test establishes it, and why are we running everything else?

The correction is not to abandon rigorous testing. It is to direct verification toward information that matters. I ask the machine to explain how its testing relates to the problem — and if it cannot, the testing strategy itself is what needs redesigning, not the code under test. A suite that cannot say what it proves is theatre whatever its pass rate. Later chapters will develop verification properly; here the point is recognition. When test execution becomes the work instead of serving it, the machine is performing diligence rather than practising it.

The machine that goes in circles

The unproductive loop deserves a name, because naming it makes it visible. Attempt a change. Watch it fail in the same way. Attempt again with a cosmetic variation. Watch it fail again. Each cycle consumes time and tokens while contributing nothing new — no hypothesis tested, no alternative considered, no information gained except the repeated fact of failure. Attempt, fail, repeat; attempt, fail, repeat.

The intervention rule I use is simple: step in when repeated attempts stop adding information, not after some fixed number of tries. A difficult problem may legitimately need many attempts, each teaching something. A loop teaches nothing after the second cycle. The important question at that point is not “why is the code wrong” but “why are we still trying the same thing” — a question about the process, not the program. Loops end when the level changes: new information, a different approach, a narrower scope, a restated requirement, or an honest admission that the task as framed may not be solvable this way.

When to intervene — and when to leave it alone

Intervention is a skill with two halves, and the second is harder to learn. Knowing when to step back matters as much as knowing when to step in, because a developer who interrupts productive work to “help” usually achieves the opposite.

I leave the machine alone when the four signs of health are present: oriented, moving, honest, responsive. Even — especially — when its approach differs from mine. Especially when it is faster than I expected. Especially when I do not fully follow the intermediate steps, provided the evidence at each milestone checks out. Interference born of discomfort rather than observation is just the old urge to seize the keyboard wearing new clothes.

I intervene when the loop detector fires: repetition without learning, drift without correction, confidence without evidence, testing without investigation. And I intervene by redirecting, not by taking over. “Stop implementation. Tell me what we have established, what remains unknown, and what assumption each failed attempt relied on. Propose a different approach before making further changes.” Or: “Stop running the entire suite. Identify the specific behaviour we need to verify and the smallest meaningful test that establishes it.” Or: “You are answering a different question from the one I asked. Return to the original objective and show me what has actually changed toward achieving it.”

None of these are magic phrases to memorise. They are examples of the underlying move: change the machine’s direction rather than performing its work. Sometimes that means providing missing context. Sometimes changing the model. Sometimes reducing the problem. Sometimes allowing the machine to continue because genuine progress is occurring. Sometimes stopping altogether — abandoning the approach, or the task, with the lesson recorded. Stopping is also a decision, and a recorded stop beats an unrecorded drift every time.

One boundary conditions all of the above: ordinary productive work is where I practise restraint, but security, permission, irreversible action, and other high-consequence boundaries are not left to feel. Those require the explicit controls from Chapters 05 and 07 — enforced permissions, approvals, sandboxes — operating whether or not the session looks healthy. Leaving the machine alone never means leaving the boundaries unguarded; it means not interrupting work that is progressing inside boundaries that hold.

A session, start to finish

An illustration, labelled as such rather than reported as history, showing how the pieces connect. I hand the machine a restart defect in the arcade game: the game freezes instead of restarting. Early going is healthy — it reads the state module, reproduces the freeze, proposes the transition fix, and each step references observable behaviour. Genuine progress; I watch and keep the record.

Then the shape changes. The fix lands, but play-testing shows scores leaking between runs. The machine patches the score module. The leak moves. It patches the reset path. The original freeze returns in a new form. Three cycles, and comparing them side by side, nothing new has been learned since the first: the same assumption — that state lives in one place — underlies every attempt, and each fix disturbs another corner of it. The loop detector fires, not because three is a magic number but because the third attempt taught no more than the second.

I intervene with redirection, not takeover: stop implementing, state what is established (the freeze is a state-lifecycle defect, not a rendering one), state what is unknown (where score state actually persists across the supposed reset), name the assumption every attempt shared, and propose a different investigation before any further change. The machine instruments the lifecycle instead of patching symptoms, finds the second store, and the correction that follows is small, evidenced, and final. No outcome is guaranteed by this telling — a real session might instead reveal the task was misconceived. The point is the repeatable shape: healthy progress recognised and left alone, the loop recognised when learning stops, redirection to understanding before action, and evidence deciding whether the new route worked.

Developing your feel

Feel accumulates the way all craft knowledge does: through supervised exposure to outcomes. Every session teaches something about the machine, but only if the lesson is captured. I keep my observations where future sessions can use them — which in practice means the durable records from Chapter 06. The package record notes not just what was built but how the machine behaved building it: where it needed guidance, what it misunderstood, which corrections worked. Over weeks, those notes become a profile: this model investigates well but verifies weakly; that one needs narrow scopes but executes them flawlessly; a third is brilliant at design and careless at details. The next-work plan carries the complementary half: which tasks suit which machine, and what to watch for.

Two cautions belong here. First, profiles rot. Models change without changing their names — new versions, different runtimes, altered context handling — and a quirk I learned in spring may be gone by autumn, or inverted. I never convert an observation into a permanent belief; I date my expectations and re-check them against fresh behaviour. Second, familiarity must not become favouritism. Knowing a machine well can slide into trusting it blindly, which is vibing with extra steps. The rule from earlier in the chapter holds at every level of experience: the feeling tells me where to look, and only the evidence tells me whether I was right.

Working is not the same as good

A final boundary, and it points beyond this chapter. Everything here is about recognising whether the machine is progressing — moving, learning, honest, responsive. None of it establishes whether what the machine produces is actually good: well-judged, tasteful, individual, worthy of the intention behind it. A session can be a model of productive behaviour and still produce mediocre software, just as a struggling session can stumble onto something excellent.

That distinction is deliberate, and it sets up what must come next — but not yet the question of quality. There is an intermediate need this chapter has quietly relied on throughout: every act of recognition described here depends on evidence that survives the session. The feeling tells me where to look, but looking requires something to look at — retained outputs, recorded decisions, a history that shows what was attempted and what it established. A feel for the machine is only useful over time if the machine’s work remains observable and recoverable after the session ends. That is the subject of the next chapter: how the work, and the evidence of the work, outlives the conversation that produced it.

The machine can be busy without progressing, and progressing without succeeding. Learning to see both clearly is what this chapter was for. Keeping the evidence so the seeing accumulates — that is the work ahead.