This week, I published a podcast episode dedicated to vibe coding, in which Julien Saumande, an expert on the subject, explained this practice and what it changes in the world of development.
The principle: describe to an AI what you want to achieve, have it generate the code for an application, then adjust the result through successive exchanges. This approach facilitates software creation, even if obtaining a first working version does not yet guarantee its reliability.
A few months ago, I also spoke to you about citizen development: the possibility for employees whose job is not IT development to create tools adapted to their needs themselves.
These two topics converge. With tools like Claude Code or Antigravity, an accountant, an executive assistant, or a project manager can consider building an application to simplify part of their work: preparing a report, tracking requests, avoiding re-entries, or automating a repetitive task.
For a manager or executive, this perspective inevitably raises questions.
- How much time will employees dedicate to these developments?
- Is there a risk that this will distract them from their core missions?
- Will the tools created truly improve their work?
- How can we verify that their results are accurate?
- What risks will they pose to company data?
- Who will take care of it in case of a problem?
- And, ultimately, how much will it cost and what will be gained?
These questions are legitimate. They can also lead to wanting to control everything even before anyone has started experimenting.
My opinion is that there must be room for this experimentation, with some understandable limits from the outset, and then more organization as the tools begin to serve the company.
Not Everyone Has to Become a Developer
The first point, in my view, is not to turn this possibility into an obligation.
Some employees will want to seize this opportunity. Others will lack the time, interest, or comfort with this way of working. This says nothing, in itself, about their professional value.
A presentation, a few demonstrations, or a workshop can help everyone understand what becomes possible. Then, let volunteers try, without making application creation a new success criterion for everyone.
It is also necessary to distinguish between the ability to start and the ability to build a reliable tool. AI facilitates code writing, but it is still necessary to know how to explain one’s needs, break down a task, identify exceptions, and verify the result.
Business knowledge is a valuable asset here. The person who performs an operation every week often knows very well where they lose time. They can identify an improvement that would never have been the subject of an IT project.
This gives them a good starting point. They may need help for the rest.
Allowing Real Room for DIY
I believe that an initial, fairly free phase is useful. An employee tries something, finds that it doesn’t work well, modifies their approach, and sometimes discovers a use that no one had thought of.
Not all trials will result in a useful application. This part of learning must be accepted if we want people to truly explore.
Therefore, I would not ask for a profitability report before each attempt. A simple agreement on available time and priorities to respect seems sufficient at the start. The manager can allow a margin of autonomy, then check in after an agreed period.
This freedom, however, presupposes an environment designed for trials. Specifically, employees must know which tools they can use, with what data, and how far they can go without asking for help.
To start, one can work with fictitious data, without connecting to critical company software and without automatic sending to clients. A failed trial must be able to remain a failed trial, with no consequences for operations.
The IT department, the IT manager, or the trusted service provider has a role to play in making this framework accessible. If the rules are incomprehensible or if each question opens an interminable procedure, employees risk giving up or continuing discreetly.
Finally, let’s give volunteers the opportunity to share their discoveries. A short demonstration can bring out other uses, avoid duplicate developments, or show the limits of an idea. Failures can also be instructive.
Verifying That an Application Is Truly Necessary
Before pushing an idea too far, a question deserves to be asked: do we really need to develop this tool?
The desired function may already exist in a company software. A colleague may have solved the same problem. And sometimes the best way to save time is to eliminate a step that has become unnecessary.
Making application creation more accessible can make people want to solve everything with a new application. A quick exchange with the relevant people can avoid spending several days reproducing an available function or automating a process that should be reviewed.
Identifying When DIY Becomes a Work Tool
Now imagine an employee creates a small tool to prepare their report. Two colleagues ask to use it. A few months later, the entire department relies on it.
It’s a success. It’s also a change in responsibility.
An application regularly used by a team deserves closer examination: are its results reliable? Are its accesses correctly defined? Is its data backed up? Can someone take it over if its creator is absent or leaves the company?
This transition must be identified before the tool becomes indispensable. Use by other people, connection to real data, or intervention in a client operation are good opportunities to take stock.
The level of verification must remain proportionate to the use. A personal text formatting tool and an application that calculates company quotes do not require the same precautions.
For a tool that gains importance, I would foresee at least an identified responsible party, brief documentation, appropriate tests, and a fallback solution in case of failure. Competent technical oversight may also become necessary.
The goal is to allow a good idea to last.
Verifying Results, as Much as Security
When we talk about risks, we quickly think of data breaches. We must also talk about business errors.
An application may seem to work perfectly and apply an incorrect calculation rule. It can produce an erroneous quote, forget a customer category in a report, or process a request twice.
A convincing interface is therefore not enough to validate a tool.
The person who knows the business must verify its results in usual situations, but also for exceptions: missing data, a particular discount, a duplicate, an incorrect entry. For important uses, a second person should participate in this verification.
Initially, comparing the results with the existing method can help identify discrepancies before fully relying on the application.
Recognizing the Work of Those Who Get Involved
I think some teams will see employees emerge who are particularly comfortable with these practices. They will develop their own tools, then help others create them.
This evolution can be very interesting. It allows bringing together knowledge of needs and the ability to meet them.
However, we must look at what it implies. Developing for colleagues also means answering their questions, correcting problems, and managing evolution requests.
These responsibilities cannot be sustainably added to an already busy main mission without arbitrating the workload.
If this contribution becomes regular, it must be given time, recognized, and a handover planned. The company must avoid depending on a single person whose expertise would remain invisible.
A Concrete Example
While 95% of generative AI projects fail due to a lack of method, the feedback from Damien Selosse at Creatis (a subsidiary of Cofidis Group) proves that another path is possible. By establishing transversal “communities of practice,” he directly involved business units in the secure experimentation of their own use cases. An essential case study for anyone looking to demystify the technology, acculturate their field teams, and transform a simple test into a truly value-creating POC.
Evaluating Value Created at the Right Time
The cost question remains. Subscriptions to AI tools represent only part of the expense: one must also account for creation time, testing, potential hosting, maintenance, and user support.
After the discovery phase, it therefore seems normal to ask what the tool brings.
How much time does it save, and how often? How many people actually use it? Does it reduce errors or delays? Does it make a task less arduous? How much time needs to be dedicated to its maintenance?
These questions can remain simple. It’s about comparing a situation before and after, with some concrete observations.
