A friend called my way of working "vibe coding" after I described how I use AI agents—tools that can explore a project, change code and run checks. The shortcut was understandable. I describe a need, agents explore my projects and produce a large share of the code. Yet I don't recognize myself in that expression. What matters is not how much code the AI writes, but how much control I keep over what gets built.
What vibe coding covers
In his post of February 2, 2025, Andrej Karpathy, an AI researcher, describes a practice where he lets AI produce the code, accepts its changes without always reviewing the changes to the code, tests the result and feeds errors back to it. He mentions, in particular, personal and throwaway projects. The term has since broadened to sometimes mean any application built with the help of AI.
That broadening blurs a useful distinction. Two people can ask an agent to produce an entire feature and get the same apparent result. One can judge the architecture, security or maintenance choices; the other will struggle to assess what happens behind the interface. The share of generated code doesn't tell these situations apart.
I'm not trying to dismiss experimentation by people who don't write software. It opens up software creation to more people. But when a system has to last, be operated and evolve, someone must be able to answer for its key decisions.
I have also come across "LARPer", a term suggesting someone is playing a role online. L'ADN describes its broader use on social media (in French). I have not found the post that applied it to people building AI apps, so I leave it at that.
Generating is not deciding
I can ask an agent to implement an API without letting it choose the overall architecture, or reject a fix that works but introduces a disproportionate dependency. A successful build doesn't guarantee a good solution; a test can pass while checking the wrong thing.
So I draw the line with this question: am I able to understand the structural decisions, spot a wrong direction and take back control? I don't need to type every line or follow every step the agent takes. I need to know what I have delegated and how to judge the result.
What I actually orchestrate
I start with a need that I discuss with a large language model (LLM) in a web interface, often ChatGPT. That conversation helps me frame the problem; it does not change the project. I then turn the thinking into a feature description or specification: goal, constraints, scope and expected result. I put it in an issue on GitHub, GitLab or Gitea. The issue becomes the worktable I share with the agent, keeping the brief, decisions and exchanges in one place.
The issue brings together my brief, the agent's feedback and my decisions.
The diagram places my conversation with the web LLM before the issue, and my work with the development agent after it. Through its connection to the Git platform, that agent can access the issue and project, explore files, propose a solution and implement it. I exchange with it in the issue or in our working session, question its choices, adjust the brief and check the result. It also records questions, proposals and execution feedback in the issue. I used to keep this working context in Markdown or text files; the Git platform is now its center.
I do not follow every line as the agent writes it. I check the resulting behavior, architectural decisions and rules that must continue to hold. For an API, for example, I check that a feature meets the need and that a user without the required permissions still cannot access it. Tests, a review of changes in Git and a manual run through the journey in the application give me evidence to judge it. If the agent drifts from the goal, I narrow the scope, correct the context or step in directly.
The agent can also flag an edge case or a constraint I had missed. In return, my experience can reveal what it lacks: an implicit business rule, a quirk of the infrastructure, an operational risk. We each have blind spots; confronting our proposals improves the diagnosis.
I also document how this process evolves on my YouTube channel, TED JB 81. These videos show how my way of framing and delegating development changes with the tools.
An additional development skill
Developing has never been limited to writing code. You have to understand a need, make trade-offs, design, test and maintain. Agents now take over part of the analysis and implementation. To delegate a task to them effectively, I often have to state the problem better, along with the limits of their autonomy and what counts as an acceptable result.
My experience then serves as much to frame the work as to evaluate what was produced. It helps me spot a generic structure added before a real need justifies it, a disproportionate solution or a problem broader than the one described in the request. Knowing how to code remains useful to understand the system and step in when delegation reaches its limits.
For now, orchestration is the word that best describes my practice. The agent explores, questions and produces; I set the conditions of its autonomy, test its proposals against reality and take responsibility for the delivered solution. The market may find another term as these practices evolve. The name is still open; the responsibility of understanding what we build, however, remains.