codeTAC · 2026
Vibe coding: speed with responsibility
Vibe coding speeds up code production, but it is only sustainable if whoever ships it knows the code that was generated.
What vibe coding is
In vibe coding, the developer describes what they want in natural language and an AI assistant writes the code. The cycle is: ask, test in the interface, ask again. Often nobody reads the code line by line: if it works on screen, you move on.
This has real value. In many cases, prototypes that used to take weeks are ready in hours, and people without deep technical training can build useful tools.
The problem: code without an owner
When nobody understands the code, nobody is truly responsible for it. The risks show up later, almost always in production:
- Maintenance: a simple change means asking the AI for everything again, without knowing what will break.
- Debugging: when something fails, the developer doesn't know where to start looking.
- Security: keys exposed in the code, missing validation, sensitive logic running on the client side or dependencies nobody asked for go unnoticed.
- Architecture: each request adds another layer; the project grows without a coherent structure and with duplicated code.
- Handover: a new team member inherits a system that not even its author can explain.
Why knowing the code is still necessary
AI writes the code, but responsibility stays with whoever ships it. A developer who knows the code can evaluate what the AI proposes, reject bad solutions and explain the system to a client, an auditor or a colleague.
Knowing the code doesn't mean having written every line. It means being able to answer simple questions: where is the logic for this screen, where does this data come from, what happens when this button is clicked, what breaks if I change this.
How to make developers know their code
- Review in proportion to risk. Treat the AI's changes like a colleague's pull request, with more attention where mistakes cost more: authentication, payments, personal data, database access. Interface and styles can get a lighter review.
- Ask the AI for explanations, and check them. Use the assistant to explain what it did and why, but verify the explanation in the code: the AI can confidently describe something it actually did differently.
- Map the code from the interface. Link each visible element to the file, the function and the data behind it.
- Keep everything in version control. Small, frequent commits, one per iteration, let you see exactly what changed and roll back when a request breaks what used to work.
- Tests that define behaviour. Decide first what the code should do, and only then ask for the tests. Tests written by the AI from the code itself tend to confirm what it does, not what it should do.
- Document decisions. Record the architecture and main choices in a living document, updated at each iteration. It's the project's memory.
- Explicit human validation. Define checkpoints (before a delivery, before going to production) where a person confirms they understand and approve what was done. It's the moment of decision.
Conclusion
Vibe coding changes who writes the code, not who answers for it. Speed only pays off if it comes with understanding; otherwise, the time saved today is paid back with interest at the next breakdown.
This reflection gave rise to codeTAC
codeTAC puts the third point into practice: it maps the code from the interface. Click a button and see the component, the server functions that ran, the database and the external services involved.
Jorge Ataíde