Coding 10x faster: what's the real benefit?

I saw a Reddit post the other day: "Developers who save a ton of time thanks to AI: what do you do with it?" (in french)

It got me thinking. I have an answer from my own experience, which I'll share with you. But I'm well aware my situation is peculiar. So I decided to dig deeper, and I realized something: the real question isn't whether you're getting faster. It's: what does that actually change for you?

Do you work less? More? Differently?

What's the impact in a large corporation? What about freelancers?

Essentially: if someone gains time, what's it actually worth to them?

Is That Time Gain Even Real?

First, let me be thorough and put things in perspective. A recent study from METR (Model Evaluation & Threat Research) shows that this time gain might not be as straightforward as we think.

The study found that experienced developers working on legacy codebases were actually 20% slower with AI, largely due to code review cycles.

Take it with a grain of salt—the sample size was only 16 people. And context matters: we're talking about expert developers working on large, complex codebases.

I won't dwell on this study because I can find others saying the opposite. But I thought it was intellectually honest to mention it, to balance the narrative and add some perspective.

The point isn't to assume that AI definitely makes us faster. I don't want to get into that debate. Instead, let's strip away the AI label entirely and just consider a hypothesis:

What if someone could produce code 20-30% faster? Or even 10x faster? What happens then? If software production becomes cheaper, what's the impact on the developer profession? What can you actually do with that gained time?

This isn't a silly hypothesis. The profession has changed radically since the days of physically wiring computers to program them. We've constantly improved productivity. And our successors probably won't work the way we do.

An Opportunity for Product Builders

I'm an outlier, so my answer doesn't apply to most people.

I work with one co-founder on a recently launched product. I have no productivity quotas, no salary pressure, no one to report to.

I control my own time. If I finish a task in an hour instead of a week, I can just stop working and do something else. I'm not obligated to pad my hours or hit some end-of-day checkpoint.

Of course, I still have pressure—the product needs to be good and adopted. I track new users monthly, revenue growth, and customer feedback via email. But for my situation, extra time is genuinely useful.

I can spend more time responding to emails thoughtfully. I can do deeper analysis of my market and user feedback.

In short, I see it as an opportunity.

Before, as a "technical founder," I spent all my time coding and lived heads-down, with no bandwidth to think strategically about the product long-term. Gaining time lets me rebalance.

I love coding. But coding was eating up brain cycles I needed for strategy.

That's no longer the case.

I can spend more time on the "why" instead of just the "how."

Time to Improve, Not Just Expand

Time has always been scarce in software and startups. When I gain time, I spend it on other product work: improving user documentation, strengthening test infrastructure to prevent future problems.

I tackle bugs I see in the logs, or UI quirks I'd noticed but pushed off indefinitely.

You know the feeling—that infinite Jira backlog filled with small improvement tickets. Those famous "we'll do it later" items that exist mostly to make us feel better, or to satisfy the support person who asked about them.

"Look, it's on our TODO list. Yeah, it'll take 15 years to get to, but it's there…"

That doesn't exist for me anymore. Small issues like that pile up by the dozens, and the product steadily improves.

Using the financial analogy of technical debt: once code costs less, you pay down the debt continuously, which reduces the interest burden.

Time to Learn

Since I spend less time coding, I've had much more time to think deeply about problems. And I've invested in education.

Before, time pressure forced shortcuts. Recently, I've documented and written about content moderation on platforms, dug into SSL certificate systems, explored proof-of-work captcha mechanisms, studied purchasing power parity.

And here's the surprising part: I've just stepped away from the keyboard.

Often in my typical day, I spend time away from the screen. I've improved my broth technique for ramen. I've done home repairs and started building furniture.

Paradoxically, that time helps me build better products.

Ever notice you solve complex problems in the shower?

Letting your mind wander is creative fuel.

It took me a while to accept it, but giving your brain rest—letting it incubate ideas and wander while you do something else—is excellent for problem-solving.

Of course, I know my situation is specific. I can't imagine starting a woodworking session in the middle of an open office surrounded by developers. But for me, gaining time on code means a holistic rebalancing of my days and, paradoxically, better-quality output.

Because it was never just about coding—it was also about thinking long-term, which is easier when you have time for it.

Clearly, though, it's different in a more traditional context. So I did some research on what others are saying.

Productivity and Burnout: The Real Cost

One of the first insights comes from a Harvard Business Review study. Increased productivity doesn't lead to reduced working hours—it leads to intensification.

Work becomes more intense for several reasons:

AI removes cognitive breaks. Since AI makes it faster to start a task, you lose the natural pause that exists at the beginning of each project when you're figuring out the approach.

AI blurs job boundaries. You feel capable of doing frontend, design, ops, backend, mobile. Your scope explodes for a single person.

Frequent gratification drives endless continuation. If you complete 10 tickets a day and each is quick, why not one more? One quick prompt before closing the laptop?

But this intensification comes at a real cost: fatigue, burnout, mistakes (because tired people miss things).

I found an article that compares AI to a vampire draining our energy.

The idea is simple: since AI handles all the simple, repetitive tasks that used to serve as cognitive breaks, we're left essentially doing high-level work and critical decisions.

But humans can't make critical decisions nonstop for 8 hours a day. It's exhausting.

That's why I personally either step away from my screen for part of the day or do more recreational activities at the computer: writing an article (which explains why I write more now), or learning something new. The article recommends finding a new balance.

I'm not sure how sincere the article is, but this seems to be GitHub's approach. They used the time gain not to drastically increase output but for other kinds of work: collaboration, reflection.

Doing More ≠ Doing Better

There's a hard limit to how many new features users can absorb daily anyway.

Just because you can ship 10x more features doesn't mean it benefits users.

This is Tesler's Law, also known as the Law of Conservation of Complexity. Every system has an irreducible level of complexity. If you reduce it in one place—say, developers moving faster—it appears elsewhere: users now have to adapt to software that evolves too quickly.

You also risk "feature fatigue," where software becomes bloated and overwhelming. Being forced to make choices is often healthy.

Essentially, speeding up benefits no one, and it's preferable that productivity gains show up as better-thought features or increased work on "invisible" quality.

When Productivity Creates Boredom

There's another scenario worth mentioning. Many people work at organizations where going faster changes absolutely nothing, because the company is fighting its own inertia more than any product challenge.

I worked at a large corporation once. I remember a project in 2003 where coding really wasn't the issue.

I'd come from a more dynamic job. I was used to a certain pace. Here, I was given a program to write. I finished it in 2 days. I went back to my manager. He said we'd discuss it again in 3 weeks. In a year, I shipped almost nothing. It was probably the worst year of my career.

Mornings brought people asking who wanted to attend meetings about various topics. I couldn't understand why everyone kept going.

But then I got it. It was to fill the day.

If I'd spent 1 hour instead of 2 days on my work, I'd just have been bored longer.

I knew burnout existed. But there I almost experienced burnout's opposite: complete stagnation. Eventually, I educated myself on the side in areas I cared about. I made that time count.

But I won't lie—I was incredibly relieved when that project ended.

The point: in some places, coding faster changes nothing. Coffee breaks just get longer.

Freelancers: From Time to Value

Now there's a population I have real questions about.

Let's say code costs collapse. What happens to people billing by the hour?

You could imagine a chunk of them won't exactly broadcast that they finished a job faster, since that means losing money.

Can that hold long-term, especially for a freelancer working on-site at the client, visible to everyone? In big companies, maybe. But it'll never work in an organization whose developers are also using the same tools to move faster.

That's where I wonder if fixed-price or outcome-based billing might become more attractive than hourly rates.

Usually, I advise against results-based contracts, especially for younger freelancers, because it's hard to contract properly, set boundaries, and accurately estimate work beforehand.

But if AI made development faster and more predictable, fixed-price work could regain appeal.

It wouldn't be about billing time. It would be about billing value.

I'd have no problem charging a fixed amount for valuable work, even if it took only 1-2 days.

I've worked 25 years to deliver that result in 2 days. Clients pay for your experience and your ability to use tools. Speed is irrelevant.

In a worst-case scenario, I might lower prices slightly, but the risk I take on also gets priced into a fixed contract.

That said, I'm not sure this logic holds forever. Competitors as good as me might take on more clients to offset losses, driving per-contract prices down.

I came across an article on this. It concluded that expert freelancers will survive, but demand will shrink. Especially since their clients will also start coding if the cost drops low enough.

But one takeaway stuck with me: AI won't replace the freelancer. The freelancer using AI will replace the one who doesn't. That's probably the most important lesson.

Conclusion

Again, the question wasn't whether AI makes us faster. The real question I wanted to explore was: what do you do with the time you gain?

The answer depends on your context.

If you're at an organization paralyzed by inertia, moving faster changes nothing—you'll just get bored sooner. If you're product-focused with the freedom to manage your own time, it's an incredible opportunity to step back and think strategically. If you're a freelancer, maybe it's time to renegotiate.

But here's the critical constraint: productivity only matters if it creates value. Shipping 10x more features might actually hurt your users. Gaining time is great, but it's only valuable if you know what to do with it.

Bottom line: there's no one-size-fits-all answer. But you might just gain the time needed to figure out what your answer is.