How AI Is Changing Our Relationship to Work in Software Engineering

Central idea — AI does not only make developers more productive: it changes their relationship to time, effort, satisfaction, and limits.

The essence: 2 min

Full article: 6 min

The essence#

AI-assisted development is radically changing the material conditions of software work. By reducing the friction between idea and result, it accelerates production, but it also transforms the subjective experience of work. The developer no longer only builds over time: they enter a fast loop of possibilities, made of prompts, answers, adjustments, and relaunches. This loop can make work more exciting, almost playful, but also harder to stop. The risk is not that engineers will produce less; it is that they will produce more in a state of permanent stimulation, with less digestion, less closure, and sometimes less satisfaction. The challenge is therefore not to reject AI, but to learn how to tame it: to recreate limits, preserve understanding, strengthen guardrails, and remain producers rather than consumers of possibilities.

In three ideas#

1. AI turns coding into a short reward loop. An idea can be formulated, generated, tested, and relaunched within minutes. This speed gives power, but it also brings work closer to a game-like mechanism: immediate feedback, visible progress, and an always-available next move.
2. The disappearance of friction also removes some stopping points. Part of the friction in software development was painful and unnecessary. But it also slowed us down, forced us to choose, and helped us prioritize. When everything seems quickly doable, it becomes harder to say: “This is enough for now.”
3. The real challenge is not productivity, but mastery. With AI, we can produce faster than we understand. The deeper risk is stronger objective production but weaker subjective appropriation: more code, less digestion, and sometimes an architecture that drifts before we notice it.

Takeaway#

Progress will not only mean going faster with AI. It will mean learning to go fast without being captured by speed: producing more while keeping the ability to choose, understand, finish, and say no to the next possibility.

---

Full article#

A software engineer friend recently told me that, since he started coding with AI, his workdays have changed in nature.

They go by at incredible speed. He chains prompts, corrections, tests, and improvements. Results come quickly. Perhaps too quickly. At the end of the day, he does not really want to stop. He comes out of it as if he had spent several hours playing a video game: stimulated, groggy, with a head full of noise.

Even on vacation, a thought returns: I could have been coding, I could have made progress.

What is striking is not only that he produces more. It is that he sometimes feels less satisfied.

Before, a day of development could end with a form of closure: a solved problem, a finished feature, a difficulty crossed. Now, there is always one last thing to improve. One last prompt. One last relaunch. One last possibility.

This is where something shifts.

Producing, or consuming possibilities#

AI makes developers more productive, but it can also transform their subjective relationship to work.

We no longer only produce code. We consume a flow of possibilities.

An idea appears. We formulate it. The AI responds. We test. We adjust. We relaunch. Another solution appears. Then another. Then another.

The loop is short, fast, and gratifying.

It feels less like the slow effort of construction and more like a game mechanic: immediate objective, instant feedback, visible progress, variable reward.

The difference is that this loop has professional legitimacy. We are not scrolling. We are not playing. We are working.

And that is precisely what makes it hard to regulate.

Friction had a function#

Before AI, software development contained a lot of friction: searching, reading, understanding, writing, testing, failing, starting again.

Some of that friction was useless. It deserved to disappear.

But not all friction was bad. It slowed us down. It forced us to choose. It imposed a rhythm. It made some tasks costly enough that we had to ask whether they were really worth doing.

AI removes part of that resistance.

That is a huge improvement.

But when the material conditions of a profession change within a few months, productivity is not the only thing that changes. The possible drifts change too.

If everything becomes easier to start, stopping becomes harder.

If every improvement seems accessible, every renunciation becomes suspicious.

If the tool answers immediately, the brain learns to want immediately.

Incompletion becomes harder to tolerate#

The trap is here: AI does not only make work faster. It makes the unfinished more visible.

Before, one could say: “I’ll do that tomorrow; it would take too long now.”

Now, one says: “I can probably do it in ten minutes.”

And sometimes that is true.

But ten minutes later, another possibility appears. Then another. The workday no longer ends because a cycle is complete. It ends because it is late, because the body is tired, because life forces us to step out of the flow.

Stopping becomes external to the work.

That is a deep change.

The risk: producing more, digesting less#

Software development is not only an activity of production. It is an activity of understanding.

It is not enough for code to exist. We need to know why it exists in this form. We need to understand boundaries, responsibilities, invariants, and architectural decisions.

With AI, we can move faster than our own capacity to digest.

We generate. We modify. We refactor. We move forward. But do we still truly understand what has just been produced?

This is one of the main risks: stronger objective production, but weaker subjective appropriation.

The code grows. Mastery may shrink.

And in a software system, this loss of mastery is not always immediately visible. It appears later: in inconsistencies, vague abstractions, blurred responsibilities, subtle bugs, and an architecture that drifts.

AI amplifies our culture of speed#

AI does not create all this from nothing. It amplifies trends that were already present in software: fascination with speed, the valorization of output volume, difficulty saying “enough,” and the confusion between passion and overinvestment.

But it changes the intensity.

In just a few months, the working conditions of software engineers have been radically transformed. What used to take a day can sometimes take an hour. What seemed too costly becomes immediately testable. What was blocked becomes negotiable through conversation.

Humans adapt to such changes.

But adaptation is not always healthy. It follows the incentives of the environment.

If the environment rewards constant relaunching, we relaunch.

If the environment rewards speed, we accelerate.

If the environment makes every possibility available, we struggle to renounce.

Learning to tame the tool#

The answer is not to reject AI.

These tools are too powerful, too useful, too structurally important. They can reduce drudgery, accelerate learning, open paths, and improve the quality of work.

But we need to learn how to tame them.

Taming AI does not only mean prompting better. It means recreating limits where friction has disappeared.

It means deciding in advance what “done” means.

It means separating exploration from production.

It means accepting that a possible improvement is not necessarily a necessary improvement.

It means preserving moments when we do not relaunch, when we reread, stabilize, document, and understand.

In software, it also means strengthening guardrails: explicit architecture, clear contracts, tests, typing, boundary validation, observability, and serious reviews.

The more AI accelerates, the more structures must hold.

Otherwise, speed becomes a force of dispersion.

Remaining a producer#

The risk of AI is not that developers will stop producing. It is the opposite: they will produce more.

The risk is that they produce from an inner state of permanent consumption: always stimulated, never satiated, always close to one more improvement, never truly satisfied.

Remaining a producer does not only mean generating more. It means choosing. Prioritizing. Closing. Assuming a form. Saying: “This is enough for now.”

The real progress will therefore not only be going faster.

It will be going fast without being captured by speed.

Producing more without losing the ability to finish.

Using AI without becoming dependent on the loop.

And putting back, at the heart of AI-assisted work, what the tool naturally tends to erase: limits, attention, digestion, and a real ability to say no to the next possibility.