Isn't that a good thing? If you're stuck on the same problem forever, then you're not going to get past it and never move on to the next thing... /shrug

1. Take a pen and paper.

2. Write down what we know.

3. Write down where we want to go.

4. Write down our methods of moving forward.

5. Make changes to 2, using 4, and see if we are getting closer to 3. And course correct based on that.

I still do it a lot. LLM's act as assist. Not as a wholesale replacement.

Chosen difficulty is a huge part of being human (music, art, athletics, games, etc.). AI hasn't taken that away.

Never have I ever used an LLM.

Just let it try and solve an issue with your advanced SQLAlchemy query and see it burn. xD

I dont write just code, i do as well network engineering, network architecture. There is stuff that, at least until now, i cannot vibe.

I have a pet project where I dont use AI. It moves slowly but, to code, is my hobby.

Hard Things in Computer Science, and AI Aren't Fixing Them

https://blog.est.im/2026/stderr-04

This essay captures that.

Even the pure artist, for whom utility may not seem to matter, manufactures meaning not just from creative exploration directly, but also from the difficulty (which can take many forms) involved in doing something genuinely new, and what they learn from that.

What happens to that when we even have “new” on tap.

Personally, I am going deeper in Quantum Computing, hoping that this field will require thinkers for a long time.

I'm not immune to that and I catch myself sometimes being more reluctant to adapt. I'm well aware and I actively try to force myself to adapt. Because the alternative is becoming stuck in my ways and increasingly less relevant. There are a lot of much younger people around me that still have most of their careers ahead of them. They can try to whine about AI all they want for the next four decades or so but I don't think it will help them. Or they can try to deal with the fact that these tools are here now and that they need to learn to adapt to them whether they like it or not. And we are probably going to see quite some progress on the tool front. It's only been 3 years since ChatGPT had its public launch.

To address the core issue here. You can use AI or let AI use you. The difference here is about who is in control and who is setting the goals. The traditional software development team is essentially managers prompting programmers to do stuff. And now we have programmers prompting AIs to do that stuff. If you are just a middle man relaying prompts from managers to the AI, you are not adding a lot of value. That's frustrating. It should be because it means apparently you are very replaceable.

But you can turn that around. What makes that manager the best person to be prompting you? What's stopping them from skipping that entirely? Because that's your added value. Whatever you are good at and they are not is what you should be doing most of your time. The AI tools are just a means to an end to free up more time for whatever that is. Adapting means figuring that out for yourself and figuring out things that you enjoy doing that are still valuable to do.

There's plenty of work to be done. And AI tools won't lift a finger to do it until somebody starts telling them what needs doing. I see a lot of work around me that isn't getting done. A lot of people are blind to those opportunities. Hint: most of that stuff still looks like hard work. If some jerk can one shot prompt it, it isn't all that valuable and not worth your time.

Hard work usually involves thinking hard, skilling up, and figuring things out. The type of stuff the author is complaining he misses doing.

Thinking hard has never been easier.

I think AI for an autodidact is a boon. Now I suddenly have a teacher who is always accessible and will teach me whatever I want for as long as I want exactly the way I want and I don;t have to worry about my social anxiety kicking in.

Learn advanced cryptography? AI, figure out formal verification - AI etc.

"But I will be left behind!" No you won't. A top 20 percentile dev is not being left behind by the 80% with AI. You'll drop to average, worst case. Unironically just get good.

It might be difficult to figure out what that is, and some folks will fail at it. It might not be code though.

But there's still a lot of programming out there which requires originality.

Speaking personally, I never was nor ever will be too interested in the former variety.

With AI the pros outweigh the cons at least at the moment with what we collectively have figured out so far. But with that everyday I wonder if it's possible now to be more ambitious than ever and take on much bigger problem with the pretend smart assistant.

Maybe I subconsciously picked these up because my Thinker side was starved for attention. Nice post.

I don’t think you can get the same satisfaction out of these tools if what you want to do is not novel.

If you are exploring the space of possibilities for which there are no clear solutions, then you have to think hard. Take on wildly more ambitious projects. Try to do something you don’t think you can do. And work with them to get there.

I was a software and systems developer on cool shit, but I realized I enjoyed solving hard problems more than how I solved them. That led me to a role that is about solving hard problems. Sometimes I still use coding to do it, but that's just one tool of many.

Seen a lot of DIY vibe coded solutions on this site and they are just waiting for a security disaster. Moltbook being a notable example.

That was just the beginning.

I used to think about my projects when in bed, now i listen to podcasts or watch youtube videos before sleeping.

I think it has a much bigger impact than using our "programming calculator" as an assistant.

AI isn’t the only thing that changes how you attend to life.

Why solve a problem when you can import library / scale up / use managed kuberneted / etc.

The menu is great and the number of problems needing deep thought seems rare.

There might be deep thought problems on the requirements side of things but less often on the technical side.

If anything, we have more intractable problems needing deep creative solutions than ever before. People are dying as I write this. We’ve got mass displacement, poverty, polarization in politics. The education and healthcare systems are broken. Climate change marches on. Not to mention the social consequences of new technologies like AI (including the ones discussed in this post) that frankly no one knows what to do about.

The solution is indeed to work on bigger problems. If you can’t find any, look harder.

Most comments in the thread are missing that critical point. Yes you are achieving the end goal, perhaps faster. And yes, built projects (perhaps worse quality) are still better than not built projects.

But take the home cooking vs ordering at restaurant example:

At a restaurant you can prompt for exactly what you want to eat and it will be made for you without you actually having to do it. When the food comes out you can taste it and notice it is missing some flavor. Problem is, you don't know what is missing. If you are knowledgeable about the dish, you can prompt for additional spices or flavours.

When I cook, I try all the ingredients before I add them and then taste the result so I know how an addition changes the final result.

I am now a much better cook because of this because I can make substitutions on the fly. Dish missing sweetness? Carrots, baby red peppers, beets etc can all substitute - never even reach for sugar. Already added a lot of salt but still feels like more needed? Add sour flavours like lemon juice.

Sure, reliance on AI will end up with more things built but you'll have a generation of "cooks" that don't know why you add a bay leaf or two to soup, except that it's always in recipes.

These are also tasks the AI can succeed at rather trivially.

Better completions is not as sexy, but in pretending agents are great engineers it's an amazing feature often glossed over.

Another example is automatic test generation or early correctness warnings. If the AI can suggest a basic test and I can add it with the push of a button - great. The length (and thus complexity) of tests can be configured conservatively relative to the AI of the day. Warnings can just be flags in the editors spotting obvious mistakes. Off-by-one errors for example, which might go unnoticed for a while, would be an achievable and valuable notice.

Also, automatic debugging and feeding the raw debugger log into an AI to parse seems promising, but I've done little of it.

...And go from there - if a well-crafted codebase and an advanced model using it as context can generate short functions well, then by all means - scale that up with discretion.

These problems around the AI coding tools are not at all special - it's a classic case of taking the new tool too far too fast.

In psychological terms, he's saying he has a need to solve hard problems in order to validate his identity and make himself feel good. At some point in his past he experienced some psychological trauma, and this hard-problem-defeating became his coping mechanism.

"That satisfaction is why software engineering was initially so gratifying."

He became a software engineer to gratify his need to solve hard problems, to validate his identity, and make himself feel good. If he stops needing to engineer difficult software, there goes his identity, his self-worth, his good feeling.

"But recently, the number of times I truly ponder a problem for more than a couple of hours has decreased tremendously. Yes, I blame AI for this."

When he runs up against something that takes away this thing that validates him, he feels de-valued. Rather than recognize that AI is making his life easier, freeing him up from mental labor, he's experiencing it as a loss, almost an attack.

"If I can get a solution that is “close enough” in a fraction of the time and effort, it is irrational not to take the AI route. And that is the real problem: I cannot simply turn off my pragmatism."

Now this link of hard work with his identity is becoming a problem. He's going to feel bad because he doesn't know how to deal with his life being easier now. This is a reason to address it head on with therapy, and a re-evaluation of what gives him value as a person, so that having an easier life doesn't feel bad.

A couple of thoughts.

First, I think the hardness of the problems most of us solve is overrated. There is a lot of friction, tuning things, configuring things right, reading logs, etc. But are the problems most of us are solving really that hard? I don't think so, except for those few doing groundbreaking work or sending rockets to space.

Second, even thinking about easier problems is good training for the mind. There's that analogy that the brain is a "muscle", and I think it's accurate. If we always take the easy way out for the easier problems, we don't exercise our brains, and then when harder problems come up what will we do?

(And please, no replies of the kind "when portable calculators were invented...").

My mindset this year: I am an engineering manager to a team of developers

If the pace of AI improvement continues, my mindset next year will need to be: I am CEO and CTO.

I never enjoyed the IC -> EM transition in the workplace because of all the tedious political issues, people management issues and repetitive admin. I actually went back to being an IC because of this.

However, with a team of AI agents, there's less BS, and less holding me back. So I'm seeing the positives - I can achieve vastly more, and I can set the engineering standards, improve quality (by training and tuning the AI) and get plenty of satisfaction from "The Builder" role, as defined in the article.

Likewise I'm sure I would hate the CEO/CTO role in real life. However, I am adapting my mindset to the 2030s reality, and imagining being a CEO/CTO to an infinitely scalable team of Agentic EMs who can deliver the work of hundreds of real people, in any direction I choose.

How much space is there in the marketplace if all HN readers become CEOs and try to launch their own products and services? Who knows... but I do know that this is the option available to me, and it's probably wise to get ahead of it.

I recently used the analogy of when compilers were invented. Old-school coders wrote machine code, and handled the intricacies of memory and storage and everything themselves. Then compilers took over, we all moved up an abstraction layer and started using high-level languages to code in. There was a generation of programmers who hated compilers because they wrote bad, inelegant, inefficient, programs. And for years they were right.

The hard problems now are "how can I get a set of non-deterministic, fault-prone, LLM agents to build this feature or product with as few errors as possible, with as little oversight as possible?". There's a few generic solutions, a few good approaches coming out, but plenty of scope for some hard thought in there. And a generic approach may not work for your specific project.

It's as if I woke up in a world where half of resturaunts worldwide started changing their name to McDonalds and gaslighting all their customers into thinking McDonalds is better than their "from scratch" menu.

Just dont use these agentic tools, they legitimately are weapons who's target is your brain. You can ship just as fast with autocomplete and decent workflows, and you know it.

Its weird, I dont understand why any self respecting dev would support these companies. They are openly hostile about their plans for the software industry (and many other verticles).

I see it as a weapon being used by a sect of the ruling class to diminsh the value of labor. While im not confident they'll be successful, I'm very disappointed in my peers that are cheering them on in that mission. My peers are obviously being tricked by promises of being able join that class, but that's not what's going to happen.

You're going to lose that thinking muscle and therefor the value of your labor is going to be directly correlated to the quantity and quality of tokens you can afford (or be given, loaned!?)

Be wary!!!

... OK I guess. I mean sorry but if that's revelation to you, that by using a skill less you hone it less, you were clearly NOT thinking hard BEFORE you started using AI. It sure didn't help but the problem didn't start then.

I think this is the issue, who associates really hard problems with Software Engineering? You should've stuck with Physics, or pivoted to Math (albeit you don't get so much of the physical building with pure math). You did Software Engineering because you like money, with a little bit of thinking. ;)

Manually coding engaged my brain much more and somehow was less exhausting, kinda feels like getting out of bed and doing something vs lazing around and ending up feel more tired despite having to do less.

deciding whether to use that to work on multiple features on the same code base, or the same feature in multiple variations is hard

deciding whether to work on a separate project entirely while all of this is happening is hard and mentally taxing

planning all of this up for a few hours and watching it go all at once autonomously is satisfying!

And also, I haven't started using AI for writing code yet. I'm shuffling toward that, with much trepidation. I ask it lots of coding questions. I make it teach me stuff. Which brings me to the point of my post:

The other day, I was looking at some Rust code and trying to work out the ownership rules. In theory, I more or less understand them. In practice, not so much. So I had Claude start quizzing me. Claude was a pretty brutal teacher -- he'd ask 4 or 5 questions, most of them solvable from what I knew already, and then 1 or 2 that introduced a new concept that I hadn't seen. I would get that one wrong and ask for another quiz. Same thing: 4 or 5 questions, using what I knew plus the thing just introduced, plus 1 or 2 with a new wrinkle.

I don't think I got 100% on any of the quizzes. Maybe the last one; I should dig up that chat and see. But I learned a ton, and had to think really hard.

Somehow, I doubt this technique will be popular. But my experience with it was very good. I recommend it. (It does make me a little nervous that whenever I work with Claude on things that I'm more familiar with, he's always a little off base on some part of it. Since this was stuff I didn't know, he could have been feeding me slop. But I don't think so; the explanations made sense and the the compiler agreed, so it'd be tough to get anything completely wrong. And I was thinking through all of it; usually the bullshit slips in stealthily in the parts that don't seem to matter, but I had to work through everything.)

Just don't use it. That's always an option. Perhaps your builder doesn't actually benefit from an unlimited runway detached from the cost of effort.

I use AI for the easy stuff.

What I miss is having other people who likes to think and not always pushing for shallow results

On top of that, the business settings/environments will always lean towards the option that provides the largest productivity gains, without awareness of the long term consequences for the worker. At that environment, not using it is not an option, unless you want to be unemployed.

Where does that leave us? Are we supposed to find the figurative "gym for problem solving" the same way office workers workout after work? Because that's the only solution I can think of: Trading off my output for problem solving outside of work settings, so that I can improve my output with the tool at work.

I can imagine many positions work out this way in startups

it's important to think hard sometimes, even if it means taking time off to do the thinking - you can do it without the socioeconomic pressure of a work environment

So, we have an inflation of worthless stuff being done.

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)

Please read up on his life. Mainlander is the most extreme/radical Philosophical Pessimist of them all. He wrote a whole book about how you should rationally kill yourself and then he killed himself shortly after.

https://en.wikipedia.org/wiki/Philipp_Mainl%C3%A4nder

https://dokumen.pub/the-philosophy-of-redemption-die-philoso...

Max Stirner and Mainlander would have been friends and are kindred spirits philosophically.

https://en.wikipedia.org/wiki/Bibliography_of_philosophical_...

I found that doing more physical projects helped me. Large woodworking, home improvement, projects. Built-in bookshelves, a huge butcher block bar top (with 24+ hours of mindlessly sanding), rolling workbenches, and lots of cabinets. Learning and trying to master a new skill, using new design software, filling the garage with tools...

I now spend most of my time at the park, in the subway or just in my bed, thinking about my app, my code, my roadmap, etc.

Since I have outsourced the actual writing and debugging of code to Copilot, I can focus my brain energy on actual thinking. And when I finish thinking, I take out my phone, write a GH issue, assign it to Copilot, and resume my thought process. ~20 minutes later, I check my phone again and read the PR.

In some cases, I just close it because it's not what I had in mind. In most cases, it's very good and starts me thinking again. After some time, I write my review. Rinse and repeat.

And once in a while, I'll sit at my desk to actually test the code, tweak some stuff and deploy.

I have never been this happy as a developer.

One of the benefits of LLM usage is to figure out the boundaries of your own knowledge and that of humanity's existing knowledge--at least for the LLM's training data.

Enumerating through existing options and existing solutions to problems gets you to the knowledge boundary sooner--where the real work begins! While faster with LLMs, I don't see this process as much different than bouncing ideas off of colleagues (and critiquing your own thoughts).

However, the difference is likely human's unpredictable ability to apply creativity throughout the process...such that a new solution may arise at any point and leap-frog existing solutions/explanations. (Think Einstein taking known data from Lorentz, Michelson, Morley plus Maxwell's equations on light and coming up with special relativity.)

More importantly, thinking and building are two very different modes of operating and it can be hard to switch at moment's notice. I've definitely noticed myself getting stuck in "non-thinking building/fixing mode" at times, only realizing that I've been making steady progress into the wrong direction an hour or two in.

This happens way less with LLMs, as they provide natural time to think while they churn away at doing.

Even when thinking, they can help: They're infinitely patient rubber ducks, and they often press all the right buttons of "somebody being wrong on the Internet" too, which can help engineers that thrive in these kinds of verbal pro/contra discussions.

I like being useful, and I'm not yet sure how much of what I'm creating with AI is _me_, and how much it is _it_. It's hard to derive as much purpose/meaning from it compared to the previous reality where it was _all me_.

If I compare it to a real world problem; e.g. when I unplug the charging cable from my laptop at my home desk, the charging cable slides off the table. I could order a solution online that fixes the problem and be done with it, but I could also think how _I_ can solve the problem with what I already have in my spare parts box. Trying out different solutions makes me think and I'm way more happy with the end result. Every time I unplug the cable now and it stays in place it reminds me of _my_ labour and creativity (and also the cable not sliding down the table -- but that's besides the point).

"[I]f a scientist proposes an important question and provides an answer to it that is later deemed wrong, the scientist will still be credited with posing the question. This is because the framing of a fundamentally new question lies, by definition, beyond what we can expect within our frame of knowledge: while answering a question relies upon logic, coming up with a new question often rests on an illogical leap into the unknown."

I've found that the best way to actually think hard about something is to write about it, or to test yourself on it. Not re-read it. Not highlight it. Generate questions from the material and try to answer them from memory.

The research on active recall vs passive review is pretty clear: retrieval practice produces dramatically better long-term retention than re-reading. Karpicke & Blunt (2011) showed that practice testing outperformed even elaborative concept mapping.

So the question isn't whether AI summarizers are good or bad -- it's whether you use them as a crutch to avoid thinking, or as a tool to compress the boring parts so you can spend more time on the genuinely hard thinking.

If you think too much you get into dead ends and you start having circular thoughts, like when you are lost in the desert and you realise you are in the same place again after two hours as you have made a great circle(because one of your legs is dominant over the other).

The thinker needs feedback on the real world. It needs constant testing of hypothesis on reality or else you are dealing with ideology, not critical thinking. It needs other people and confrontation of ideas so the ideas stay fresh and strong and do not stagnate in isolation and personal biases.

That was the most frustrating thing before AI, a thinker could think very fast, but was limited in testing by the ability to build. Usually she had to delegate it to people that were better builders, or else she had to be builder herself, doing what she hates all the time.

At one point, I was using Copilot very heavily. One day I lost my internet connection and tried to write code manually, but I did not even know what to write. All I had been doing was reading the code and pressing the Tab key.

When I tried to write code myself, my fingers automatically moved to the Tab key with perfect millisecond timing. That was the day I disabled AI auto-completion and decided to use only Ask mode in Copilot.

Now I only use code generation when I 100% (atleast 90%) understand what is happening in the code, or when I am working on something that will not help my future growth, like routine code at my job.

If your answer to that is "but I'll fall behind! It's not pragmatic to take the slower route!", think about the damage you're inflicting on yourself. You're allowing your neurons to wither while you trick your brain into releasing pleasure chemicals with a simulation of the real activity. Who is really falling behind, here?

This I can’t relate to. For me it’s “the better I build, the better”. Building poor code fast isn’t good: it’s just creating debt to deal with in the future, or admitting I’ll toss out the quickly built thing since it won’t have longevity. When quality comes into play (not just “passed the tests”, but is something maintainable, extensible, etc), it’s hard to not employ the Thinker side along with the Builder. They aren’t necessarily mutually exclusive.

Then again, I work on things that are expected to last quite a while and aren’t disposable MVPs or side projects. I suppose if you don’t have that longevity mindset it’s easy to slip into Build-not-Think mode.

As I'm providing context I get to think about what an ideal approach would look like and often dive into a research session to analyze pros and cons of various solutions.

I don't use agents much because it's important to see how a component I just designed fits into the larger codebase. That experience provides insights on what improvements I need to make and what to build next.

The time I've spent thinking about the composability, cohesiveness, and ergonomics of the code itself have really paid off. The codebase is a joy to work in, easy to maintain and extend.

The LLMs have helped me focus my cognitive bandwidth on the quality and architecture instead of the tedious and time consuming parts.

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!

What he told me is that he loves thinking about the design of the code in his head, picking the best piece for each part of "the machine" and assembling it design in his head.

After doing that he loathed the act of translating that pure design into code. He told me it felt like pushing all that design through a thin tube through sheer force against syntax, wrong library versions, compiler errors, complex IDEs...

So for him, this is the best scenario possible.

I'm more a of a builder but after talking with him and reading the OP post maybe thinkers come in various shapes.

It's like saying I miss running. Get out and run then.

7 months later waffling on it on and off with and without ai I finally cracked it.

Author is not wrong though, the number of times i hit this isnt as often since ai. I do miss the feeling though

I've resigned to mostly using it for "tip-of-my-tongue" style queries, i.e. "where do I look in the docs". Especially for Apple platforms where almost nothing is documented except for random WWDC video tutorials that lack associated text articles.

I don't trust LLMs at all. Everything they make, I end up rewriting from scratch anyway, because it's always garbage. Even when they give me ideas, they can't apply them properly. They have no standards, no principle. It's all just slop.

I hate this. I hate it because LLMs give so many others the impression of greatness, of speed, and of huge productivity gains. I must look like some grumpy hermit, stuck in their ways. But I just can't get over how LLMs all give me the major ick. Everything that comes out of them feels awful.

My standards must be unreasonably high. Extremely, unsustainably high. That must also be the reason I hardly finish any projects I've ever started, and why I can never seem to hit any deadlines at work. LLMs just can't reach my exacting, uncompromising standards. I'm surely expecting far too much of them. Far too much.

I guess I'll just keep doing it all myself. Anything else really just doesn't sit right.

This mindset is a healthy and good one. It is built on training yourself, learning, and practicing a discipline of problem solving without giving up.

Persistence is something we build, not something we have. It must be maintained. Persistence is how most good in the world has been created.

Genius is worthless without the will to see things through.

I think perhaps moving the goal posts to demand better quality and performance might force people who rely on AI to "think hard". Like your app works fine, now make it load in under a second on any platform.

I think hard about this with a notebook and a pencil and a coffee. And I spend weeks and sometimes months thinking about this. I go deep. And then the actual coding is just the grunt work. I don’t hate it but I don’t love it. I couldn’t care less what language is written in as long as it accomplishes my goal. So AI works great for me in this step.

I think you can still use AI and think deeply. It just depends on your mindset and how you use it.

This is why I am so deeply opposed to using AI for problem solving I suppose: it just doesn’t play nice with this process.

Mainländer’s statement—“God has died and his death was the life of the world”—is not a metaphor for cultural decline, cognitive atrophy, or the loss of intellectual depth. It is a literal metaphysical claim. In Mainländer’s philosophy, the Absolute unity of being actively annihilates itself, and the existence of the world is the irreversible consequence of that ontological self-destruction. The death he speaks of is not contingent, regrettable, or historically situated; it is necessary, total, and final. There is no nostalgia in Mainländer, no sense of loss that might have been avoided, and no implied call to recover what was lost. On the contrary, preservation, striving, depth, and effort are all expressions of the same will-to-be that Mainländer ultimately rejects.

By contrast, the argument being made in the essay is explicitly contingent and experiential. It concerns a personal and cultural shift in how intellectual work is done: the replacement of prolonged cognitive struggle with tools that optimize for speed, efficiency, and “good enough” solutions. The author is not claiming that deep thinking had to die for progress to occur, nor that its disappearance is metaphysically necessary. Quite the opposite: the tone is one of regret, ambivalence, and unresolved tension. Something valuable has been eroded, perhaps unnecessarily, and the loss feels meaningful precisely because it might have been otherwise.

This is where the quote fails. Mainländer’s framework leaves no room for lament. If “God” dies in his system, that death is the very condition of possibility for everything that follows. To mourn it would be incoherent. Using this quote to frame a loss that is psychological, cultural, and potentially reversible imports an apocalyptic metaphysics that undermines the author’s own point. It elevates a specific, historically situated concern into a cosmic necessity—and in doing so, distorts both.

What the essay is really circling is not the death of an absolute, but the displacement of a mode of attention: slow, effortful, internally transformative thinking giving way to instrumental cognition. That intuition has a long and well-matched philosophical lineage, but it is not Mainländer’s.

Two examples of quotes that align far more precisely with what the author seems to want to express:

1. “The most thought-provoking thing in our thought-provoking time is that we are still not thinking.” —Martin Heidegger This captures exactly the concern at stake: not the impossibility of thought, but its quiet displacement by modes of engagement that no longer demand it.

2. “Attention is the rarest and purest form of generosity.” —Simone Weil Here, the loss is not metaphysical annihilation but ethical and cognitive erosion—the fading of a demanding inner posture that once shaped understanding itself.

Either of these frames the problem honestly: as a tension between convenience and depth, productivity and transformation, speed and understanding. Mainländer’s quote, powerful as it is, belongs to a radically different conversation—one in which the value of effort, preservation, and even thinking itself has already been metaphysically written off.

The quote sounds right because it is dramatic, but it means something far more extreme than what the author is actually claiming. The result is rhetorical force at the expense of conceptual fidelity.

What?

i was working for months on an entity resolution system at work. i inherited the basic algo of it: Locality Sensitive Hashing. Basically breaking up a word into little chunks and comparing the chunk fingerprints to see which strings matched(ish). But it was slow, blew up memory constraints, and full of false negatives (didn't find matches).

of course i had claude seek through this looking to help me and it would find things. and would have solutions super fast to things that I couldn't immediately comprehend how it got there in its diff.

but here's a few things that helped me get on top of lazy mode. Basically, use Claude in slow mode. Not lazy mode:

1. everyone wants one shot solutions. but instead do the opposite. just focus on fixing one small step at a time. so you have time to grok what the frig just happened. 2. instead of asking claude for code immediately, ask for more architectural thoughts. not claude "plans". but choices. "claude, this sql model is slow. and grows out of our memory box. what options are on the table to fix this." and now go back and forth getting the pros and cons of the fixes. don't just ask "make this faster". Of course this is the slower way to work with Claude. But it will get you to a solution you more deeply understand and avoid the hallucinations where it decides "oh just add where 1!=1 to your sql and it will be super fast". 3. sign yourself up to explain what you just built. not just get through a code review. but now you are going to have a lunch and learn to teach others how these algorithms or code you just wrote work. you better believe you are going to force yourself to internalize the stuff claude came up with easily. i gave multiple presentations all over our company and to our acquirers how this complicated thing worked. I HAD TO UNDERSTAND. There's no way I could show up and be like "i have no idea why we wrote that algorithm that way". 4. get claude to teach it to you over and over and over again. if you spot a thing you don't really know yet, like what the hell is is this algorithm doing. make it show you in agonizingly slow detail how the concept works. didn't sink in, do it again. and again. ask it for the 5 year old explanation. yes, we have a super smart, over confident and naive engineer here, but we also have a teacher we can berate with questions who never tires of trying to teach us something, not matter how stupid we can be or sound.

Were there some lazy moments where I felt like I wasn't thinking. Yes. But using Claude in slow mode I've learned the space of entity resolution faster and more thoroughly than I could have without it and feel like I actually, personally invented here within it.

I realized that when a friend of mine gave me Factorio as a gift last Christmas, and I found myself facing the exact same resistance I'm facing while thinking about working on my personal projects. To be more specific, it's a fear and urge of closing the game and leaving it "for later" the moment I discover that I've either done something wrong or that new requirements have been added that will force me to change the way my factories connect with each other (or even their placement). Example: Tutorial 4 has the players introduced to research and labs, and this feeling appears when I realize that green science requires me to introduce all sorts of spaghetti just to create the mats needed for green science!

So I've done what any AI user would do and opted to use chatGPT to push through the parts where things are either overwhelming, uncertain, too open-ended, or everything in between. The result works, because the LLM has been trained to Factorio guides, and goes as far as suggesting layouts to save myself some headache!

Awesome, no? Except all I've done is outsource the decision of how to go about "the thing" to someone else. And while true, I could've done this even before LLM's by simply watching a youtube video guide, the LLM help doesn't stop there: It can alleviate my indecisiveness and frustration with dealing with open-ended problems for personal projects, can recommend me project structure, can generate a bullet pointed lists to pretend that I work for a company where someone else creates the spec and I just follow it step by step like a good junior software engineer would do.

And yet all I did just postponed the inevitable exercise of a very useful mental habit: To navigate uncertainty, pause and reflect, plan, evaluate a trade-off or 2 here and there. And while there are other places and situations where I can exercise that behavior, the fact remains that my specific use of LLM removed that weight off my shoulders. I became objectively someone who builds his project ideas and makes progress in his Factorio playthrough, but the trade-off is I remain the same person who will duck and run the moment resistance happens, and succumb to the urge of either pushing "the thing" for tomorrow or ask chatGPT for help.

I cannot imagine how someone would claim that removing an exercise from my daily gym visit will not result in weaker muscles. There are so many hidden assumptions in such statements, and an excessive focus of results in "the new era where you should start now or be left behind" where nobody's thinking how this affects the person and how they ultimately function in their daily lives across multiple contexts. It's all about output, output, output.

How far are we from the day where people will say "well, you certainly don't need to plan a project, a factory layout, or even decide, just have chatGPT summarize the trade-offs, read the bullet points, and choose". We're off-loading portion of the research AND portion of the execution, thinking we'll surely be activating the neurosynapses in our brains that retains habits, just like someone who lifts 50% lighter weights at the gym will expect to maintain muscle mass or burn fat.

I actually had to think really, really hard to keep up with the idiot savant as it cranked out code.

Correctness was extremely important for this feature. Claude would consistently make subtle mistakes, and I needed to catch them to keep things from going off the rails. I could have done it myself, but it would have taken MUCH longer.

I essentially compressed a week’s worth of work into a few hours, and my brain paid the price.

So yeah. You can use AI to replace your thinking, or you can use it to push yourself to your max potential.

I intentionally do not use AI though.

But I sympathize with the author. I enjoy thinking deeply about problems which is why I studied compsci and later philosophy, and ended up in the engineering field. I’m an EM now so AI is less of an “immediate threat” to my thinking habits than the role change was.

That said, I did recently pick up more philosophy reading again just for the purpose of challenges my brain.

So I’m tempted to say that this is just a part of the economic system in general, and isn’t specifically linked to AI. Unless you’re lucky enough to grab a job that requires deep intellectual work, your day job will probably not challenge your mental abilities as much as a difficult college course does.

Sad but true, but unfortunately I don’t think any companies are paying people to think deeply about metaphysics (my personal favorite “thinking hard subject” from college.)

This sounds like approving bad/poor abstractions too prematurely and keep building on top of that.

What about the satisfaction that comes not with struggling but from the calmness of an elegant functional model that dynamically covers all the flows and all the edge cases you could (deep and slowly [1]) think about?

[1] maybe refining in different days, in the shower, after recovering breath in a hard set in a workout session, after a nap...

I'm not sure how you live and work in the US, but here in Sweden, in my experience, it's more focused on results than sitting at your desk 9-5.

So AI does enable me to take more free time, be outside more when the sun is out, because I finish my tasks faster.

I'm just afraid that managers will start demanding more, demand that we increase our output instead of our work life balance. But in that case I at least have the seniority to protest.

It's hard to rationalise this as billable time, but they pay for outcome even if they act like they pay for 9-5 and so if I'm thinking why I like a particular abstraction, or see analogies to another problem, or begin to construct dialogues with mysel(ves|f) about this, and it happens I'm scrubbing my back (or worse) I kind of "go with the flow" so to speak.

Definitely thinking about the problem can be a lot better than actually having to produce it.

But to be honest, those hours spent structuring thoughts are so important to making things work. Or you might as well get out of the way and let AI do everything, why even pretend to work when all we're going to do is just copy and paste things from AI outputs?

Contemplating the old RTFM, I started a new personal project called WTFM and spends time writing instead of coding. There is no agenda and product goals.

https://wtfm-rs.github.io/

There are so many interesting things in human generated computer code and documentation. Well crafted thoughts are precious.

More to the piece itself, I know some crusty old embedded engineers who feel the same way about compilers as this guy does about AI, it doesn’t invalidate his point but it’s food for thought

There's no need to create another serialization format or a JavaScript framework. You now have more time to direct your focus onto those problems that haven't yet been solved, or at least haven't been solved well.

A question that might be hard to digest: was that "thinker" really a thinker, or a well-disguised re-inventor?

Except for eating and sleeping, all other human activities are fake now.

The current major problem with the software industry isn't quantity, it's quality; and AI just increases the former while decreasing the latter. Instead of e.g. finding ways to reduce boilerplate, people are just using AI to generate more of it.

It's a different type of thinking in my opinion, more "systems" thinking.

The last time I had to be a Thinker was because I was in Builder mode. I’ve been trying to build an IoT product but I’ve been wayyyy over my head because I knew maybe 5% of what I needed to be successful. So I would get stuck many, many times, for days or weeks at a time.

I will say though that AI has made the difference in the last few times I got stuck. But I do get more enjoyment out of Building than Thinking, so I embrace it.

I tried this with physics and philosophy. I think i want to do a mix of hard but meaningful. For academic fields like that its impossible for a regular person to do as a hobby. Might as well just do puzzles or something.

Reverse engineering is imo the best way of getting the experience of pushing your thinking in a controlled way, at least if you have the kind of personality where you are stubborn in wanting to solve the problem.

Go crack an old game or something!

Just don't use AI. The idea that you have ship ship ship 10X ship is an illusion and a fraud. We don't really need more software

I'm more spent than before where I would spend 2 hours wrestling with tailwind classes, or testing API endpoints manually by typing json shapes myself.

I too am an ex-physcist used to spending days thinking about things, but programming is a gold mine as it is adjacent to computer science. You can design a programming language (or improve an existing one), try to build a better database (or improve an existing one), or many other things that are quite hard.

The LLM is a good rubber duck for exploring the boundaries of human knowledge (or at least knowledge common enough to be in its training set). It can't really "research" on its own, and whenever you suggest something novel and plausable it gets sycophantic, but it can help you prototype ideas and implementation strategies quite fast, and it can help you explore how existing software works and tackles similar problems (or help you start working on an existing project).

A few years before this wave of AI hit, I got promoted into a tech lead/architect role. All of my mental growth since then has been learning to navigate office politics and getting the 10k ft view way more often.

I was already telling myself "I miss thinking hard" years before this promotion. When I build stuff now, I do it with a much clearer purpose. I have sincerely tried the new tools, but I'm back to just using google search if anything at all.

All I did was prove to myself the bottleneck was never writing code, but deciding why I'm doing anything at all. If you want to think so hard you stay awake at night, try existential dread. It's an important developmental milestone you'd have been forced to confront anyway even 1000 years ago.

My point is, you might want to reconsider how much you blame AI.

As a beginner I often thought about a problem for days before finding a solution, but this happened less and less as I improved

I got better at exploiting the things I knew, to the point where I could be pretty confident that if I couldn't solve a problem in a few hours it was because I was missing some important piece of theory

I think spending days "sitting with" a problem just points at your own weakness in solving some class of problems.

If you are making no articulable progress whatsoever, there is a pathology in your process.

Even when working on my thesis, where I would often "get stuck" because the problem was far beyond what I could solve in one sitting, I was still making progress in some direction every time.

I do miss hard thinking, I haven't really found a good alternative in the meantime. I notice I get joy out of helping my kids with their, rather basic, math homework, so the part of me that likes to think and solve problems creatively is still there. But it's hard to nourish in today's world I guess, at least when you're also a 'builder' and care about efficiency and effectiveness.

But I feel better for not taking the efficient way. Having to be the one to make a decision at every step of the way, choosing the constraints and where I cut my losses on accuracy, I think has taught me more about the subject than even reading literature would’ve directly stated.

I strongly experience that coding agents are helping me think about stuff I wasn't able to think through before.

I very much have both of these builder and thinker personas inside me, and I just am not getting this experience with "lack of thinking" that I'm seeing so many other people write about. I have it exactly the other way around, even if I'm a similar arch type of person. I'm spending less time building and more time thinking than ever.

While this may be an unfair generalization, and apologies to those who don't feel this way, but I believe STEM types like the OP are used to problem solving that's linear in the sense that the problem only exists in its field as something to be solved, and once they figure it out, they're done. The OP even described his mentality as that of a "Thinker" where he received a problem during his schooling, mulled over it for a long time, and eventually came to the answer. That's it, next problem to crack. Their whole lives revolve around this process and most have never considered anything outside it.

Even now, despite my own healthy skepticism of and distaste for AI, I am forced to respect that AI can do some things very fast. People like the OP, used to chiseling away at a problem for days, weeks, months, etc., now have that throughput time slashed. They're used to the notion of thinking long and hard about a very specific problem and finally having some output; now, code modules that are "good enough" can be cooked up in a few minutes, and if the module works the problem is solved and they need to find the next problem.

I think this is more common than most people want to admit, going back to grumblings of "gluing libraries together" being unsatisfying. The only suggestion I have for the OP is to expand what you think about. There are other comments in this thread supporting it but I think a sea change that AI is starting to bring for software folks is that we get to put more time towards enhancing module design, user experience, resolving tech debt, and so on. People being the ones writing code is still very important.

I think there's more to talk about where I do share the OP's yearning and fears (i.e., people who weren't voracious readers or English/literary majors being oneshot by the devil that is AI summaries, AI-assisted reading, etc.) but that's another story for another time.

For me it's always been the effort that's fun, and I increasingly miss that. Today it feels like I'm playing the same video game I used to enjoy with all the cheats on, or going back to an early level after maxing out my character. In some ways the game play is the same, same enemies, same map, etc, but the action itself misses the depth that comes from the effort of playing without cheats or with a weaker character and completing the stage.

What I miss personally is coming up with something in my head and having to build it with my own fingers with effort. There's something rewarding about that which you don't get from just typing "I want x".

I think this craving for effort is a very human thing to be honest... It's why we bake bread at home instead just buying it from a locally bakery that realistically will be twice as good. The enjoyment comes from the effort. I personally like building furniture and although my furniture sucks compared to what you might be able buy at store, it's so damn rewarding to spend days working on something then having a real physical thing that you can use that you build from hand.

I've never thought of myself as someone who likes the challenge of coding. I just like building things. And I think I like building things because building things is hard. Or at least it was.

Just a few days ago, I let it do something that I thought was straightforward, but it kept inserting bugs, and after a few hours of interaction it said itself it was running in circles. It took me a day to figure out what the problem was: an invariant I had given it was actually too strong, and needed to be weakened for a special case. If I had done all of it myself, I would have been faster, and discovered this quicker.

For a different task in the same project I used it to achieve a working version of something in a few days that would have taken me at least a week or two to achieve on my own. The result is not efficient enough for the long term, but for now it is good enough to proceed with other things. On the other hand, with just one (painful) week more, I would have coded a proper solution myself.

What I am looking forward to is being able to converse with the AI in terms of a hard logic. That will take care of the straightforward but technically intricate stuff that it cannot do yet properly, and it will also allow the AI to surface much quicker where a "jump of insight" is needed.

I am not sure what all of this means for us needing to think hard. Certainly thinking hard will be necessary for quite a while. I guess it comes down to when the AIs will be able to do these "jumps of insight" themselves, and for how long we can jump higher than they can.

Sure, I'm doing less technical thinking these days. But all the hard thinking is happening on feature design.

Good feature design is hard for AI. There's a lot of hidden context: customer conversations, unwritten roadmaps, understanding your users and their behaviour, and even an understanding of your existing feature set and how this new one fits in.

It's a different style of thinking, but it is hard, and a new challenge we gotta embrace imo.

We can play a peaceful game and a intense one.

Now, when we think, we can always find a right level of abstract to think on. Decades ago a programmer thought with machine codes, now we think with high level concepts, maybe towards philosophy.

A good outcome always requires hard thinking. We can and we WILL think hard at a appropriate level.

Software engineers are lazy. The good ones are, anyway.

LLMs are extremely dangerous for us because it can easily become a "be lazy button". Press it whenever you want and get that dopamine hit -- you don't even have to dive into the weeds and get dirty!

There's a fine line between "smart autocomplete" and "be lazy button". Use it to generate a boilerplate class, sure. But save some tokens and fill that class in yourself. Especially if you don't want to (at your own discretion; deadlines are a thing). But get back in those weeds, get dirty, remember the pain.

We need to constantly remind ourselves of what we are doing and why we are doing it. Failing that, we forget the how, and eventually even the why. We become the reverse centaur.

And I don't think LLMs are the next layer of abstraction -- if anything, they're preventing it. But I think LLMs can help build that next layer... it just won't look anything like the weekly "here's the greatest `.claude/.skills/AGENTS.md` setup".

If you have to write a ton of boilerplate code, then abstract away the boilerplate in code (nondeterminism is so 2025). And then reuse that abstraction. Make it robust and thoroughly tested. Put it on github. Let others join in on the fun. Iterate on it. Improve it. Maybe it'll become part of the layers of abstraction for the next generation.

You now have a bicycle which gets you there in a third of the time

You need to find destinations that are 3x as far away than before

Not every programming task needs to be a research project. There are plenty of boring business problems that needs the application of computing to automate. And it’s been a decent way to make a living for a while.

It’s great getting a good problem to chew on.

I try to keep a small percentage of my time occupied by one or two good ones. If I’m always bored it’s a sign I could be doing better. And I like being at my best.

In some ways, it's magical. e.g. I whipped up a web based tool for analyzing performance statistics of a blockchain. Claude was able to do everything from building the gui, optimizing the queries, adding new indices to the database etc. I broke it down into small prompts so that I kept it on track and it didn't veer off course. 90% of this I could have done myself but Claude took hours where it would have taken me days or even weeks.

Then yesterday I wanted to do a quick audit of our infra using Ansible. I first thought: let's try Claude again. I gave it lots of hints on where our inventory is, which ports matter etc but it still was grinding away for several minutes. I eventually Ctrl-C'ed and used a couple one liners that I wrote myself in a few minutes. In other words, I was faster that the machine in this case.

After the above, it makes sense to me that people may have conflicting feelings about productivity. e.g. sometimes it's amazing, sometimes it does the wrong thing.

I don't think AI has affected my thinking much, but that's because I probably don't know how to use it well. Whenever AI writes a lot of code, I end up having to understand if not change most of it; either because I don't trust the AI, I have to change the specification (and either it's a small change or I don't trust the AI to rewrite), the code has a leaky abstraction, the specification was wrong, the code has a bug, the code looks like it has a bug (but the problem ends up somewhere else), I'm looking for a bug, etc. Although more and more often the AI saves time and thinking vs. if I wrote the implementation myself, it doesn't prevent me from having to think about the code at all and treating it like a black box, due to the above.

That description is NOT coding, coding is a subset of that.

Coding comes once you know what you need to build, coding is the process of you expressing that in a programming language and as you do so you apply all your knowledge, experience and crucially your taste, to arrive at an implementation which does what's required (functionally and non-functionally) AND is open to the possibility of change in future.

Someone else here wrote a great comment about this the other day and it was along the lines of if you take that week of work described in the GP's comment, and on the friday afternoon you delete all the code checked in. Coding is the part to recreate the check in, which would take a lot less than a week!

All the other time was spent turning you into the developer who could understand why to write that code in the first place.

These tools do not allow you to skip the process of creation. They allow you to skip aspects of coding - if you choose to, they can also elide your tastes but that's not a requirement of using them, they do respond well to examples of code and other directions to guide them in your tastes. The functional and non-functional parts they're pretty good at without much steering now but i always steer for my tastes because, e.g. opus 4.5 defaults to a more verbose style than i care for.

Most of the OP article also resonated with me as I bounce back and forth between learning (consuming, thinking, pulling, integrating new information) to building (creating, planning, doing) every few weeks or months. I find that when I'm feeling distressed or unhappy, I've lingered in one mode or the other a little too long. Unlike the OP, I haven't found these modes to be disrupted by AI at all, in fact it feels like AI is supporting both in ways that I find exhilarating.

I'm not sure OP is missing anything because of AI per se, it might just be that they are ready to move their focus to broader or different problem domains that are separate from typing code into an IDE?

For me, AI has allowed me to probe into areas that I would have shied away from in the past. I feel like I'm being pulled upward into domains that were previously inaccessible.

I use Claude on a daily basis, but still find myself frequently hand-writing code as Claude just doesn't deliver the same results when creating out of whole cloth.

Claude does tend to make my coarse implementations tighter and more robust.

I admittedly did make the transition from software only to robotics ~6 years ago, so the breadth of my ignorance is still quite thrilling.

I think the biggest beef I have with Engineers is that for decades they more or less reduced the value of other lumps of clay and now want to throw up arms when its theirs.

That has actually been a major problem for me in the past where my core idea is too simple, and I don't give "the muse" enough time to visit because it doesn't take me long enough to build it. Anytime I have given the muse time to visit, they always have.

That said, the framing feels a bit too poetic for engineering. Software isn't only craft, it's also operations, risk, time, budget, compliance, incident response, and maintenance by people who weren't in the room for the "lump of clay" moment. Those constraints don't make the work less human; they just mean "authentic creation" isn't the goal by itself.

For me the takeaway is: pursue excellence, but treat learning as a means to reliability and outcomes. Tools (including LLMs) are fine with guardrails, clear constraints up front and rigorous review/testing after, so we ship systems we can reason about, operate, and evolve (not just artefacts that feel handcrafted).

One must be conversant in abstractions that are themselves ephemeral and half hallucinated. It's a question of what to cling to, what to elevate beyond possible hallucinated rubbish. At some level it's a much faster version of the meastspace process and it can be extermely emotionally uncomfortable and anarchic to many.

Sometimes you want a utilitarian teapot to reliably pour a cup of tea.

The materials and rough process for each can be very similar. One takes a master craftsman and a lot of time to make and costs a lot of money. The other can be made on a production line and the cost is tiny.

Both have are desirable, for different people, for different purposes.

With software, it's similar. A true master knows when to get it done quick and dirty and when to take the time to ponder and think.

Phillip G. Armour The Five Orders of Ignorance https://www.researchgate.net/publication/27293624_The_Five_O...

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 user facing things at all but things that absolutely improve code maintenance, scalability, testing/testability, or reduce side effects.

You can imagine the artisans who made shirts saying the exact same thing as the first textile factories became operational.

Humans have been coders in the sense we mean for a matter of decades at most - a blip in our existence. We’re capable of far more, and this is yet another task we should cast into the machine of automation and let physical laws do the work for us.

We’re capable of manipulating the universe into doing our bidding, including making rocks we’ve converted into silicones think on our behalf. Making shirts and making code: we’re capable of so much more.

It seems to assume that vibe coding or like whatever you call the Gas Town model of programming is the only option, but you don't have to do that. You don't have to specify upfront what you want and then never change or develop that as you go through the process of building it, and you don't have to accept whatever the AI gives you on the other end as final.

You can explore the affordances of the technologies you're using, modify your design and vision for what you're building as you go; if anything, I've found AI coding mix far easier to change and evolve my direction because it can update all the various parts of the code that need to be updated when I want to change direction as well as keeping the tests and specification and documentation in sync, easily and quickly.

You also don't need to take the final product as a given, a "simulacrum delivered from a vending machine": build, and then once you've gotten something working, look at it and decide that it's not really what you want, and then continue to iterate and change and develop it. Again, with AI coding, I've found this easier than ever because it's easier to iterate on things. The process is a bit faster for not having to move the text around and looking up API documentation myself, even though I'm directly dictating the architecture and organization and algorithms and even where code should go most of the time.

And with the method I'm describing, where you're in the code just as much as the AI is, just using it to do the text/API/code munging, you can even let the affordances of not just the technologies, but the source code and programming language itself effect how you do this: if you care about the code quality and clarity and organization of the code that the AI is generating, you'll see when it's trying to brute force its way past technical limitations and instead redirect it to follow the grain. It just becomes easier and more fluid to do that.

If anything, AI coding in general makes it easier to have a conversation with the machine and its affordances and your design vision and so on, then before because it becomes easier to update everything and move everything around as your ideas change.

And nothing about it means that you need to be ignorant of what's going on; ostensibly you're reviewing literally every line of code it creates and deciding what libraries and languages as well as the architecture, organization and algorithms it's using. You are aren't you? So you should know everything you need to know. In fact, I've learned several libraries and a language just from watching it work, enough that I can work with them without looking anything up, even new syntax and constructs that would have been very unfamiliar prior on my manual coding days.

"Most developers don't know the assembly code of what they're creating. When you skip assembly you trade the very thing you could have learned to fully understand the application you were trying to make. The end result is a sad simulacrum of the memory efficiency you could have had."

This level of purity-testing is shallow and boring.

The humane and the machinic need to meet halfway - any computing endeavor involves not only specifying something clearly enough for a computer to execute it, but also communicating to humans how to benefit from the process thus specified. And that's the proper domain not only of software engineering, but the set of related disciplines (such as the various non-coding roles you'd have in a project team - if you have any luck, that is).

But considering the incentive misalignments which easily come to dominate in this space even when multiple supposedly conscious humans are ostensibly keeping their eyes on the ball, no matter how good the language machines get at doing the job of any of those roles, I will still intuitively mistrust them exactly as I mistrust any human or organization with responsibly wielding the kind of pre-LLM power required for coordinating humans well enough to produce industrial-scale LLMs in the first place.

What's said upthread about the wordbox continually trying to revert you to the mean as you're trying to prod it with the cowtool of English into outputting something novel, rings very true to me. It's not an LLM-specific selection pressure, but one that LLMs are very likely to have 10x-1000xed as the culmination of a multigenerational gambit of sorts; one whose outset I'd place with the ever-improving immersive simulations that got the GPU supply chain going.

Hence why a lot of software development is gluing libraries together these days.

yea these kind of problems are the exact ones that claude code is very good at one shotting these days. If you can descibe in detail what needs to be done without context switching or research, then describe it to the LLM and bam

I've also mostly worked at small companies so the high level requirements are never well defined :D

Artisans in Japan might go to incredible lengths to create utilitarian teapots. Artisans who graduated last week from a 4-week pottery workshop will produce a different kind quality, albeit artisan. $5.00 teapots from an East Asian mass production factory will be very different than high quality mass-produced upmarket teapots at a higher price. I have things in my house that fall into each of those categories (not all teapots, but different kinds of wares).

Sometimes commercial manufacturing produces worse tolerances than hand-crafting. Sometimes, commercial manufacturing is the only way to get humanly unachievable tolerances.

You can't simplify it into "always" and "never" absolutes. Artisan is not always nicer than commercial. Commercial is not always cheaper than artisan. _____ is not always _____ than ____.

If we bring it back to AI, I've seen it produce crap, and I've also seen it produce code that honestly impressed me (my opinion is based on 24 years of coding and engineering management experience). I am reluctant to make a call where it falls on that axis that we've sketched out in this message thread.

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.

People felt (wrongly) that traditional representational forms like portraiture were threatened by photography. Happily, instead of killing any existing genres, we got some interesting new ones.

The biggest lesson I am learning recently is that technologists will bend over backwards to gaslight the public to excuse their own myopia.

I'd argue that in most cases it's better to do some research and find out if a tool already exists, and if it isn't exactly how you want it... to get used to it, like one did with all other tools they used.

I so severely doubt this to the point I'd say this statement is false.

As we go toward the past art was expensive and rare. Better quality landscape/portraits were exceptionally rare and really only commissioned by those with money, which again was a smaller portion of the population in the time before cameras. It's likely there are more high quality paintings now per capita than there were ever in the past, and the issue is not production, but exposure to the high quality ones. Maybe this is what you mean by 'miss out'?

In addition the general increase in wealth coupled with the cost of art supplies dropping this opens up a massive room for lower quality art to fill the gap. In the past canvas was typically more expensive so sucky pictures would get painted over.

1826 - The Heliograph - 8+ hours

1839 - The Daguerreotype - 15–30 Mins

1841 - The Calotype - 1–2 Mins

1851 - Wet Plate Collodion - 2–20 Secs

1871 - The Dry Plate - < 1 Second.

So it took 45 years to perfect the process so you could take an instant image. Yet we complain after 4 years of LLMs that they're not good enough.

I know that programming has gone terribly wrong, but it's hard for me to articulate how, because it's all of it - the entire frontend web development ecosystem, mobile development languages and frameworks, steep learning curve languages like Rust that were supposed to make things easier but put the onus on the developer to get the busywork right, everything basically. It's like trying to explain screws to craftsmen only familiar with nails.

In the simplest terms, it's because corporations are driving the development of those tools and vacuuming up all profits on the backs of open sources maintainers working in their parents' basements, rather than universities working from first principles to solve hard problems and give solutions away to everyone for free for the good of society. We've moved from academia to slavery and call it progress.

I don't really understand what that means:

1. If the cost of not thinking upfront is high, that means you need to think upfront.

2. If the cost of being wrong upfront is low, that means you don't need to think upfront.

To me, it looks like those assertions contradict each other.

So whether you’re writing the spec code out by hand or ask an LLM to do it is besides the point if the code is considered a means to an end, which is what the post above yours was getting at.

Which spec? Is there a spec that says if you use a particular set of libraries you’d get less than 10 millisecond response? You can’t even know that for sure if you roll your own code, with no 3rd party libraries.

Bugs are by definition issues arise when developers expect they code to do one thing, but it does another thing, because of unforeseen combination of factors. Yet we all are ok with that. That’s why we accept AI code. They work well enough.

The other day people were talking about metrics, the amount of lines of code people vs LLMs could output in any given time, or the lines of code in an LLM assisted application - using LOC as a metric for productivity.

But would an LLM ever suggest using a utility or library, or re-architecture an application, over writing their own code?

I've got a fairly simple application, renders a table (and in future some charts) with metrics. At the moment all that is done "by hand", last features were stuff like filtering and sorting the data. But that kind of thing can also be done by a "data table" library. Or the whole application can be thrown out in favor of a workbook (one of those data analysis tools, I'm not at home in that are at all). That'd save hundreds of lines of code + maintenance burden.

The LLM adding a bunch of extra formatting to add emphasis and structure to what might have originally been a bit of a ramble, but obviously human written. The comments absolutely lambasted this OP for being a hypocrite complaining about their team using AI, but then seeing little problem with posting what is obviously an AI generated question because the OP didn't deem their English skills good enough to ask the question directly.

I'm not going to pass judgement on this scenario, but I did think the entire encounter was a "fun" anecdote in addition to your comments.

Edit: wrods

I still love the work, but to say I’m disillusioned by the industry is an understatement.

Not inherently, no. Reading it and getting a cursory understanding is easy, truly understanding what it does well, what it does poorly, what the unintended side effects might be, that's the difficult part.

In real life I've witnessed quite a few intelligent and experienced people who truly believe that they're thinking "really hard" and putting out work that's just as good as their previous, pre-AI work, and they're just not. In my experience it roughly correlates to how much time they think they're saving, those who think they're saving the most time are in fact cutting corners and putting out the sloppiest quality work.

We have lots of documentation. Arguably too much - it quickly fills much of the claude opus context window with relevant documentation alone, and even then repeatedly outputs things directly counter to the documentation it just ingested.

We’ve created formal notation to shorten writing. And computation is formal notation that is actually useful. Why write pages of specs when I could write a few lines of code?

Obviously I am not comparing his final product with my code, I am simply pointing out how this metaphor is flawed. Having "workers" shape the material according to your plans does not reduce your agency.

> I keep trying to ride a bike but I keep falling off

I do not think this analogy is apt.

The core issue is that AI is taking away, or will take away, or threatens to take away, experiences and activities that humans would WANT to do.

The article is lamenting the disappearing of something meaningful for the OP. One can feel sad for this alone. It is not an equation to balance: X is gone but Y is now available. The lament stands alone. As the OP indicates with his 'pragmatism' we now collectively have little choice about the use of AI. The flood waters do not ask they take everyone in their path.

You are going to tell me that the vibe coders care and read the code they merge with the same attention to detail and care that Linus has? Come on...

That's the key for me. People are churning out "full features" or even apps claiming they are dealing with a new abstraction level, but they don't give a fuck about the quality of that shit. They don't care if it breaks in 3 weeks/months/years or if that code's even needed or not.

Someone will surely come say "I read all the code I generate" and then I'll say either you're not getting these BS productivity boost people claim or you're lying.

I've seen people pushing out 40k lines of code in a single PR and have the audacity to tell me they've reviewed the code. It's preposterous. People skim over it and YOLO merge.

Or if you do review everything, then it's not gonna be much faster than writing it yourself unless it's extremely simple CRUD stuff that's been done a billion times over. If you're only using AI for these tasks maybe you're a bit more efficient, but nothing close to the claims I keep reading.

I wish people cared about what code they wrote/merged like Linus does, because we'd have a hell of a lot less issues.

But even then...don't you think his insight into and ability to verify a PR far exceeds that of most devs (LLM or not)? Most of us cannot (reasonably) aspire to be like him.

There is a difference between cooking and putting a ready meal into the microwave.

Both satisfy your hunger but only one can give some kind of pride.

But if he enjoyed being in the forest, and _doesn't really care about lumber at all_ (Because it turns out, he never used or liked lumber, he merely produced it for his employer) then these screens won't give him any joy at all.

That's how I feel. I don't care about code, but I also don't really care about products. I mostly care about the craft. It's like solving sudokus. I don't collect solved sudokus. Once solved I don't care about them. Having a robot solve sudokus for me would be completely pointless.

> I sense a pattern that many developers care more about doing what they want instead of providing value to others.

And you'd be 100% right. I do this work because my employer provides me with enough sudokus. And I provide value back which is more than I'm compensated with. That is: I'm compensated with two things: intellectual challenge, and money. That's the relationship I have with my employer. If I could produce 10x more but I don't get the intellectual challenge? The employer isn't giving me what I want - and I'd stop doing the work.

I think "You do what the employer wants, produce what needs to be produced, and in return you get money" is a simplification that misses the literal forest for all the forestry.

I use LLMs a lot. They're ridiculously cool and useful.

But I don't think it's fair to categorize anybody as "egotistical". I enjoy programming for the fun puzzley bits. The big puzzles, and even often the small tedious puzzles. I like wiring all the chunks up together. I like thinking about the best way to expose a component's API with the perfect generic types. That's the part I like.

I don't always like "delivering value" because usually that value is "achieve 1.5% higher SMM (silly marketing metric) by the end of the quarter, because the private equity firm that owns our company is selling it next year and they want to get a good return".

But really, most of us who personally feel sad about the work being replaced by LLMs can still act reasonable, use the new tooling at work like a good employee, and lament about it privately in a blog or something.

Maybe you don’t care about the environment (which includes yourself and the people you like), or income inequality, or the continued consolidation of power in the hands of a few deranged rich people, or how your favourite artists (do you have any?) are exploited by the industry, but some of us have been banging the drum about those issues for decades. Just because you’re only noticing it now or don’t care it doesn’t mean it’s a new thing or that everyone else is being duplicitous. It’s a good thing more people are waking up and talking about those.

Except without the reward of an intellectual high afterwards.

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

Yes, but you’re not taking into account what actually caused this evolution. At first glance, it looks like exponential growth, but then we see OpenAI (as one example) with trillions in obligations compared to 12–13 billion in annual revenue. Meanwhile, tool prices keep rising, hardware demand is surging (RAM shortages, GPUs), and yet new and interesting models continue to appear. I’ve been experimenting with Claude over the past few days myself. Still, at some point, something is bound to backfire.

The AI "bubble" is real, you don’t need a masters degree in economics to recognize it. But with mounting economic pressures worldwide and escalating geopolitical tension we may end up stuck with nothing more than those amusing Will Smith eating pasta videos for a while.

It killed an aspect of it. The film processing in the darkroom. Even before digital cameras were ubiquitous it was standard to get a scan before doing any processing digitally. Chemical processing was reduced the minimum necessary.

LLMs don’t “reason” the same way humans do. They follow text predictions based on statistical relevance. So raising the temperature will more likely increase the likelihood of unexecutable pseudocode than it would create a valid but more esoteric implementation of a problem.

Or, risking to beat the metaphor to death, because over a span of time I'll cross many more deserts than I would have on a camel, and because I'll cross deserts that I wouldn't even try crossing on a camel.

They’re destroying the only thing I like about my job - figuring problems out. I have a fundamental impedance mismatch with my company’s desires, because if someone hands me a weird problem, I will happily spend all day or longer on that problem. Think, hypothesize, test, iterate. When I’m done, I write it up in great detail so others can learn. Generally, this is well-received by the engineer who handed the problem to me, but I suspect it’s mostly because I solved their problem, not because they enjoyed reading the accompanying document.

"Write a gangster movie that I like", instead of "...a movie this other guy likes".

But because this is not the case, we appreciate Tarantino more than we appreciate gangster movies. It is about the process.

Doesn’t that prove the point? You could do that right now, and it would be absolute trash. Just like how right now we are nowhere close to being able to make great software with a single prompt.

I’ve been vibecoding a side project and it has been three months of ideating, iterating, refining and testing. It would have taken me immeasurably longer without these tools, but the end result is still 100% my vision, and it has been a tremendous amount of work.

More power to society if my skills become easily replaceable. I can learn new things, contribute to society in different ways. I'm not afraid.

Now, the only reason I code and have been since the week I graduated from college was to support my insatiable addictions to food and shelter.

While I like seeing my ideas come to fruition, over the last decade my ideas were a lot larger than I could reasonably do over 40 hours without having other people working on projects I lead. Until the last year and a half where I could do it myself using LLMs.

Seeing my carefully designed spec that includes all of the cloud architecture get done in a couple of days - with my hands on the wheel - that would have taken at least a week with me doing some work while juggling dealing with a couple of other people - is life changing

If I wanted to work on electric power systems I would have become an electrician.

(The transition is happening.)

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.

Can't speak to firmware code or complex cryptography but my hunch is if it's in it's training dataset and you know enough to guide it, it's generally pretty useful.

Some commentators dismissed this trend towards photography as simply a beneficial weeding out of second-raters. For example, the writer Louis Figuier commented that photography did art a service by putting mediocre artists out of business, for their only goal was exact imitation. Similarly, Baudelaire described photography as the “refuge of failed painters with too little talent”. In his view, art was derived from imagination, judgment and feeling but photography was mere reproduction which cheapened the products of the beautiful [23].

https://www.artinsociety.com/pt-1-initial-impacts.html#:~:te...

You wouldn't have known that, going by all the bellyaching and whining from the artists of the day.

Guess what, they got over it. You will too.

I'm trying my best to adapt to being a "centaur" in this world. (In Chess it has become statistically evident that Human and Bot players of Chess are generally "worse" than the hybrid "Centaur" players.) But even "centaurs" are going to be increasingly taken for granted by companies, and at least for me the sense is growing that as WOPR declared about tic-tac-toe (and thermo-nuclear warfare) "a curious game, the only way to win is not to play". I don't know how I'd bootstrap an entirely new career at this point in my life, but I keep feeling like I need to try to figure that out. I don't want to just be a janitor of other people's messes for the rest of my life.

If you really care about using the hardware effectively, optimizing the code is so much more than what you describe.

I'm not old. But slightly past where most would call "young". I see a decent career for the first 5-6 years and then a disruption that completely cuts down on the things you likely had your entire career. Enough time to get a taste of the good times,not enough time to get stable. Meanwhile you buult networks, accomplishments, a seal of trust, in times with overall lower standards.

I don't even use AI but AI has shaped the way I need to navigate the job market and verify knowledge. If you have plenty of pre-AI colleagues and projects to point to you skip all this. But it's a hellscape for people like me.

And I'm sure its an absolute wasteland for new grads

It's a carved wooden dragon that my dad got from Indonesia (probably about 50 years ago).

It's hard to appreciate, if you aren't holding it, but it weighs a lot, and is intricately carved, all over.

I guarantee that the carver used a Dremel.

I still have a huge amount of respect for their work. That wood is like rock. I would not want to carve it with hand tools.

There's just some heights we can't reach, without a ladder.

If you just chuck ideas at the external coding team/tool you often get rubbish back.

If you're good at managing the requirements and defining things well you can achieve very good things with much less cost.

AI assistance in programming is a service, not a tool. You are commissioning Anthropic, OpenAI, etc. to write the program for you.

On-shoring ;

Thoughtful retorts such as this are deserving of the same esteem one affords the "rubber v glue"[0] idiom.

As such, I must oblige.

0 - https://idioms.thefreedictionary.com/I%27m+rubber%2c+you%27r...

That's how I have been using AI the entire time. I do not use Claude Code or Codex. I just use AI to ask questions instead of parsing the increasingly poor Google search results.

I just use the chat options in the web applications with manual copy/pasting back and forth if/when necessary. It's been wonderful because I feel quite productive, and I do not really have much of an AI dependency. I am still doing all of my work, but I can get a quicker answer to simple questions than parsing through a handful of outdated blogs and StackOverflow answers.

If I have learned one thing about programming computers in my career, it is that not all documentation (even official documentation) was created equally.

When you do this with an outsourced team, it can happen at most once per sprint, and with significant pushback, because there's a desire for them to get paid for their deliverable even if it's not what you wanted or suffers some other fundamental flaw.

The meetings will continue regardless. Those meetings aren't purely there for productivity reasons. It's the incentives for middle managers and directors and whatnot.

Its just that all that throughput of an outside team is pushed onto you and 0-3 more engineers. You will optimize accordingly for your job and get something out to satisfy their demands. Likely sacrificing quality in the process. It's not different domesticating the outsourcing.

And that's fpr now. Maybe in decades' time the engineer is extinct and it's simply cheap scriptors who run it.

Just like people more, and have better meetings.

Life is what you make it.

Enjoy yourself while you can.

I agree the info is out there about how to run effective meetings.

Gladly! I think what I would choose is building on-shore teams exclusively. That's the change I'd like to see more of, while overseas teams build their own economies instead of ripping away jobs from domestic citizens in an already difficult job market.

Already long. Got laid off.

>Be the change you want to see in the world.

Easy to say when you're at a desk and not scrounging up pennies to pay rent.