For six months now, I have worked almost exclusively with vibe coding. Initially, I was skeptical of tools whose stated ambition seemed to be to make my core profession disappear: software analyst-developer. Over time, however, I have learned to appreciate them, to understand their limits and, above all, to measure what they can really bring when they are properly managed.

6 monthsof vibe coding on a daily basis
2 hoursto migrate the first API project
3 tiersas my first architecture rule

01My first POC: a beautiful facade is not enough

My first POCs focused on subjects that I mastered perfectly: features that I had already developed dozens of times and that I almost always achieved according to the same principles. Creating a customer file is a good example.

At first, my prompts were very basic: Create me a client management application. The result would probably have looked great to a client unfamiliar with development. The facade was clean and the program worked.

But as soon as I opened the cover, I discovered code comparable to that of a first-year computer science intern: functional, certainly, but difficult to maintain and very far from the standards expected for a professional application.

My following tests were therefore much more directive:

I want a three-thirds architecture. Access to the database must be achieved via an API. Uses a professional tech stack, limits unnecessary dependencies, and avoids Python whenever possible.

With this type of instructions, the results became much more interesting. I began to understand that I could really capitalize on the tool, provided I provided it with a precise technical framework.

02Reduce costs with local models

After these first tests, the logical next step was to seek to reduce costs. Systems like Codex or Claude Code are based on usage quotas which can quickly become restrictive when projects are linked together.

So I tested several models locally with LM Studio and Ollama. The first results were encouraging, but I quickly encountered an important limitation: the size of the context.

At startup, everything went well. As soon as the project grew, the agent began to loop, forgetting certain decisions or constantly compressing its context.

One solution is to use models with fewer parameters to free up more memory for context. Unfortunately, the level of reasoning then often becomes insufficient for professional use on complex development tasks.

I concluded that self-hosted solutions are not yet systematically up to standard for this use, even if it remains essential to test them regularly.

For professional purposes, my client acquired a DGX Spark with 128 GB of memory shared between the CPU and GPU. The context constraint is much less present, but certain development tasks remain particularly long.

However, I qualify this observation: at the time of writing this article, I am mainly working with GPT-5.6 SOL in Ultra reflection mode. It too can be slow, but the result obtained is very often correct from the first launch.

03From POC to professional use

My first real professional use case was the migration of an API project developed with WinDev to another technology. I will return more specifically to my methodology in a future article.

PC SOFT charges for the use of its application servers. Last year, the cost of this license doubled without significant enough change to justify it in my eyes.

So I decided to change the technology stack, while taking advantage of the operation to correct a bug present in the application. Thanks to my functional and technical knowledge of the project, I was able to precisely guide the agent.

About two hours later, the migration was complete. The new APIs, developed in another language, continued to use the existing HFSQL database through an ODBC driver, while now operating in a Linux x64 environment.

After a first series of manual unit tests, I wondered if Codex could itself automate the verification of all the APIs. So I asked him:

Launch a test campaign on my APIs, provide me with an Excel table listing all the scenarios executed and correct the malfunctions detected.

That day, I had my second big surprise. The system identified anomalies that I didn't suspect, corrected the malfunctions and then published the changes to the server.

An experiment launched almost as a POC had just become a real quality control step.

04Replace the GDS with Gitea

At this point, my new project was running in production, but I had lost an important element of my usual environment: the GDS, the source manager of PC SOFT.

After studying several solutions, I chose to deploy Gitea in a Docker container. Gitea is based on Git and offers a web interface allowing you to consult repositories, history, branches and files, like GitHub, while remaining self-hosted.

I pushed my sources into the repository and found a complete version manager. I was still missing the documentation.

However, AI tools are particularly effective for producing Markdown documents, and Gitea knows how to display them natively in its interface.

In just a few steps, I found myself with a much more complete source and documentation manager than the GDS I had been using for over ten years.

05My development rules Markdown file

Like many developers, I'm a big believer in least effort. Writing a perfect prompt before each intervention is effective, but particularly repetitive.

So I created a Markdown file describing all the rules that the agent must respect during development.

This document specifies in particular:

  • the architectures to be favored depending on the nature of the project;
  • rigorous data modeling, inspired by Merise;
  • the clear separation between the front-end, APIs and data layer;
  • creating reusable views and components;
  • the relevant use of inheritance and polymorphism;
  • the implementation of threads, events or the observer boss when justified;
  • the use of asynchronous calls to avoid unnecessary reloads;
  • limiting unnecessary libraries and hard-to-maintain dependencies;
  • backup and recovery when a database is used;
  • the ability to configure ports and runtime settings.

These are ultimately the principles that we already apply on a daily basis, but whose formalization usually requires long architectural phases.

Once recorded in a reference document, these rules become a sort of technical contract between the agent and me.

06AI always seeks the shortest path

I come to a subject that is particularly close to my heart. When I simply ask an AI to create a program, without letting it understand that I am a developer and that I expect a maintainable result, it generally chooses the fastest path to achieve the goal.

On the other hand, when I impose rules of architecture, quality, security and operation on it, it becomes an extremely productive developer that I can direct towards a specific result.

This is where the vibe coding really becomes powerful. Not everyone is a developer. We have studied, accumulated experience, had successful projects and others that were more difficult.

This expertise allows us to distinguish a simple functional demonstration from a truly usable application.

The AI ​​does not remove this value. On the contrary, it allows us to use it to offer our clients, even when their budgets are limited, architectures, tools and levels of automation that would previously have been difficult to access to them.

07From vibe coding to AI-driven development

Looking back, what I practice today no longer really corresponds to the improvised image that the expression vibe coding sometimes conveys.

I no longer simply ask an AI to produce an application. I provide it with a target architecture, development conventions, security rules, test procedures and operating constraints.

My role is gradually approaching that of an architect or technical manager leading a virtual team: I define the framework, I control the choices, I validate the result and I remain responsible for what is delivered.

08And now?

Today, I converted all of my WinDev, WebDev and WinDev Mobile applications to other technologies.

The next project will be the gradual migration of the applications of my clients who still have maintenance contracts.

And that's another story: it will be necessary to manage existing dependencies, user habits, production environments, data recovery and contractual commitments.

This will probably be the subject of a future series of articles.