Introduction
Understand what TCAF is, why it exists and how it changes AI-assisted software development.
TCAF is a model-agnostic operating framework for software development assisted by AI. It connects project analysis, architecture, planning, implementation, verification and reconciliation through explicit, reviewable work.
TCAF constrains AI execution, not the developer’s authority or ability to work directly on the software.
The developer remains the developer
TCAF does not turn a developer or engineering team into a passive supervisor of generated code. Developers remain free to analyse the system, make architectural decisions, write code, edit any part of the repository, replace an approach, perform a justified refactor, run investigations and resolve problems directly.
AI tools are used to accelerate and support real software engineering. They do not receive an independent mandate to redesign the application, broaden the task, replace working code or choose a different implementation strategy without authorization.
Developer edits are part of the current project state. An AI agent must re-read and integrate them rather than restore an earlier version, overwrite them or assume that only its own changes matter.
Why TCAF exists
AI models can produce code quickly, but they may fill missing information with assumptions, expand the requested scope, rewrite working areas, ignore local conventions or report checks that were not actually completed. A plausible answer can still describe an incorrect or incomplete result.
TCAF replaces that implicit freedom with an explicit operating boundary. Before implementation, the relevant project state is inspected and the requested change is converted into a Task Contract that defines the authorized objective, edit surface, preserved areas, expected behaviour, checks and stop conditions.
This structure is intended to make AI assistance more useful, not merely more restrictive. A model can work decisively inside a clear task because it does not need to invent authority or project context.
The operating cycle
- Inspect the relevant project state instead of assuming it.
- Identify the task source and perform only the analysis required for that task.
- Produce a Task Contract with explicit objectives, boundaries and stop conditions.
- Obtain developer review and approval before consequential implementation.
- Implement preservation-first and conform new code to the project’s existing local patterns.
- Run or report the smallest relevant checks, distinguishing executed evidence from pending verification.
- Return the result, limitations, detected deviations and the next developer action.
- Reconcile documentation, backlog and project status only when explicitly authorized.
More than controlled code generation
TCAF is not limited to prompting an AI to write a function. It can support the operating process from initial project understanding and architectural baselines through task planning, implementation, review and status reconciliation.
The framework is deliberately model- and tool-agnostic. The same principles can be transported through Codex, Cline, a generic CLI or another interface, although each adapter may have different capabilities and limitations.
What TCAF is not
TCAF is not an autonomous project manager, a coding agent, a replacement for engineering judgement or a form of partially supervised vibe coding. It does not grant the AI ownership of the repository and then ask the developer to approve the result after the fact.
It is the operating discipline that lets developers use AI as an accelerator while retaining full authorship, technical freedom and responsibility for the software.
Current validation status
The framework has been exercised through installation, project adoption, development-task and documentation-reconciliation scenarios, including verified Codex usage and Cline usage with documented limitations. Not every principle has yet been tested across every model, adapter, project type and active-task condition. The documentation therefore distinguishes verified behaviour, verified behaviour with limitations, framework-aligned procedures, planned capabilities and unsupported operations.