For the past six months, I have worked almost exclusively with vibe coding. Initially, I was skeptical of tools whose stated ambition seemed to threaten the profession at the heart of my career: software analyst and 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 I knew inside out: features that I had already developed dozens of times and that I had almost always implemented according to the same principles. Creating a customer record is a good example.

At first, my prompts were very basic: Build me a customer management application. The result would probably have looked great to a client unfamiliar with development. The interface looked polished and the program worked.

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

My next tests were therefore much more specific:

I want a three-tier architecture. Access to the database must be achieved via an API. Use a professional tech stack, limit unnecessary dependencies, and avoid Python whenever possible.

With this type of instruction, the results became much more interesting. I began to understand that I could really capitalize on the tool, provided I gave it 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 that can quickly become restrictive during back-to-back projects.

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 first, 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 consistently capable enough for this use case, 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-window constraint is far less restrictive, but certain development tasks remain particularly long.

That said, I should put this observation into perspective: at the time of writing this article, I am mainly working with GPT-5.6 SOL in Ultra reasoning mode. It too can be slow, but the result obtained is very often correct on the first run.

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 cover my methodology in more detail in a future article.

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

So I decided to change the technology stack, while using the opportunity to correct an existing bug 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 automate the verification of all the APIs itself. So I asked it:

Launch a test campaign on my APIs, provide an Excel table listing every scenario executed, and fix any issues you detect.

That day, I had my second big surprise. The system identified issues I had not noticed, fixed them and then deployed the changes to the server.

What had begun as something close to a POC had just become a genuine quality-control step.

04Replace the GDS with Gitea

At this point, my new project was running in production, but I no longer had an important part of my usual environment: the GDS, PC SOFT's source control manager.

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

I pushed my source code to the repository and regained a complete version-control setup. I was still missing the documentation.

However, AI tools are particularly effective for producing Markdown documents, and Gitea renders them natively in its interface.

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

05My Markdown file for development rules

Like many developers, I believe in avoiding unnecessary 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 preferred architectures depending on the nature of the project;
  • rigorous data modeling, inspired by Merise;
  • the clear separation between the front-end, APIs and data layer;
  • the creation of reusable views and components;
  • the appropriate use of inheritance and polymorphism;
  • the implementation of threads, events or the Observer pattern when justified;
  • the use of asynchronous calls to avoid unnecessary reloads;
  • limiting unnecessary libraries and hard-to-maintain dependencies;
  • backup and recovery procedures 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 documenting them usually requires lengthy architecture work.

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

This brings me to a subject that is particularly important to me. 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.

By contrast, when I require it to follow rules for architecture, quality, security and operations, it becomes an extremely productive developer that I can direct towards a specific result.

This is where vibe coding becomes truly powerful. Not everyone is a developer. We have trained, built up experience, delivered successful projects and learned from more difficult ones.

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

AI does not erase 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 for them to access.

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 becoming 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?

I have now migrated all of my WINDEV, WEBDEV and WINDEV Mobile applications to other technologies.

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

And that's another story: I will need 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.