AI amplifies what I know.That’s why I keep studying.
I believe AI amplifies my career: with it, I deliver more and take on bigger problems. But it only multiplies what I already know. Someone who doesn’t understand the code can’t tell when an answer is wrong, so I keep studying programming and software architecture.
My flow: decide before generating code
I write the product and the architecture first. Agents only come in after that, following what has already been decided.
Product
What and whyThe PRD, the product document, defines the problem, the audience, the business rules, the scope and the success metrics.
Architecture
The technical structureThe architecture document settles the structure and the technical specs before any implementation.
Specification
What to do, exactlyI follow Spec-Driven Development (SDD): Spec Kit turns the PRD and the architecture into a specification, a plan and tasks, with quality gates along the way.
Agents
Who does the workAI agents implement the tasks inside the harness I build for each project, the infrastructure around the model: rules, tools, permissions, memory, subagents, skills and automated checks.
Validation
Does it all still fitI check that the code is still consistent with the PRD, the architecture, the specification, the plan and the tasks.
Which decision wins
- PRD
- Architecture
- Specification
- Plan
- Tasks
- Code
A lower layer can’t contradict a decision from a higher one without explicit review and approval. If there is a conflict, the original decision is identified and the conflict is explained. Nothing changes silently.
What goes to AI and what stays with me
With AI agents
- Implementing tasks that are already specified.
- Looking up current documentation, navigating the code and testing, with Context7, Serena, TestSprite and MCP.
- Repeating the work until the checks pass.
With me
- Defining the problem, the scope and the architecture.
- Building the harness for each project and orchestrating the agents and subagents.
- Reviewing what was done and answering for the result.
- Only calling something done when it passes the tests.
I keep studying code and architecture
I need to understand what’s underneath to review what AI delivers and to know when it’s wrong. AI doesn’t replace my studies: they’re what let me use it well.
I’m taking a postgraduate course in Software Architecture with AI at Full Stack Club and keep practicing in study projects, such as FIT.AI, created in the Treinos bootcamp.
See my projects on GitHubWhat I’ve already taken into real projects
- Clean Architecture with DDD and the Repository Pattern
- Work Order System
- Hexagonal architecture in a modular monolith, with boundaries checked by tooling
- This site
- Decisions recorded in ADRs, including the rejected alternatives
- Work Order System and PIBLS Website
- OpenAPI contract with a client generated by Orval
- Work Order System and FIT.AI
- Database indexes and pagination
- Work Order System, FIPE Matching and PIBLS Website
I also have knowledge of vertical and horizontal scaling, distributed caching and load balancing.
Where this method has already run
- Work Order System
Spec Kit from the first commit, with a documented PRD and architecture. In production, with 358 tests.
- FIPE Matching
Spec Kit applied to an existing system. In production, with the API covered by 518 tests.
- PIBLS Website
In production, with a PRD, architecture, decisions recorded in ADRs and more than 1,600 tests.
- This site
PRD and architecture open for anyone to read, with the step-by-step published.
I also taught this method at Rumo Soluções: I prepared 2 internal AI training sessions (harnesses and MCP) and wrote 9 playbooks that guide agents in building bots to the team’s standard.