I had similar thoughts recently. I wouldn't consider myself "the thinker", but I simply missed learning by failure. You almost don't fail anymore using AI. If something fails, it feels like it's not your fault but the AI messed up. Sometimes I even get angry at the AI for failing, not at myself. I don't have a solution either, but I came up with a guideline on when and how to use AI that has helped me to still enjoy learning. I'm not trying to advertise my blog and you don't need to read it, the important part is the diagram at the end of "Learning & Failure": https://sattlerjoshua.com/writing/2026-02-01-thoughts-on-ai-.... In summary, when something is important and long-term, I heavily invest into understanding and use an approach that maximizes understanding over speed. Not sure if you can translate it 100% to your situation but maybe it helps to have some kind of guideline, when to spend more time thinking instead of directly using and AI to get to the solution.
I miss thinking hard
211–220 of 764 posts
Re: I miss thinking hard
#212I have a very similar background and a very similar feeling when i think of programming nowadays.
Personally, I am going deeper in Quantum Computing, hoping that this field will require thinkers for a long time.
Re: I miss thinking hard
#213have a look at
https://projecteuler.net/
for "Thinker" brain food. (it still has the issue of not being a pragmatic use of time, but there are plenty interesting enough questions which it at least helps)
Re: I miss thinking hard
#214Re: I miss thinking hard
#215Re: I miss thinking hard
#216If you feel this way, you arent using AI right.
For me, Claude, Suno, Gemini and AI tools are pure bliss for creation, because they eliminate the boring grunt work. Who cares how to implement OAuth login flow, or anything that has been done 1000 times?
I do not miss doing grunt work!
Re: I miss thinking hard
#217I will never not be upset at my fellow engineers for selling out the ONE thing that made us valuable and respected in the marketplace and trying to destroy software engineering as a career because "Claude Code go brrrrrr" basically. It's like we had the means for production and more or less collectively decided "You know what? Actually, the bourgeoisie can have it, sure."
Money. It's always money. It was always money.
Couldn't agree more. AI as it's designed today is very heavy on the "f u; got mine" vibe.
Re: I miss thinking hard
#218I'm using LLMs to code and I'm still thinking hard. I'm not doing it wrong: I think about design choices: risks, constraints, technical debt, alternatives, possibilities... I'm thinking as hard as I've ever done.
Yeah, but thinking with an LLM is different. The article says: > By “thinking hard,” I mean encountering a specific, difficult problem and spending multiple days just sitting with it to overcome it. The "thinking hard" I do with an LLM is more like management thinking. Its chaotic and full of conversations and context switches. Its tiring, sure. But I'm not spending multiple days contemplating a single idea. The "thi…
YMMV, but I've found that I actually do way more of that type of "thinking hard" thanks to LLMs. With the menial parts largely off my plate, my attention has been freed up to focus on a higher density of hard problems, which I find a lot more enjoyable.
Re: I miss thinking hard
#219Earlier quoted context omitted.
>I haven't reduced my thinking! You just detailed an example of where you did in fact reduce your thinking. Managers who tell people what to get done do not think about the problem.
I think my message is doing a disservice to explaining what actually happened because a lot of it happens in my head. 1. I received the ticket, as soon as I read it I had a hunch it was related to some querying ignoring a field that should be filtered by every query (thinking) 2. I give this hunch to the AI which goes search in the codebase in the areas I suggested the problem could be and that's when it find the iss…
Did you use your AI to create that list for you?
Re: I miss thinking hard
#220Earlier quoted context omitted.
I dunno, when you've made about 10,000 clay pots its kinda nice to skip to the end result, you're probably not going to learn a ton with clay pot #10,001. You can probably come up with some pretty interesting ideas for what you want the end result to look like from the onset. I find myself being able to reach for the things that my normal pragmatist code monkey self would consider out of scope - these are often not u…
Depends on the problem. If the complexity of what you are solving is in the business logic or, generally low, you are absolutely right. Manually coding a signup flow #875 is not my idea of fun either. But if the complexity is in the implementation, it’s different. Doing complex cryptography, doing performance optimization or near-hardware stuff is just a different class of problems.
> If the complexity of what you are solving is in the business logic or, generally low, you are absolutely right.
The problem is rather that programmers who work on business logic often hate programmers who are actually capable of seeing (often mathematical) patterns in the business logic that could be abstracted away; in other words: many business logic programmers hate abstract mathematical stuff.
So, in my opinion/experience this is a very self-inflected problem that arises from the whole culture around business logic and business logic programming.