Comment by topspin

1 day ago

I'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 "thinking hard" I do over multiple days with a single problem is more like that of a scientist / mathematician. I find myself still thinking about my problem while I'm lying in bed that night. I'm contemplating it in the shower. I have little breakthroughs and setbacks, until I eventually crack it or give up.

Its different.

  • 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.

I very much think its possible to use LLMs as a tool in this way. However a lot of folks are not. I see people, both personally and professionally, give it a problem and expect it to both design and implement a solution, then hold it as a gold standard.

I find the best uses, for at least my self, are smaller parts of my workflow where I'm not going to learn anything from doing it: - build one to throw away: give me a quick prototype to get stakeholder feedback - straightforward helper functions: I have the design and parameters planned, just need an implementation that I can review - tab-completion code-gen - If I want leads for looking into something (libraries, tools) and Googling isn't cutting it

  • > then hold it as a gold standard

    I just changed employers recently in part due to this: dealing with someone that appears to now spend his time coercing LLM's to give the answers he wants, and becoming deaf to any contradictions. LLMs are very effective at amplifying the Reality Distortion Field for those that live in them. LLMs are replacing blog posts for this purpose.

I echo this sentiment. Even though I'm having Claude Code write 100% of the code for a personal project as an experiment, the need for thinking hard is very present.

In fact, since I don't need to do low-thinking tasks like writing boilerplate or repetitive tests, I find my thinking ratio is actually higher than when I write code normally.

  • I'm with you, thinking about architecture is generally still a big part of my mental effort. But for me most architectural problems are solve in short periods of thought and a lot of iteration. Maybe its an skill issue, but not now nor in the pre-LLM era I've been able to pre-solve all the architecture with pure thinking.

    That said architectural problems have been also been less difficult, just for the simple fact that research and prototyping has become faster and cheaper.

    • I think it depends on the scope and level of solution I accept as “good”. I agree that often the thinking for the “next step” is too easy architecturally. But I still enjoy thinking about the global optimum or a “perfect system”, even it’s not immediately feasible, and can spend large amounts of time on this.

      And then also there’s all the non-systems stuff - what is actually feasible, what’s most valuable etc. Less “fun”, but still lots of potential for thinking.

      I guess my main point is there is still lots to think about even post-LLM, but the real challenge is making it as “fun” or as easily useful as it was pre-LLM.

      I think local code architecture was a very easy domain for “optimality” that is actually tractable and the joy that comes with it, and LLMs are harmful to that, but I don’t think there’s nothing to replace it with.

  • Agreed. My recent side projects involve lots of thinking over days and weeks.

    With AI we can set high bars and do complex original stuff. Obviously boilerplate and common patterns are slop slap without much thinking. That's why you branch into new creative territory. The challenge then becomes visualising the mental map of modular pieces all working nicely together at the right time to achieve your original intent.

My experience is similar, but I feel I'm actually thinking way harder than I ever was before LLMs.

Before LLMs once I was done with the design choices as you mention them - risks, constraints, technical debt, alternatives, possibilities, ... I cooked up a plan, and with that plan, I could write the code without having to think hard. Actually writing code was relaxing for me, and I feel like I need some relax between hard thinking sessions.

Nowadays we leave the code writing to LLMs because they do it way faster than a human could, but then have to think hard to check if the code LLM wrote satisfies the requirements.

Also reviewing junior developers' PRs became harder with them using LLMs. Juniors powered by AI are more ambitious and more careless. AI often suggests complicated code the juniors themselves don't understand and they just see that it works and commit it. Sometimes it suggests new library dependencies juniors wouldn't think of themselves, and of course it's the senior's role to decide whether the dependency is warranted and worthy of being included. Average PR length also increased. And juniors are working way faster with AI so we spend more time doing PR reviews.

I feel like my whole work somehow from both sides collapsed to reviewing code = from one side the code that my AI writes, from the other side the code that juniors' AI wrote, the amount of which has increased. And even though I like reviewing code, it feels like the hardest part of my profession and I liked it more when it was balanced with tasks which required less thinking...

> I'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.

Okay, for you that is new - post-LLM.

For me, pre-LLM I thought about all those things as well as the code itself.

IOW, I thought about even more things. Now you (if I understand your claim correctly) think only about those higher level things, unencumbered by stuff like implementation misalignments, etc. By definition alone, you are thinking less hard.

------------------------

[1] Many times the thinking about code itself acted as a feedback mechanism for all those things. If thinking about the code itself never acted as a feedback mechanism to your higher thought processes then ... well, maybe you weren't doing it the way I was.

Reading this comment and other similar comments there's definitely a difference between people. Personally I agree and resonate a lot with the blog post, and I've always found designs of my programs to come sort of naturally. Usually the hard problems are the technical problems and then the design is figured out based on what's needed to control the program. I never had to think that hard about design.

It's certainly a different style of thinking hard. I used to really stress myself over coding - i.e. I would get frustrated that solving an issue would cause me to introduce some sort of hack or otherwise snowball into a huge refactor. Now I spend most of my time thinking about what cool new features I am going to build and not really stressing myself out too much.

I think OP's post is an attempt to move us past this stage of the discussion, which is frankly an old hat.

The point they are making is that using AI tools makes it a lot harder for them to keep up the discipline to think hard.

This may or may not be true for everyone.

I use Claude Code a lot, and it always lets me know the moment I stopped thinking hard, because it will build something completely asinine. Garbage in, garbage out, as they say...

its how you use the tool... reminds me of that episode of simpsons when homer gets a gun lic... he goes from not using it at all, to using it a little, to using it without thinking about what hes doing and for ludicrous things...

thinking is tiring and life is complicated, the tool makes it easy to slip into bad habits and bad habits are hard to break even when you recognise its a bad habit.

Many people are too busy/lazy/self-unaware to evaluate their behaviour to recognise a bad habit.

there's no such thing as right or wrong , so the following isn't intended as any form of judgement or admonition , merely an observation that you are starting to sound like an llm

  • > you are starting to sound like an llm

    My observation: I've always had that "sound." I don't know or care much about what that implies. I will admit I'm now deliberately avoiding em dashs, whereas I was once an enthusiastic user of them.

    • I still use em-dashes. I started using them when my professor lambasted my use of semi-colons. I'm not looking back -- LLM haters be damned!

I'd go as far as to say I think harder now – or at least quicker. I'm not wasting cycles on chores; I can focus on the bigger picture.

  • I've never felt more mental exhaustion than after a LLM coding session. I assume that is a result of it requiring me to think harder too.

    • It wasn't until I read your comment that I was able to pinpoint why the mental exhaustion feels familiar. It's the same kind (though not degree) of exhaustion as formal methods / proofs.

      Except without the reward of an intellectual high afterwards.

      1 reply →

    • I feel this too. I suspect its a byproduct of all the context switching I find myself doing when I'm using an LLM to help write software. Within a 10 minute window, I'll read code, debug a problem, prompt, discuss the design, test something, do some design work myself and so on.

      When I'm just programming, I spend a lot more time working through a single idea, or a single function. Its much less tiring.

    • In my experience it's because you switch from writing code to reviewing code someone else wrote. Which is massively more difficult than writing code yourself.

      1 reply →

Yes, if anything I think harder because I know it's on the frontier of whatever I'm building (so i'm more motivated and there's much more ROI)