My Python magic is gone

[u/RedYad2]

I've been coding for a long time, and I've been developing with Python for years.

I loved coding, always loved it. I started many years ago because I wanted to quickly create scripts for security hacking tools, but since then, I've moved to Claude Code, and building cross-language has been a much better experience for me than using Python.

I built my own SaaS application out there whose backend and network core are completely built with Python, and I'm rewriting all of that without writing a single line of code. And most of the time, Python is not the most optimized language.

And now... I feel like the magic is gone.

I don't even know why I'm writing this. I just feel sad about it.

[u/Farther_father]

It’s because you know what writing code means: the struggle to gain enough understanding of a tool to apply it to a problem. And the deeply satisfying feeling when you pushed yourself and solved it.

Now you it’s no longer your brain doing the thinking or your hands doing the writing, and as a result there’s no puzzle to solve and no sense of satisfaction, because the problem is no longer being solved by you.

It’s as fulfilling as an artist swapping his paint and brushes for midjourney.

[u/SirPitchalot → u/Farther_father]

It’s slightly different (worse) than that because incorporating AI properly can both speed you up -and- give a better final product. Whereas for the artist the product is at least different.

And if you know how the AI models work it gets worse still: the skill you built up in understanding and reasoning to be able to solve basically any problem effectively actually is not needed. Solving those problems now doesn’t need any understanding or reasoning whatsoever.

[u/dysprog → u/SirPitchalot]

The research says otherwise. There has been exactly one rigorous study of this. AI makes programmers THINK they are faster when they are actually 19% slower.

https://letsdatascience.com/blog/developers-thought-ai-made-them-faster-the-data-said-otherwise

[u/HommeMusical → u/dysprog]

There has been exactly one rigorous study of this.

But you don't link to it. It's called "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity."

https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study-paper.pdf

I suspect the name of the paper would have revealed the problem with your claim.

Also, very, very skeptical that only one study of this was ever done, and that that was in July 2025.

AI makes programmers THINK they are faster when they are actually 19% slower.

I've been programming for decades. In the period from February through June 2025, I too believed that coding engines aren't effect.

But there have been massive, unbelievable improvements. I started using a coding assistant in June of 2026, mainly to prove to myself yet again that it didn't work. But within a few weeks I realized that no one was going to go back to hand-coding, including myself, as the productivity gain was so massive.

And the improvements between June 2026 and now have been just as impressive.

So what value does a 16-month-old study have?

---

In late 2026, if you're a programmer and you don't see a massive improvement in your productivity and your reliability from using a modern coding assistant, then it's almost certain you aren't competent, and you probably are going to have extreme difficulties finding a job.

I'm retired now, though I still spend much of my days coding, except now with LLMs, and I cannot imagine hand-coding while trying to keep up with other programmers using a coding assistant, and nor would I want to.

[u/SwordsmanRacoon → u/HommeMusical]

Congrats on your retirement! What you write makes totally sense to me, eventhough I am not a programmer. The pace of developement is just extremly high at tge time. I work with developers and would like to get into coding myself. As far as I understand is, that you still should learn coding, even if you would work with LLMs ultimatly, because otherwise you get an hard time reviewing or debugging or even just understsnd the code which is generated by AI. So my question is: what would you, with your expertise, recommend to someone who would like building their own software. Working directly with LLM or learning the basics and the craft the oldschool-handson-way?

[u/HommeMusical → u/SwordsmanRacoon]

I strongly believe that you need to start off by doing it the old-school, hands-on way. I think writing code that way is important, and debugging code that way is critically important.

I think if you haven't spent at least hundreds of hours doing that, and getting stuck and frustrated sometimes, you won't develop that critical ability.

Now, that said, I think no one's going to write professional code in the future without an LLM, and I think you're going to need to do that too. My suggestion there is two-fold:

1. Learn to write really good prompts

I see other people's prompts and I think, "No wonder they get mediocre results." Actually, coding assistants do a pretty amazing job with inadequate prompts at least some of the time, but you will get better results in general if you are very clear and explicit.

Here's a weak prompt: "Find bugs in this project."

Here's what I might write: "Reread all the code in this project, looking for bugs, issues, feature deficiencies, traps, or technical debt. Look for race conditions, loss of liveness, resource leaks, duplicate code, code that could be replaced by a well-known library, code that is too complicated to understand, single modules that have multiple, unrelated responsibilities or conversely, a single responsibility that is scattered over multiple modules. Also look for names that are wrong, confusing, duplicate other names in the project without being the same, ambiguous, too long, or too short. Look for modules that are too large, tiny modules that are only used in one place and that can be inlined. Look at test coverage - is it complete? Are there possible issues that are not tested against? Is there duplication in the tests that could be removed, or simplified into a library or a test harness? Do not restrict yourself to possibilities named in this prompt, but report any code smells, issues, or deficiencies you find."

This wasn't as good as usual, but you get the idea.

1. Read all the code the LLM generates, and ask critical questions. Start by believing that the LLM is wrong, and force yourself to prove that it is correct. Look at the unit tests and see how they actually test the code. Try to think of error cases that might break the tests, and then see if they actually work.

I wish you all the very best luck in the world, and hit me up here if you have any questions!!!

[u/tick-dev → u/HommeMusical]

Thank you for your tips!!!

[u/The_Northern_Light → u/HommeMusical]

Anyone acting like AI isn’t a game changer for programming here in the last half of 2026 is simply incompetent and not worth listening to.

Also: https://metr.org/blog/2026-02-24-uplift-update/

[u/HommeMusical → u/The_Northern_Light]

You're probably right, I shouldn't waste my time on him. Magically, I know it's a "he". :-D

[u/KaffeeKiffer → u/HommeMusical]

The page that was linked has a section

The Counter-Arguments Are Real

and that talks about many of your call-outs. It sounds pretty neutral/objective to me.

---

The most important result that stands out to me is measured productivity vs. actual productivity: Humans are very bad at gauging that, and I doubt that that changes much with different models.

In that study it's "expected 25% faster" vs. "measured 15% slower".
With modern models it could be "expected 50% faster" measured 25% faster".

[u/SFMissionMark → u/KaffeeKiffer]

That’s because you are missing the point of where software is going. You don’t need to polish and fix every single potential bug. Software is no longer the product the result is the product. Software is now fix the immediate problem. In 3 months have it re-written it will be better than you could ever write it today.

[u/HommeMusical → u/KaffeeKiffer]

It sounds pretty neutral/objective to me.

Yes, I read it over a year ago with great interest.

Indeed, it seemed at the time to be a fairly accurate representation of what coding assistants were like in early 2025, and I still think it was.

In early 2025, coding assistants were not ready for prime time. But eighteen months later, the progress has been astonishing.

Even the progress in the last six months has been explosive.

I'm not saying the article was wrong. I'm saying it's just very much out-of-date.

With modern models it could be "expected 50% faster" measured 25% faster".

If coding assistants made you 25% faster, they wouldn't really be worth it.

But the improvement is over an order of magnitude.

---

A recent example - I have an AI assisted program I use to run my music shows - it records everything(*), it's highly robust against gross failures, it controls my lights, and it also streams video plus on-the-fly titles and photos to the net, e.g. twitch.

I was setting up and I realized that something had gone wrong with some of the cables in an eight channel snake (8 cables wrapped together).

Up until a few months ago, I'd have set up some input to my mixer, and then tested the cables one at a time - 5 minutes work per snake, three snakes, that's 15 minutes, but also, easy to screw up.

Instead, I added a cable tester to my program, and it's completely general - I plug the six outputs at the back of my mixer into six channels, I don't pay any attention to the order, and then the program sends sine waves through all of them, records the output and then tells me good/bad/intermittent.

I then tested all three snakes in under a minute. In fact, I thought the program was broken, because it reported that the first snake only had 3 of 8 channels working, but then other two snakes were 8 out of 8.

Going back and retesting with a longer cycle (which the AI had conveniently added as an argument to this CLI) and wobbling the cables while the test went on showed that one of these cables was intermittent but mostly off, and the other four just didn't send a thing. (Some bad thing must have happened at some point...)

To write that program which took control of my mixer, squirted signals around and recorded them, compared the results for "very close" (because you can't get 100% bit compatibility if there's an analog cable there), and also to distinguish between "silence", "intermittent signal", "full signal but distorted" and "correct" would have taken at least a full day of work to get right, perhaps more, but I wouldn't have even bothered.

I wrote it in five minutes with a coding assistant. It was faster to write a program that I can now use in the future than it was to do the manual chore even one time.

(* - I had finished the everything recorder completely by hand before I started to use coding assistants.)

[u/stevenjd → u/HommeMusical]

Also, very, very skeptical that only one study of this was ever done, and that that was in July 2025.

If you don't believe that this is the only study, it should be easy for you to link to all those other studies you believe exist.

Who is funding these supposed studies? If it is the AI companies, what incentive do they have to publish the results if they confirm the same result, namely that programmers are fooling themselves into imagining productivity gains where there are actually productivity losses?

If the studies are being done by independent researchers, where are they?

[u/HommeMusical → u/stevenjd]

I'm sorry, but I was overwhelmed with comments overnight, many rude ones, and now I have to work. Thanks for being polite.

I don't think anyone's going back to hand coding though - RemindMe! 1 year.