Note on the writing of this article

Yes, this article was written with the help of AI. However, the ideas, opinions, and experiences expressed in it are entirely my own. The text came out of lengthy prior discussions during which I developed my thinking, answered questions, and clarified my point of view. AI was mainly used to organize and formulate that material into an article. I then reread, corrected, and approved the entire text before publication.

I’m Not a Good Developer. And That’s Precisely Why AI Changed the Way I Create

I’m going to start with something that might sound strange coming from someone who has been developing applications for several years: I don’t consider myself a very good developer.

This isn’t false modesty, and I’m not saying it so that people can tell me I have impostor syndrome and that I’m actually great.

I genuinely have technical shortcomings. I’m not particularly good at algorithms, I’ve never found computer science abstraction or mathematics especially easy, and I’m not the kind of person who can open an editor and start building a complex architecture from scratch in their head.

And yet, I develop software.

Quite a lot of it, actually.

That is precisely why I think my experience with LLMs is interesting.

I Was Already Developing Before ChatGPT

I started with a bootcamp in 2020–2021 covering HTML, CSS, JavaScript, PHP, and Symfony.

Then, like many self-taught developers or people coming out of short training programs, I kept learning by doing.

During a six-month internship at Plastic Omnium, I was the only developer. I had been recruited by the site’s IT department, which was mainly focused on system administration and needed small internal web solutions.

I built several of them.

The first was a very simple application for comparing barcodes. If the two matched, the screen displayed a huge green message. If they didn’t, it displayed a huge red one. The goal was simply to prevent certain mistakes when shipping parts.

I also developed a Symfony application for managing factory workers, including creating worker profiles and assigning them to workstations.

Finally, I built an interface connected to SQL Server that displayed live production data from several production cells on a screen divided into four sections.

All of this existed before LLMs became mainstream.

So no, AI did not suddenly take me from knowing nothing to being able to build applications.

But the way I developed software back then was already revealing.

I watched tutorials on Udemy and YouTube. I searched Google. When I got stuck, I went to Stack Overflow. I found someone who had encountered a similar problem, tried to adapt their answer to my situation, and moved forward.

I could produce something functional without necessarily having a deep understanding of everything I was using.

Looking back, the Internet had already started externalizing part of my skill set.

I didn’t have all the knowledge in my head. What I mainly knew was where to find it and how to assemble it well enough to achieve the result I wanted.

Then LLMs arrived.

LLMs Didn’t Change Who I Am; They Removed the Friction

The biggest difference with ChatGPT, Claude, Gemini, DeepSeek, and the others isn’t simply that they write code faster than I do.

It’s that almost all the friction that once existed between an idea and its implementation has disappeared.

Before, a feature could take me several hours simply because I would encounter a technical problem, search for a solution, read several answers, try something, realize it didn’t work, and start again.

Today, when I get stuck, I can explain the problem precisely to a model.

If it can’t solve it, I try another one.

If the context becomes too complex, I can export the code, provide more information, and have several models analyze the problem.

In the vast majority of cases, I end up getting unstuck very quickly.

The result is rather paradoxical: I’ve become much more productive without becoming proportionally better at programming.

And I would even say there is a reverse effect.

I try to understand less than I used to.

Before, getting stuck sometimes forced me to understand what was happening. Now, the blockage often disappears before that understanding becomes necessary.

That is probably one of the less comfortable aspects of how I work today. I produce more, but I exercise certain skills less.

In Reality, I Never Really Wanted to Be a Programmer

For a long time, I equated creating software with being a developer.

Today, I make a much clearer distinction.

What really interests me is the product.

When I imagine a feature for LingRise, my first instinct is almost never to ask myself what data structure to use, which design pattern to choose, or how to organize the components.

I first think about what the feature should provide.

How the user will use it.

Why it should exist.

What would feel pleasant, practical, or frustrating.

The technical “how” has become secondary.

I know this position will probably make some developers jump out of their seats, but for most of the projects I want to create, I largely don’t care whether an application is built with Symfony, Laravel, React, or something else.

The same goes for mobile applications: Flutter, React Native, Kotlin, or Swift.

I’m not saying there are no differences. Of course there are.

I’m simply saying that in my context, for the vast majority of conventional products I might want to build, those differences matter far less than the quality of the product itself.

I’m not working on a critical banking system, a medical device, or infrastructure where a few milliseconds, a particular mathematical property, or certain technical guarantees can become fundamental.

I build products for users.

So my main question has become: what should we build?

Not: do I technically know how to build it?

And AI has accelerated that transition enormously.

LingRise Probably Would Never Have Existed Before

This is perhaps the best way to measure AI’s real impact on me.

Without LLMs, I probably would never have launched LingRise.

Not because the project would have been impossible.

I could have learned. I could have spent hundreds—thousands?—of additional hours researching, experimenting, and developing.

But that is precisely the problem.

I probably wouldn’t have done it.

The cost would have been too high relative to my motivation for programming itself.

AI has changed which ideas I consider feasible.

Before, you could have an idea and immediately think about the weeks or months of development it would require.

Today, it’s much easier for me to think: let’s try it.

And I think this shift will have consequences far more significant than simply making existing developers more productive.

If Building Becomes Easier, Having the Right Idea Becomes More Important

People often say that an idea is worth nothing without execution.

I understand what that phrase means, but I think AI is gradually changing the equation.

When execution is extremely expensive, a huge number of good ideas never come to life.

If the cost falls, more people can test their ideas.

To me, that is good news for humanity.

There are probably countless people with very good intuitions, a perfect understanding of a problem, or interesting product ideas who would never have spent two years learning software development in order to build them.

AI gives them a chance.

Obviously, on a personal level, that is slightly less convenient because it also means much more competition.

And I’m not certain LingRise will escape this new reality. I really like what I’m building, and I think the product has significant potential, but I’m fully aware that it could also one day join the gigantic pile of SaaS products that someone built and almost nobody uses.

Because if everyone can build, the problem shifts: you have to build something people actually want.

And at that point, product, design, marketing, understanding users, strategy, and creativity become even more valuable.

That is where I feel much more at home.

My Impostor Syndrome Doesn’t Apply to Everything

I doubt myself enormously when it comes to development. When it comes to computer science abstractions or pure technical skills, I frankly consider myself mediocre.

But I don’t feel the same way at all about imagination.

That is probably the quality I have the most confidence in.

A rather silly example often comes back to me. During the French baccalaureate exam, I had barely studied at all, but one of the exercises asked us to imagine and write the continuation of a text. I got 18 out of 20.

It might seem anecdotal, but it is fairly representative of what has always attracted me.

Imagining.

Creating something that doesn’t exist yet.

Finding a direction.

And my ultimate dream has never been to become an exceptional developer.

One day, I would like to write a memorable work—something capable of affecting me as deeply as a work like Attack on Titan affected me.

And paradoxically, I wouldn’t want AI to write that for me.

I could use it to proofread a passage or suggest better wording, but the work itself, the characters, the story, and the ideas—I would want those to come from me.

That is an important boundary in my relationship with AI.

I have no particular attachment to writing a PHP or Java function myself if a machine can do it better and faster.

But I care deeply about remaining the author of what I consider genuinely creative and personal.

Code That Works Is Not Necessarily Good Software

Obviously, delegating so much to AI creates a problem.

An LLM is extremely good at producing a solution that works right now.

That doesn’t mean it will spontaneously produce a solution you’ll still be happy with two years from now.

I experienced this with LingRise.

For a feature related to audio, the AI chose a solution that technically worked but was poor from an architectural standpoint. It favored the most direct path instead of thinking about reusability and the long-term consistency of the system.

The code worked. But the decision was genuinely bad.

That is probably one of the most important lessons I have learned from working with LLMs.

They tend to look for a quick path toward a satisfactory answer.

And when you’re developing a real product, that isn’t always what you want.

Good software isn’t just code that passes the tests today.

It is also a system that can still be understood, modified, and maintained tomorrow.

After that mistake, I changed the way I work.

In particular, I use BMAD—Breakthrough Method for Agile AI-Driven Development—a lot to structure agents’ work more effectively, give them more context, and introduce several stages of review.

I also try to pay much more attention to decisions that may have long-term consequences.

That is where I think the developer’s role is genuinely evolving.

Understanding Consequences Becomes More Important Than Writing Quickly

If I had to complete a sentence about how the profession is changing, I would say this:

With AI, a developer is no longer primarily someone who knows how to code quickly, but someone who understands the implications of each decision and knows how to guide LLMs so they don’t create technical debt and waste time.

That is very different.

Producing ten times more code has no value if you are producing a disastrous architecture ten times faster.

When agents become capable of implementing enormous amounts of work, the bottleneck shifts.

You need to be able to say what you want.

To provide the right constraints.

To identify a questionable decision.

To know when to request a second analysis.

To understand that a solution that is elegant locally can create a problem globally.

And that is precisely where my own limitations become dangerous.

I can supervise a lot of things.

But I also know there are situations in which I am not competent enough to properly judge what the AI is proposing.

I would rather admit that than pretend a few prompts have suddenly turned me into a senior engineer.

I Wouldn’t Trust AI With Everything Either

I have no desire to fall into the narrative that today you can simply launch a few agents and replace any engineering team.

The extent to which I trust AI is proportional to the potential cost of its mistakes.

If it chooses a bad abstraction for a small feature and I lose three hours, that isn’t a disaster.

If it introduces a vulnerability into payments, authentication, or user-data management, the situation is completely different.

If LingRise works well enough and starts gaining real usage, I plan to have the fundamental parts reviewed by someone who is genuinely competent, especially anything involving payments, security, and user accounts.

For me, the rule is quite simple.

The easier a decision is to reverse and the less dangerous it is, the more I can delegate.

The more significant the potential consequences become, the more I need human understanding and validation.

This principle also explains why I don’t generalize my experience to every field.

Building a small SaaS application and building a banking or medical system obviously do not require the same level of caution.

I Don’t Think a Degree Magically Solves the Problem Either

The opposite conclusion would be equally simplistic.

Saying that competent humans are necessary does not mean that putting ten qualified engineers in a room automatically guarantees excellent software.

We regularly see systems built by large organizations encounter major problems.

Technical competence matters enormously, but it is only one part of the equation.

You also need seriousness, willingness, resources, time, good organization, proper maintenance, and people who are sufficiently motivated and well paid to do their jobs properly.

The fact that experts can make mistakes is therefore not proof that expertise is no longer useful.

It is simply proof that building complex software is difficult.

AI or no AI.

I’m Not Sure LLMs Are “More Intelligent” Than I Am Either

I now sometimes let models think through a huge number of problems for me.

Not necessarily because I consider them intelligent in the human sense of the word.

We could spend hours debating what intelligence really means.

What interests me more is the practical result.

They have access to an amount of knowledge I cannot compete with and a speed of execution far greater than mine.

For a huge number of problems, it simply no longer makes sense for me to spend an hour thinking through something alone when a model can explore it in a few seconds.

But that creates another risk.

If you keep delegating your thinking, you may become less capable of thinking for yourself.

I can see that happening to me.

It is a trade-off I accept today because my main goal is to build.

Someone whose goal is to become an excellent engineer should probably take a very different approach.

If I Were 20 Today, I Probably Wouldn’t Choose Software Development

This may be my most personal conclusion.

If I were 20 today and had to choose a career, I don’t think I would become a developer.

Not because I think the profession is going to disappear.

I have no idea, and I’m very wary of overly confident predictions on that subject.

I would simply make a calculation based on my own profile.

I’m not passionate about code itself.

I’m not excellent at mathematics or abstraction.

I don’t particularly enjoy spending hours understanding the inner workings of a system simply because the problem is interesting.

What attracts me is products and ideas.

In a market where huge numbers of people are learning to develop software, where competition is global, and where companies can probably produce more with fewer developers thanks to AI, I don’t see why I would voluntarily choose to compete in one of my weaker areas.

I would gravitate much more naturally toward product or another field in which my ability to imagine and design something would be more central.

That said, I absolutely would not give that advice to everyone.

If you are 18 or 20, excellent at abstraction, and you love mathematics, systems, programming, security, or deeply understanding computers, go for it.

AI might even make you incredibly powerful.

If you have very good ideas and want to learn enough technical skills to bring them to life, go for it as well. The barrier has probably never been lower.

But if you are simply an average person who was sold software development as an easy path to success, I would be much more cautious.

You may find yourself competing with millions of people who had exactly the same idea as you, on top of machines that can now produce quantities of code that would have been unimaginable just a few years ago.

Learning a few frameworks is probably no longer enough to provide a lasting advantage.

Maybe I’m Exactly the Kind of Creator AI Will Multiply

Ultimately, I find it quite difficult to say whether I am still really a developer.

I build software.

I make product decisions.

I define features.

I give instructions to agents.

I test manually.

I ask agents to make corrections when I find flaws.

I sometimes choose between several solutions.

I monitor the consequences of certain decisions.

But I no longer write code myself.

And I don’t particularly want that to change.

Maybe in a few years, my profile will be completely ordinary.

People who understand enough about technology to communicate with machines, but whose real value lies elsewhere.

In their knowledge of an industry.

In their understanding of a user.

In their taste.

In their ability to sell.

In their creativity.

In their imagination.

In their ability to identify an interesting problem before others do.

I find that prospect both exciting and worrying.

Exciting because more people will be able to create.

Worrying because when everyone can build, building is no longer enough.

And maybe, deep down, that is what AI has really changed for me.

It hasn’t taught me to love programming.

It hasn’t turned me into an excellent engineer.

It has simply allowed me to depend less on the things I’m average at, so I can spend more time on the things I think I’m good at.

Having ideas.

Imagining products.

Creating.

And if AI continues to improve, perhaps the most interesting question will no longer even be whether developers are going to disappear.

Perhaps it will be why, for so long, knowing how to program was a requirement for turning an idea into something real.