Make the current problem explicit
An agent can propose several architectures for the same feature. One uses an existing controller and model relationship. Another introduces an interface, repository and service. Each additional piece has a reading, maintenance and change cost. Assess that cost against the current problem.
Before implementation, write down what changes, which data is saved and which behavior must remain compatible. Ask the agent to identify an existing mechanism it can reuse. In a framework application, standard framework constructs belong to the project's context.
Earn an abstraction through real needs
An abstraction extracts a shared rule or hides a detail other code does not need to use directly. It helps when it removes real duplication or gives complex logic a clear boundary. Single-use code that delegates a simple operation to another class can make execution harder to follow.
On the other hand, copying an important rule across several places creates a risk of disagreement. In Kodivo, the browser and MCP both handle learning progress. Those entry points need to follow the same lesson rules. Sharing that logic addresses an existing need.
Ask the agent: “Which concrete callers use this abstraction? What rule does it centralize? Would the solution remain readable without it?” The answer should refer to code and requirements.
Evaluate a dependency beyond installation
A library can save you from implementing a complex mechanism, but it becomes part of the system you maintain. Check runtime compatibility, updates, licensing and configuration scope. Establish whether the framework already supplies a similar feature.
Ask the agent to describe the simplest option using current tools and justify a proposed package. For an authenticated protocol, a maintained integration can have a practical reason to exist. Adding a package for one array operation calls for a different assessment.
Do not apply “always fewer classes” mechanically. Aim for code whose responsibilities you can understand and change safely. File count alone does not measure that.
Keep changes reversible
For a larger change, establish data and contract compatibility. If you change a response format, check existing consumers. A database migration may require preserving old data and a deployment order in which the previous application version still works.
Request small working stages with tests at the relevant boundaries. Ask what can be rolled back and which operation could permanently remove data. Assess the implementation, compatibility and production rollout separately.
If these concepts are new, revisit functions and conditions in the earlier articles and practice PHP fundamentals in Kodivo. Ask your own agent to fetch a relevant lesson through MCP and explain the rule with a small example.
