01
Technical expertise
Code quality, architecture, APIs, frontend systems, testing, debugging, and maintainability.
Method
A practical way to use AI in software development became TCAF.
TCAF grew out of recurring problems encountered while using AI on real software projects: unwanted scope changes, unnecessary rewrites, lost context, and code that could be harder to review than to write directly. The aim is to keep useful acceleration without giving up understanding, maintainability, or human technical responsibility.
Experience first
Built on 10+ years of hands-on software development.
AngeliniLabs grows out of real software work: frontend and full-stack development, architecture and integrations, maintainability, technical debt, feature implementation, team collaboration, Agile projects, and increasingly broader project responsibility.
02
Project management
Scope, priorities, planning, dependencies, risks, stakeholder needs, team coordination, and preparation for release.
03
Controlled AI use
AI as an accelerator for selected work, not as a substitute for technical judgment, review, or responsibility.
From practice to framework
It started as a simple way to keep AI-assisted tasks under control.
The first goal was straightforward: make AI-assisted work smaller, clearer, easier to review, and easier to recover when a tool behaved unpredictably.
After using AI repeatedly for analysis, implementation, debugging, refactoring, tests, and documentation, the same pattern kept appearing: the tool could produce useful work quickly, but it could also broaden the requested change, replace logic that already worked, lose earlier decisions, or generate code that took longer to understand than the time it saved.
Shorter prompts helped, but they were not enough. A reliable process also needed persistent project context, explicit permissions, mandatory developer review, a clear record of what had and had not been verified, and rules that could remain consistent across different tools and models.
That is how a lightweight working method became TCAF: an installable, versioned framework with a runtime, reusable project rules, Task Contracts, project setup procedures, tool integrations, validation, and documentation.
The objective is not to automate software engineering away. It is to delegate selected work without surrendering the decisions, project context, and responsibility for code that make software maintainable.
What had to be solved
The main problem was not generating code. It was controlling the change.
The most expensive failures were not always obvious errors. They were changes that looked reasonable on their own but weakened the project as a whole.
Scope expands without being asked
An AI tool can solve the requested problem and still modify nearby code, add unnecessary abstractions, or broaden the implementation beyond what the task requires.
Fast code can create slow debugging
Generation stops being an advantage when the resulting code is difficult to explain, inconsistent with the project, or costly to debug and maintain.
Project context gets lost
A chat may contain important decisions behind a task, but that context can disappear when the session, tool, model, or developer changes.
Working code gets rewritten unnecessarily
AI tools often prefer the approach they would design from scratch, even when the existing implementation already works and should simply be extended.
The TCAF approach
Keep normal engineering practices. Make AI delegation explicit.
TCAF keeps developers and teams responsible for the software. AI supports selected tasks; it does not become the decision-maker for the project.
01
Developers remain the decision-makers
Requirements, architecture, task decomposition, implementation strategy, quality expectations, and final acceptance remain human responsibilities.
02
Delegation is explicit
The AI receives selected work through a Task Contract that states the expected outcome, what may change, what must remain intact, how the result will be checked, and when the tool should stop.
03
Existing code remains the reference
Current files, working methods, project rules, developer edits, and local conventions are treated as the current state to understand and preserve before proposing broader changes.
04
Verification is explicit
Automated checks, manual verification, known limitations, and pending decisions remain visible. A tool saying that its work is correct never replaces developer review.
How it works
A controlled sequence, without requiring AI for every task.
AI can inspect, draft, implement, verify, or be left out entirely. The developer or team decides where delegation actually saves time without creating more risk or review work.
01
Understand the real project
Inspect the repository, project rules, nearby implementation, available tools, and the source of the task before proposing changes.
02
Define one bounded task
Clarify the goal, expected behaviour, files or areas that may change, exclusions, acceptance criteria, checks, and stop conditions.
03
Choose what to delegate
The developer can write the code directly, ask AI to inspect or implement a specific part, or combine both approaches. TCAF does not require AI-first development.
04
Preserve working code before rewriting it
Reuse existing functions, validation, utilities, naming, and architectural patterns when they already solve part of the problem instead of replacing them without a reason.
05
Verify the result before accepting it
Inspect the changes, run the relevant checks, verify the expected behaviour, and record any limitation or unresolved point before considering the task complete.
06
Update project state only when authorized
Commits, backlog updates, issue status, and project documentation remain explicit actions rather than automatic side effects of an AI run.
Principles
A practical alternative to uncontrolled AI coding.
The important difference is not whether AI is used. It is whether the work remains understandable, reviewable, and under the responsibility of people who know the software they are building.
- Professional software engineering remains the foundation.
- AI accelerates selected work; it does not own the project or its technical decisions.
- Small tasks make changes easier to understand and review, not merely prompts shorter.
- Working code and local conventions are extended before they are replaced without necessity.
- Human edits and accepted changes become the current project state that future work must respect.
- The framework is designed to remain usable across different models and development tools.
Public framework
TCAF is installable, versioned, and documented.
The framework includes a CLI runtime, the Universal Run Protocol, Task Contracts, reusable project rules, tool integrations, validation, and bilingual documentation.
Applied project
Software Delivery Planner is the first larger public application using TCAF.
The work-in-progress React, TypeScript, and Fastify application connects implementation with backlog, architecture, tests, risks, estimates, and project documentation. It is also the first larger project being continued using the TCAF rules in day-to-day development.
Current status
A public beta being improved through real use.
TCAF 0.3.3 is usable today, but it is still pre-1.0. The Codex integration and the documented manual workflow for Cline have been tested; additional tool integrations and development scenarios will be validated progressively.