Building software with AI agents that take on whole units of work — planning, writing, testing, reviewing — rather than completing lines inside an editor.
Why it mattersThe unit shifts from a suggestion to a task, which moves the hard problems to coordination, review and trust.
Why we built YATFA →Sandboxing, permissions, approval tiers and server-side enforcement that bound what an agent can do — outside the model, where no prompt can talk around them.
Why it mattersInstructions are guidance, not boundaries: a defence that lives in the prompt can be talked around, so real guardrails are enforced outside the model.
Permissions in YATFA →Guardrails for AI coding agents →How an agent carries what earlier runs learned into the next one — rule files, retrieval, versioned knowledge — instead of starting from zero each session.
Why it mattersThe context window is working memory and it evaporates; memory is what survives it, and stuffing it degrades the very behaviour memory exists to improve.
Knowledge in YATFA →Memory for AI coding agents →A setting that decides how far an agent may take work before a person must act — propose only, file tickets, build, or approve the result.
Why it mattersIt turns “can we trust agents?” into a dial you move per project as evidence accumulates.
Trust levels in YATFA →An agent that takes a whole task, completes it in its own isolated environment, and delivers a pull request for later review — while you do something else.
Why it mattersThe work continues unattended, so trust moves from watching to reviewing: the hard engineering is everything between the task and the PR.
Guardrails for AI coding agents →Testing AI-generated code →A reading of whether a line of work is alive, taken from what actually shipped rather than from a status someone set by hand.
Why it mattersSelf-reported status drifts; shipped work doesn’t.
Directions in YATFA →Coordination in which the same state of work always leads to the same next step, decided by rules rather than by a model improvising.
Why it mattersWhen agents run unattended, a predictable next step bounds the cost of anything going wrong.
How YATFA coordinates →Handing a stuck case to a person — ideally with the full history of what was tried and why it stopped.
Why it mattersAn agent that can stop is cheaper than one that loops; the history is what makes the handover useful.
Escalation in YATFA →A test or check that passes even though the behaviour it claims to guard is broken — for example, one that stays green when the fix is reverted.
Why it mattersAutomated work multiplies checks; a check that cannot fail gives confidence without protection.
An article on false greens →A workflow in which a person must act at defined points before work continues.
Why it mattersThe question is not whether a human is in the loop but where — and whether that point can move.
Folding scattered findings from past work into maintained articles, and correcting them when the facts change.
Why it mattersMemory without curation becomes a pile; curated knowledge is what the next task can actually use.
Living knowledge in YATFA →Documentation kept current by the process that changes the system, rather than by people remembering to update it.
Why it mattersDocs that depend on goodwill go stale; docs tied to the work stay true.
Living knowledge in YATFA →A single change that must land in several repositories — for example, a web app and the API it calls.
Why it mattersSplitting it into unrelated tickets invites half-shipped features and hand-synced statuses.
One ticket, every repository →Text crafted to make a model ignore its instructions — hidden in a web page, an issue or a file the agent reads.
Why it mattersDefences that live in the prompt can be talked around; permissions enforced outside the model can’t.
Permissions in YATFA →A suggested piece of work, with its reasons, filed for approval before it becomes a ticket.
Why it mattersAgents that find work need a gate between finding and doing — and a record of why.
Self-found work in YATFA →Cutting a direction into small, reviewable pieces of work. Execution-time slicing cuts each piece only when the previous one has landed.
Why it mattersSlices cut in advance go stale as the code moves; slices cut at execution time see the current code.
Roadmaps in YATFA →An isolated environment in which an agent runs code without reaching anything it wasn’t given.
Why it mattersIsolation limits what a mistaken or manipulated agent can touch.
Agent isolation in YATFA →Writing the specification first — requirements, design, tasks — and having agents implement from it, so the spec is the source of truth, not chat history.
Why it mattersAgents are literal: the brief carries all the context they will ever get, so a disciplined spec is the cheapest way to get work that is right the first time.
Directions and tickets in YATFA →Writing software by prompting an AI and accepting its output without reviewing the code — fast, fun, and safe only for work nobody has to maintain.
Why it mattersThe term names a real workflow, and its limits matter: what is fine for a weekend prototype is a liability in a production codebase.
How to review AI-generated code →A rendered proposal for an interface — ideally produced from the real application, so the options can be compared as they would ship.
Why it mattersInterfaces are the most disputed layer; seeing beats describing.
Visual drafts in YATFA →