Resources / Working with AI

Engineer the feedback loop.

Give the agent a direction, let it act, then make the evidence change what happens next.

Two directions. Two kinds of mechanism.

Forward pressure feeds guidance into the next action. Back pressure feeds evidence from an action back into the next decision. The second distinction is between predefined computation and interpretation.

Forward · Computational

Create a predictable starting point

Generators
Templates
Setup scripts

These create files or environments according to predefined rules. Their output gives the agent less to invent.

Back · Computational

Check observable results

RuboCop · style and lint rules
Flog · complexity metrics
Reek · code-smell checks
Code Climate · configured analysis
Security scanner · configured rules
Tests · expected behaviour
Playwright · scripted browser checks
Logs · recorded observations

Tests and analysers can fail a check. Logs need someone or something to interpret them. Browser checks may be flaky; a computational check is not automatically reliable.

Forward · Inferential

Give the agent context to interpret

Prompts
AGENTS.md
Static docs
Nearby source code

These explain intent, constraints and existing patterns. The agent still has to judge how they apply.

Back · Inferential

Review what the change means

Agentic review
Agentic security scan
Intelligent code analysis

A model or person looks for defects and mismatches. Require a concrete finding, evidence and a consequence, not just a reassuring score.

Classify the use, not just the tool. A security scanner may use rules, a model or both. A test read before coding is forward guidance; its failing result is back pressure. Playwright is the browser-testing tool, sometimes misspelled Playwrite.

A check matters when it changes the next step.

Acceptance example

After expiry, an invite must fail.

Observed failure

The test accepts an expired invite.

Targeted correction

Fix the expiry check. Run that case again.

Useful failure output

Name the failed condition, show expected and actual behaviour, and give the shortest reproduction command. Keep secrets out of logs.

A bounded retry policy

Retry only when there is a new hypothesis or correction. If the same failure returns, stop and investigate. Do not delete the check or weaken the expectation to get green.

A safety boundary should reject a prohibited action when possible, rather than depend on a review after the damage. Keep production permissions separate from permission to edit local files.

A small loop you can audit

Before acting: One outcome, explicit constraints and acceptance examples.
After a change: Run the relevant checks and inspect the diff.
On failure: Record evidence, test a cause, make a targeted correction.
On success: Stop when the agreed evidence is sufficient. Avoid speculative review rounds.
On repeated failure: Escalate with the reproduction and what has been ruled out.

Watch the discussion

These are references to the Beyond Coding interview. The pressure map and invitation example here are explanatory adaptations. Passing tests only support the behaviours they actually exercise.