I Thought AI Would Give Me More Free Time. Now I Want to Build More.
Tech
AI
AI Productivity
AI Coding
Developer Workflow

I Thought AI Would Give Me More Free Time. Now I Want to Build More.

I expected AI to give me more free time. After 229 commits across five repositories, I noticed I wanted to build more. Here is the honest trade-off.

Uygar DuzgunUUygar Duzgun
Sep 12, 2026
8 min read

I thought AI would give me more time away from work. Finish earlier. Close the laptop. Get some evenings back.

Instead, I want to build more.

That is the AI productivity paradox I keep noticing in my own work. A task becomes easier to start, so I start it. An idea that would have stayed in my notes gets a first implementation. Then I see something else worth improving.

Looking through five local repository histories, I counted 229 non-merge commits between September 1 and September 12, 2026. That number needs context. It includes features, tests, documentation, fixes, reverts, and reapplied work. It is not 229 finished features, a deployment report, or a measurement of time saved.

Still, reading through that history made me stop. I had been moving between enough different problems that I had barely noticed the accumulated work.

Three years ago, getting a useful answer felt impressive

OpenAI introduced GPT-4 on March 14, 2023. Around three years later, I find myself treating capabilities that once felt surprising as ordinary parts of a workday.

The useful comparison is the workflow around the model. A chat answer could explain an error or suggest an implementation. Someone still had to provide the relevant context, move the code into the project, run it, and work out whether the answer fit the actual system.

Those responsibilities have not disappeared. But I can now connect an agent to the repository and tools where the work happens. It can inspect existing files, propose a scoped change, run commands, and work through failures with feedback.

I use both OpenAI and Anthropic tools. My interest is less about winning a model argument and more about getting a useful result from the system in front of me. A capable model with the wrong context can still waste an evening.

What those 229 commits contained

The history covered e-commerce, CRM workflows, a music product, a mobile app with its website, and my own publishing site. I am keeping internal project and customer names out of this account.

In e-commerce, the work included translation handling, rich FAQ content, navigation contracts, and product-management tools. Several changes were about preserving existing information correctly when another system touched it.

The CRM history included mobile layouts, expense views, sales workspaces, dashboard widgets, and permission checks. There were also reversals and follow-up corrections. Counting those as separate completed outcomes would exaggerate what the history proves.

The music product included report-loading improvements and fixes to recommendation states. The app and website history included subscription navigation and signup confirmation work. My publishing site included draft previews, authentication boundaries, and URL-validation fixes.

This is a record of activity across several products. I did not compare equivalent tasks with and without AI, and Git cannot tell me which model caused a particular result. I cannot honestly turn the total into a percentage productivity gain.

The interesting part, for me, is the range of work I was willing to tackle.

The AI productivity paradox: I spend the saved time building

I expected to use faster tools to finish the same list earlier. In practice, I keep changing the list.

An awkward mobile view used to compete with everything else I needed to do. Now I can ask an agent to inspect the layout, identify the relevant components, and prepare a change I can review. That lowers the effort needed to begin.

Once I start, I often notice another problem. A loading state hides useful information. A test covers the easy case but misses a permission boundary. A translation looks correct until it passes through the real renderer.

Some of that is necessary follow-up. Some is work I choose because I can finally see a manageable path to it.

Anthropic describes a related pattern in its 2026 Agentic Coding Trends Report: its internal research found engineers reporting less time spent per task category alongside a larger increase in output volume. The report interprets this as doing more work, including more features, fixes, and experiments.

That is company research about its own environment, not proof that every developer benefits equally. But the distinction between finishing faster and choosing to do more fits my experience.

What other developers say, and what the numbers measure

Work that would never have made the list

In Anthropic's December 2025 workplace study, 132 engineers and researchers were surveyed and 53 gave detailed interviews. Employees estimated that 27% of their Claude-assisted work would not have happened without it. That included exploratory work and useful tools that would otherwise have been too expensive to make manually.

One participant said AI helped them "persist on tasks that I previously would've given up on immediately." That sounds familiar. Sometimes the change is my willingness to try.

These are reports from people working inside an AI company, with privileged access to its tools. They are not a controlled estimate of how much time everyone saves.

AI productivity evidence: 27% additional enabled work in an Anthropic survey, and 19% longer completion time in METR's early-2025 trial
AI productivity evidence: 27% additional enabled work in an Anthropic survey, and 19% longer completion time in METR's early-2025 trial

*Original graphic, coded from the reported numbers. The panels measure different things; they are not competing model scores. The same figures and limitations are explained in the text for accessibility.*

Feeling faster is not the same as being faster

METR's July 2025 randomized study followed 16 experienced open-source developers across 246 tasks in familiar repositories. With the early-2025 AI tools tested, they took 19% longer to complete tasks. Afterwards, participants still estimated that AI had made them faster.

The graphic sets no-AI completion time to 100 and AI-assisted time to 119. That is a normalized illustration of the reported effect, not minutes, raw task data, or a benchmark of today's models.

There is an important follow-up. In February 2026, METR said its newer experiment faced selection problems. Some developers avoided participation or withheld tasks because they did not want to work without AI. METR considered greater speedups likely, but said the newer data was weak evidence for their size.

For my own workflow, I take three things from this:

Enjoyment matters: I want to attempt more ideas, and that has value to me.
Measurement matters: enthusiasm and commit totals cannot establish hours saved.
Context matters: the task, developer, tools and review requirements can change the result.

The research does not prove that my longer wish list is universal. It does explain why a single productivity percentage would miss much of what I am trying to describe.

More output still creates more review work

My Git history also contains the less exciting side of this story: fixes to earlier fixes.

An agent can produce something plausible quickly. I still need to check that it respects the existing system, handles the failure case, and works in the place a user will encounter it.

For a mobile screen, that means looking at the actual screen. For a permission rule, it means testing who can perform the action. For an article, it means checking that the sources support the wording.

Recommended reading

I have written about testing an AI coding model on real CRM problems. That kind of bounded task gives me something concrete to inspect. A confident explanation alone does not.

Using another model for review can help surface problems, but agreement between models is not the same as a passing test or a working product. I still own the decision to accept the work.

I need a stopping point more than another idea

There is a difference between wanting to work and feeling unable to stop. I like building. I also want a private life that does not get whatever time remains after the next fix.

I do not want to turn long hours into advice. The lesson I take from this is that faster tools make my own boundaries more important.

A clear definition of done helps: the requested behavior works, the relevant checks pass, and remaining issues are recorded. Discovering another possible improvement does not automatically make it part of tonight's job.

I am still learning that distinction. AI has given me more reasons to open the laptop. Choosing when to close it remains my responsibility.

Why I think we are still early

I believe we are early in learning how to work with these tools. That is a personal judgment, not a forecast of endless model progress.

There is still plenty to improve in how we provide context, control permissions, verify results, and hand work between people and agents. Better habits around today's models already change what I can get from them.

Three years is a short time for such a large change in my everyday workflow. I cannot tell you exactly what the next three will bring.

I can tell you that I expected more free evenings. What surprised me was how much more I wanted to make.

For now, my next improvement is learning to keep some of the time I save.

*Hero image: AI-edited editorial illustration based on my own portrait; the workspace is generated.*

FAQ

Does AI give developers more free time?+
It can reduce the effort required for some tasks, but that does not guarantee a shorter workday. In my experience, making work easier to start also makes me choose more work.
What does the AI productivity paradox mean in this article?+
Here it describes my personal experience of expecting AI to create more free time, then using the saved effort to build and improve more things. It is not a measured claim about economy-wide productivity.
Do 229 Git commits prove an AI productivity increase?+
No. The count covers five local repository histories from September 1 to 12, 2026, excluding merge commits. It includes fixes, documentation, reverts, and reapplied work, and does not establish time saved, AI attribution, or production delivery.
How do I keep AI-assisted development under control?+
Define the requested outcome and checks before starting, review the actual result, and record additional ideas separately. Another model's approval can support review but cannot replace testing.

Recommended for you

GPT-6 Astra Review: I Put It to Work on a Real CRM

GPT-6 Astra Review: I Put It to Work on a Real CRM

I tested GPT-6 Astra on real CRM bugs. Three local fixes, independent benchmarks, early reviews, and practical tips for working with the new model.

7 min read
AI Engineering Build Log: What I Shipped in July 2026

AI Engineering Build Log: What I Shipped in July 2026

July's work spanned a notarized macOS release, controlled music-analysis tests, public SEO actors, internal TestFlight builds, and deliberate non-releases.

9 min read
LLM Energy Efficiency Depends on the Serving Stack

LLM Energy Efficiency Depends on the Serving Stack

LLM energy efficiency changes with traffic, serving choices, hardware and SLOs. Use this phase-aware audit before optimizing production inference.

12 min read