June, 2026
Oh, it seems that there is no point in calling “vibecoding” a practice that even top reference programmers around the world are calling their new workflow.
So, no more “vibecoding“. We’re into agentic engineering now!
We are so fancy.
++ Create the project folder and add ./docs
++ Write the project manifest with high level specs about what the product/service is about and its core process. Add it to ./docs
++ Based on the above, create a version of my “agent-swarm” opencode.json config file and edit it to define the team of agents that must be employed in the project. This is from a role/function standpoint.
++ Define the models each agent will use to perform their work. Decisions are made considering the capabilities and the cost of each model within the context of their agents. It’s a cost:performance decision.
+ Drop my home-grown MVC framework into the new project’s directory.
++ Run opencode with the agent-swarm loaded in plan mode. Ask the PO agent to analyse the product manifest document and the MVC skeleton. Its objective is to generate a phased project implementation plan within ./docs
++ Once the plan is created, I run /init for OpenCode to create AGENTS.md in the root folder.
++ I write a preliminary TODO with important tasks I believe are important per phase. Those tasks often extrapolate pure product/service build-up and stretches out to infra, deployment, dev tooling, external services etc.
++ At this point we are very close to execution. I choose a task group within a phase and craft prompts for execution. They are much shorter and objective than the huge multi-hour epic prompts I used to write until last month.
++ Executions always end with test writing and coverage analysis. If they all pass, we update documentation to reflect the final outcome and the implementation tactic we adopted, then add/commit.
++ I use the processing time to do UI testing myself or go to X.com and try to catch up with the week’s AI buzz.
Models
+ Qwen 3.7, DeepSeek V4 Pro and Flash
– GPT 5.3 Codex, Big Pickle, Gemini family
May, 2026
I usually copy/paste my home-grown MVC framework into the new project’s directory.
I have a subdir called /app that contains the generic structure for auth, security, etc.
I delete all the project-specific controllers/models/helpers. I keep just the skeleton. Some views and partials are useful, so I leave them as-is.
Then I write an initial prompt that usually takes me 1–2 hours to craft. I put all the details there and how I imagine the integration with the elements in /app, the basic structure of controllers and models, and a few views, starting with the “core business” ones — the central value-aggregation point of the product.
Next I ask the agent to analyze and ask follow-up questions. Once everything is broken down in implementation terms, I authorize the first build.
++ Then I run an intermediate build focused on creating an initial test coverage based on parameters I have defined for “value adding” each unit test must have.
That build generates a few hours of analysis and follow-up questions and to-dos to the agent.
Meanwhile, I take that time to study documents related to the business processes the app supports, and often times, some legal aspects and laws.
+ I request a review and a second build. I finish by asking for a GEMINI.md agents.md checking in English with all project details, from architecture to business rules. It needs to be a mirror of my initial prompt with refinements.
+ Work continues from there with the usual iterations with the agent — much more “micro” or “granular” than the initial phase. Before each PR the GEMINI.md agents.md, tests.md and security.md are updated and the commit message is generated.
+ I noticed that if I fail to update GEMINI.md any piece of documentation or if it is not correctly updated by the model, this may generate issues in future interactions when the coding agent reads the documentation.
April, 2026
I usually copy/paste my framework into the new project’s directory.
I have a subdir called /app that contains the generic structure for auth, security, etc.
I delete all the project-specific controllers/models/helpers. I keep just the skeleton. Some views and partials are useful, so I leave them as-is.
Then I write an initial prompt that usually takes me 1–2 hours to craft. I put all the details there and how I imagine the integration with the elements in /app, the basic structure of controllers and models, and a few views, starting with the “core business” ones — the central value-aggregation point of the product.
Next I ask the agent to analyze and ask follow-up questions. Once everything is broken down in implementation terms, I authorize the first build.
That build generates a few hours of analysis and follow-up questions to the agent.
Meanwhile, I take that time to study documents related to the business processes the app supports, and often times, some legal aspects and impacting laws.
I request a review and a second build. I finish by asking for a GEMINI.md checking in English with all project details, from architecture to business rules. It needs to be a mirror of my initial prompt with the refinements.
Work continues from there with the usual iterations with the agent — much more “micro” or “granular” than the initial phase. Before each PR the GEMINI.md is updated and the commit message is generated.
++ I noticed that if I fail to update GEMINI.md or if it is not correctly updated by the model, this may generate issues in future interactions when the model reads the documentation.
March, 2026
I usually copy/paste my framework into the new project’s directory.
I have a subdir called /app that contains the generic structure for auth, security, etc.
I delete all the project-specific controllers/models/helpers. I keep just the skeleton. Some views and partials are useful, so I leave them as-is.
Then I write an initial prompt that usually takes me 1–2 hours to craft. I put all the details there and how I imagine the integration with the elements in /app, the basic structure of controllers and models, and a few views, starting with the “core business” ones — the central value-aggregation point of the product.
Next I ask the agent to analyze and ask follow-up questions. Once everything is broken down in implementation terms, I authorize the first build.
That build generates a few hours of analysis and follow-up questions to the agent.
Meanwhile, I take that time to study documents related to the business processes the app supports, and often times, some legal aspects and impacting laws.
I request a review and a second build. I finish by asking for a GEMINI.md checking in English with all project details, from architecture to business rules. It needs to be a mirror of my initial prompt with the refinements.
Work continues from there with the usual iterations with the agent — much more “micro” or “granular” than the initial phase. Before each PR the GEMINI.md is updated and the commit message is generated.
