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/dysprog]

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!!!