"Coding is like taking a lump of clay and slowly working it into the thing you want it to become. It is this process, and your intimacy with the medium and the materials you’re shaping, that teaches you about what you’re making – its qualities, tolerances, and limits – even as you make it. You know the least about what you’re making the moment before you actually start making it. That’s when you think you know what you want to make. The process, which is an iterative one, is what leads you towards understanding what you actually want to make, whether you were aware of it or not at the beginning. Design is not merely about solving problems; it’s about discovering what the right problem to solve is and then solving it. Too often we fail not because we didn’t solve a problem well but because we solved the wrong problem.
When you skip the process of creation you trade the thing you could have learned to make for the simulacrum of the thing you thought you wanted to make. Being handed a baked and glazed artefact that approximates what you thought you wanted to make removes the very human element of discovery and learning that’s at the heart of any authentic practice of creation. Where you know everything about the thing you shaped into being from when it was just a lump of clay, you know nothing about the image of the thing you received for your penny from the vending machine."
And when programming with agentic tools, you need to actively push for the idea to not regress to the most obvious/average version. The amount of effort you need to expend on pushing the idea that deviates from the 'norm' (because it's novel), is actually comparable to the effort it takes to type something out by hand. Just two completely different types of effort.
There's an upside to this sort of effort too, though. You actually need to make it crystal clear what your idea is and what it is not, because of the continuous pushback from the agentic programming tool. The moment you stop pushing back, is the moment the LLM rolls over your project and more than likely destroys what was unique about your thing in the first place.
Fair enough but I am a programmer because I like programming. If I wanted to be a product manager I could have made that transition with or without LLMs.
I can't help but imagine training horses vs training cats. One of them is rewarding, a pleasure, beautiful to see, the other is frustrating, leaves you with a lot of scratches and ultimately both of you "agreeing" on a marginal compromise.
This is why people thinkless of artists like Damien Hirst and Jeff Koons because their hands have never once touched the art. They have no connection to the effort. To the process. To the trail and error. To the suffer. They’ve out sourced it, monetized it, and make it as efficient as possible. It’s also soulless.
That's not an upside in that it's unique to LLM vs human written code. When writing it yourself, you also need to make it crystal clear. You do that in the language of implementation.
To me it feels a bit like literate programming, it forces you to form a much more accurate idea of your project before your start. Not a bad thing, but can be wasteful also when eventually you realise after the fact that the idea was actually not that good :)
Uniqueness is not the aim. Who cares if something is uniquely bad? But in any case, yes, if you use LLMs uncritically, as a substitute for reasoning, then you obviously aren't doing any reasoning and your brain will atrophy.
But it is also true that most programming tedious and hardly enriching for the mind. In those cases, LLMs can be a benefit. When you have identified the pattern or principle behind a tedious change, an LLM can work like a junior assistant, allowing you to focus on the essentials. You still need to issue detailed and clear instructions, you still need to verify the work.
Of course, the utility of LLMs is a signal that either the industry is bad at abstracting, or that there's some practical limit.
I think harder while using agents, just not about the same things. Just because we all got a super powers doesn't make the problems go away, they just move and we still have our full brains to solve them.
It isn't all great, skills that feel important have already started atrophying, but other skills have been strengthened. The hardest part is in being able to pace onself as well as figuring out how to start cracking certain problems.
Yet another example of "comments that are only sort of true because high temperature sampling isn't allowed".
If you use LLMs at very high temperature with samplers which correctly keep your writing coherent (i.e. Min_p, or better like top-h, P-less decoding, etc), than "regression to the mean" literally DOES NOT HAPPEN!!!!
To me it's all abstraction. I didn't write my own OS. I didn't write my own compiler. I didn't write the standard library. I just use them. I could write them but I'm happy to work on the new thing that uses what's already there.
This is no different than many things. I could grow a tree and cut it into wood but I don't. I could buy wood and nails and brackets and make furniture but I don't. I instead just fill my house/apartment with stuff already made and still feel like it's mine. I made it. I decided what's in it. I didn't have to make it all from scratch.
For me, lots of programming is the same. I just want to assemble the pieces
> When you skip the process of creation you trade the thing you could have learned to make for the simulacrum of the thing you thought you wanted to make
No, your favorite movie is not crap because the creators didn't grind their own lens. Popular and highly acclaimed games not at crap because they didn't write their own physics engine (Zelda uses Havok) or their own game engine (Plenty of great games use Unreal or Unity)
When I read discussions about this sort of thing, I often find that folks look harder for similarities and patterns but once they succeed here, they ignore the differences. AI in particular is so full of this "pattern matching" style of thinking that the really significance of this tech, ie., how absolutely new and different it is, yeah it just sort of goes ignored, or even worse, machines get "pattern matched" into humans and folks argue from that point of view lol witness all the "new musicians" who vibe code disco hits, I'll invariably see the argument that AIs train on existing music just like humans do so whats the big deal?
But these arguments and the OP's article do reinforce that AI rots brains. Even my sparing use of googles gemini and my interaction with the bots here have really dinged my ability to do simple math.
There are two stages to becoming a decent programmer: first you learn to use abstraction, then you learn when not to use abstraction.
Trying to find the right level is the art. Once you learn the tools of the trade and can do abstraction, it's natural to want to abstract everything. Most programmers go through such a phase. But sometimes things really are distinct and trying to find an abstraction that does both will never be satisfactory.
When building a house there are generally a few distinct trades that do the work: bricklayers, joiners, plumbers, electricians etc. You could try to abstract them all: it's all just joining stuff together isn't it? But something would be lost. The dangers of working with electricity are completely different to working with bricks. On the other hand, if people were too specialised it wouldn't work either. You wouldn't expect a whole gang of electricians, one who can only do lighting, one who can only do sockets, one who can only do wiring etc. After centuries of experience we've found a few trades that work well together.
So, yes, it's all just abstraction, but you can go too far.
OS and compilers have a deterministic public interface. They obey a specification developers know, so you they can be relied on to write correct software that depends on them even without knowing the internal behavior. Generative AI does not have those properties.
The creative process is not dependent on the abstraction.
> For me, lots of programming is the same. I just want to assemble the pieces
How did those pieces came to be? By someone assembling other pieces or by someone crafting them together out of nowhere because nobody else had written them by the time?
Of course you reuse other parts and abstractions to do whatever things that you're not working on but each time you do something that hasn't been done before you can't but engage the creative process, even if you're sitting on top of 50 years worth of abstractions.
In other words, what a programmer essentially has is a playfield. And whether the playfield is a stack of transistors or coding agents, when you program you create something new even if it's defined and built in terms of the playfield.
>I instead just fill my house/apartment with stuff already made and still feel like it's mine.
I'm starting to wonder if we lose something in all this convenience. Perhaps my life is better because I cook my own food, wash my own dishes, chop my own firewood, drive my own car, write my own software. Outwardly the results look better the more I outsource but inwardly I'm not so sure.
On the subject of furnishing your house the IKEA effect seems to confirm this.
I really appreciate this sentiment. It feels absolutely overwhelming the pace at which new tools and AI protocols are being released, leaving a feeling of constantly falling behind. But approaching from the other end, I can just make things that I do come up with and explore the new protocols only if I can't do the thing with what I've already grasped.
> No, your favorite movie is not crap because the creators didn't grind their own lens.
One of the reasons Barry Lyndon is over 50 years old and still looks like no other movie today is because Kubrick tracked down a few lenses originally designed for NASA and had custom mounts built for them to use with cinema cameras.
> Popular and highly acclaimed games not at crap because they didn't write their own physics engine (Zelda uses Havok)
Super Mario Bros is known for having a surprisingly subtle and complex physics system that enabled the game to feel both challenging and fair even for players very new to consoles. Celeste a newer game also famous for being very difficult yet not feeling punishing does something similar:
> or their own game engine (Plenty of great games use Unreal or Unity)
And Minecraft doesn't, which is why few other games at the time of its release felt and played like it.
You're correct that no one builds everything from scratch all the time. However, if all you ever do is cobble a few pre-made things together, I think you'll discover that nothing you make is ever that interesting or enduring in value. Sure, it can be useful, and satisfying. But the kinds of things that really leave a mark on people, that affect them deeply, always have at least some aspect where the creator got obsessive and went off the deep end and did their own thing from scratch.
Further, you'll never learn what a transformative experience it can be to be that creator who gets obsessive about a thing. You'll miss out on discovering the weird parts of your own soul that are more fascinated by some corner of the universe than anyone else is.
I have a lot of regrets in my life, but I don't regret the various times I've decided I've deeply dug into some thing and doing it from scratch. Often, that has turned out later to be some of the most long-term useful things I've done even though it seemed like a selfish indulgence at the time.
Of course, it's your life. But consider that there may be a hidden cost to always skimming along across the tops of the stacks of things that already exist out there. There is growth in the depths.
In 30 years across 10 jobs, the companies I’ve worked for have not paid me to “code”. They’ve paid me to use my experience to add more business value than the total cost of employing me.
I’m no less proud of what I built in the last three weeks using three terminal sessions - one with codex, one with Claude, and one testing everything from carefully designed specs - than I was when I first booted a computer, did “call -151” to get to the assembly language prompt on my Apple //e in 1986.
The goal then was to see my ideas come to life. The goal now is to keep my customers happy, get projects done on time, on budget and meets requirements and continue to have my employer put cash in my account twice a month - and formerly put AMZN stock in my brokerage account at vesting.
Instead of pouring all of your efforts into making one single static object with no moving parts, you can simply specify the individual parts, have the machine make them for you, and pour your heart and soul into making a machine that is composed of thousands of parts, that you could never hope to make if you had to craft each one by hand from clay.
We used to have a way to do this before LLMs, of course: we had companies that employed many people, so that the top level of the company could simply specify what they wanted, and the lower levels only had to focus on making individual parts.
Even the person making an object from clay is (probably) not refining his own clay or making his own oven.
> we had companies that employed many people, so that the top level of the company could simply specify what they wanted, and the lower levels only had to focus on making individual parts.
I think this makes a perfect counter-example. Because this structure is an important reason for YC to exist and what the HN crowd often rallies against.
Such large companies - generally - don't make good products. Large companies rarely make good products in this way. Most, today, just buy companies that built something in the GP's cited vein: a creative process, with pivots, learnings, more pivots, failures or - when successful - most often successful in an entirely different form or area than originally envisioned.
Even the large tech monopolies of today originated like that. Zuckerberg never envisioned VR worlds, photo-sharing apps, or chat apps, when he started the campus-fotobook-website. Bezos did not have some 5d-chess blueprint that included the largest internet-infrastructure-for-hire when he started selling books online.
If anything, this only strengthens the point you are arguing against: a business that operates by a "head" "specifying what they want" and having "something" figure out how to build the parts, is historically a very bad and inefficient way to build things.
It's more like the chess.com vs lichess example in my mind. On the one hand you have a big org, dozens of devs, on the other you have one guy doing a better job.
It's amazing what one competent developer can do, and it's amazing how little a hundred devs end up actually doing when weighed down by beaurocracy. And lets not pretend even half of them qualify as competent, not to mention they probably don't care either. They get to work and have a 45 min coffee break, move some stuff around in the Kanban board, have another coffee break, then lunch, then foosball etc. Ad when they actually write some code it's ass.
And sure, for those guys maybe LLMs represent a huge productivity boost. For me it's usually faster to do the work myself than to coax the bot into creating something acceptable.
And therein lies the crux: some people love to craft each part themselves, whereas others love to orchestrate but not manufacture each part.
With LLMs and engineers often being forced by management to use them, everyone is pushed to become like the second group, even though it goes against their nature. The former group see the part as a means, whereas the latter view it as the end.
Some people love the craft itself and that is either taken away or hollowed out.
As someone that started with Machine Code, I'm grateful for compiled -even interpreted- languages. I can’t imagine doing the kind of work that I do, nowadays, in Machine Code.
I’m finding it quite interesting, using LLM-assisted development. I still need to keep an eye on things (for example, the LLM tends to suggest crazy complex solutions, like writing an entire control from scratch, when a simple subclass, and five lines of code, will work much better), but it’s actually been a great boon.
I find that I learn a lot, using an LLM, and I love to learn.
I personally have found success with an approach that's the inverse of how agents are being used generally.
I don't allow my agent to write any code. I ask it for guidance on algorithms, and to supply the domain knowledge that I might be missing. When using it for game dev for example, I ask it to explain in general terms how to apply noise algorithms for procedural generation, how to do UV mapping etc, but the actual implementation in my language of choice is all by hand.
Honestly, I think this is a sweet spot. The amount of time I save getting explanations of concepts that would otherwise get a bit of digging to get is huge, but I'm still entirely in control of my codebase.
Yep, this is the sweet spot. Though I still let it type code a lot - boilerplate stuff I’d be bored out of my mind typing. And I’ve found it has an extremely high success rate typing that code on top of its very easy for me to review that code. No friction at all. Granted this is often no larger than 100 lines or so (across various files).
If it takes you more than a few seconds or so to understand code an agent generated you’re going to make mistakes. You should know exactly what it’s going to produce before it produces it.
Supposedly when Michelangelo was asked about how he created the statue of David, he said "I just chipped away everything that wasn’t David.”
Your work is influenced by the medium by which you work. I used to be able to tell very quickly if a website was developed in Ruby on Rails, because some approaches to solve a problem are easy and some contain dragons.
If you are coding in clay, the problem is getting turned into a problem solvable in clay.
The challenge if you are directing others (people or agents) to do the work is that you don't know if they are taking into account the properties of the clay. That may be the difference between clean code - and something which barely works and is unmaintainable.
I'd say in both cases of delegation, you are responsible for making sure the work is done correctly. And, in both cases, if you do not have personal experiences in the medium you may not be prepared to judge the work.
This is an amazing quote - thank you. This is also my argument for why I can't use LLMs for writing (proofreading is OK) - what I write is not produced as a side-effect of thinking through a problem, writing is how I think through a problem.
Counterpoint (more devil's advocate), I'd argue it's better than an LLM writes something (e.g. the solution or thinking through of a problem) than nothing at all.
Counterpoint to my own counterpoint, will anyone actually (want to) read it?
counterpoint to the third degree, to loop it back around, an LLM might and I'd even argue an LLM is better at reading and ingesting long text (I'm thinking architectural documentation etc) than humans are. Speaking for myself, I struggle to read attentively through e.g. a document, I quickly lose interest and scan read or just focus on what I need instead.
Writing is how I think through a problem too, but that also applies to writing and communicating with an AI coding agent. I don't need to write the code per se to do the thinking.
Coding is not at all like working a lump of clay unless you’re still writing assembly.
You’re taking a bunch of pre-built abstractions written by other people on top of what the computer is actually doing and plugging them together like LEGOs. The artificial syntax that you use to move the bricks around is the thing you call coding.
The human element of discovery is still there if a robot stacks the bricks based on a different set of syntax (Natural Language), nothing about that precludes authenticity or the human element of creation.
It depends what you're doing not really what you do it with.
I can do some crud apps where it's just data input to data store to output with little shaping needed. Or I can do apps where there's lots of filters, actions and logic to happen based on what's inputted that require some thought to ensure actually solve the problem it's proposed for.
"Shaping the clay" isn't about the clay, it's about the shaping. If you have to make a ball of clay and also have to make a bridge of Lego a 175kg human can stand on, you'll learn more about Lego and building it than you will about clay.
Get someone to give you a Lego instruction sheet and you'll learn far less, because you're not shaping anymore.
> You’re taking a bunch of pre-built abstractions written by other people on top of what the computer is actually doing and plugging them together like LEGOs.
Correct. However, you will probably notice that your solution to the problem doesn't feel right, when the bricks that are available to you, don't compose well. The AI will just happily smash together bricks and at first glance it might seem that the task is done.
Choosing the right abstraction (bricks) is part of finding the right solution. And understanding that choice often requires exploration and contemplation. AI can't give you that.
Exactly, and that's why I find AI coding solving this well, because I find it tedious to put the bricks together for the umpteenth time when I can just have an AI do it (which I will of course verify the code when it's done, not advocating for vibe coding here).
This actually leaves me with a lot more time to think, about what I want the UI to look like, how I'll market my software, and so on.
> Coding is not at all like working a lump of clay unless you’re still writing assembly.
Isn't the analogy apt? You can't make a working car using a lump of clay, just a car statue, a lump of clay is already an abstraction of objects you can make in reality.
I think the analogy to high level programming languages misunderstands the value of abstraction and notation. You can’t reason about the behavior of an English prompt because English is underspecified. The value of code is that it has a fairly strong semantic correlation to machine operations, and reasoning about high level code is equivalent to reasoning about machine code. That’s why even with all this advancement we continue to check in code to our repositories and leave the sloppy English in our chat history.
Lego boxes include a set of instructions that implies there's only one way to assemble the contents, but that's sometimes an injustice to the creative space that Legos are built to provide. There can be a joy in algorithmically building the thing some other designers worked to make look nice, but there's a creative space outside the instructions, too.
The risk of LLMs laying more of these bricks isn't just loss of authenticity and less human elements of discovery and creation, it's further down the path of "there's only one instruction manual in the Lego box, and that's all the robots know and build for you". It's an increased commodification of a few legacy designers' worth of work over a larger creative space than at first seems apparent.
You’re both right. It just depends on the problems you’re solving and the languages you use.
I find languages like JavaScript promote the idea that of “Lego programming” because you’re encouraged to use a module for everything.
But when you start exploring ideas that haven’t been thoroughly explored already, and particularly in systems languages which are less zealous about DRY (don’t repeat yourself) methodologies, the you can feel a lot more like a sculptor.
Likewise if you’re building frameworks rather than reusing them.
So it really depends on the problems you’re solving.
For general day-to-day coding for your average 9-to-5 software engineering job, I can definitely relate to why people might think coding is basically “LEGO engineering”.
changing "clay" for "legos" doesn't change the core argument. The tactile feel you get for the medium as you work it with your hands and the "artificial syntax" imposed by the medium.
Aren't Legos known for their ability to enable creativity and endless possibilities? It doesn't feel that different from the clay analogy, except a bit coarser grained.
For me it’s a related but different worry. If I’m no longer thinking deeply, then maybe my thinking skills will simply atrophy and die. Then when I really need it, I won’t have it. I’ll be reduced to yanking the lever on the AI slot machine, hoping it comes up with something that’s good enough.
But at that point, will I even have the ability to distinguish a good solution from a bad one? How would I know, if I’ve been relying on AI to evaluate if ideas are good or not? I’d just be pushing mediocre solutions off as my own, without even realising that they’re mediocre.
While there is still a market for artisanal furniture, dishes and clothes most people buy mass-produced dishes, clothes and furniture.
I wonder if software creation will be in a similar place. There still might be a small market for handmade software but the majority of it will be mass produced. (That is, by LLM or even software itself will mostly go away and people will get their work done via LLM instead of "apps")
As with furniture, it's supply vs demand, and it's a discussion that goes back decades at this point.
Very few people (even before LLM coding tools) actually did low level "artisanal" coding; I'd argue the vast majority of software development goes into implementing features in b2b / b2c software, building screens, logins, overviews, detail pages, etc. That requires (required?) software engineers too, and skill / experience / etc, but it was more assembling existing parts and connecting them.
Years ago there was already a feeling that a lot of software development boiled down to taping libraries together.
Or from another perspective, replace "LLM" with "outsourcing".
What you get right now is mass replicated software, just another copy of sap/office/Spotify/whatever
That software is not made individually for you, you get a copy like millions of other people and there is nearly no market anymore for individual software.
Llms might change that, we have a bunch of internal apps now for small annoying things..
They all have there quirks, but are only accessible internally and make life a little bit easier for people working for us.
Most of them are one shot llms things, throw away if you do not need it anymore or just one shoot again
> Being handed a baked and glazed artefact that approximates what you thought you wanted to make
Isn't this also an overstatement, and the problem is worse. That is - the code being handed back is a great prototype, needs polishing/finishing, and is ignorant of obvious implicit edge cases unless you explicitly innumerate all of them in your prompts??
For me, the state of things reminds me of a bad job I had years ago.
Worked with a well-regarded long tenured but truculent senior engineer who was immune to feedback due to his seniority. He committed code that either didn't run, didn't past tests, or implemented only the most obvious happy path robotically literal interpretation of requirements.
He was however, very very fast... underbidding teammates on time estimates by 10x.
He would hand back the broken prototype and we'd then spend the 10x time making his code actually something you can run in production.
Management kept pushing this because he had a great reputation, promised great things, and every once in a while did actually deliver stuff fast. It took years for management to come around to the fact that this was not working.
This makes no sense to me. There are plenty of artists out there (e.g. El Anatsui), not to mention whole professions such as architects, who do not interact directly with what they are building, and yet can have profound relationship with the final product.
Discovering the right problem to solve is not necessarily coupled to being "hands on" with the "materials you're shaping".
In my company, [enterprise IT] architects are separated into two kinds.
People with a CV longer than my arm who know/anticipate everything that could fail and have reached a level of understandind that I personnally call "wisdom".
And theorists, who read books and norms, who focus mostly on the nominal case, and have no idea [and no interest] in how the real world will be a hard brick wall that challenges each and every idea you invent.
Not being hands-on, and more important not LISTENING to the hands-on people and learning from them, is a massive issue in my surroundings.
So thinking hard on something is cool. But making it real is a whole different story.
I relate to this. But also, isn't it just that every human endeavor goes through an evolution from craft to commodity, which is sad for the craftsmen but good for everyone else, and that we happen to be the ones living through that for software?
For instance, I think about the pervasive interstate overpass bridge. There was a time long ago when building bridges was a craft. But now I see like ten of these bridges every day, each of which is better - in the sense of how much load they can support and durability and reliability - than the best that those craftsmen of yore could make.
This doesn't mean I'm in any way immune to nostalgia. But I try to keep perspective, that things can be both sad and ultimately good.
there is a presumption that the models we are using today are 'good enough'. by models I mean thinks like linkers and package managers, micro services and cluster management tools.
I personally think that we're not done evolving really, and to call it quits today would leave alot of efficiency and productivity on the table
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.
It's all individual. That's like saying writing only happens when you know exactly the story to tell. I love open a blank project with a vague idea of what I want to do, and then just start exploring while I'm coding.
Having a background in fine art (and also knew Aral many years ago!), this prose resonates heavily with me.
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.
This is cute, but this is true for ALL activities in life. I have to constantly remind my brother that his job is not unique and if he took a few moments, he might realize, flipping burgers is also molding lumps of clay.
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.
"The muse visits during the act of creation, not before. Start alone."
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.
I get what he's pointing at: building teaches you things the spec can't, and iteration often reveals the real problem.
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).
> That said, the framing feels a bit too poetic for engineering.
I wholeheartedly disagree but I tend to believe that's going to be highly dependent on what type of developer a person is. One who leans towards the craftsmanship side or one who leans towards the deliverables side. It will also be impacted by the type of development they are exposed to. Are they in an environment where they can even have a "lump of clay" moment or is all their time spent on systems that are too old/archaic/complex/whatever to ever really absorb the essence of the problem the code is addressing?
The OP's quote is exactly how I feel about software. I often don't know exactly what I'm going to build. I start with a general idea and it morphs towards excellence by the iteration. My idea changes, and is sharpened, as it repeatedly runs into reality. And by that I mean, it's sharpened as I write and refactor the code.
I personally don't have the same ability to do that with code review because the amount of time I spend reviewing/absorbing the solution isn't sufficient to really get to know the problem space or the code.
It's very similar now, you have to surf a swell of selective ignorance that is (feels?) less reliable than the ignorance that one adopts when using a dependency one hasn't read and understood the source code for.
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 an artistic vase that captures some essential element of beauty, culture, or emotion.
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.
> Sometimes you want a utilitarian teapot to reliably pour a cup of tea.
If you pardon the analogy, watch how Japanese make a utilitarian teapot which reliably pours a cup of tea.
It's more complicated and skill-intensive than it looks.
In both realms, making an artistic vase can be simpler than a simple utilitarian tool.
AI is good at making (poor quality, arguably) artistic vases via its stochastic output, not highly refined, reliable tools. Tolerances on these are tighter.
The best analogy I think is, if you just take Stack Overflow code solutions, smoosh over your code and hit compile / build, and move on without ever looking at "why it works" you're really not using your skills to the best of your ability, and it could introduce bugs you didn't expect, or completely unnecessary dependencies. With Stack Overflow you can have other people pointing out the issues with the accepted answer and giving you better options.
This keeps coming up again and again and again, but like how many times were you able to copy paste SO solution wholesale and just have it work? Other than for THE most simple cases (usually CSS) there would always have to be some understanding involved. Of course you don't always learn deeply every time, but the whole "copy paste off of stackoverflow" was always an exaggeration that is being used in seeming earnest.
I have no idea who this guy is (I guess he's a fantasy novelist?) but this video came up in my YouTube feed recently and feels like it matches closely with the themes you're expressing. https://youtu.be/mb3uK-_QkOo?si=FK9YnawwxHLdfATv
This is very insightful, thanks. I had a similar thought regarding data science in particular. Writing those pandas expressions by hand during exploration means you get to know the data intimately. Getting AI to write them for you limits you to a superficial knowledge of said data (at least in my case).
Thanks for the quote, it definitely resonates. Distressing to see many people who can't relate to this, taking it literally and arguing that there is nothing lost the more removed they are from the process.
yes, this is maybe it's my preference to jump directly to coding, instead of canva to draw the gui and stuff.
i would not know what to draw because the involvemt is not so deep ...or something
I dunno, when you've made about 10,000 clay pots its kinda nice to skip to the end result, you're probably not going to learn a ton with clay pot #10,001. You can probably come up with some pretty interesting ideas for what you want the end result to look like from the onset.
I find myself being able to reach for the things that my normal pragmatist code monkey self would consider out of scope - these are often not user facing things at all but things that absolutely improve code maintenance, scalability, testing/testability, or reduce side effects.
Depends on the problem. If the complexity of what you are solving is in the business logic or, generally low, you are absolutely right. Manually coding a signup flow #875 is not my idea of fun either. But if the complexity is in the implementation, it’s different. Doing complex cryptography, doing performance optimization or near-hardware stuff is just a different class of problems.
Honestly this sounds like a Luddite mindset (and I mean that descriptively, not to be insulting). This mindset holds us back.
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.
This is beautifully written, but as a point against agentic AI coding, I just don't really get it.
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.
Yeah? And then you continue prompting and developing, and go through a very similar iterative process, except now it's faster and you get to tackle more abstract, higher level problems.
"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.
I don't think this comparison holds up. With a higher-level language, the material you're building with is a formal description of the software, which can be fed back into a compiler to get a deterministic outcome.
With an LLM, you put in a high-level description, and then check in the "machine code" (generated code).
Ironic. The frequency and predictability of this type of response — “This criticism of new technology is invalid because someone was wrong once in the past about unrelated technology” — means there might as well be an LLM posting these replies to every applicable article. It’s boring and no one learns anything.
It would be a lot more interesting to point out the differences and similarities yourself. But then if you wanted an interesting discussion you wouldn’t be posting trite flamebait in the first place, would you?
Interesting comparison. I remember watching a video on that. Landscape paintings, portraits, etc, was an art that has taken an enormous nosedive. We, as humans, have missed out on a lot of art because of the invention of the camera. On the other hand, the benefits of the camera need no elaboration. Currently AI had a lot of foot guns though, which I don't believe the camera had. I hope AI gets to that point too.
> Eloquent, moving, and more-or-less exactly what people said when cameras first hit the scene.
This is a non sequitur. Cameras have not replaced paintings, assuming this is the inference. Instead, they serve only to be an additional medium for the same concerns quoted:
The process, which is an iterative one, is what leads you
towards understanding what you actually want to make,
whether you were aware of it or not at the beginning.
Just as this is applicable to refining a software solution captured in code, just as a painter discards unsatisfactory paintings and tries again, so too is it when people say, "that picture didn't come out the way I like, let's take another one."
I think just as hard, I type less. I specify precisely and I review.
If anything, all we've changed is working at a higher level. The product is the same.
But these people just keep mixing things up like "wow I got a ferrari now, watch it fly off the road!"
Yeah so you got a tools upgrade; it's faster, it's more powerful. Keep it on the road or give up driving!
We went from auto completing keywords, to auto completing symbols, to auto completing statements, to auto completing paragraphs, to auto completing entire features.
Because it happened so fast, people feel the need to rename programming every week. We either vibe coders now, or agentic coders or ... or just programmers hey. You know why? I write in C, I get machine code, I didn't write the machine code! It was all an abstraction!
Oh but it's not the same you say, it changes every time you ask. Yes, for now, it's still wonky and janky in places. It's just a stepping stone.
Just chill, it's programming. The tools just got even better.
You can still jump on a camel and cross the desert in 3 days. Have at it, you risk dying, but enjoy. Or you can just rent a helicopter and fly over the damn thing in a few hours. Your choice. Don't let people tell you it isn't travelling.
We're all Linus Torvalds now. We review, we merge, we send back. And if you had no idea what you were doing before, you'll still have no idea what you're doing today. You just fat-finger less typos today than ever before.
I find it interesting, the comments on this post (not just this particular comment per se) and the sheer inability to relate or ATTEMPT to relate to another persons experience or feeling. The post itself articulated a viewpoint and experience, your having a different one does not negate the other. Nor does your perspective mean the other does not exist. I'm dumbfounded at many of the comments.
Here are some clipped comments that I pulled from the overall post
> I don't get it.
> I'm using LLMs to code and I'm still thinking hard.
> I don't. I miss being outside, in the sun, living my life. And if there's one thing AI has done it's save my time.
> Then think hard? Have a level of self discipline and don’t consistently turn to AI to solve your problems.
> I am thinking harder than ever due to vibe coding.
> Skill issue
> Maybe this is just me, but I don't miss thinking so much.
The last comment pasted is pure gold, a great one to put up on a wall.
Gave me a right chuckle thanks!!!
When I read the article, I feel the same emotions that I feel if someone were to tell me "I keep trying to ride a bike but I keep falling off". My experience with LLMs is that the "lack of thinking" is mostly a quick trough you fall into before you come out the other side understanding how to deal with LLMs better. And yes, there's nothing wrong with relating to someone's experience, but mostly I just want to tell that guy, just keep trying, it'll get better, and you'll be back to thinking hard if you keep at it.
But then OP says stuff like:
> I am not sure if there will ever be a time again when both needs can be met at once.
In my head that translates to "I don't think there will ever be a time again when I can actually ride my bike for more than 100 feet." At which point you probably start getting responses more like "I don't get it" because there's only so much empathy you can give someone before you start getting a little frustrated and being like "cmon it's not THAT bad, just keep trying, we've all been there".
It's honestly just an example of ego and coping. These people are trading temporary gains in pseudo-productivity for training their replacements and atrophying their skills.
The truth of the matter is that the people who will choose to partake already weren't thinking; otherwise they wouldn't have chosen. This is the same with every bubble or major revolutionary thing that ends up having negative effects in the long run. GLP-1 is another great example of one that is still on the upward arc.
Sheep will always be sheep, and, in my opinion, this is the reason for the changes in hiring and the large scale encouragement of folks that obviously are not smart enough for this career to suddenly join in over the past 10 years.
>You can still jump on a camel and cross the desert in 3 days. Have at it, you risk dying, but enjoy. Or you can just rent a helicopter and fly over the damn thing in a few hours. Your choice. Don't let people tell you it isn't travelling.
its obviously not wrong to fly over the desert in a helicopter. its a means to an end and can be completely preferable. I mean myself I'd prefer to be in a passenger jet even higher above it, at a further remove personally. But I wouldn't think that doing so makes me someone who knows the desert the same way as someone who has crossed it on foot. It is okay to prefer and utilize the power of "the next abstraction", but I think its rather pig headed to deny that nothing of value is lost to people who are mourning the passing of what they gained from intimate contact with the territory. and no it's not just about the literal typing. the advent of LLMs is not the 'end of typing', that is more reductionist failure to see the point.
Reminds me of all the parables about kings who "pretend to be a common man" for a day and walk among their subjects and leave with some new enlightenment.
The idea that you lose a ton of knowledge when you experience things through intermediaries is an old one.
I think I understand what the author is trying to say.
We miss thinking "hard" about the small details. Maybe "hard" isn't the right adjective, but we all know the process of coding isn't just typing stuff while the mind wanders. We keep thinking about the code we're typing and the interactions between the new code and the existing stuff, and keep thinking about potential bugs and issues. (This may or may not be "hard".)
And this kind of thinking is totally different from what Linus Torvalds has to think about when reviewing a huge patch from a fellow maintainer. Linus' work is probably "harder", but it's a different kind of thinking.
You're totally right it's just tools improving. When compilers improved most people were happy, but some people who loved hand crafting asm kept doing it as a hobby. But in 99+% cases hand crafting asm is a detriment to the project even if it's fun, so if you love writing asm yourself you're either out of work, or you grudgingly accept that you might have to write Java to get paid. I think there's a place for lamenting this kind of situation.
Spot on. It’s the lumberjack mourning the axe while holding a chainsaw. The work is still hard. it’s just different.
The friction comes from developers who prioritize the 'craft' of syntax over delivering value. It results in massive motivated reasoning. We see people suddenly becoming activists about energy usage or copyright solely to justify not using a tool they dislike. They will hunt for a single AI syntax error while ignoring the history of bugs caused by human fatigue. It's not about the tech. it's about the loss of the old way of working.
And it's also somewhat egotistical it seems to me. I sense a pattern that many developers care more about doing what they want instead of providing value to others.
I agree. I think some of us would rather deal with small, incremental problems than address the big, high-level roadmap. High-level things are much more uncertain than isolated things that can be unit-tested. This can create feelings of inconvenience and unease.
I work with a lot of artists, and selling them on (not totally rejecting) AI has largely been unsuccessful until they both understand the analogies and the specifics of what different tools do.
AI makes you the manager. The models are like GRAs or contract workers, maybe new to their fields but with tireless energy, and you need to be able to instruct them correctly and evaluate their outputs. None of them can do everything, and you'll need to carefully hire the ones you want based on the work you need, which means breaking workflows into batchable parts. If you've managed projects before, you've done this.
Right now, my focus is improving pipelines in composition and arrangement based on an artist's corpus. A lot of them just want to be more productive, and it's a slog to write, then break into parts, etc using modern notation software.
Well, depending on the scope of work, they may be still thinking hard, just on a higher level. That is, thinking about the requirements, specification, and design.
That's a warm and cozy way to look at things but its not true.
LLM-aided coding is not a higher level tool. It is not writing in C vs writing in assembly. It is closer to asking other people to do something for you and (supposedly, hopefully, although how many people really do it?) reviewing the result.
The thing is, some people already disliked the thinking involved in programming and are welcoming these tools. That's fine, but you don't get to equate it with programming.
You don't have a strong mental model after agentic coding something in my experience.
It isn't an abstraction like assembly -> C.
If you code something like: extract the raw audio data from an audio container, it doesn't matter if you write it in assembly, C, Javascript, whatever. You will be able to visualize how the data is structured when you are done. If you had an agent generate the code the data would just be an abstraction.
It just isn't worth it to me. If I am working with audio and I get a strong mental model for what different audio formats/containers/codecs look like who knows what creative idea that will trigger down the line. If I have an agent just fix it then my brain will never even know how to think in that way. And it takes like... a day...
So I get it as a optimized search engine, but I will never just let it replace understanding every line I commit.
Maybe in order to get the most out of agentic programming one needs to either a) already master the domain in question, or b) become a master in the process.
When (b) then the process can be the thing that triggers "thinking hard", and when (a) the one's mastery can be the reason one "thinks hard" when driving the agent.
Does this help TFA? Idk. Maybe if TFA can try either doing (a) a lot or (b) a lot it might. Or maybe agentic programming is going to drive out of the business those who stop thinking hard because they have agents to help them.
> We're all Linus Torvalds now. We review, we merge, we send back. And if you had no idea what you were doing before, you'll still have no idea what you're doing today. You just fat-finger less typos today than ever before.
Except Linus understands the code that is being reviewed / merged in since he already built the kernel and git by hand. You only see him vibe-coding toys but not vibe-coding in the kernel.
Today, we are going to see a gradual skill atrophy with developers over-relying on AI and once something like Claude goes down, they can't do any work at all.
The most accurate representation is that AI is going to rapidly make lots of so-called 'senior engineers' who are over-reliant and unable to detect bad AI code like juniors and interns.
My “skill” for 40 years has been to turn what I wanted my computer to do into code to get it done using the tools available to me. A “senior developer” is not someone who “codez real gud”. It’s someone who can work at a higher level of scope and ambiguity and has a larger impact on the organization than a ticket taker
I think the more apt analog isn't a faster car, a la Ferrari, it's more akin to someone who likes to drive and now has to sit and monitor the self-driving car steer and navigate. Comparing to the Ferrari is incorrect since it still takes a similar level of agency from the driver versus a <insert slower vehicle>
FSD is very very good most of the time. It's so good (well, v14 is, anyway), it makes it easy to get lulled into thinking that it works all the time. So you check your watch here, check your phone there, and attend to other things, and it's all good until the car decides to turn into a curb (which almost happened to me the other day) or swerve hard into a tree (which happened to someone else).
Funny enough, much like AI, Tesla is shoving FSD down people's throats by gating Autopilot 2, a lane keeping solution that worked extremely well and is much friendlier to people who want limited autonomy here and there, behind the $99/mo FSD sub (and removing the option to pay for the package out of pocket).
> I think just as hard, I type less. I specify precisely and I review.
Even if you "think just as hard" the act of physically writing things down is known to improve recall, so you're skipping a crucial step in understanding.
And when I review code, it's a different process than writing code.
These tradeoffs may be worth it, because we can ask the tools to analyze things for us just as easily as we can ask them to create things for us, but your own knowledge and understanding of the system is absolutely being degraded when working this way.
It is simple. Continuing your metaphor, I have a choice of getting exactly where I want on a camel in 3 days, or getting to a random location somewhere on the other side of the desert on a helicopter in few hours.
And being a reasonable person I, just like the author, choose the helicopter. That's it, that's the whole problem.
I got excited about agents because I told myself it would be "just faster typing". I told myself that my value was never as a typist and that this is just the latest tool like all the tools I had eagerly added to my kit before.
But the reality is different. It's not just typing for me. It's coming up with crap. Filling in the blanks. Guessing.
The huge problem with all these tools is they don't know what they know and what they don't. So when they don't know they just guess. It's absolutely infuriating.
It's not like a Ferrari. A Ferrari does exactly what I tell it to, up to the first-order effects of how open the throttle is, what direction the wheels face, how much pressure is on the brakes etc. The second-order effects are on me, though. I have to understand what effect these pressures will have on my ultimate position on the road. A normie car doesn't give you as much control but it's less likely to come off the road.
Agents are like a teleport. You describe where you want to be and it just takes you directly there. You say "warm and sunny" and you might get to the Bahamas, but you might also get to the Sahara. So you correct: "oh no, I meant somewhere nice" and maybe you get to the Bahamas. But because you didn't travel there yourself you failed to realise what you actually got. Yeah, it's warm, sunny and nice, but now you're on an island in the middle of nowhere and have to import basically everything. So I prompt again and rewrite the entire codebase, right?
Linus Torvalds works with experts that he trusts. This is like a manic 5 year old that doesn't care but is eager to work. Saying we all get to be Torvalds is like saying we all get to experience true love because we have access to porn.
I get your point that wetware stills matter, but I think it's a bit much to contend that more than a handful of people (or everyone) is on the level of Linus Torvalds now that we have LLMs.
I should have been clearer. It was a pun, a take, a joke. I was referring to his day-to-day activity now, where he merges code, doesn't write hardly any code for the linux kernel.
I didn't imply most of use can do half the thing he's done. That's not right.
I agree! It's a lot more pleasant than being stuck over figuring out how to use awk properly for hours. I knew what I needed to do then, and I know what I need to do now too. The difference is I get to results faster. Sometimes I even learn that awk was not even the right tool in my situation and learn about a new way of doing things while AI is "thinking" for me
Like I said that's temporary. It's janky and wonky but it's a stepping stone.
Just look at image generation. Actually factually look at it. We went from horror colours vomit with eyes all over, to 6 fingers humans, to pretty darn good now.
It really bothers me how many comments on this topic (here and elsewhere) draw a false parallel between LLM-based coding as an abstraction and frameworks and compilers as an abstraction. They're not the same thing and it matters.
Frameworks and compilers are designed to be leak-proof abstractions. Any way in which they deviate from their abstract promise is a bug that can be found, filed, and permanently fixed. You get to spend your time and energy reasoning in terms of the abstraction because you can trust that the finished product works exactly the way you reasoned about at the abstract level.
LLMs cannot offer that promise by design, so it remains your job to find and fix any deviations from the abstraction you intended. If you fell short of finding and fixing any of those bugs, you've just left yourself a potential crisis down the line.
[Aside: I get why that's acceptable in many domains, and I hope in return people can get why it's not acceptable in many other domains]
All of our decades of progress in programming languages, frameworks, libraries, etc. has been in trying to build up leak-proof abstractions so that programmer intent can be focused only on the unique and interesting parts of a problem, with the other details getting the best available (or at least most widely applicable) implementation. In many ways we've succeeded, even though in many ways it looks like progress has stalled. LLMs have not solved this, they've just given up on the leak-proof part of the problem, trading it for exactly the costs and risks the industry was trying to avoid by solving it properly.
Your comment gets to the crux of my thinking about LLM coding. The way I think of what LLM coding is doing is decompressing your prompt into code based on the statistical likelihood of that decompression based on training data. Basically "Build me an IOS app" -> a concrete implementation of an iOS app. The issue here is that the user supplying the prompt needs to encode all of the potential variables that the AI needs to work with into the prompt, or else the implementation will just be based on the "bog-standard" iOS app based on the training corpus, although with potential differences in the app based on other tokens in the prompt. Is natural language the right way to encode that information? Do we want to rely on input tokens to the context of a model successfully making it into the output to guarantee accuracy? I think the Kiro Spec driven development starts to get at addressing the inherent issues in LLM based coding assistance, but it is an early step.
Another way in which their different is that, because they are non-deterministic, we check in the output, not the input. It's the equivalent of checking machine code into our source control instead of the input language. It's not abstraction, its non-deterministic code generation.
> LLMs cannot offer that promise by design, so it remains your job to find and fix any deviations from the abstraction you intended.
LLMs are clumsy interns now, very leaky. But we know human experts can be leak-proof. Why can't LLMs get there, too, better at coding, understanding your intentions, reviewing automatically for deviations, etc.?
Thought experiment: could you work well with a team of human experts just below your level? Then you should be able to work well with future LLMs.
Well, sometimes your compiler will work out how to more efficiently compile a thing (e.g. vectorize a loop), and other times you'll rework some code to an equivalent formulation and suddenly it won't get vectorized because you've tripped some invisible flag that prevents an inlining operation that was crucial to enabling that vectorization, and now that hot path runs at a quarter of the speed it did before.
Technically it's (usually) deterministic for a given input, and you can follow various best practices to increase your odds of triggering the right optimizations.
But practically speaking "will I get the good & fast code for this formulation" is a crap shoot, and something like 99% (99.99%?) of programmers live with that. (you have guidelines and best practices you can follow, kinda like steering agents, but rarely get guarantees)
Maybe in the future the vast majority of programmers put up with a non-deterministic & variable amount of correctness in their programs, similar to how most of us put up with a (in practice) non-deterministic & variable amount of performance in our programs now?
You know, I was expecting what the post would say and was prepared to dunk on it and just tell them to stop using ai then, but the builder/thinker division they presented got me thinking. How ai/vibe coding fulfills the builder, not the thinker, made me realize that I'm basically 100% thinker, 0% builder, and that's why I don't really care at all about ai for coding.
I'll spend years working on a from scratch OS kernel or a vulkan graphics engine or whatever other ridiculous project, which never sees the light of day, because I just enjoy the thinking / hard work. Solving hard problems is my entertainment and my hobby. It's cool to eventually see results in those projects, but that's not really the point. The point is to solve hard problems. I've spent decades on personal projects that nobody else will ever see.
So I guess that explains why I see all the ai coding stuff and pretty much just ignore it. I'll use ai now as an advanced form of google, and also as a last ditch effort to get some direction on bugs I truly can't figure out, but otherwise I just completely ignore it. But I guess there's other people, the builders, where ai is a miraculous thing and they're going to crazy lengths to adopt it in every workflow and have it do as much as possible. Those 'builder' types of people are just completely different from me.
Absolutely nah. I know it feels good to jump into the 'thinker' camp and lump the users of AI into a non-thinker group, but this dichotomy is very poorly suited. Builders/engineers want a great tool to build faster with. Coders want to write code and find elegance in the prose. Both are thinkers.
This just sounds like a boring definitional issue. 'Thinker' is a loaded word.
You are advocating for a particular (more inclusive) definition for 'thinker' which clashes with the author's, but his is equally valid. You're both just gesturing at different concepts and suggesting they should be tagged to that word.
OP raises a particular way to classify something about personalities, says he finds it quite interesting/discriminative, and calls that kind of personality a "thinker". You instead consider a "thinker" a broader category.
That feels like an empty disagreement (nobody is right on such matters) - the real debatable question of substance is whether the _concept_ OP is gesturing at has interesting discriminative power. That concept is something like "personalities which seem to value the act of thinking through a problem/problem solving itself rather than downstream result".
As someone who's been coding for several decades now (i.e. I'm old), I find the current generation of AI tools very ... freeing.
As an industry, we've been preaching the benefits of running lots of small experiments to see what works vs what doesn't, try out different approaches to implementing features, and so on. Pre-AI, lots of these ideas never got implemented because they'd take too much time for no definitive benefit.
You might spend hours thinking up cool/interesting ideas, but not have the time available to try them out.
Now, I can quickly kick off a coding agent to try out any hare-brained ideas I might come up with. The cost of doing so is very low (in terms of time and $$$), so I get to try out far more and weirder approaches than before when the costs were higher. If those ideas don't play out, fine, but I have a good enough success rate with left-field ideas to make it far more justifiable than before.
Also, it makes playing around with one-person projects a lot practical. Like most people with partner & kids, my down time is pretty precious, and tends to come in small chunks that are largely unplannable. For example, last night I spent 10 minutes waiting in a drive-through queue - that gave me about 8 minutes to kick off the next chunk of my one-person project development via my phone, review the results, then kick off the next chunk of development. Absolutely useful to me personally, whereas last year I would've simply sat there annoyed waiting to be serviced.
I know some people have an "outsourcing Lego" type mentality when it comes to AI coding - it's like buying a cool Lego kit, then watching someone else assemble it for you, removing 99% of the enjoyment in the process. I get that, but I prefer to think of it in terms of being able to achieve orders of magnitude more in the time I have available, at close to zero extra cost.
> 8 minutes to kick off the next chunk of my one-person project development via my phone, review the results, then kick off the next chunk of development.
claude can deploy to github spaces and modify code for deployment to those by commits and pull requests to the repo exclusively
claude via browser and claude mobile apps function this way
but alongside that, people do make tunnels to their personal computer and setup ways to be notified on their phone, or to get the agent unstuck when it asks for a permission, from their phone
Just wanted to +1 this as a deep thinker who disagrees with the blog post's conclusion. I remember back on the years and decades I wasted dealing with the conceptual flaws inherent to nearly all software, and it breaks my heart.
90-99% of programming is a waste of time. Most apps today have less than a single spreadsheet page of actual business logic. The rest is boilerplate. Conjuring up whatever arcane runes are needed to wake a slumbering beast made of anti-patterns and groupthink.
For me, AI offers the first real computer that I've had access to in over 25 years. Because desktop computing stagnated after the 2000 Dot Bomb, and died on the table after the iPhone arrived in 2007. Where we should have symmetric multiprocessing with 1000+ cores running 100,000 times faster for the same price, we have the same mediocre quad core computer running about the same speed as its 3 GHz grandfather from the early 2000s. But AI bridges that divide by recruiting video cards that actually did increase in speed, albeit for SIMD which is generally useless for desktop computing. AI liberates me from having to mourn that travesty any longer.
I think that people have tied their identity to programming without realizing that it's mostly transcribing.
But I will never go back to manual entry (the modern equivalent of punch cards).
If anything, I can finally think deeply without it costing me everything. No longer having to give my all just to tread water as I slowly drown in technical debt and deadlines which could never be met before without sacrificing a part of my psyche in the process.
What I find fascinating is that it's truly over. I see so clearly how networks of agents are evolving now, faster than we can study, and have already passed us on nearly every metric. We only have 5-10 years now until the epiphany, the Singularity, AGI.
It's so strange to have worked so hard to win the internet lottery when that no longer matters. People will stop buying software. Their AI will deliver their deepest wish, even if that's merely basic resources to survive, that the powers that be deny us to prop up their fever dream of late-stage crony capitalism under artificial scarcity.
Everything is about to hit the fan so hard, and I am so here for it.
> 90-99% of programming is a waste of time. Most apps today have less than a single spreadsheet page of actual business logic.
I would very much like to know the kind of app you’ve seen. It’s very hard to see something like mpv, calibre, abiword, cmus,… through that lens. Even web apps like forgejo, gonic, sr.ht, don’t fit into that view.
> For me, AI offers the first real computer that I've had access to in over 25 years.
That's such a weird perspective. No matter your dissatisfaction with the software available, the computers we had were perfectly fine for writing whatever software you wanted to write.
Totally agree. I can spend an afternoon trying out an approach to a problem or product (usually while taking meetings and writing emails as well). If it doesn't work, then that's a useful result from my time. If it does work, I can then double-down on review, tests, quality, security, etc and make sure it's all tickety-boo.
Completely agree, there’s so many small projects I’d never been able to even start in my free time, because I’m NOT a full-stack dev and I’d rather not spend all my evenings fixing or working around all the small changes and quirks of the $currentjsframework
I think this is the other side of the same coin, and it's a really important one. When time is scarce, especially with family and a life outside work, the ability to turn tiny, fragmented moments into forward progress is huge
Exactly, it kills me to see a people a lot younger (I’m 51) pining about the good old days while the coding part of my day to day life now is using AI tools to their fullest extent.
I will never not be upset at my fellow engineers for selling out the ONE thing that made us valuable and respected in the marketplace and trying to destroy software engineering as a career because "Claude Code go brrrrrr" basically.
It's like we had the means for production and more or less collectively decided "You know what? Actually, the bourgeoisie can have it, sure."
Will we see growing unemployment in software development? Maybe in the short term, but the appetite for software is not finite just as the appetite for any other kind of economic tool is not finite.
What percentage of software just ceases development when it's "good enough?" Probably a tiny percentage of all software, and which is mostly internal tooling.
It's going to push software development into the front of business development precisely because it will be cheaper to develop. The companies that will benefit from AI at least early on will all be software-driven companies since the results are undeniable. If software developers lose out when all of their companies become more efficient and new companies are built because it becomes easier to build software with small teams, I will be very surprised.
The personification of the quote “your scientists were so preoccupied with whether or not they could that they didn't stop to think if they should”
I feel the existential problem for a world that follows the religion of science and technology to its extreme, is that most people in STEM have no foundation in humanities, so ethical and philosophical concerns never pass through their mind.
We have signed a pact with the devil to help us through boring tasks, and no one thought to ask what we would give in exchange.
Yeah, lawyers, politicians and MBA types all usually have solid foundation in humanities. Not exactly known for concerning themselves with ethics or philosophy though.
I find it fascinating how the “true believers” of AI and AGI, have essentially been manipulated by capitalists to undermine the value of their own labor.
The bloodless pragmatists aided and abetted them. Those who have no apparent values. Only short-term, terminally idiotic obsession with building things, creating value, creating business value, or whatever the pragmatist posturing of the day is.
Now they can have the fruits of their labor. Nothing. But why would they even want that? It’s not about getting something out of it. Or maintaining a living. It’s about building things.
so AI can actually replace software engineers? It's relatively unusual to see someone who "believes in AI", but is "anti-AI", at least among the HN crowd.
Also, I find this view very selfish. Yes, let's gatekeep a ground-breaking technology because it will hurt my specific profession. That's literally what technological progress is- it always (at least temporarily) disadvantages a particular sector of workers that specialized in that skill for the benefit of society. It's just funny because usually it's the blue collar workers who have to worry about this and the white collar workers who sanctimoniously tell them to suck it up or learn to code.
Also, I can't help but chuckle slightly at the irony here. The entire purpose of software engineering and computers is automation, and the lost jobs in other sectors due to SWEs is massive. To spend one's entire life in pursuit of this and be morally opposed to the "ultimate" automation (automating this process of automation itself) is a bit rich.
One thing this discussion made me realize is that "thinking hard" might not be a single mode of thinking.
In grad school, I had what I'd call the classic version. I stayed up all night mentally working on a topology question about turning a 2-torus inside out. I already knew you can't flip a torus inside out in ordinary R^3 without self-intersection. So I kept moving and stretching the torus and the surrounding space in my head, trying to understand where the obstruction actually lived.
Sometime around sunrise, it clicked that if you allow the move to go through infinity(so effectively S^3), the inside/outside distinction I was relying on just collapses, and the obstruction I was visualizing dissolves. Birds were chirping, I hadn't slept, and nothing useful came out of it, but my internal model of space felt permanently upgraded. That's clearly "thinking hard" in the sense.
But there's another mode I've experienced that feels related but different. With a tough Code Golf problem, I might carry it around for a week. I'm not actively grinding on it the whole time, but the problem stays loaded in the background. Then suddenly, in the shower or on a walk, a compression trick or a different representation just clicks.
That doesn't feel "hard" moment to moment. It's more like keeping a problem resident in memory long enough for the right structure to surface.
One is concentrated and exhausting, the other is diffuse and slow-burning. They're different phenomenologically, but both feel like forms of deep engagement that are easy to crowd out.
Yup, yup! There's so many different ways of thinking hard.
For me, thinking about an extremely technical TCS problem, for example, is my version of actively, tirelessly thinking hard. I'm logging a ton of observations, trying new ideas and hypotheses, using a mix of computer simulation and math to try and arrive at a concrete framing and answer.
On the other end of the specturm, I have philosophy. It's definitely a different type of hard. Most of my "Aha!" moments come from when I realize I've been strawmanning some argument, and not actually understanding what the person is saying. Why is the person saying this, relative to what, why is this a new observation, etc. Things are so amorphus and you can tweak the problem parameters in so many ways, and it's really tempting to either be too fluid and pretend you understand the thinker (because it's a subset of some conception you already have), or be too rigid and dissolve the thinker as a category error / meaningless. I've never felt the same feeling as I did when doing TCS research, but the feeling was definitely hard thinking nonetheless.
In terms of extremely nitty-gritty technical things, like linker bullshit and linux kernel programming, I'm much more familiar with, and these things are more about reading documentation (because the tool won't behave like you want it to) and iteration / testing (because... the tool won't behave like you want it to, so you need to make sure it behaves like you want it to!). This is also a type of thinking - I would call it hard as in the physiological response I have is similar to that of research in the very bad moments, but in terms of my lofty ideals, I don't want to call this hard.... it's very "accidental" complexity, but it's what I get paid to do :/
At work, you have a huge idea space to consider, both problem and solution framings, mixing in "bullshit" constraints like business ones. You also throw in the real-time aspect of it, so I can't just either armchair on a problem for a month (unlike Philosophy) or deep dive on a problem for a month (unlike research). I'm technically doing the third type of programming right now, but we'll see how long that lasts and I get put on a new project.
I'm not even sure if there's a clean demarcation between any of these. These are certainly better than brainrotting youtube though.
I think the article has a point. There seem to be two reactions among senior engineers atound me these days.
On one side, there are people who have become a bit more productive. They are certainly not "10x," but they definitely deliver more code. However, I do not observe a substantial difference in the end-to-end delivery of production-ready software. This might be on me and my lack of capacity to exploit the tools to their full extent. But, iterating over customer requirements, CI/CD, peer reviews, and business validation takes time (and time from the most experienced people, not from the AI).
On the other hand, soemtimes I observe a genuine degradation of thinking among some senior engineers (there aren’t many juniors around, by the way). Meetings, requirements, documents, or technology choices seem to be directly copy/pasted from an LLM, without a grain of original thinking, many times without insight.
The AI tools are great though. They give you an answer to the question. But, many times making the correct question, and knowing when the answer is not correct is the main issue.
I wonder if the productivity boost that senior engineers actually need is to profit from the accumulated knowledge found in books. I know it is an old technology and it is not fashionable, but I believe it is mostly unexploited if you consider the whole population of engineers :D
> This might be on me and my lack of capacity to exploit the tools to their full extent. But, iterating over customer requirements, CI/CD, peer reviews, and business validation takes time (and time from the most experienced people, not from the AI).
Yeah, you're certainly not the only one. For me the implementation part has always been a breeze compared to all the "communication overhead" so to speak. And in any mature system it easily takes 90% of all time or more.
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.
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
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.
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...
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.
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.
Aptitude testing centers like Johnson O'Connor have tests for that. There are (relatively) huge differences between different people's thinking and problem solving styles. For some, creating an efficient process feels natural, while others need stability and redundancy. Programmers are by and large the latter.
> 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.
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.
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
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 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...
I haven't reduced my thinking! Today I asked AI to debug an issue. It came with a solution that it was clearly correct, but it didn't explain why the code was in that state. I kept steering AI (which just wanted to fix) toward figuring out the why and it digged through git and github issue at some point,in a very cool way.
And finally it pulled out something that made sense. It was defensive programming introduced to fix an issue somewhere else, which was also in turn fixed, so useless.
At that point an idea popped in my mind and I decided to look for similar patterns in the codebase, related to the change, found 3. 1 was a non bug, two were latent bugs.
Shipped a fix plus 2 fixes for bugs yet to be discovered.
I think my message is doing a disservice to explaining what actually happened because a lot of it happens in my head.
1. I received the ticket, as soon as I read it I had a hunch it was related to some querying ignoring a field that should be filtered by every query (thinking)
2. I give this hunch to the AI which goes search in the codebase in the areas I suggested the problem could be and that's when it find the issue and provide a fix
3. I think the problem could be spread given there is a method that removes the query filter, it could have been used in multiple places, so I ask AI to find other usages of it (thinking, this is my definition of "steering" in this context)
4. AI reports 3 more occurrences and suggests that 2 have the same bug, but one is ok
5. I go in, review the code and understand it and I agree, it doesn't have the bug (thinking)
6. AI provide the fix for all the right spots, but I said "wait, something is fishy here, there is a commit that explicitly say it was added to remove the filter, why is that?" (thinking), so I ask AI to figure out why the commit says that
7. AI proceeds to run a bunch of git-history related commands, finds some commit and then does some correlation to find another commit. This other commit introduced the change at the same time to defend from a bug in a different place
8. I understand what's going on now, I'm happy with the fix, the history suggests I am not breaking stuff. I ask AI to write a commit with detailed information about the bug and the fix based on the conversation
There is a lot of thinking involved. What's reduced is search tooling. I can be way more fuzzy, rather than `rg 'whatever'` I now say "find this and similar patterns"
I've found that it's often useful to spend the time thinking about the way I would architect the code (down to a fair level of minutia) before letting the agent have a go.
That way my 'thinker' is satiated and also challenged - Did the solution that my thinker came up with solve the problem better than the plan that the agent wrote?
Then either I acknowledge that the agent's solution was better, giving my thinker something to chew on for the next time; or my solution is better which gives the thinker a dopamine hit and gives me better code.
I'm wondering if everyone here saying they think harder with LLM agents have never reached "flow state" while programming. I just can't imagine using 100% of my mental focus state for hours with an agent. Sure, I think differently when my coding is primarily via agent, but I've never been totally enveloped by my thoughts while doing so.
For those who have found a "flow state" with LLM agents, what's that like?
I've literally never found flow state with programming. Is it even possible when working as a full stack web dev? I am constantly context switching between backend/frontend, reading documentation, looking at/modifying data, refreshing & interacting with the browser, checking/double checking feature requirements, asking people about things.
For me, yes. It is possible as when working full-stack if you aren't being interrupted. Not all tasks, but some tasks, where you're pretty sure of the high-level requirements, have the necessary agency to stay in a bubble for a bit, and the task is sufficiently complex but narrow enough so you don't have to context switch too much.
With LLM Agents I can't seem to do it, as waiting for the agent to finish working just doesn't tickle my brain in the right way. I feel... distracted, I guess?
I believe you can enter "flow state" with something like Claude Code, from what I've read, but it's mostly reduced to pressing 1 or 2 and typing a few prompts. The reward loop is much more closed now though, so it's a bit more akin to reaching flow state playing Tetris.
People here seem to be conflating thinking hard and thinking a lot.
Most examples mentioned of “thinking hard” in the comments sound like they think about a lot of stuff superficially instead one particular problem deeply, which is what OP is referring to.
If you actually have a problem worth thinking deeply about, AI usually can’t help with it. For example, AI can’t help you make performant stencil buffers on a Nokia Ngage for fun. It just doesn’t have that in it. Plenty of such problems abound, especially in domains involving some or the other extreme (like high throughput traffic). Just the other day someone posted a vibe coded Wikipedia project that took ages to load (despite being “just” 66MB) and insisted it was the best it was possible to do, whereas Google can load the entire planet (perceptually) in a fraction of a second.
I miss the thrill of running through the semi-parched grasslands and the heady mix of terror triumph and trepidation as we close in on our meal for the week.
To be honest, I do not quite understand the author's point. If he believes that agentic coding or AI has negative impact on being a thinker, or prevent him from thinking critically, he can simply stop using them.
Why blame these tools if you can stop using them, and they won't have any effect on you?
In my case, my problem was often overthinking before starting to build anything. Vibe coding rescued me from that cycle. Just a few days ago, I used openclaw to build and launch a complete product via a Telegram chat. Now, I can act immediately rather than just recording an idea and potentially getting to it "someday later"
To me, that's evolutional. I am truly grateful for the advancement of AI technology and this new era. Ultimately, it is a tool you can choose to use or not, rather than something that prevents you from thinking more.
For me personally, the problem is my teammates. The ability or will to critically think, or investigate existing tools in the codebase seems to disappear. Too often now I have to send back a PR where something is fixed using novel implementations instead of the single function call using existing infrastructure.
I generally feel the same. But in addition, I also enjoy the pure act of coding. At least for me that’s another big part why I feel left behind with all this Agent stuff.
I agree, that's another factor. Definitely the mechanical act of coding specially if your are good at it gives the type of joy that I can imagine an artisan or craftsman having when doing his work.
Good highlight of the struggle between Builder and Thinker, I enjoyed the writing.
So why not work on PQC? Surely you've thought about other avenues here as well.
If you're looking for a domain where the 70% AI solution is a total failure, that's the field. You can't rely on vibe coding because the underlying math, like Learning With Errors (LWE) or supersingular isogeny graphs, is conceptually dense and hasn't been commoditized into AI training data yet. It requires that same 'several-day-soak' thinking you loved in physics, specifically because we're trying to build systems that remain secure even against an adversary with a quantum computer. It’s one of the few areas left where the Thinker isn't just a luxury, but a hard requirement for the Builder to even begin.
I have to think more rigorously. I have to find ways to tie up loose ends, to verify the result efficiently, to create efficient feedback loops and define categorical success criteria.
I've thought harder about problems this last year than I have in a long time.
> I have to find ways to tie up loose ends, to verify the result efficiently, to create efficient feedback loops and define categorical success criteria.
So... you didn't have to do that prior to using agents?
Not as much upfront. I had plenty of opportunities to adjust and correct along the way. With AI, the cost of not thinking upfront is high and the cost of being wrong in upfront decisions is low, so we bias towards that.
But beyond that, I have been thinking deeply about AI itself, which has all sorts of new problems. Permissions, verification, etc.
I find I think harder with AI programming. It generates the code, but I have to approve the overall design and then approve every single line. I will edit and rearrange the code until it is correct.
But since the AI is generating a lot of code, it is challenging me. It also allows me to tackle problems in unfamiliar areas. I need to properly understand the solutions, which again is challenging. I know that if I don't understand exactly what the code is doing and have confidence in the design and reliability, it will come back and bite me when I release it into the wild. A lesson learnt the hard way during many decades of programming.
Seems like a lot of people use AI to code in their private commercial IP and products. How are people not concerned with the fact that all these ai companies have the source code to everything? Your just helping them destroy your job. Code is not worthless, you cannot easily duplicate any complex project with equal features, quality, and stability.
I think that is a very good point. Code is definitely not worthless, but I don't think that capitalism has the right tools for pricing it properly. I think it will become a lot like mathematics in that way.
> 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.
I've not seen this take yet, but this is exactly how I feel. I do not yet know what I want to do, and my parts of my personality are no longer satisfied by coding. I'm thinking we need some kind of community of people like us where we can discuss these things.
I bring these up with others, and I find that most people around me are just builders.
> 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.
I think this is context dependent. Over time, within a single code base or ecosystem, incompatibilities between "close enough" solutions can add up and create a lot of problems and complexity, kinda like floating point inaccuracies. Especially if you're not going back and revisiting the structure/abstractions you've already got when you're adding/changing something.
There's another angle too, which is that time taken to improve your abilities isn't necessarily irrational, especially because that improvement is usually applicable in many different ways. It can be an investment.
I've been coding since the late 70s (Commodore PET 2001), and I've always paired it with real-world physical work—mechanical engineering, rigging, technical diving, hydraulics, welding, electronics, controls, you name it. Programming was just one of the tools, never the whole job.
What I've learned is that the best thinking almost never happens staring at a screen. It happens when you're away from it: reading something deep, building something with your hands, debugging why the thing you designed doesn't work in reality.
I love the updated saying: "Jack of all trades, master of none—but often better than a master of one." In a world obsessed with hyper-specialization, that range is a real advantage.
What bothers me most is how quickly people—especially younger ones—now reach for a phone the second there's any friction. Forgotten a name? Phone. Stuck on a small logic puzzle? Phone. A group of engineers at the lunch table can't remember an actor and within seconds everyone's just silently googling instead of laughing and piecing it together from their collective memory. Where's the fun in that?
Yeah, you get the answer instantly. But you skip the actual mental workout—and the fun of it. Remembering and reasoning are muscles. Use them or lose them. And honestly, the shared back-and-forth is usually the best part.
I feel like AI has given me the opportunity to think MORE, not less. I’m doing so much less mindless work, spending most of my efforts critically analyzing the code and making larger scale architectural decisions.
The author says “ Even though the AI almost certainly won't come up with a 100% satisfying solution, the 70% solution it achieves usually hits the “good enough” mark.”
The key is to keep pushing until it gets to the 100% mark. That last 30% takes multiples longer than the first 70%, but that is where the satisfaction lies for me.
I miss entering flow state when coding. When vibe coding, you are in constant interruption and only think very shallow. I never see anyone enter flow state when vibe coding.
The two ways I get into flow state these days are in setting up agentic loops, so I can get out of the way by letting AI check the results for itself, and by doing more things. I've got ~4 Claude Code instances working on problems, per project, and I've got multiple projects I'm working on at the same time.
If it's this easy to convince you to stop being creative, to stop putting in effort to think critically, then you don't deserve the fulfilment that creativity and critical thinking can give you. These vibe coding self pity articles are so bizarre.
The post resonates deeply with me.
I am a health professional in diagnostics and through the years I have observed different extremes in approaches to solving diagnostic challenges - the one extreme is to rely on "knowing", the other on "thinking/reasoning". The former is usually very fast, but not easily explainable - just like pattern recognition. The latter was slow, but could give a solution from "first principles" and possibly not described before.
Of course it's a spectrum and the thinking part requires and includes the deep enough "knowing" part. One usually uses both approaches on daily work, but I have seen some people who relied much more on knowing than thinking/reasoning, sometimes to the extreme (as in refusing to diagnose a condition on their own because they "have not seen this before").
With AI, I now think much harder. Timelines are shorter, big decisions are closer together, and more system interactions have to be "grokked" in my head to guide the model properly.
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.
My solution has been to lean into harder problems - even as side projects, if they aren't available at work.
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).
> I have tried to get that feeling of mental growth outside of coding
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.
Great article. Moment I finished reading this article, I thought of my time in solving a UI menu problem with lot of items in it and algorithm I came up with to solve for different screen sizes. It took solid 2 hrs of walking and thinking. I still remember how I was excited when I had the feeling of cracking the problem. Deep thinking is something everyone has it within and it varies how fast you can think. But we all got it with right environment and time we all got it in us. But thats long time ago. Now I always off load some thinking to AI. it comes up with options and you just have to steer it. By time it is getting better. Just ask it you know. But I feel like it is good old days to think deep by yourself. Now I have a partner in AI to think along with me. Great article.
I did competitive programming seriously between '17 and '24, then kept on coaching people
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.
Do you mean that sitting with the problem for days is a weakness that you should fix since you're wasting time making no progress? Or that it is a necessary practice in order to understand your weaknesses?
Eventually I always get to a problem I can't solve by just throwing an LLM at it and have to go in and properly debug things. At that point knowing the code base helps a hell of a lot, and I would've been better off writing the entire thing by hand.
This resonates with me, but I quit programming about a decade ago when we were moving from doing low level coding to frameworks. It became no longer about figuring out the actual problem, but figuring out how to get the framework to solve it and that just didn't work for me.
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.
I’d been feeling this until quite literally yesterday, where I sort of just forced myself to not touch an AI and grappled with the problem for hours. Got myself all mixed up with trig and angles until I got a headache and decided to back off a lot of the complexity. I doubt I got everything right, I’m sure I could’ve had a solution with near identical outputs using an AI in a fraction of the time.
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 think the heart of the matter is this section in the blog:
> Yes, I blame AI for this.
> I am currently writing much more, and more complicated software than ever, yet I feel I am not growing as an engineer at all. [...] (emphasis added by me)
I'm thinking much more than ever, now that the coding agent is building for me.
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.
Many people here might be in a similar situation to me, but I took an online masters program that allowed for continuing education following completion of the degree. This has become one of my hobbies; I can take classes at my own expense, not worry about my grades, and just enjoy learning. I can push myself as much as I want and since the classes are hard, just completing 1 assignment is enough to force me to "think". Just sharing my experience for people who might be looking for ways to challenge themselves intellectually.
I think what plagues a lot of pure STEM types in this tumultuous period of AI (or "AI") is that they've spent a majority of their lives mulling over some problem until they've worked out every possible imperfection, and once they've achieved something they consider close to that level of perfection, that's when they say they're done.
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.
> I think what plagues a lot of pure STEM types in this tumultuous period of AI (or "AI") is that they've spent a majority of their lives mulling over some problem until they've worked out every possible imperfection, and once they've achieved something they consider close to that level of perfection, that's when they say they're done.
These people are miserable to work with if you need things done quickly and can tolerate even slight imperfection.
That operating regime is, incidentally, 95% of the work we actually get paid to do.
Maybe this is just me, but I don't miss thinking so much. I personally quite like knowing how to do things and being able to work productively.
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.
I see the current generation of AI very much as a thing in between. Opus 4.5 can think and code quite well, but it cannot do these "jumps of insight" yet. It also struggles with straightforward, but technically intricate things, where you have to max out your understanding of the problem.
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.
If you are thinking hard I think you are software engineering wrong. Even before AI. As an industry all the different ways of doing things have already played out. Even doing big reactors or performance optimizations often can not be 100% predicted in their effectiveness. You will want to just go ahead and implement these things over spending more time thinking. And as AI gets stronger the just try a bunch of approaches will beat the think hard approach by an even bigger margin.
Why do anything at all then? It's all been done before. This line of thinking sounds like depression to me. Why decorate my house? I know I could do it, but it's all been done before, why bother?
Just because we know the best way to add 2 ints together that doesn't mean it's pointless to do addition with ints. We don't need people trying to spend a lot of extra time to come up with alternate ways to do it. The right function using addition may be valuable to a certain population.
The answer to this is to shift left into product/design.
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.
The sampling rate we use to take input information is fixed. And we always find a way to work with the sampled information, no matter if the input information density is high or low.
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.
I had similar thoughts recently. I wouldn't consider myself "the thinker", but I simply missed learning by failure. You almost don't fail anymore using AI. If something fails, it feels like it's not your fault but the AI messed up. Sometimes I even get angry at the AI for failing, not at myself. I don't have a solution either, but I came up with a guideline on when and how to use AI that has helped me to still enjoy learning. I'm not trying to advertise my blog and you don't need to read it, the important part is the diagram at the end of "Learning & Failure": https://sattlerjoshua.com/writing/2026-02-01-thoughts-on-ai-.... In summary, when something is important and long-term, I heavily invest into understanding and use an approach that maximizes understanding over speed. Not sure if you can translate it 100% to your situation but maybe it helps to have some kind of guideline, when to spend more time thinking instead of directly using and AI to get to the solution.
"I don't want to have to write this for the umpteenth time" -- Don't let it even reach a -teenth. Automate it on the 2nd iteration. Or even the 1st if you know you'll need it again. LLMs can help with this.
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.
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.
I'm a DevOps/SRE and I've spent the past couple weeks trying to vibecode as much of what I do as possible.
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 think there's an argument where if Claude had the knowledge map of your personal one liners and a tool for using them, it would often do the right thing in those cases. But it's definitely not as able to compress all the entropy of 'what can go wrong' operations wise as it is when composing code yet.
My experience that with careful specs, Claude or Codex can whip up either CDK, Cloudformation, or Terraform code much quicker than I can and I’ve been using IAC for 8 years - developer/consultant specializing in development + cloud architecture
Personally: technical problems I usually think for a couple days at most before I need to start implementing to make progress. But I have background things like future plans, politics, philosophy, and stories, so I always have something to think about. Close-up technical thinking is great, but sometimes step back and look at the bigger picture?
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.
Instant upvote for a Philiip Mainlander quote at the end. He's the OG "God is Dead" guy and Nietzsche was reacting (very poorly) to Mainlander and other pessimists like Schopenhauer when he followed up with his own, shittier version of "god is dead"
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.
I believe it is a type of burnout. AI might have accelerated both the work and that feeling.
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...
This is not my experience with AI at all.
The best thing that happened to me as a solo developer in a startup is Copilot in the Github mobile app.
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've loved programming my whole life. Something happens inside my brain when I'm solving a problem. I think it's a release of endorphins or something that has a calming effect. When I was younger, it came easier. I used to be able to get "into the zone" and stay there for hours. Almost a constant stream of endorphins, almost a euphoria. Other things give me a similar feeling. Anything with numbers. I used to really love playing blackjack. Something about figuring out how to get to 21 just really did it for me. Or playing dominoes or other games that require me to solve something. I'm almost 65 now and it's just much more difficult to get there. I think I've been slow to adopt AI partly because I'm afraid it's going to take me further away from what I've loved. Friends tell me it's just a new tool to add to my toolbox. I'm giving it a try but I'm still skeptical.
I definitely identify with the "Thinker" described in this post, but I am routinely mulling over ideas and problems (multiple hours, days, and weeks) with the help of LLMs now.
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.)
I've had the completely opposite experience as somebody that also likes to think more than to build: LLMs take much of the legwork of actually implementing a design, fixing trivial errors etc. away from me and let me validate theories much more quickly than I could do by myself.
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 relate to the post, but I'm not sure it's hitting the nail on the head _for me_.
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).
That's exactly it for me. Coming up with a solution using my own brainpower is a large part of the pleasure of programming for me.
A silly example to illustrate the kind of guy I am: when I'm watching a show or movie, I'll often wonder where I've seen an actor before. A "normal" person, like my wife, would just look it up on IMDB and be done with it. But I almost always insist on rifling through all the dustiest corners of my brain to figure it out. Even if it takes me a day or two of thinking about it off and on. Because to me, the satisfaction of doing it myself is worth it.
I sympathize with this. I wonder if the author might find it helpful to reimagine the thinking they do as coming up with good questions, rather than good answers. I was inspired to try to do so myself after reading this essay: https://link.springer.com/article/10.1186/s13059-019-1902-1
"[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 am thinking harder than ever due to vibe coding. How will markets shift? What will be in demand? How will the consumer side adapt? How do we position? Predicting the future is a hard problem... The thinker in me is working relentlessly since December. At least for me the thinker loves an existential crisis like no other.
There's an irony here -- the same tools that make it easy to skim and summarize can also be used to force deeper thinking. The problem isn't the tools, it's the defaults.
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.
I agree with your points. I can clearly see the difference in myself between how I used to program before and how I do now.
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 vibe coding satisfies your need to build, then you're performing a deception on yourself. I guarantee it's still possible to satisfy one's need to create in the era of AI. Just switch off the autocomplete slot machine.
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?
The use of AI is a choice. You make that choice, no one else does it for you. I myself chose to act like AI does not exist. The author, evidently, did not. So it's odd, then, that they're complaining about the consequences of their own choices.
> At the end of the day, I am a Builder. I like building things. The faster I build, the better.
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.
Cognitive skills are just like any other - use them and they will grow, do not and they will decline. Oddly enough, the more one increases their software engineering cognition, the less the distance between "The Builder" and "The Thinker" becomes.
Thinking harder than I have in a long time with AI assisted coding.
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.
Dear author,
I suggest trying out a job in a niche part of the field like firmware/embedded. Bonus if it's a company with a bunch of legacy devices to maintain. AI just hasn't quite grokked it there yet and thinking still reigns supreme :)
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?
One of the best programmers I know is a self declared thinker that also is loving this new wave of agentic coding.
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.
You don't have to miss it, buy a differential equation book and do one per day. Play chess on hard mode. I mean there's so many ways to make yourself think hard daily, this makes no sense.
It's like saying I miss running. Get out and run then.
I also recognise ‘thinking’ as a valuable and enjoyable activity - and have also obsessed about problems for days (even in my sleep)to reach a deeper understanding. But I think the issue here is the impact of AI on just that - ‘understanding’. It might be true that with AI we no longer need to have as deeper understanding in order to ‘ship’. And even if that is true I think there are plenty of other domains you can think deeply about without AI getting in the way e.g. mathematics or philosophy - where is object is often to understand in and of itself, not just the products it may generate.
Every time I try to use LLMs for coding, I completely lose touch with what it's doing, it does everything wrong and it can't seem to correct itself no matter how many times I explain. It's so frustrating just trying to get it to do the right thing.
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.
There's clearly a gap in how or for what LLM-enthusiasts and I would use LLMs. When I've tried it, I've found it just as frustrating as you describe, and it takes away the elements of programming that make it tolerable for me to do. I don't even think I have especially high standards - I can be pretty lazy for anything outside of work.
I don't view LLMs as a substitute for thinking; I view them as an aid to research and study, and as a translator from pseudocode to syntax. That is, instead of trawling through all the documentation myself and double-checking everything manually, an LLM can pop up a solution of some quality, and if that agrees with how my mental model assumes it should work, I'll accept it or improve on it. And if I know what I want to do but don't know some exact syntax, like has happened in Swift recently as I explore macOS development, an LLM can translate my implementation ideas into something that compiles.
More to the point of the article, though, LLM-enthusiasts do seem to view it as a substitute for thinking. They're not augmenting their application of knowledge with shortcuts and fast-paths; they're entirely trusting the LLM to engineer things on its own. LLMs are great at creating the impression that they are suitable for this; after all, they are trained on tons of perfectly reasonable engineering data, and start to show all the same signals that a naïve user would use to tell quality of engineering... just without the quality.
> My method was simply to think. To think hard and long... This method never failed me. I always felt that deep prolonged thinking was my superpower. I might not be as fast or naturally gifted as the top 1%, but given enough time, I was confident I could solve anything.
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.
Just yesterday I noticed I was mentally EXHAUSTED after building out a feature with Claude Code.
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.
So today are you doing it again? Or did you compress a week's worth of work into a few hours and the rest of the week is shot because you don't expand?
I did do it again, and spent time figuring out how to do it even more.
The cool thing though is that I could have chosen to do something else, too. I’m not at a loss for fulfilling, productive things to do. AI won’t change that.
Advent of Code (which given my schedule runs into January). That’s the last time thinking hard about a coding problem, I don’t remember exactly if it was day 10 or 11 that had me scratching my head for a while.
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.
This title and the first half of the post (before the AI discussion) just makes me miss the intellectual environment of college.
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.)
I think this problem existed before AI. At least in my current job, there is constant, unrelenting demand for fast results. “Multi-day deep thinking” sounds like an outrageous luxury, at least in my current job.
Even 30 years ago when I started in the industry, most jobs required very little deep thinking. All of mine has been done on personal projects. Thats just the reality of the typical software engineering job.
> I am currently writing much more, and more complicated software than ever, yet I feel I am not growing as an engineer at all.
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 don't. I miss being outside, in the sun, living my life. And if there's one thing AI has done it's save my time.
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.
A lot of productive thinking happens when asleep, in the shower, in flow walking or cycling or rowing.
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.
I really don't believe AI allows you to think less hard. If it did, it would be amazing, but the current AI hasn't got to that capability. It forces you to think about different things at best.
You're extremely on point. I don't remember the last time I was able to sit around to think because at the back of my mind, I knew AI could help me generate the initial draft of ideas, logic, or structure that would otherwise require hours of my time.
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?
I heard this interesting quote about AI (paraphrasing): "We invented a cure for exercise, we should not be surprised later when we realize that we quickly run out of breath".
While I large agree, when I rely too much on agentic llm usage I come away feeling that I haven’t really learnt much over the session, and the code wasn’t really “mine”. It’s also easy to let your skills atrophy over time if you’re not careful, and for the hardest / interesting problems I often turn the llm off entirely and write out the code by hand, and come out a lot happier than just guiding Claude
After leaving my previous day job, I have some downtime to get back to thinking and realizing how much I love reading and thinking.
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.
This isn’t the point of the piece, but I have found that the thinker often gets in the way of the builder, because there’s always a better way to build, there’s always some imperfect subsystem you just want to tear out and rewrite and then you realize you were all wrong about this and that, etc.
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
LLMs haven't changed how hard it is to truly invent. What LLMs do instead is painfully rub it in that most problems already have their solutions.
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?
What a bizarre claim. If you can solve anything by thinking, why don't you become a scientist? Think of a theory that unites quantum physics and general relativity.
you forget about fake sleeping being loaded with fake dopamine hits before sleep AND broken sleep schedules; and eating fake ultraprocessed food instead of wholefoods.
In my experience you will need to think even harder with AI if you want a decent result, although the problems you'll be thinking about will be more along the lines of "what the hell did it just write?"
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.
The friction didn't disappear with AI tools. It just shifted. It's now more so about knowing when to trust an AI system versus when to dig into things yourself. The key insight is this: don't devalue learning things on your own. AI is a tool, but if the tool messes up, you need other tools in your toolbox. If you've only ever leaned on the AI, you're in trouble the moment it fails on something subtle.
It's funny to think that all this discussion would not be happening if not for naive idealism embraced by software people fo decades, which enabled sharing everything they made after working hours for free and for everyone. That all it was hijacked by a handful of rich and not very altruistic people to enslave everyone comes as a big surprise. Who would have thought. I guess we arent that smart after all
I've found that AI still makes me think. Yes I use it as my 10x, but I still have to plan what I am going to do, call it on its bull, and keep it on track. AI just saves me from the tedium of typing (and lets be real, mistyping). I can't specialize in 13 different languages, but I can bring good architecture, and good practices to bear.
It's a different type of thinking in my opinion, more "systems" thinking.
I dont think LLMs really took away much thinking, for me they replaced searching stackexchange to find incantations. Now I can get them instantly and customized to my situation. I miss thinking hard too, but I dont blame that on AI, its more that as a dev you are paid to think the absolute minimal amount needed to solve an issue or implement a feature. I dont regret leaving academia, but being paid to think I will always miss.
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 getting back in touch with physics, reading old textbooks. But that wasn’t successful either. It is hard to justify spending time and mental effort solving physics problems that aren’t relevant or state-of-the-art
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.
I've missed the same even since before AI because I've done far too much work that's simple but time intensive. It's frustrating, and I miss problems that keep me up all night.
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.
You can't change the world, you can change yourself. Many people don't like change. So, people get frustrated when the world inevitably changes and they fail to adapt. It's called getting older. Happens to us all.
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.
While I see where you are coming from but I think what has really gone for a toss is the utility of thinking hard.
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.
Sometimes I miss thinking hard, but I also don't miss thinking really hard on a problem that seems difficult only to find out it was actually trivial and I was just looking at it the wrong way or overthinking it. We've all spent hours tracking down bugs that turned out to be silly syntax errors or spelling mistakes. It seems like that might be the trade off now.
On the other hand, those situations can be valuable learning experiences, and (even if subconscious) can help you learn to see things from more angles in the future.
Unfortunately, predicting which situations are worth it and which aren't is as hard as predicting anything else...
Listen... I'm just not going to use AI. This is a choice you can make kind of easily. I don't know why we have ten threads per day about AI angst. Just don't use it.
"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.
In reality, us thinkers will have to find other things to think about. Maybe not right now, but in the not-too-distant future we'll have to find other things that make us think and scratch that bit of our brains that need itching from learning new stuff and thinking hard about it.
It might be difficult to figure out what that is, and some folks will fail at it. It might not be code though.
Well, for programming work which is essentially repetition (e.g. making another website not unlike thousands of others), it's no surprise that AI programming can work wonders - you're essentially using a sophisticated form of copy paste.
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.
I guess it depends on what you build, i feel the most complex part of the deal, that makes me think the hardest, is to figure out what to build. Eg understanding the client, and creating a solution that fits between their needs and abilities. The rest is often a technical detail, yes sometimes you need to deep dive to optimize. Anyway if you miss debugging try debugging people;)
I miss this too, I have had those moments of reward where something works and I want to celebrate. It's missing too for me.
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.
He specifically wrote that his intellect was not in the "top 1%" of people who seemed to solve problems easily. His "1% status" was in the bullheadedness needed to pound away at a problem for days to find a solution.
The problem with the "70% solution" is that it creates a massive amount of hidden technical debt. You aren't thinking hard because you aren't forced to understand the edge cases or the real origin of the problem. It used to be the case that you will need plan 10 steps ahead because refactoring was expensive, now people just focus in the next problem ahead, but the compounding AI slop will blow up eventually.
When I wrote nimja's template inheritance.
I thought about it multiple days, until, during a train commute, it made click and I had to get out my notebook and write it, directly in the train.
Then some month later I found out, I had the same bug that jinja2 had fixed years ago. So I felt kinda like a brothers in hard thinking :)
I can relate to this. Coding satisifies my urge to build and ship and have an impact on the world. But it doesn't make me think hard. Two things which I've recently gravitated to outside of coding which make me think: blogging and playing chess.
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 think the author has discovered that coding is not what they actually enjoy.
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.
I'm not sure I agree. Actually, I don't agree. You only stop thinking hard if you decide to stop thinking hard. Nobody, no tool, is forcing you to stop thinking, pushing, reaching. If the thinking ceiling has changed, which I think it has, then it's entirely up to you to either move with it or stay still.
There are many difficult problems involved in building LLMs that I have to think about on a regular basis, which the models themselves cannot help me with. I think that just because the cognitive load has been taken off of some tasks does not mean that there is nothing that requires serious thinking anymore.
Great, so does that mean that it is time to vibe code our own alternatives of everything such as the Linux kernel because the AI is sure 'smarter' than all of us?
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.
Before I started using AI, I was already used to thinking abstractly. When I first got into AI, that way of thinking, combined with interacting with these models, really brought out the best in both. Honestly, I haven’t felt that “peak” in a while
AI doesn't remove difficulty so much as it removes friction, and friction was often what forced me into deeper conceptual understanding. When the path of least resistance is always "ask the model", my brain never has to build the scaffolding it used to
What OP wants to say is that they miss the process of thinking hard for days and weeks and one day this brilliant idea popping up on their bed before sleep. I lost my "thinking hard" process again too today at work against my pragmatism, or more precisely my job.
> the number of times I truly ponder a problem for more than a couple of hours has decreased tremendously
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
The author clearly loves coding more than the output from coding. I'm thinking harder than ever and so grateful I can finally think hard about the output I really want rather than how to resolve bugs or figure out how to install some new dependency.
Then think hard? Have a level of self discipline and don’t consistently turn to AI to solve your problems. Go to a library if you have to! People act like victims to the machine when it comes to building their thinking muscles and AI and it confuses me.
Thinking hard and fast with positive results is like a drug, ah those were good and rewarding days in my past, would jump back into that work framework any time ( that was running geological operations in an unusually agile oil exploration programme )
In my experience, the so-called 1% are mostly just thinkers and researchers who have dedicated a lot more time from an earlier age to thinking and/or researching. There are a few geniuses out there but it's 1 in millions not in hundreds.
If you miss challenge, the world has plenty more. Maybe it's not all your comfort zone, but if you try being a little ambitious and maybe use AI to understand a field you're not already deeply familiar with, you can continue to grow.
I have mixed feelings. On the one hand, I totally feel what this author is saying. On the other hand , I love that I am now able to push into areas that I could have never touched before, and complete successful projects in them.
I feel that AI doesn't necessarily replace my thinking, but actually helps to explore deeper - on my behalf - alternative considerations in the approach to solving a problem, which in turn better informs my thinking.
This is less of a lament that software engineering was replaced by AI, and more that the challenging work has been cooped by large corporations. Mainly through weaponized bloat of platforms
Exactly what I've been thinking. outsourcing tasks and thinking of problems to AI just seems easier these days; and you still get to feel in charge because you're the one still giving instructions.
Then work on hard problems in your free time. I've found myself clinging onto some fun ones after work lately, and I'm having fun building things in the weekends/evenings lately!
i have often pondered if the (sometimes facetiously, sometimes seriously) postulated AI utopia scenario of humans who don’t need to work but can devote their time to art and recreational pursuits, might be a hellscape for many industrious people.
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.
I feel like I'm doing much nicer thinking now, I'm doing more systems thinking, not only that I'm iterating on system design a lot more because it is a lot easier to change with AI
It seems like what you miss is actually a stable cognitive regime built around long uninterrupted internal simulation of a single problem. This is why people play strategy video games.
I've been writing C/C++/Java for 25 years and am trying to learn forex disciplined, risk managed forex trading, It's a whole new level of hard work/thinking.
The author's point is, If you use AI to solve the problem and after the chat gives you the solution you say “oh yes, ok, I understand it, I can do it”(and no, you can’t do it).
man, setting up worktrees for parallelized agentic coding is hard, setting up containerized worktrees is hard so you can run with dangerous permissions on without nuking host system
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!
I definitely relate to this. Except that while I was in the 1% in university who thought hard, I don't think my success rate was that high. My confidence in the time was quite high, though, and I still remember the notable successes.
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.)
Last weekend, was struggling with traversing nested trees/recursion was funny. I did eventually solve it but probably shows my tier as a dev, not FAANG tier for sure.
That's why i'm still pushing bytes on C64 demoscene (and recommend such a niche as a hobby to anyone). It's great for the sanity in modern ai-driven dev-world ;)
I always search the web, ask others, or read books in order to find a solution. When I do not find an answer from someone else, that's where I have to think hard.
The crowd that counterpoints with "just don't use it then" miss the point: The general population lacks the ability to judge when should use it and when they shouldn't. The average person will always lean towards the less effortful option, without awareness of the long term consequences.
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.
> Are we supposed to find the figurative "gym for problem solving" the same way office workers workout after work?
That's it, yeah. It sucks but it's part of the job. It makes you a better engineer.
You're absolutely right that this isn't sustainable however. In one of my earlier jobs - specifically, the one that trained me up to become the senior engineer I am now - we had "FedEx Fridays" (same day delivery, get it?). In a word, you have a single work day to work on something non-work related, with one condition: you had to have a deliverable by the end of the day. I cannot overstate how useful having something like this in place in the place of business is for junior devs. The trick is convincing tech businesses that this kind of "training" is a legitimate overhead - the kinds of businesses that are run by engineers get this intuitively. The kind that have a non-technical C-suite less so.
this also used to happened to me when I in a position that involved a lot of research earlier on and then after the product was a reality, and it worked, it tapered off to be small improvements and maintenance
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
you still can think hard but you can offload some parts to LLM when you're stuck. Then you can leave space for more hard-won inspiration. When you're faced with a high-stakes decision, evaluating all sorts of possibilities, it's really easy to maximize the utilization of your brain, so in those cases you have plenty of chance to think hard.
I think a lot of people are struggling with this. Look at the obesity epidemic. Nobody is forcing you to buy ultraprocessed foods. Nobody is forcing you to overeat. You can still cook with fresh vegetables at home. But many/most people in Western countries struggle with their weight.
An even better analogy is the slot machine. Once you've "won" one time it's hard to break the cycle. There's so little friction to just having another spin. Everyone needs to go and see the depressed people at slot machines at least once to understand where this ends.
Nobody is "forcing" but billions of dollars on the best psychologists and marketing is doing their hundred year long best to get as close as they can to it.
They (collectively) have thousands of employees, billions of dollars, and tons of things to play with (taste, texture, appearance, mouthfeel, snappiness, salt, sweet, sugar, packaging colours and styles, slogans, marketing, brand associations, shop placement, advertising) all you have is willpower to fight against 4 billion years of evolution telling you that fatty, sugary, energy dense food is important, and a whole pile of biases and weaknesses that you aren't really aware of and they are very aware of and trying to maximally take advantage of.
Do you miss thinking hard or do you missing typing? GenAI can save you from lots of typing and stack overflow copy/paste but it’s not going to think for you. Further, think as hard as you want you’re perfectly free to do so. I get the feeling a lot of people are deep down upset that knowledge and speed with code that use to be theirs and theirs alone is now much more accessible to the unwashed masses.
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)
> but the number of problems requiring deep creative solutions feels like it is diminishing rapidly.
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.
> skipping the process of creation you trade the thing you could have learned
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.
Give the AI less responsibility but more work. Immediate inference is a great example: if the AI can finish my lines, my `if` bodies, my struct instantiations, type signatures, etc., it can reduce my second-by-second work significantly while taking little of my cognitive agency.
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.
This is the way I would consider using them; I just haven't really been able to figure out what I would need to get a reasonably fast and useful local setup without spending a ton of money.
"I always felt that deep prolonged thinking was my superpower. I might not be as fast or naturally gifted as the top 1%, but given enough time, I was confident I could solve anything. I felt a deep satisfaction in that process."
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.
Maybe. But I don't have trauma that causes me to tie my self worth to physical exercise. Yet when I can get myself to actually do it, I feel better. I'm not sure deep thinking is that different.
The article is interesting. I don't know how I feel about it, though I'm both a user of AI (no choice anymore in the current job environment) and vaguely alarmed by it; I'm in the camp of those who fear for the future of our profession, and I know the counterarguments but I'm not convinced.
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 last year: I am now a mentor to a junior developer
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 think it's just another abstraction layer, and moves the thinking process from "how do I solve this problem in code?" to "how do I solve this problem in orchestration?".
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.
yes but you solved problems already solved by someone else.
how about something that hasn't been solved, or yet even noticed? that gives the greatest satisfaction
Well thinking hard is still there if you work on hard abstract problems. I keep thinking very hard, even though 4 CCs pump code while I do this. Besides, being a Gary Kasparov, playing on several tables, takes thinking.
That’s funny cause I feel the opposite: LLMs can automate, in a sloppy fashion, building the first trivial draft. But what remains is still thinking hard about the non trivial parts.
Many times, the really hard problems that I ask AI to solve, it solves it not so well, and that just makes me more frustrated. If you're building that just need to barely work, that's one thing. if you need things to work securely, scale, and be really efficient, I don't see how AI changes things. To the contrary, it might spit out test-cases and sample code to test your hypothesis with, saving you time and frustration, letting you focus on the architecture and problem solving.
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.
My favorite part of programming is thinking about the whole system before I write a single line of code. How will my data be structured? What does the UI look like? How do I structure the project? What tools do I use? What do I need to take out to make this simpler? Etc.
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.
“We now buy our bread… it comes sliced… and sure you can just go and make your sandwich and it won’t be a rustic, sourdough that you spent months cultivating. Your tomatoes will be store bought not grown heirlooms. In the end… you have lost the art of baking bread. And your sandwich making skills are lost to time… will humanity ever bake again with these mass factories of bread? What have we lost! Woe is me. Woe is me.”
That is a very good analogy - sliced shop bread is tasteless and not that good for you compared to sourdough. Likewise awful store bought tomatoes taste like nothing compared to heirloom tomatoes and arguably have different nutritional content.
Shop bread and tomatoes though can be manufactured without any thought of who makes them, though they can be reliably manufactured without someone guiding an LLM which is perhaps where the analogy falls down, and we always want them to be the same, but software is different in every form.
I 100% agree. Though i would argue that, like trash sliced bread, 99% of software is just CRUD reinvented over and over. Which, like a deli sandwich, is probably fine not to have artisanal bread for.
Man, this resonates SO MUCH with me. I have always loved being confronted with a truly difficult problem. And I always had that (obviously misguided, but utterly motivating) feeling that, with enough effort, no problem could ever resist me. That it was just a matter of grinding a bit further, a bit longer.
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.
Dude, I know you touched on this but seriously. Just don't use AI then. It's not hard, it's your choice to use it or not. It's not even making you faster, so the pragmatism argument doesn't really work well! This is a totally self inflicted problem that you can undo any time you want.
I have a Claude code set up in a folder with instructions on how to access iMessage. Ask it questions like “What did my wife say I should do next Friday?”
Reads the SQLite db and shit. So burn your tokens on that.
That sucks, but honestly I’d get out of there as fast as possible. Life is too short to live under unfulfilling work conditions for any extended amount of time.
It's not hard to burn tokens on random bullshit (see moltbook). If you really can deliver results at full speed without AI, it shouldn't be hard to keep cover.
I get it and somehow also agree with the division (thinker/builder) but I feel this is only the representation of a new society where less humans are necessary to think deeply.
No offense here, it's just my own unsatisfacted brain trying to adapt to a whole new era.
I mean I spent most of my career been being pressured to move from type 3 to any one of the other 2 so I don't blame AI for this (it doesn't help, though, especially if you delegate to much to it).
The closing quotation from Philipp Mainländer introduces a serious conceptual mismatch with the argument it is meant to reinforce.
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.
"Before you read this post, ask yourself a question: When was the last time you truly thought hard?
...
a) All the time. b) Never. c) Somewhere in between."
author obviously isn't wrong. it's easy to fall into this trap. and it does take willpower to get out of it. and the AI (christ i'm going to sound like they paid me) can actually be a tool to get there.
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 am one of those junior software developers who always struggled with starting their own projects. Long story short, I realized that my struggle stems from my lack of training in open-ended problems, where there are many ways to go about solving something, and while some ways are better than others, there's no clear cut answer because the tradeoffs may not be relevant with the end goal.
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.
This is just the kind of thing that Dr David Burns' work on TEAM-CBT therapy deals with.
> "Long story short, I realized that my struggle stems from my lack of training"
you say, and then you explain exactly where your struggle is, and it's not lack of training:
> "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"
There you are. It's that fear. Fear comes from your brain modeling the world and predicting the future, and predicting a bad future and generating fear (or anxiety, or other bad feelings) to change your behaviour and avoid that future. So find why "doing something wrong" is making you predict a bad future, what bad future, and then find a way to fix that where you can be wrong but it isn't the end of your world, and then this fear and urge won't appear anymore.
1) one of those things like "finding out I've done something wrong" happens, or you imagine it happening.
2) you imagine some kind of negative future event that follows on from doing something wrong, this is a habit of thinking that you learned so it might be fast, almost sub-conscious, flicker of ideas and thoughts.
3) from those, your brain generates bad feelings (feelings are a high level sweeping way to change our behaviour without thinking about tons of details).
4) you get the urge to push it away and close the game, so you can avoid those future events happening, so that can save you from future badness, bad feelings calm down (but different ones may appear like guilt, shame, inadequacy, etc).
5) you don't consciously notice this happening, so you make up some other reason that sounds nice and plausible and doesn't involve changing anything ("lack of training").
6) repeat this mental habit for a long time, maybe the rest of your life.
> "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."
That's not where your problem is, you aren't lacking the ability to evaluate a trade-off, you're lacking the ability to go wrong. Being able to evaluate any situation so you never ever go wrong isn't possible, that can't be the answer. The only answer can be from becoming okay with going wrong [I hope you will feel an automatic rejection here, how can it possibly be OK to be wrong and screw something up? I don't want to be OK with going wrong! See?].
Step one of a fix is to focus your attention on "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" and push into that. Remember or find a specific example of that which makes the feeling come up - what task were going wrong brings up that feeling - write it down.
Step two, look at your thoughts at that moment, what are you telling yourself will happen next that is so automatic and habitual and reflex and fast that you can barely notice it happening, but is basically the horrible future you're always worrying about? [If it helps, imagine a cartoon character who is just like you, in that "oh no I screwed up" situation with a thought bubble above their head, and write in what they are thinking which is oh so very relatable to you].
It will be some typical human thing like "it will prove I'm not smart and my fiance or parents won't love me" or "I will become unemployed and homeless and get sick on the streets and die" or "it will prove my lifelong fear that I don't deserve respect and am inferior to everyone else" but the details will be unique to you and what you fear and worry about.
And the next Dr Burns specific step is that you need to see why you are holding onto that pattern of thought, it's not just stopping you from making progress in projects, it's got some silver lining that is protecting and upholding some other ideals you value, and you don't want to let this pattern change and let go of the fear if it means losing something else equally or more valuable (e.g. "if I don't fear becoming homeless then I won't push myself to work harder and will waste my life as a drifter", or what I said earlier "I don't want to be okay with going wrong, people who screw things up and don't care are LOSERS who make everything worse!", again, the details will be specific to you).
And then to do some therapy techniques to work out how to unpick all this, and change it, in a way that keeps the ideals you want, and releases the sticking points you don't want.
> "I cannot imagine how someone would claim that removing an exercise from my daily gym visit will not result in weaker muscles."
If you do weighted abs exercises first, then you can't do good squats because your abs hurt, removing the abs work might be an overall gain. If you do too much everyday so you can't recover properly in one night of rest, removing some more intense work might be an overall gain. If you try to do too many exercises in a rush so you can't do a good job on any of them, removing one so you can do fewer, better quality, might be an overall gain. If you hate one exercise and it puts you in a bad mood and every month or two you get a minor injury from it that knocks your progress back, removing it might be a mood boost and an overall gain. If you remove a small targetted exercise and replace it with a larger compound exercise, it might be an overall gain.
I literally just went through this yesterday. Had a few failing tests in an unfamiliar domain. Took a cursory look, couldn't figure it out. Pasted the error messages into Claude to see if it could speed things up for me. We went back and forth for a while, pulling on different threads and trying various things. In the end, it gave up and essentially relaxed the test's assertions to make it pass.
I wasn't happy with that outcome, so I decided to invest some time in debugging through the test, tracing the flow of data, looking at the state of the stack frames and finally figured out what was wrong -- the solution was so simple and so obvious that had I just given the effort up front, it would have saved me some time and tokens.
It's a valuable lesson to take to heart. I think it's better to go from tinkering and trying it out yourself, than to go straight to AI and then giving it a go independently.
That reminds me of why I don't think that if err != nil in Go is actually a problem, because while it's annoying to have to pause each time an error can happen, it's actually very useful, because it forces you to consider all the possible failure states and it often lets you discover the flaws in your original design while you're typing in the code. This eventually leads to much better outcomes and allows for the tools I write to be much more resilient than they otherwise would.
Obviously it all goes out of the window as soon as AI coding comes into question, and that's why I learned that I actually _don't_ want AI to generate code for me. I would only ask it simple questions like "how do I do X in Go" or in some other system, but the implementation I do myself, otherwise I lose this "having to consider every error path" part, which is apparently very helpful when your goal is to write resilient software
I’ve given these sorts of haystack search struggles completely over to the LLM. Whether it’s finding a bug in code or searching documentation for the answer, I view it as a near-obsolete skill. The past couple of decades it was important to know how to chase down documentation and zero in on the one line of config you were missing. Now it’s not.
I don’t view this as a hollowing out of my skill tree, I view it as freeing myself to focus on modern skills I need to develop. Such as learning how to steer LLM context windows towards maintainable solutions in large codebases.
I’m sure I’ll be thankful now and then that I know how to manually sift through stack traces for answers. But I expect those moments to be rarer and rarer. I basically never look at machine code, but I bet that used to be an important skill for programmers many decades ago.
I refer to it as "Think for me SaaS", and it should be avoided like the plague. Literally, it will give your brain a disease we haven't even named yet.
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!?)
I'm with you. It scares me how quickly some of my peers' critical thinking and architectural understanding have noticeably atrophied over the last year and a half.
Pre-processed food consumer complains about not cooking anymore. /s
... 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.
> It (Software Engineering) satisfied The Builder (feeling productive and pragmatic by creating useful things) and The Thinker (solving really hard problems).
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. ;)
I feel tired working with AI much faster than I did when I used to code, dunno if it's just that I don't really need to think much at all other than keep in mind the broad plan and have an eye out if a red flag of the wrong direction shows in the transcript, don't even bother reading the code anymore since Opus 4.5 I haven't felt the need to.
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.
Something that people underestimate a lot is that we aren’t “brains in a jar” and the elevated states of consciousness, such as “flow”, require a deep involvement of the body. As such manual coding is much more likely to bring you into the zone than irregular interactions with an LLM.
I actually believe that there are much better ways to incorporate AI into software development than any of the mechanisms we’ve seen so far. For instance, it would make a lot more sense that you actually write the software manually and get the usual autocomplete suggestions, along with some on the fly reviews, an extension proposals, such as writing the body of a function that you’re calling from the core function you’re writing now.
This March 2025 post from Aral Balkan stuck with me:
https://mastodon.ar.al/@aral/114160190826192080
"Coding is like taking a lump of clay and slowly working it into the thing you want it to become. It is this process, and your intimacy with the medium and the materials you’re shaping, that teaches you about what you’re making – its qualities, tolerances, and limits – even as you make it. You know the least about what you’re making the moment before you actually start making it. That’s when you think you know what you want to make. The process, which is an iterative one, is what leads you towards understanding what you actually want to make, whether you were aware of it or not at the beginning. Design is not merely about solving problems; it’s about discovering what the right problem to solve is and then solving it. Too often we fail not because we didn’t solve a problem well but because we solved the wrong problem.
When you skip the process of creation you trade the thing you could have learned to make for the simulacrum of the thing you thought you wanted to make. Being handed a baked and glazed artefact that approximates what you thought you wanted to make removes the very human element of discovery and learning that’s at the heart of any authentic practice of creation. Where you know everything about the thing you shaped into being from when it was just a lump of clay, you know nothing about the image of the thing you received for your penny from the vending machine."
And when programming with agentic tools, you need to actively push for the idea to not regress to the most obvious/average version. The amount of effort you need to expend on pushing the idea that deviates from the 'norm' (because it's novel), is actually comparable to the effort it takes to type something out by hand. Just two completely different types of effort.
There's an upside to this sort of effort too, though. You actually need to make it crystal clear what your idea is and what it is not, because of the continuous pushback from the agentic programming tool. The moment you stop pushing back, is the moment the LLM rolls over your project and more than likely destroys what was unique about your thing in the first place.
You just described the burden of outsourcing programming.
45 replies →
Fair enough but I am a programmer because I like programming. If I wanted to be a product manager I could have made that transition with or without LLMs.
20 replies →
I can't help but imagine training horses vs training cats. One of them is rewarding, a pleasure, beautiful to see, the other is frustrating, leaves you with a lot of scratches and ultimately both of you "agreeing" on a marginal compromise.
6 replies →
This is why people thinkless of artists like Damien Hirst and Jeff Koons because their hands have never once touched the art. They have no connection to the effort. To the process. To the trail and error. To the suffer. They’ve out sourced it, monetized it, and make it as efficient as possible. It’s also soulless.
> need to make it crystal clear
That's not an upside in that it's unique to LLM vs human written code. When writing it yourself, you also need to make it crystal clear. You do that in the language of implementation.
2 replies →
To me it feels a bit like literate programming, it forces you to form a much more accurate idea of your project before your start. Not a bad thing, but can be wasteful also when eventually you realise after the fact that the idea was actually not that good :)
1 reply →
Uniqueness is not the aim. Who cares if something is uniquely bad? But in any case, yes, if you use LLMs uncritically, as a substitute for reasoning, then you obviously aren't doing any reasoning and your brain will atrophy.
But it is also true that most programming tedious and hardly enriching for the mind. In those cases, LLMs can be a benefit. When you have identified the pattern or principle behind a tedious change, an LLM can work like a junior assistant, allowing you to focus on the essentials. You still need to issue detailed and clear instructions, you still need to verify the work.
Of course, the utility of LLMs is a signal that either the industry is bad at abstracting, or that there's some practical limit.
I think harder while using agents, just not about the same things. Just because we all got a super powers doesn't make the problems go away, they just move and we still have our full brains to solve them.
It isn't all great, skills that feel important have already started atrophying, but other skills have been strengthened. The hardest part is in being able to pace onself as well as figuring out how to start cracking certain problems.
Yet another example of "comments that are only sort of true because high temperature sampling isn't allowed".
If you use LLMs at very high temperature with samplers which correctly keep your writing coherent (i.e. Min_p, or better like top-h, P-less decoding, etc), than "regression to the mean" literally DOES NOT HAPPEN!!!!
12 replies →
To me it's all abstraction. I didn't write my own OS. I didn't write my own compiler. I didn't write the standard library. I just use them. I could write them but I'm happy to work on the new thing that uses what's already there.
This is no different than many things. I could grow a tree and cut it into wood but I don't. I could buy wood and nails and brackets and make furniture but I don't. I instead just fill my house/apartment with stuff already made and still feel like it's mine. I made it. I decided what's in it. I didn't have to make it all from scratch.
For me, lots of programming is the same. I just want to assemble the pieces
> When you skip the process of creation you trade the thing you could have learned to make for the simulacrum of the thing you thought you wanted to make
No, your favorite movie is not crap because the creators didn't grind their own lens. Popular and highly acclaimed games not at crap because they didn't write their own physics engine (Zelda uses Havok) or their own game engine (Plenty of great games use Unreal or Unity)
When I read discussions about this sort of thing, I often find that folks look harder for similarities and patterns but once they succeed here, they ignore the differences. AI in particular is so full of this "pattern matching" style of thinking that the really significance of this tech, ie., how absolutely new and different it is, yeah it just sort of goes ignored, or even worse, machines get "pattern matched" into humans and folks argue from that point of view lol witness all the "new musicians" who vibe code disco hits, I'll invariably see the argument that AIs train on existing music just like humans do so whats the big deal?
But these arguments and the OP's article do reinforce that AI rots brains. Even my sparing use of googles gemini and my interaction with the bots here have really dinged my ability to do simple math.
There are two stages to becoming a decent programmer: first you learn to use abstraction, then you learn when not to use abstraction.
Trying to find the right level is the art. Once you learn the tools of the trade and can do abstraction, it's natural to want to abstract everything. Most programmers go through such a phase. But sometimes things really are distinct and trying to find an abstraction that does both will never be satisfactory.
When building a house there are generally a few distinct trades that do the work: bricklayers, joiners, plumbers, electricians etc. You could try to abstract them all: it's all just joining stuff together isn't it? But something would be lost. The dangers of working with electricity are completely different to working with bricks. On the other hand, if people were too specialised it wouldn't work either. You wouldn't expect a whole gang of electricians, one who can only do lighting, one who can only do sockets, one who can only do wiring etc. After centuries of experience we've found a few trades that work well together.
So, yes, it's all just abstraction, but you can go too far.
3 replies →
OS and compilers have a deterministic public interface. They obey a specification developers know, so you they can be relied on to write correct software that depends on them even without knowing the internal behavior. Generative AI does not have those properties.
10 replies →
> I didn't write my own OS. I didn't write my own compiler. I didn't write the standard library. I just use them. I could write them
Maybe, but beware assuming you could do something you haven't actually tried to do.
Everything is easy in the abstract.
1 reply →
> No, your favorite movie is not crap because the creators didn't grind their own lens.
But Pulp Fiction would not have been a masterpiece if Tarantino just typed “Write a gangster movie.” into a prompt field.
9 replies →
The creative process is not dependent on the abstraction.
> For me, lots of programming is the same. I just want to assemble the pieces
How did those pieces came to be? By someone assembling other pieces or by someone crafting them together out of nowhere because nobody else had written them by the time?
Of course you reuse other parts and abstractions to do whatever things that you're not working on but each time you do something that hasn't been done before you can't but engage the creative process, even if you're sitting on top of 50 years worth of abstractions.
In other words, what a programmer essentially has is a playfield. And whether the playfield is a stack of transistors or coding agents, when you program you create something new even if it's defined and built in terms of the playfield.
>I instead just fill my house/apartment with stuff already made and still feel like it's mine.
I'm starting to wonder if we lose something in all this convenience. Perhaps my life is better because I cook my own food, wash my own dishes, chop my own firewood, drive my own car, write my own software. Outwardly the results look better the more I outsource but inwardly I'm not so sure.
On the subject of furnishing your house the IKEA effect seems to confirm this.
https://en.wikipedia.org/wiki/IKEA_effect
I really appreciate this sentiment. It feels absolutely overwhelming the pace at which new tools and AI protocols are being released, leaving a feeling of constantly falling behind. But approaching from the other end, I can just make things that I do come up with and explore the new protocols only if I can't do the thing with what I've already grasped.
> No, your favorite movie is not crap because the creators didn't grind their own lens.
One of the reasons Barry Lyndon is over 50 years old and still looks like no other movie today is because Kubrick tracked down a few lenses originally designed for NASA and had custom mounts built for them to use with cinema cameras.
https://neiloseman.com/barry-lyndon-the-full-story-of-the-fa...
> Popular and highly acclaimed games not at crap because they didn't write their own physics engine (Zelda uses Havok)
Super Mario Bros is known for having a surprisingly subtle and complex physics system that enabled the game to feel both challenging and fair even for players very new to consoles. Celeste a newer game also famous for being very difficult yet not feeling punishing does something similar:
https://maddymakesgames.com/articles/celeste_and_towerfall_p...
> or their own game engine (Plenty of great games use Unreal or Unity)
And Minecraft doesn't, which is why few other games at the time of its release felt and played like it.
You're correct that no one builds everything from scratch all the time. However, if all you ever do is cobble a few pre-made things together, I think you'll discover that nothing you make is ever that interesting or enduring in value. Sure, it can be useful, and satisfying. But the kinds of things that really leave a mark on people, that affect them deeply, always have at least some aspect where the creator got obsessive and went off the deep end and did their own thing from scratch.
Further, you'll never learn what a transformative experience it can be to be that creator who gets obsessive about a thing. You'll miss out on discovering the weird parts of your own soul that are more fascinated by some corner of the universe than anyone else is.
I have a lot of regrets in my life, but I don't regret the various times I've decided I've deeply dug into some thing and doing it from scratch. Often, that has turned out later to be some of the most long-term useful things I've done even though it seemed like a selfish indulgence at the time.
Of course, it's your life. But consider that there may be a hidden cost to always skimming along across the tops of the stacks of things that already exist out there. There is growth in the depths.
1 reply →
Did you not read the post? You're talking from the space of the Builder while neglecting the Thinker. That's fine for some people, but not for others.
In 30 years across 10 jobs, the companies I’ve worked for have not paid me to “code”. They’ve paid me to use my experience to add more business value than the total cost of employing me.
I’m no less proud of what I built in the last three weeks using three terminal sessions - one with codex, one with Claude, and one testing everything from carefully designed specs - than I was when I first booted a computer, did “call -151” to get to the assembly language prompt on my Apple //e in 1986.
The goal then was to see my ideas come to life. The goal now is to keep my customers happy, get projects done on time, on budget and meets requirements and continue to have my employer put cash in my account twice a month - and formerly put AMZN stock in my brokerage account at vesting.
But you can move a layer up.
Instead of pouring all of your efforts into making one single static object with no moving parts, you can simply specify the individual parts, have the machine make them for you, and pour your heart and soul into making a machine that is composed of thousands of parts, that you could never hope to make if you had to craft each one by hand from clay.
We used to have a way to do this before LLMs, of course: we had companies that employed many people, so that the top level of the company could simply specify what they wanted, and the lower levels only had to focus on making individual parts.
Even the person making an object from clay is (probably) not refining his own clay or making his own oven.
> we had companies that employed many people, so that the top level of the company could simply specify what they wanted, and the lower levels only had to focus on making individual parts.
I think this makes a perfect counter-example. Because this structure is an important reason for YC to exist and what the HN crowd often rallies against.
Such large companies - generally - don't make good products. Large companies rarely make good products in this way. Most, today, just buy companies that built something in the GP's cited vein: a creative process, with pivots, learnings, more pivots, failures or - when successful - most often successful in an entirely different form or area than originally envisioned. Even the large tech monopolies of today originated like that. Zuckerberg never envisioned VR worlds, photo-sharing apps, or chat apps, when he started the campus-fotobook-website. Bezos did not have some 5d-chess blueprint that included the largest internet-infrastructure-for-hire when he started selling books online.
If anything, this only strengthens the point you are arguing against: a business that operates by a "head" "specifying what they want" and having "something" figure out how to build the parts, is historically a very bad and inefficient way to build things.
It's more like the chess.com vs lichess example in my mind. On the one hand you have a big org, dozens of devs, on the other you have one guy doing a better job.
It's amazing what one competent developer can do, and it's amazing how little a hundred devs end up actually doing when weighed down by beaurocracy. And lets not pretend even half of them qualify as competent, not to mention they probably don't care either. They get to work and have a 45 min coffee break, move some stuff around in the Kanban board, have another coffee break, then lunch, then foosball etc. Ad when they actually write some code it's ass.
And sure, for those guys maybe LLMs represent a huge productivity boost. For me it's usually faster to do the work myself than to coax the bot into creating something acceptable.
1 reply →
And therein lies the crux: some people love to craft each part themselves, whereas others love to orchestrate but not manufacture each part.
With LLMs and engineers often being forced by management to use them, everyone is pushed to become like the second group, even though it goes against their nature. The former group see the part as a means, whereas the latter view it as the end.
Some people love the craft itself and that is either taken away or hollowed out.
This is really what it’s about.
As someone that started with Machine Code, I'm grateful for compiled -even interpreted- languages. I can’t imagine doing the kind of work that I do, nowadays, in Machine Code.
I’m finding it quite interesting, using LLM-assisted development. I still need to keep an eye on things (for example, the LLM tends to suggest crazy complex solutions, like writing an entire control from scratch, when a simple subclass, and five lines of code, will work much better), but it’s actually been a great boon.
I find that I learn a lot, using an LLM, and I love to learn.
9 replies →
Yes, but bad ingredients do not make a yummy pudding.
Or, it's like trying to make a MacBook Pro by buying electronics boards from AliExpress and wiring them together.
9 replies →
I personally have found success with an approach that's the inverse of how agents are being used generally.
I don't allow my agent to write any code. I ask it for guidance on algorithms, and to supply the domain knowledge that I might be missing. When using it for game dev for example, I ask it to explain in general terms how to apply noise algorithms for procedural generation, how to do UV mapping etc, but the actual implementation in my language of choice is all by hand.
Honestly, I think this is a sweet spot. The amount of time I save getting explanations of concepts that would otherwise get a bit of digging to get is huge, but I'm still entirely in control of my codebase.
Yep, this is the sweet spot. Though I still let it type code a lot - boilerplate stuff I’d be bored out of my mind typing. And I’ve found it has an extremely high success rate typing that code on top of its very easy for me to review that code. No friction at all. Granted this is often no larger than 100 lines or so (across various files).
If it takes you more than a few seconds or so to understand code an agent generated you’re going to make mistakes. You should know exactly what it’s going to produce before it produces it.
Supposedly when Michelangelo was asked about how he created the statue of David, he said "I just chipped away everything that wasn’t David.”
Your work is influenced by the medium by which you work. I used to be able to tell very quickly if a website was developed in Ruby on Rails, because some approaches to solve a problem are easy and some contain dragons.
If you are coding in clay, the problem is getting turned into a problem solvable in clay.
The challenge if you are directing others (people or agents) to do the work is that you don't know if they are taking into account the properties of the clay. That may be the difference between clean code - and something which barely works and is unmaintainable.
I'd say in both cases of delegation, you are responsible for making sure the work is done correctly. And, in both cases, if you do not have personal experiences in the medium you may not be prepared to judge the work.
This is an amazing quote - thank you. This is also my argument for why I can't use LLMs for writing (proofreading is OK) - what I write is not produced as a side-effect of thinking through a problem, writing is how I think through a problem.
Counterpoint (more devil's advocate), I'd argue it's better than an LLM writes something (e.g. the solution or thinking through of a problem) than nothing at all.
Counterpoint to my own counterpoint, will anyone actually (want to) read it?
counterpoint to the third degree, to loop it back around, an LLM might and I'd even argue an LLM is better at reading and ingesting long text (I'm thinking architectural documentation etc) than humans are. Speaking for myself, I struggle to read attentively through e.g. a document, I quickly lose interest and scan read or just focus on what I need instead.
3 replies →
Writing is how I think through a problem too, but that also applies to writing and communicating with an AI coding agent. I don't need to write the code per se to do the thinking.
1 reply →
Coding is not at all like working a lump of clay unless you’re still writing assembly.
You’re taking a bunch of pre-built abstractions written by other people on top of what the computer is actually doing and plugging them together like LEGOs. The artificial syntax that you use to move the bricks around is the thing you call coding.
The human element of discovery is still there if a robot stacks the bricks based on a different set of syntax (Natural Language), nothing about that precludes authenticity or the human element of creation.
It depends what you're doing not really what you do it with.
I can do some crud apps where it's just data input to data store to output with little shaping needed. Or I can do apps where there's lots of filters, actions and logic to happen based on what's inputted that require some thought to ensure actually solve the problem it's proposed for.
"Shaping the clay" isn't about the clay, it's about the shaping. If you have to make a ball of clay and also have to make a bridge of Lego a 175kg human can stand on, you'll learn more about Lego and building it than you will about clay.
Get someone to give you a Lego instruction sheet and you'll learn far less, because you're not shaping anymore.
> You’re taking a bunch of pre-built abstractions written by other people on top of what the computer is actually doing and plugging them together like LEGOs.
Correct. However, you will probably notice that your solution to the problem doesn't feel right, when the bricks that are available to you, don't compose well. The AI will just happily smash together bricks and at first glance it might seem that the task is done.
Choosing the right abstraction (bricks) is part of finding the right solution. And understanding that choice often requires exploration and contemplation. AI can't give you that.
4 replies →
Exactly, and that's why I find AI coding solving this well, because I find it tedious to put the bricks together for the umpteenth time when I can just have an AI do it (which I will of course verify the code when it's done, not advocating for vibe coding here).
This actually leaves me with a lot more time to think, about what I want the UI to look like, how I'll market my software, and so on.
> Coding is not at all like working a lump of clay unless you’re still writing assembly.
Isn't the analogy apt? You can't make a working car using a lump of clay, just a car statue, a lump of clay is already an abstraction of objects you can make in reality.
1 reply →
I think the analogy to high level programming languages misunderstands the value of abstraction and notation. You can’t reason about the behavior of an English prompt because English is underspecified. The value of code is that it has a fairly strong semantic correlation to machine operations, and reasoning about high level code is equivalent to reasoning about machine code. That’s why even with all this advancement we continue to check in code to our repositories and leave the sloppy English in our chat history.
3 replies →
Lego boxes include a set of instructions that implies there's only one way to assemble the contents, but that's sometimes an injustice to the creative space that Legos are built to provide. There can be a joy in algorithmically building the thing some other designers worked to make look nice, but there's a creative space outside the instructions, too.
The risk of LLMs laying more of these bricks isn't just loss of authenticity and less human elements of discovery and creation, it's further down the path of "there's only one instruction manual in the Lego box, and that's all the robots know and build for you". It's an increased commodification of a few legacy designers' worth of work over a larger creative space than at first seems apparent.
You’re both right. It just depends on the problems you’re solving and the languages you use.
I find languages like JavaScript promote the idea that of “Lego programming” because you’re encouraged to use a module for everything.
But when you start exploring ideas that haven’t been thoroughly explored already, and particularly in systems languages which are less zealous about DRY (don’t repeat yourself) methodologies, the you can feel a lot more like a sculptor.
Likewise if you’re building frameworks rather than reusing them.
So it really depends on the problems you’re solving.
For general day-to-day coding for your average 9-to-5 software engineering job, I can definitely relate to why people might think coding is basically “LEGO engineering”.
changing "clay" for "legos" doesn't change the core argument. The tactile feel you get for the medium as you work it with your hands and the "artificial syntax" imposed by the medium.
> plugging them together like LEGOs
Aren't Legos known for their ability to enable creativity and endless possibilities? It doesn't feel that different from the clay analogy, except a bit coarser grained.
For me it’s a related but different worry. If I’m no longer thinking deeply, then maybe my thinking skills will simply atrophy and die. Then when I really need it, I won’t have it. I’ll be reduced to yanking the lever on the AI slot machine, hoping it comes up with something that’s good enough.
But at that point, will I even have the ability to distinguish a good solution from a bad one? How would I know, if I’ve been relying on AI to evaluate if ideas are good or not? I’d just be pushing mediocre solutions off as my own, without even realising that they’re mediocre.
While there is still a market for artisanal furniture, dishes and clothes most people buy mass-produced dishes, clothes and furniture.
I wonder if software creation will be in a similar place. There still might be a small market for handmade software but the majority of it will be mass produced. (That is, by LLM or even software itself will mostly go away and people will get their work done via LLM instead of "apps")
As with furniture, it's supply vs demand, and it's a discussion that goes back decades at this point.
Very few people (even before LLM coding tools) actually did low level "artisanal" coding; I'd argue the vast majority of software development goes into implementing features in b2b / b2c software, building screens, logins, overviews, detail pages, etc. That requires (required?) software engineers too, and skill / experience / etc, but it was more assembling existing parts and connecting them.
Years ago there was already a feeling that a lot of software development boiled down to taping libraries together.
Or from another perspective, replace "LLM" with "outsourcing".
Acceptance of mass production is only post establishment of quality control.
Skipping over that step results in a world of knock offs and product failures.
People buy Zara or H&M because they can offload the work of verifying quality to the brand.
This was a major hurdle that mass manufacturing had to overcome to achieve dominance.
1 reply →
I would argue the opposite..
What you get right now is mass replicated software, just another copy of sap/office/Spotify/whatever
That software is not made individually for you, you get a copy like millions of other people and there is nearly no market anymore for individual software.
Llms might change that, we have a bunch of internal apps now for small annoying things..
They all have there quirks, but are only accessible internally and make life a little bit easier for people working for us.
Most of them are one shot llms things, throw away if you do not need it anymore or just one shoot again
2 replies →
> Being handed a baked and glazed artefact that approximates what you thought you wanted to make
Isn't this also an overstatement, and the problem is worse. That is - the code being handed back is a great prototype, needs polishing/finishing, and is ignorant of obvious implicit edge cases unless you explicitly innumerate all of them in your prompts??
For me, the state of things reminds me of a bad job I had years ago.
Worked with a well-regarded long tenured but truculent senior engineer who was immune to feedback due to his seniority. He committed code that either didn't run, didn't past tests, or implemented only the most obvious happy path robotically literal interpretation of requirements.
He was however, very very fast... underbidding teammates on time estimates by 10x.
He would hand back the broken prototype and we'd then spend the 10x time making his code actually something you can run in production.
Management kept pushing this because he had a great reputation, promised great things, and every once in a while did actually deliver stuff fast. It took years for management to come around to the fact that this was not working.
This makes no sense to me. There are plenty of artists out there (e.g. El Anatsui), not to mention whole professions such as architects, who do not interact directly with what they are building, and yet can have profound relationship with the final product.
Discovering the right problem to solve is not necessarily coupled to being "hands on" with the "materials you're shaping".
In my company, [enterprise IT] architects are separated into two kinds. People with a CV longer than my arm who know/anticipate everything that could fail and have reached a level of understandind that I personnally call "wisdom". And theorists, who read books and norms, who focus mostly on the nominal case, and have no idea [and no interest] in how the real world will be a hard brick wall that challenges each and every idea you invent.
Not being hands-on, and more important not LISTENING to the hands-on people and learning from them, is a massive issue in my surroundings.
So thinking hard on something is cool. But making it real is a whole different story.
Note: as Steve used to say, "real artists ship".
you think El Anatsui would concur that they didn't interact directly with what they were building? "hands on", "material you're shaping" is a metaphor
3 replies →
I relate to this. But also, isn't it just that every human endeavor goes through an evolution from craft to commodity, which is sad for the craftsmen but good for everyone else, and that we happen to be the ones living through that for software?
For instance, I think about the pervasive interstate overpass bridge. There was a time long ago when building bridges was a craft. But now I see like ten of these bridges every day, each of which is better - in the sense of how much load they can support and durability and reliability - than the best that those craftsmen of yore could make.
This doesn't mean I'm in any way immune to nostalgia. But I try to keep perspective, that things can be both sad and ultimately good.
there is a presumption that the models we are using today are 'good enough'. by models I mean thinks like linkers and package managers, micro services and cluster management tools.
I personally think that we're not done evolving really, and to call it quits today would leave alot of efficiency and productivity on the table
If you're only building things that have been built before, then sure, though I'd argue we already had solutions for that before LLMs.
>> Coding is like
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.
It's all individual. That's like saying writing only happens when you know exactly the story to tell. I love open a blank project with a vague idea of what I want to do, and then just start exploring while I'm coding.
1 reply →
Having a background in fine art (and also knew Aral many years ago!), this prose resonates heavily with me.
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.
This is cute, but this is true for ALL activities in life. I have to constantly remind my brother that his job is not unique and if he took a few moments, he might realize, flipping burgers is also molding lumps of clay.
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.
"The muse visits during the act of creation, not before. Start alone."
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.
I get what he's pointing at: building teaches you things the spec can't, and iteration often reveals the real problem.
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).
> That said, the framing feels a bit too poetic for engineering.
I wholeheartedly disagree but I tend to believe that's going to be highly dependent on what type of developer a person is. One who leans towards the craftsmanship side or one who leans towards the deliverables side. It will also be impacted by the type of development they are exposed to. Are they in an environment where they can even have a "lump of clay" moment or is all their time spent on systems that are too old/archaic/complex/whatever to ever really absorb the essence of the problem the code is addressing?
The OP's quote is exactly how I feel about software. I often don't know exactly what I'm going to build. I start with a general idea and it morphs towards excellence by the iteration. My idea changes, and is sharpened, as it repeatedly runs into reality. And by that I mean, it's sharpened as I write and refactor the code.
I personally don't have the same ability to do that with code review because the amount of time I spend reviewing/absorbing the solution isn't sufficient to really get to know the problem space or the code.
It's very similar now, you have to surf a swell of selective ignorance that is (feels?) less reliable than the ignorance that one adopts when using a dependency one hasn't read and understood the source code for.
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 an artistic vase that captures some essential element of beauty, culture, or emotion.
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.
> Sometimes you want a utilitarian teapot to reliably pour a cup of tea.
If you pardon the analogy, watch how Japanese make a utilitarian teapot which reliably pours a cup of tea.
It's more complicated and skill-intensive than it looks.
In both realms, making an artistic vase can be simpler than a simple utilitarian tool.
AI is good at making (poor quality, arguably) artistic vases via its stochastic output, not highly refined, reliable tools. Tolerances on these are tighter.
1 reply →
The best analogy I think is, if you just take Stack Overflow code solutions, smoosh over your code and hit compile / build, and move on without ever looking at "why it works" you're really not using your skills to the best of your ability, and it could introduce bugs you didn't expect, or completely unnecessary dependencies. With Stack Overflow you can have other people pointing out the issues with the accepted answer and giving you better options.
This keeps coming up again and again and again, but like how many times were you able to copy paste SO solution wholesale and just have it work? Other than for THE most simple cases (usually CSS) there would always have to be some understanding involved. Of course you don't always learn deeply every time, but the whole "copy paste off of stackoverflow" was always an exaggeration that is being used in seeming earnest.
"... software is not a product, but rather a medium for the storage of knowledge"
Phillip G. Armour The Five Orders of Ignorance https://www.researchgate.net/publication/27293624_The_Five_O...
I have no idea who this guy is (I guess he's a fantasy novelist?) but this video came up in my YouTube feed recently and feels like it matches closely with the themes you're expressing. https://youtu.be/mb3uK-_QkOo?si=FK9YnawwxHLdfATv
This is very insightful, thanks. I had a similar thought regarding data science in particular. Writing those pandas expressions by hand during exploration means you get to know the data intimately. Getting AI to write them for you limits you to a superficial knowledge of said data (at least in my case).
Thanks for the quote, it definitely resonates. Distressing to see many people who can't relate to this, taking it literally and arguing that there is nothing lost the more removed they are from the process.
yes, this is maybe it's my preference to jump directly to coding, instead of canva to draw the gui and stuff. i would not know what to draw because the involvemt is not so deep ...or something
I dunno, when you've made about 10,000 clay pots its kinda nice to skip to the end result, you're probably not going to learn a ton with clay pot #10,001. You can probably come up with some pretty interesting ideas for what you want the end result to look like from the onset.
I find myself being able to reach for the things that my normal pragmatist code monkey self would consider out of scope - these are often not user facing things at all but things that absolutely improve code maintenance, scalability, testing/testability, or reduce side effects.
Depends on the problem. If the complexity of what you are solving is in the business logic or, generally low, you are absolutely right. Manually coding a signup flow #875 is not my idea of fun either. But if the complexity is in the implementation, it’s different. Doing complex cryptography, doing performance optimization or near-hardware stuff is just a different class of problems.
9 replies →
import claypot
trillion dollar industry boys
1 reply →
> you're probably not going to learn a ton with clay pot #10,001
Why not just use a library at that point? We already have support for abstractions in programming.
Honestly this sounds like a Luddite mindset (and I mean that descriptively, not to be insulting). This mindset holds us back.
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.
That quote sounds like special pleading for artisans.
reminds of arguments for - hosting a server vs running stuff in cloud - vps vs containers
I love Aral, he is so invested.
This is beautifully written, but as a point against agentic AI coding, I just don't really get it.
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.
Yeah? And then you continue prompting and developing, and go through a very similar iterative process, except now it's faster and you get to tackle more abstract, higher level problems.
"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.
I don't think this comparison holds up. With a higher-level language, the material you're building with is a formal description of the software, which can be fed back into a compiler to get a deterministic outcome.
With an LLM, you put in a high-level description, and then check in the "machine code" (generated code).
Eloquent, moving, and more-or-less exactly what people said when cameras first hit the scene.
Ironic. The frequency and predictability of this type of response — “This criticism of new technology is invalid because someone was wrong once in the past about unrelated technology” — means there might as well be an LLM posting these replies to every applicable article. It’s boring and no one learns anything.
It would be a lot more interesting to point out the differences and similarities yourself. But then if you wanted an interesting discussion you wouldn’t be posting trite flamebait in the first place, would you?
1 reply →
Interesting comparison. I remember watching a video on that. Landscape paintings, portraits, etc, was an art that has taken an enormous nosedive. We, as humans, have missed out on a lot of art because of the invention of the camera. On the other hand, the benefits of the camera need no elaboration. Currently AI had a lot of foot guns though, which I don't believe the camera had. I hope AI gets to that point too.
2 replies →
> Eloquent, moving, and more-or-less exactly what people said when cameras first hit the scene.
This is a non sequitur. Cameras have not replaced paintings, assuming this is the inference. Instead, they serve only to be an additional medium for the same concerns quoted:
Just as this is applicable to refining a software solution captured in code, just as a painter discards unsatisfactory paintings and tries again, so too is it when people say, "that picture didn't come out the way I like, let's take another one."
18 replies →
Source?
1 reply →
Yeah, and cameras changed art forever.
3 replies →
I don't get it.
I think just as hard, I type less. I specify precisely and I review.
If anything, all we've changed is working at a higher level. The product is the same.
But these people just keep mixing things up like "wow I got a ferrari now, watch it fly off the road!"
Yeah so you got a tools upgrade; it's faster, it's more powerful. Keep it on the road or give up driving!
We went from auto completing keywords, to auto completing symbols, to auto completing statements, to auto completing paragraphs, to auto completing entire features.
Because it happened so fast, people feel the need to rename programming every week. We either vibe coders now, or agentic coders or ... or just programmers hey. You know why? I write in C, I get machine code, I didn't write the machine code! It was all an abstraction!
Oh but it's not the same you say, it changes every time you ask. Yes, for now, it's still wonky and janky in places. It's just a stepping stone.
Just chill, it's programming. The tools just got even better.
You can still jump on a camel and cross the desert in 3 days. Have at it, you risk dying, but enjoy. Or you can just rent a helicopter and fly over the damn thing in a few hours. Your choice. Don't let people tell you it isn't travelling.
We're all Linus Torvalds now. We review, we merge, we send back. And if you had no idea what you were doing before, you'll still have no idea what you're doing today. You just fat-finger less typos today than ever before.
I find it interesting, the comments on this post (not just this particular comment per se) and the sheer inability to relate or ATTEMPT to relate to another persons experience or feeling. The post itself articulated a viewpoint and experience, your having a different one does not negate the other. Nor does your perspective mean the other does not exist. I'm dumbfounded at many of the comments.
Here are some clipped comments that I pulled from the overall post
> I don't get it.
> I'm using LLMs to code and I'm still thinking hard.
> I don't. I miss being outside, in the sun, living my life. And if there's one thing AI has done it's save my time.
> Then think hard? Have a level of self discipline and don’t consistently turn to AI to solve your problems.
> I am thinking harder than ever due to vibe coding.
> Skill issue
> Maybe this is just me, but I don't miss thinking so much.
The last comment pasted is pure gold, a great one to put up on a wall. Gave me a right chuckle thanks!!!
When I read the article, I feel the same emotions that I feel if someone were to tell me "I keep trying to ride a bike but I keep falling off". My experience with LLMs is that the "lack of thinking" is mostly a quick trough you fall into before you come out the other side understanding how to deal with LLMs better. And yes, there's nothing wrong with relating to someone's experience, but mostly I just want to tell that guy, just keep trying, it'll get better, and you'll be back to thinking hard if you keep at it.
But then OP says stuff like:
> I am not sure if there will ever be a time again when both needs can be met at once.
In my head that translates to "I don't think there will ever be a time again when I can actually ride my bike for more than 100 feet." At which point you probably start getting responses more like "I don't get it" because there's only so much empathy you can give someone before you start getting a little frustrated and being like "cmon it's not THAT bad, just keep trying, we've all been there".
3 replies →
It's honestly just an example of ego and coping. These people are trading temporary gains in pseudo-productivity for training their replacements and atrophying their skills.
The truth of the matter is that the people who will choose to partake already weren't thinking; otherwise they wouldn't have chosen. This is the same with every bubble or major revolutionary thing that ends up having negative effects in the long run. GLP-1 is another great example of one that is still on the upward arc.
Sheep will always be sheep, and, in my opinion, this is the reason for the changes in hiring and the large scale encouragement of folks that obviously are not smart enough for this career to suddenly join in over the past 10 years.
>You can still jump on a camel and cross the desert in 3 days. Have at it, you risk dying, but enjoy. Or you can just rent a helicopter and fly over the damn thing in a few hours. Your choice. Don't let people tell you it isn't travelling.
its obviously not wrong to fly over the desert in a helicopter. its a means to an end and can be completely preferable. I mean myself I'd prefer to be in a passenger jet even higher above it, at a further remove personally. But I wouldn't think that doing so makes me someone who knows the desert the same way as someone who has crossed it on foot. It is okay to prefer and utilize the power of "the next abstraction", but I think its rather pig headed to deny that nothing of value is lost to people who are mourning the passing of what they gained from intimate contact with the territory. and no it's not just about the literal typing. the advent of LLMs is not the 'end of typing', that is more reductionist failure to see the point.
Reminds me of all the parables about kings who "pretend to be a common man" for a day and walk among their subjects and leave with some new enlightenment.
The idea that you lose a ton of knowledge when you experience things through intermediaries is an old one.
I felt the same way about python when I was switching from C++ to python for data analysis
3 replies →
I think I understand what the author is trying to say.
We miss thinking "hard" about the small details. Maybe "hard" isn't the right adjective, but we all know the process of coding isn't just typing stuff while the mind wanders. We keep thinking about the code we're typing and the interactions between the new code and the existing stuff, and keep thinking about potential bugs and issues. (This may or may not be "hard".)
And this kind of thinking is totally different from what Linus Torvalds has to think about when reviewing a huge patch from a fellow maintainer. Linus' work is probably "harder", but it's a different kind of thinking.
You're totally right it's just tools improving. When compilers improved most people were happy, but some people who loved hand crafting asm kept doing it as a hobby. But in 99+% cases hand crafting asm is a detriment to the project even if it's fun, so if you love writing asm yourself you're either out of work, or you grudgingly accept that you might have to write Java to get paid. I think there's a place for lamenting this kind of situation.
Spot on. It’s the lumberjack mourning the axe while holding a chainsaw. The work is still hard. it’s just different. The friction comes from developers who prioritize the 'craft' of syntax over delivering value. It results in massive motivated reasoning. We see people suddenly becoming activists about energy usage or copyright solely to justify not using a tool they dislike. They will hunt for a single AI syntax error while ignoring the history of bugs caused by human fatigue. It's not about the tech. it's about the loss of the old way of working.
And it's also somewhat egotistical it seems to me. I sense a pattern that many developers care more about doing what they want instead of providing value to others.
8 replies →
I agree. I think some of us would rather deal with small, incremental problems than address the big, high-level roadmap. High-level things are much more uncertain than isolated things that can be unit-tested. This can create feelings of inconvenience and unease.
I work with a lot of artists, and selling them on (not totally rejecting) AI has largely been unsuccessful until they both understand the analogies and the specifics of what different tools do.
AI makes you the manager. The models are like GRAs or contract workers, maybe new to their fields but with tireless energy, and you need to be able to instruct them correctly and evaluate their outputs. None of them can do everything, and you'll need to carefully hire the ones you want based on the work you need, which means breaking workflows into batchable parts. If you've managed projects before, you've done this.
Right now, my focus is improving pipelines in composition and arrangement based on an artist's corpus. A lot of them just want to be more productive, and it's a slog to write, then break into parts, etc using modern notation software.
You _think_ you're thinking as hard. Reading code != writing it. Just like watching someone do a thing isn't the same as actually doing it.
Correct… reading code is a much more difficult and ultimately, productive, task.
I suspect those using the tools in the best way are thinking harder than ever for this reason.
4 replies →
Well, depending on the scope of work, they may be still thinking hard, just on a higher level. That is, thinking about the requirements, specification, and design.
That's a warm and cozy way to look at things but its not true.
LLM-aided coding is not a higher level tool. It is not writing in C vs writing in assembly. It is closer to asking other people to do something for you and (supposedly, hopefully, although how many people really do it?) reviewing the result.
The thing is, some people already disliked the thinking involved in programming and are welcoming these tools. That's fine, but you don't get to equate it with programming.
You don't have a strong mental model after agentic coding something in my experience.
It isn't an abstraction like assembly -> C. If you code something like: extract the raw audio data from an audio container, it doesn't matter if you write it in assembly, C, Javascript, whatever. You will be able to visualize how the data is structured when you are done. If you had an agent generate the code the data would just be an abstraction.
It just isn't worth it to me. If I am working with audio and I get a strong mental model for what different audio formats/containers/codecs look like who knows what creative idea that will trigger down the line. If I have an agent just fix it then my brain will never even know how to think in that way. And it takes like... a day...
So I get it as a optimized search engine, but I will never just let it replace understanding every line I commit.
Maybe in order to get the most out of agentic programming one needs to either a) already master the domain in question, or b) become a master in the process.
When (b) then the process can be the thing that triggers "thinking hard", and when (a) the one's mastery can be the reason one "thinks hard" when driving the agent.
Does this help TFA? Idk. Maybe if TFA can try either doing (a) a lot or (b) a lot it might. Or maybe agentic programming is going to drive out of the business those who stop thinking hard because they have agents to help them.
> We're all Linus Torvalds now. We review, we merge, we send back. And if you had no idea what you were doing before, you'll still have no idea what you're doing today. You just fat-finger less typos today than ever before.
Except Linus understands the code that is being reviewed / merged in since he already built the kernel and git by hand. You only see him vibe-coding toys but not vibe-coding in the kernel.
Today, we are going to see a gradual skill atrophy with developers over-relying on AI and once something like Claude goes down, they can't do any work at all.
The most accurate representation is that AI is going to rapidly make lots of so-called 'senior engineers' who are over-reliant and unable to detect bad AI code like juniors and interns.
My “skill” for 40 years has been to turn what I wanted my computer to do into code to get it done using the tools available to me. A “senior developer” is not someone who “codez real gud”. It’s someone who can work at a higher level of scope and ambiguity and has a larger impact on the organization than a ticket taker
If you can't rebuke code today. You can't rebuke code tomorrow.
3 replies →
I think the more apt analog isn't a faster car, a la Ferrari, it's more akin to someone who likes to drive and now has to sit and monitor the self-driving car steer and navigate. Comparing to the Ferrari is incorrect since it still takes a similar level of agency from the driver versus a <insert slower vehicle>
This is exactly the right analogy here.
FSD is very very good most of the time. It's so good (well, v14 is, anyway), it makes it easy to get lulled into thinking that it works all the time. So you check your watch here, check your phone there, and attend to other things, and it's all good until the car decides to turn into a curb (which almost happened to me the other day) or swerve hard into a tree (which happened to someone else).
Funny enough, much like AI, Tesla is shoving FSD down people's throats by gating Autopilot 2, a lane keeping solution that worked extremely well and is much friendlier to people who want limited autonomy here and there, behind the $99/mo FSD sub (and removing the option to pay for the package out of pocket).
> I think just as hard, I type less. I specify precisely and I review.
Even if you "think just as hard" the act of physically writing things down is known to improve recall, so you're skipping a crucial step in understanding.
And when I review code, it's a different process than writing code.
These tradeoffs may be worth it, because we can ask the tools to analyze things for us just as easily as we can ask them to create things for us, but your own knowledge and understanding of the system is absolutely being degraded when working this way.
It is simple. Continuing your metaphor, I have a choice of getting exactly where I want on a camel in 3 days, or getting to a random location somewhere on the other side of the desert on a helicopter in few hours.
And being a reasonable person I, just like the author, choose the helicopter. That's it, that's the whole problem.
Why is that the reasonable choice if it doesn't get you to your destination?
I too did a lot of AI coding but when I saw the spaghetti it made, I went back to regular coding, with ask mode not agent mode as a search engine.
5 replies →
You did something smart and efficinently using the least amount of energy and time needed. +1 for consciousness being a mistake
Helicopters are deterministic though :)
I get it.
I got excited about agents because I told myself it would be "just faster typing". I told myself that my value was never as a typist and that this is just the latest tool like all the tools I had eagerly added to my kit before.
But the reality is different. It's not just typing for me. It's coming up with crap. Filling in the blanks. Guessing.
The huge problem with all these tools is they don't know what they know and what they don't. So when they don't know they just guess. It's absolutely infuriating.
It's not like a Ferrari. A Ferrari does exactly what I tell it to, up to the first-order effects of how open the throttle is, what direction the wheels face, how much pressure is on the brakes etc. The second-order effects are on me, though. I have to understand what effect these pressures will have on my ultimate position on the road. A normie car doesn't give you as much control but it's less likely to come off the road.
Agents are like a teleport. You describe where you want to be and it just takes you directly there. You say "warm and sunny" and you might get to the Bahamas, but you might also get to the Sahara. So you correct: "oh no, I meant somewhere nice" and maybe you get to the Bahamas. But because you didn't travel there yourself you failed to realise what you actually got. Yeah, it's warm, sunny and nice, but now you're on an island in the middle of nowhere and have to import basically everything. So I prompt again and rewrite the entire codebase, right?
Linus Torvalds works with experts that he trusts. This is like a manic 5 year old that doesn't care but is eager to work. Saying we all get to be Torvalds is like saying we all get to experience true love because we have access to porn.
> We're all Linus Torvalds now.
So...where's your OS and SCM?
I get your point that wetware stills matter, but I think it's a bit much to contend that more than a handful of people (or everyone) is on the level of Linus Torvalds now that we have LLMs.
I should have been clearer. It was a pun, a take, a joke. I was referring to his day-to-day activity now, where he merges code, doesn't write hardly any code for the linux kernel.
I didn't imply most of use can do half the thing he's done. That's not right.
4 replies →
My hair hasn't turned blonde and I don't suddenly know how to speak Finnish, either.
You might have missed their point.
> You just fat-finger less typos today than ever before.
My typos are largely admissible.
I agree! It's a lot more pleasant than being stuck over figuring out how to use awk properly for hours. I knew what I needed to do then, and I know what I need to do now too. The difference is I get to results faster. Sometimes I even learn that awk was not even the right tool in my situation and learn about a new way of doing things while AI is "thinking" for me
except the thing does not work as expected and it just makes you worse not better
Like I said that's temporary. It's janky and wonky but it's a stepping stone.
Just look at image generation. Actually factually look at it. We went from horror colours vomit with eyes all over, to 6 fingers humans, to pretty darn good now.
It's only time.
5 replies →
Comments like these are why I don't browse HN nearly ever anymore
9 replies →
That's your opinion and you can not use those tools.
People are paying for it because it helps them. Who are you to whine about it?
5 replies →
It really bothers me how many comments on this topic (here and elsewhere) draw a false parallel between LLM-based coding as an abstraction and frameworks and compilers as an abstraction. They're not the same thing and it matters.
Frameworks and compilers are designed to be leak-proof abstractions. Any way in which they deviate from their abstract promise is a bug that can be found, filed, and permanently fixed. You get to spend your time and energy reasoning in terms of the abstraction because you can trust that the finished product works exactly the way you reasoned about at the abstract level.
LLMs cannot offer that promise by design, so it remains your job to find and fix any deviations from the abstraction you intended. If you fell short of finding and fixing any of those bugs, you've just left yourself a potential crisis down the line.
[Aside: I get why that's acceptable in many domains, and I hope in return people can get why it's not acceptable in many other domains]
All of our decades of progress in programming languages, frameworks, libraries, etc. has been in trying to build up leak-proof abstractions so that programmer intent can be focused only on the unique and interesting parts of a problem, with the other details getting the best available (or at least most widely applicable) implementation. In many ways we've succeeded, even though in many ways it looks like progress has stalled. LLMs have not solved this, they've just given up on the leak-proof part of the problem, trading it for exactly the costs and risks the industry was trying to avoid by solving it properly.
Your comment gets to the crux of my thinking about LLM coding. The way I think of what LLM coding is doing is decompressing your prompt into code based on the statistical likelihood of that decompression based on training data. Basically "Build me an IOS app" -> a concrete implementation of an iOS app. The issue here is that the user supplying the prompt needs to encode all of the potential variables that the AI needs to work with into the prompt, or else the implementation will just be based on the "bog-standard" iOS app based on the training corpus, although with potential differences in the app based on other tokens in the prompt. Is natural language the right way to encode that information? Do we want to rely on input tokens to the context of a model successfully making it into the output to guarantee accuracy? I think the Kiro Spec driven development starts to get at addressing the inherent issues in LLM based coding assistance, but it is an early step.
Another way in which their different is that, because they are non-deterministic, we check in the output, not the input. It's the equivalent of checking machine code into our source control instead of the input language. It's not abstraction, its non-deterministic code generation.
> LLMs cannot offer that promise by design, so it remains your job to find and fix any deviations from the abstraction you intended.
LLMs are clumsy interns now, very leaky. But we know human experts can be leak-proof. Why can't LLMs get there, too, better at coding, understanding your intentions, reviewing automatically for deviations, etc.?
Thought experiment: could you work well with a team of human experts just below your level? Then you should be able to work well with future LLMs.
That is a good point because your brain interacts with them differently as well.
If my C compiler sometimes worked and sometimes didn't I would just mash compile like an ape until it started working.
Well, sometimes your compiler will work out how to more efficiently compile a thing (e.g. vectorize a loop), and other times you'll rework some code to an equivalent formulation and suddenly it won't get vectorized because you've tripped some invisible flag that prevents an inlining operation that was crucial to enabling that vectorization, and now that hot path runs at a quarter of the speed it did before.
Technically it's (usually) deterministic for a given input, and you can follow various best practices to increase your odds of triggering the right optimizations.
But practically speaking "will I get the good & fast code for this formulation" is a crap shoot, and something like 99% (99.99%?) of programmers live with that. (you have guidelines and best practices you can follow, kinda like steering agents, but rarely get guarantees)
Maybe in the future the vast majority of programmers put up with a non-deterministic & variable amount of correctness in their programs, similar to how most of us put up with a (in practice) non-deterministic & variable amount of performance in our programs now?
Exactly. It’s a bit startling how many programmers don’t seem to know the meaning of “abstraction.”
You know, I was expecting what the post would say and was prepared to dunk on it and just tell them to stop using ai then, but the builder/thinker division they presented got me thinking. How ai/vibe coding fulfills the builder, not the thinker, made me realize that I'm basically 100% thinker, 0% builder, and that's why I don't really care at all about ai for coding.
I'll spend years working on a from scratch OS kernel or a vulkan graphics engine or whatever other ridiculous project, which never sees the light of day, because I just enjoy the thinking / hard work. Solving hard problems is my entertainment and my hobby. It's cool to eventually see results in those projects, but that's not really the point. The point is to solve hard problems. I've spent decades on personal projects that nobody else will ever see.
So I guess that explains why I see all the ai coding stuff and pretty much just ignore it. I'll use ai now as an advanced form of google, and also as a last ditch effort to get some direction on bugs I truly can't figure out, but otherwise I just completely ignore it. But I guess there's other people, the builders, where ai is a miraculous thing and they're going to crazy lengths to adopt it in every workflow and have it do as much as possible. Those 'builder' types of people are just completely different from me.
Absolutely nah. I know it feels good to jump into the 'thinker' camp and lump the users of AI into a non-thinker group, but this dichotomy is very poorly suited. Builders/engineers want a great tool to build faster with. Coders want to write code and find elegance in the prose. Both are thinkers.
This just sounds like a boring definitional issue. 'Thinker' is a loaded word.
You are advocating for a particular (more inclusive) definition for 'thinker' which clashes with the author's, but his is equally valid. You're both just gesturing at different concepts and suggesting they should be tagged to that word.
OP raises a particular way to classify something about personalities, says he finds it quite interesting/discriminative, and calls that kind of personality a "thinker". You instead consider a "thinker" a broader category.
That feels like an empty disagreement (nobody is right on such matters) - the real debatable question of substance is whether the _concept_ OP is gesturing at has interesting discriminative power. That concept is something like "personalities which seem to value the act of thinking through a problem/problem solving itself rather than downstream result".
1 reply →
As someone who's been coding for several decades now (i.e. I'm old), I find the current generation of AI tools very ... freeing.
As an industry, we've been preaching the benefits of running lots of small experiments to see what works vs what doesn't, try out different approaches to implementing features, and so on. Pre-AI, lots of these ideas never got implemented because they'd take too much time for no definitive benefit.
You might spend hours thinking up cool/interesting ideas, but not have the time available to try them out.
Now, I can quickly kick off a coding agent to try out any hare-brained ideas I might come up with. The cost of doing so is very low (in terms of time and $$$), so I get to try out far more and weirder approaches than before when the costs were higher. If those ideas don't play out, fine, but I have a good enough success rate with left-field ideas to make it far more justifiable than before.
Also, it makes playing around with one-person projects a lot practical. Like most people with partner & kids, my down time is pretty precious, and tends to come in small chunks that are largely unplannable. For example, last night I spent 10 minutes waiting in a drive-through queue - that gave me about 8 minutes to kick off the next chunk of my one-person project development via my phone, review the results, then kick off the next chunk of development. Absolutely useful to me personally, whereas last year I would've simply sat there annoyed waiting to be serviced.
I know some people have an "outsourcing Lego" type mentality when it comes to AI coding - it's like buying a cool Lego kit, then watching someone else assemble it for you, removing 99% of the enjoyment in the process. I get that, but I prefer to think of it in terms of being able to achieve orders of magnitude more in the time I have available, at close to zero extra cost.
> 8 minutes to kick off the next chunk of my one-person project development via my phone, review the results, then kick off the next chunk of development.
How are you doing this via your phone?
Termius + tailscale + tmux is a common setup for mobile coding sessions.
3 replies →
The (iOS) Claude phone app has a Claude code feature which runs "in the cloud". It's pretty handy for getting things done on the bus.
claude can deploy to github spaces and modify code for deployment to those by commits and pull requests to the repo exclusively
claude via browser and claude mobile apps function this way
but alongside that, people do make tunnels to their personal computer and setup ways to be notified on their phone, or to get the agent unstuck when it asks for a permission, from their phone
Just wanted to +1 this as a deep thinker who disagrees with the blog post's conclusion. I remember back on the years and decades I wasted dealing with the conceptual flaws inherent to nearly all software, and it breaks my heart.
90-99% of programming is a waste of time. Most apps today have less than a single spreadsheet page of actual business logic. The rest is boilerplate. Conjuring up whatever arcane runes are needed to wake a slumbering beast made of anti-patterns and groupthink.
For me, AI offers the first real computer that I've had access to in over 25 years. Because desktop computing stagnated after the 2000 Dot Bomb, and died on the table after the iPhone arrived in 2007. Where we should have symmetric multiprocessing with 1000+ cores running 100,000 times faster for the same price, we have the same mediocre quad core computer running about the same speed as its 3 GHz grandfather from the early 2000s. But AI bridges that divide by recruiting video cards that actually did increase in speed, albeit for SIMD which is generally useless for desktop computing. AI liberates me from having to mourn that travesty any longer.
I think that people have tied their identity to programming without realizing that it's mostly transcribing.
But I will never go back to manual entry (the modern equivalent of punch cards).
If anything, I can finally think deeply without it costing me everything. No longer having to give my all just to tread water as I slowly drown in technical debt and deadlines which could never be met before without sacrificing a part of my psyche in the process.
What I find fascinating is that it's truly over. I see so clearly how networks of agents are evolving now, faster than we can study, and have already passed us on nearly every metric. We only have 5-10 years now until the epiphany, the Singularity, AGI.
It's so strange to have worked so hard to win the internet lottery when that no longer matters. People will stop buying software. Their AI will deliver their deepest wish, even if that's merely basic resources to survive, that the powers that be deny us to prop up their fever dream of late-stage crony capitalism under artificial scarcity.
Everything is about to hit the fan so hard, and I am so here for it.
> 90-99% of programming is a waste of time. Most apps today have less than a single spreadsheet page of actual business logic.
I would very much like to know the kind of app you’ve seen. It’s very hard to see something like mpv, calibre, abiword, cmus,… through that lens. Even web apps like forgejo, gonic, sr.ht, don’t fit into that view.
1 reply →
> For me, AI offers the first real computer that I've had access to in over 25 years.
That's such a weird perspective. No matter your dissatisfaction with the software available, the computers we had were perfectly fine for writing whatever software you wanted to write.
Totally agree. I can spend an afternoon trying out an approach to a problem or product (usually while taking meetings and writing emails as well). If it doesn't work, then that's a useful result from my time. If it does work, I can then double-down on review, tests, quality, security, etc and make sure it's all tickety-boo.
Completely agree, there’s so many small projects I’d never been able to even start in my free time, because I’m NOT a full-stack dev and I’d rather not spend all my evenings fixing or working around all the small changes and quirks of the $currentjsframework
I think this is the other side of the same coin, and it's a really important one. When time is scarce, especially with family and a life outside work, the ability to turn tiny, fragmented moments into forward progress is huge
Exactly, it kills me to see a people a lot younger (I’m 51) pining about the good old days while the coding part of my day to day life now is using AI tools to their fullest extent.
I will never not be upset at my fellow engineers for selling out the ONE thing that made us valuable and respected in the marketplace and trying to destroy software engineering as a career because "Claude Code go brrrrrr" basically.
It's like we had the means for production and more or less collectively decided "You know what? Actually, the bourgeoisie can have it, sure."
Will we see growing unemployment in software development? Maybe in the short term, but the appetite for software is not finite just as the appetite for any other kind of economic tool is not finite.
What percentage of software just ceases development when it's "good enough?" Probably a tiny percentage of all software, and which is mostly internal tooling.
It's going to push software development into the front of business development precisely because it will be cheaper to develop. The companies that will benefit from AI at least early on will all be software-driven companies since the results are undeniable. If software developers lose out when all of their companies become more efficient and new companies are built because it becomes easier to build software with small teams, I will be very surprised.
This is a more honest comment than the many around it making overly intellectualized arguments.
But I would sooner compare this engineer class to something of a small bourgeoisie swallowed by a yet larger one, especially in the United States.
The personification of the quote “your scientists were so preoccupied with whether or not they could that they didn't stop to think if they should”
I feel the existential problem for a world that follows the religion of science and technology to its extreme, is that most people in STEM have no foundation in humanities, so ethical and philosophical concerns never pass through their mind.
We have signed a pact with the devil to help us through boring tasks, and no one thought to ask what we would give in exchange.
Yeah, lawyers, politicians and MBA types all usually have solid foundation in humanities. Not exactly known for concerning themselves with ethics or philosophy though.
I find it fascinating how the “true believers” of AI and AGI, have essentially been manipulated by capitalists to undermine the value of their own labor.
Money. It's always money. It was always money.
Couldn't agree more. AI as it's designed today is very heavy on the "f u; got mine" vibe.
2 replies →
The bloodless pragmatists aided and abetted them. Those who have no apparent values. Only short-term, terminally idiotic obsession with building things, creating value, creating business value, or whatever the pragmatist posturing of the day is.
Now they can have the fruits of their labor. Nothing. But why would they even want that? It’s not about getting something out of it. Or maintaining a living. It’s about building things.
so AI can actually replace software engineers? It's relatively unusual to see someone who "believes in AI", but is "anti-AI", at least among the HN crowd.
Also, I find this view very selfish. Yes, let's gatekeep a ground-breaking technology because it will hurt my specific profession. That's literally what technological progress is- it always (at least temporarily) disadvantages a particular sector of workers that specialized in that skill for the benefit of society. It's just funny because usually it's the blue collar workers who have to worry about this and the white collar workers who sanctimoniously tell them to suck it up or learn to code.
Also, I can't help but chuckle slightly at the irony here. The entire purpose of software engineering and computers is automation, and the lost jobs in other sectors due to SWEs is massive. To spend one's entire life in pursuit of this and be morally opposed to the "ultimate" automation (automating this process of automation itself) is a bit rich.
Based comment
[dead]
One thing this discussion made me realize is that "thinking hard" might not be a single mode of thinking.
In grad school, I had what I'd call the classic version. I stayed up all night mentally working on a topology question about turning a 2-torus inside out. I already knew you can't flip a torus inside out in ordinary R^3 without self-intersection. So I kept moving and stretching the torus and the surrounding space in my head, trying to understand where the obstruction actually lived.
Sometime around sunrise, it clicked that if you allow the move to go through infinity(so effectively S^3), the inside/outside distinction I was relying on just collapses, and the obstruction I was visualizing dissolves. Birds were chirping, I hadn't slept, and nothing useful came out of it, but my internal model of space felt permanently upgraded. That's clearly "thinking hard" in the sense.
But there's another mode I've experienced that feels related but different. With a tough Code Golf problem, I might carry it around for a week. I'm not actively grinding on it the whole time, but the problem stays loaded in the background. Then suddenly, in the shower or on a walk, a compression trick or a different representation just clicks.
That doesn't feel "hard" moment to moment. It's more like keeping a problem resident in memory long enough for the right structure to surface.
One is concentrated and exhausting, the other is diffuse and slow-burning. They're different phenomenologically, but both feel like forms of deep engagement that are easy to crowd out.
Yup, yup! There's so many different ways of thinking hard.
For me, thinking about an extremely technical TCS problem, for example, is my version of actively, tirelessly thinking hard. I'm logging a ton of observations, trying new ideas and hypotheses, using a mix of computer simulation and math to try and arrive at a concrete framing and answer.
On the other end of the specturm, I have philosophy. It's definitely a different type of hard. Most of my "Aha!" moments come from when I realize I've been strawmanning some argument, and not actually understanding what the person is saying. Why is the person saying this, relative to what, why is this a new observation, etc. Things are so amorphus and you can tweak the problem parameters in so many ways, and it's really tempting to either be too fluid and pretend you understand the thinker (because it's a subset of some conception you already have), or be too rigid and dissolve the thinker as a category error / meaningless. I've never felt the same feeling as I did when doing TCS research, but the feeling was definitely hard thinking nonetheless.
In terms of extremely nitty-gritty technical things, like linker bullshit and linux kernel programming, I'm much more familiar with, and these things are more about reading documentation (because the tool won't behave like you want it to) and iteration / testing (because... the tool won't behave like you want it to, so you need to make sure it behaves like you want it to!). This is also a type of thinking - I would call it hard as in the physiological response I have is similar to that of research in the very bad moments, but in terms of my lofty ideals, I don't want to call this hard.... it's very "accidental" complexity, but it's what I get paid to do :/
At work, you have a huge idea space to consider, both problem and solution framings, mixing in "bullshit" constraints like business ones. You also throw in the real-time aspect of it, so I can't just either armchair on a problem for a month (unlike Philosophy) or deep dive on a problem for a month (unlike research). I'm technically doing the third type of programming right now, but we'll see how long that lasts and I get put on a new project.
I'm not even sure if there's a clean demarcation between any of these. These are certainly better than brainrotting youtube though.
I think the article has a point. There seem to be two reactions among senior engineers atound me these days.
On one side, there are people who have become a bit more productive. They are certainly not "10x," but they definitely deliver more code. However, I do not observe a substantial difference in the end-to-end delivery of production-ready software. This might be on me and my lack of capacity to exploit the tools to their full extent. But, iterating over customer requirements, CI/CD, peer reviews, and business validation takes time (and time from the most experienced people, not from the AI).
On the other hand, soemtimes I observe a genuine degradation of thinking among some senior engineers (there aren’t many juniors around, by the way). Meetings, requirements, documents, or technology choices seem to be directly copy/pasted from an LLM, without a grain of original thinking, many times without insight.
The AI tools are great though. They give you an answer to the question. But, many times making the correct question, and knowing when the answer is not correct is the main issue.
I wonder if the productivity boost that senior engineers actually need is to profit from the accumulated knowledge found in books. I know it is an old technology and it is not fashionable, but I believe it is mostly unexploited if you consider the whole population of engineers :D
> This might be on me and my lack of capacity to exploit the tools to their full extent. But, iterating over customer requirements, CI/CD, peer reviews, and business validation takes time (and time from the most experienced people, not from the AI).
Yeah, you're certainly not the only one. For me the implementation part has always been a breeze compared to all the "communication overhead" so to speak. And in any mature system it easily takes 90% of all time or more.
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.
1 reply →
There are a lot of hard problems to solve in orchestration. We've barely scratched the surface on this.
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.
1 reply →
And thinking of how to convey all of that to Claude without having to write whole books :)
2 replies →
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...
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.
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.
Aptitude testing centers like Johnson O'Connor have tests for that. There are (relatively) huge differences between different people's thinking and problem solving styles. For some, creating an efficient process feels natural, while others need stability and redundancy. Programmers are by and large the latter.
[1]: https://www.jocrf.org/how-clients-use-the-analytical-reasoni...
> 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.
Thats not thinking hard, you are making decisions
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.
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.
1 reply →
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.
It is a different kind of thinking, though.
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.
5 replies →
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...
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)
I haven't reduced my thinking! Today I asked AI to debug an issue. It came with a solution that it was clearly correct, but it didn't explain why the code was in that state. I kept steering AI (which just wanted to fix) toward figuring out the why and it digged through git and github issue at some point,in a very cool way. And finally it pulled out something that made sense. It was defensive programming introduced to fix an issue somewhere else, which was also in turn fixed, so useless.
At that point an idea popped in my mind and I decided to look for similar patterns in the codebase, related to the change, found 3. 1 was a non bug, two were latent bugs.
Shipped a fix plus 2 fixes for bugs yet to be discovered.
>I haven't reduced my thinking!
You just detailed an example of where you did in fact reduce your thinking.
Managers who tell people what to get done do not think about the problem.
I think my message is doing a disservice to explaining what actually happened because a lot of it happens in my head.
There is a lot of thinking involved. What's reduced is search tooling. I can be way more fuzzy, rather than `rg 'whatever'` I now say "find this and similar patterns"
4 replies →
I've found that it's often useful to spend the time thinking about the way I would architect the code (down to a fair level of minutia) before letting the agent have a go.
That way my 'thinker' is satiated and also challenged - Did the solution that my thinker came up with solve the problem better than the plan that the agent wrote?
Then either I acknowledge that the agent's solution was better, giving my thinker something to chew on for the next time; or my solution is better which gives the thinker a dopamine hit and gives me better code.
I'm wondering if everyone here saying they think harder with LLM agents have never reached "flow state" while programming. I just can't imagine using 100% of my mental focus state for hours with an agent. Sure, I think differently when my coding is primarily via agent, but I've never been totally enveloped by my thoughts while doing so.
For those who have found a "flow state" with LLM agents, what's that like?
I've literally never found flow state with programming. Is it even possible when working as a full stack web dev? I am constantly context switching between backend/frontend, reading documentation, looking at/modifying data, refreshing & interacting with the browser, checking/double checking feature requirements, asking people about things.
For me, yes. It is possible as when working full-stack if you aren't being interrupted. Not all tasks, but some tasks, where you're pretty sure of the high-level requirements, have the necessary agency to stay in a bubble for a bit, and the task is sufficiently complex but narrow enough so you don't have to context switch too much.
With LLM Agents I can't seem to do it, as waiting for the agent to finish working just doesn't tickle my brain in the right way. I feel... distracted, I guess?
1 reply →
I believe you can enter "flow state" with something like Claude Code, from what I've read, but it's mostly reduced to pressing 1 or 2 and typing a few prompts. The reward loop is much more closed now though, so it's a bit more akin to reaching flow state playing Tetris.
People here seem to be conflating thinking hard and thinking a lot.
Most examples mentioned of “thinking hard” in the comments sound like they think about a lot of stuff superficially instead one particular problem deeply, which is what OP is referring to.
If you actually have a problem worth thinking deeply about, AI usually can’t help with it. For example, AI can’t help you make performant stencil buffers on a Nokia Ngage for fun. It just doesn’t have that in it. Plenty of such problems abound, especially in domains involving some or the other extreme (like high throughput traffic). Just the other day someone posted a vibe coded Wikipedia project that took ages to load (despite being “just” 66MB) and insisted it was the best it was possible to do, whereas Google can load the entire planet (perceptually) in a fraction of a second.
I miss the thrill of running through the semi-parched grasslands and the heady mix of terror triumph and trepidation as we close in on our meal for the week.
I think that feeling is fairly common across the entire population. Play more tag, it’ll help.
There are people who still hunt, fish and run. Some even climb without ropes. It would seem the feeling is missed.
To be honest, I do not quite understand the author's point. If he believes that agentic coding or AI has negative impact on being a thinker, or prevent him from thinking critically, he can simply stop using them.
Why blame these tools if you can stop using them, and they won't have any effect on you?
In my case, my problem was often overthinking before starting to build anything. Vibe coding rescued me from that cycle. Just a few days ago, I used openclaw to build and launch a complete product via a Telegram chat. Now, I can act immediately rather than just recording an idea and potentially getting to it "someday later"
To me, that's evolutional. I am truly grateful for the advancement of AI technology and this new era. Ultimately, it is a tool you can choose to use or not, rather than something that prevents you from thinking more.
For me personally, the problem is my teammates. The ability or will to critically think, or investigate existing tools in the codebase seems to disappear. Too often now I have to send back a PR where something is fixed using novel implementations instead of the single function call using existing infrastructure.
I generally feel the same. But in addition, I also enjoy the pure act of coding. At least for me that’s another big part why I feel left behind with all this Agent stuff.
I agree, that's another factor. Definitely the mechanical act of coding specially if your are good at it gives the type of joy that I can imagine an artisan or craftsman having when doing his work.
Good highlight of the struggle between Builder and Thinker, I enjoyed the writing. So why not work on PQC? Surely you've thought about other avenues here as well.
If you're looking for a domain where the 70% AI solution is a total failure, that's the field. You can't rely on vibe coding because the underlying math, like Learning With Errors (LWE) or supersingular isogeny graphs, is conceptually dense and hasn't been commoditized into AI training data yet. It requires that same 'several-day-soak' thinking you loved in physics, specifically because we're trying to build systems that remain secure even against an adversary with a quantum computer. It’s one of the few areas left where the Thinker isn't just a luxury, but a hard requirement for the Builder to even begin.
I think harder because of AI.
I have to think more rigorously. I have to find ways to tie up loose ends, to verify the result efficiently, to create efficient feedback loops and define categorical success criteria.
I've thought harder about problems this last year than I have in a long time.
> I have to find ways to tie up loose ends, to verify the result efficiently, to create efficient feedback loops and define categorical success criteria.
So... you didn't have to do that prior to using agents?
Not as much upfront. I had plenty of opportunities to adjust and correct along the way. With AI, the cost of not thinking upfront is high and the cost of being wrong in upfront decisions is low, so we bias towards that.
But beyond that, I have been thinking deeply about AI itself, which has all sorts of new problems. Permissions, verification, etc.
2 replies →
I find I think harder with AI programming. It generates the code, but I have to approve the overall design and then approve every single line. I will edit and rearrange the code until it is correct.
But since the AI is generating a lot of code, it is challenging me. It also allows me to tackle problems in unfamiliar areas. I need to properly understand the solutions, which again is challenging. I know that if I don't understand exactly what the code is doing and have confidence in the design and reliability, it will come back and bite me when I release it into the wild. A lesson learnt the hard way during many decades of programming.
Seems like a lot of people use AI to code in their private commercial IP and products. How are people not concerned with the fact that all these ai companies have the source code to everything? Your just helping them destroy your job. Code is not worthless, you cannot easily duplicate any complex project with equal features, quality, and stability.
I think that is a very good point. Code is definitely not worthless, but I don't think that capitalism has the right tools for pricing it properly. I think it will become a lot like mathematics in that way.
> 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.
I've not seen this take yet, but this is exactly how I feel. I do not yet know what I want to do, and my parts of my personality are no longer satisfied by coding. I'm thinking we need some kind of community of people like us where we can discuss these things.
I bring these up with others, and I find that most people around me are just builders.
> 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.
I think this is context dependent. Over time, within a single code base or ecosystem, incompatibilities between "close enough" solutions can add up and create a lot of problems and complexity, kinda like floating point inaccuracies. Especially if you're not going back and revisiting the structure/abstractions you've already got when you're adding/changing something.
There's another angle too, which is that time taken to improve your abilities isn't necessarily irrational, especially because that improvement is usually applicable in many different ways. It can be an investment.
I've been coding since the late 70s (Commodore PET 2001), and I've always paired it with real-world physical work—mechanical engineering, rigging, technical diving, hydraulics, welding, electronics, controls, you name it. Programming was just one of the tools, never the whole job. What I've learned is that the best thinking almost never happens staring at a screen. It happens when you're away from it: reading something deep, building something with your hands, debugging why the thing you designed doesn't work in reality. I love the updated saying: "Jack of all trades, master of none—but often better than a master of one." In a world obsessed with hyper-specialization, that range is a real advantage. What bothers me most is how quickly people—especially younger ones—now reach for a phone the second there's any friction. Forgotten a name? Phone. Stuck on a small logic puzzle? Phone. A group of engineers at the lunch table can't remember an actor and within seconds everyone's just silently googling instead of laughing and piecing it together from their collective memory. Where's the fun in that? Yeah, you get the answer instantly. But you skip the actual mental workout—and the fun of it. Remembering and reasoning are muscles. Use them or lose them. And honestly, the shared back-and-forth is usually the best part.
I feel like AI has given me the opportunity to think MORE, not less. I’m doing so much less mindless work, spending most of my efforts critically analyzing the code and making larger scale architectural decisions.
The author says “ Even though the AI almost certainly won't come up with a 100% satisfying solution, the 70% solution it achieves usually hits the “good enough” mark.”
The key is to keep pushing until it gets to the 100% mark. That last 30% takes multiples longer than the first 70%, but that is where the satisfaction lies for me.
I miss entering flow state when coding. When vibe coding, you are in constant interruption and only think very shallow. I never see anyone enter flow state when vibe coding.
The two ways I get into flow state these days are in setting up agentic loops, so I can get out of the way by letting AI check the results for itself, and by doing more things. I've got ~4 Claude Code instances working on problems, per project, and I've got multiple projects I'm working on at the same time.
Same here, waiting for response destroys any focus I have had.
If it's this easy to convince you to stop being creative, to stop putting in effort to think critically, then you don't deserve the fulfilment that creativity and critical thinking can give you. These vibe coding self pity articles are so bizarre.
"Oh no, I am using a thing that no one is forcing me to use, and now I am sad".
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
Corollary: you don't really need more software engineers.
Who decides what we "need"? Software provides value, and if we want to keep providing value moving forward there will be more software
> We don't really need more software
Yeah, we need better software.
The post resonates deeply with me. I am a health professional in diagnostics and through the years I have observed different extremes in approaches to solving diagnostic challenges - the one extreme is to rely on "knowing", the other on "thinking/reasoning". The former is usually very fast, but not easily explainable - just like pattern recognition. The latter was slow, but could give a solution from "first principles" and possibly not described before. Of course it's a spectrum and the thinking part requires and includes the deep enough "knowing" part. One usually uses both approaches on daily work, but I have seen some people who relied much more on knowing than thinking/reasoning, sometimes to the extreme (as in refusing to diagnose a condition on their own because they "have not seen this before").
With AI, I now think much harder. Timelines are shorter, big decisions are closer together, and more system interactions have to be "grokked" in my head to guide the model properly.
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.
My solution has been to lean into harder problems - even as side projects, if they aren't available at work.
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).
> I have tried to get that feeling of mental growth outside of coding
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.
Great article. Moment I finished reading this article, I thought of my time in solving a UI menu problem with lot of items in it and algorithm I came up with to solve for different screen sizes. It took solid 2 hrs of walking and thinking. I still remember how I was excited when I had the feeling of cracking the problem. Deep thinking is something everyone has it within and it varies how fast you can think. But we all got it with right environment and time we all got it in us. But thats long time ago. Now I always off load some thinking to AI. it comes up with options and you just have to steer it. By time it is getting better. Just ask it you know. But I feel like it is good old days to think deep by yourself. Now I have a partner in AI to think along with me. Great article.
I did competitive programming seriously between '17 and '24, then kept on coaching people
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.
Do you mean that sitting with the problem for days is a weakness that you should fix since you're wasting time making no progress? Or that it is a necessary practice in order to understand your weaknesses?
When you're a beginner you're a beginner, no way around it.
But understanding your weaknesses and working on them is huge, and I think most people just don't try to do it.
Being stuck for days is something to be overcome.
The next step would be being slow because you are trying out many different ideas and have no intuition for what the right one is.
Eventually I always get to a problem I can't solve by just throwing an LLM at it and have to go in and properly debug things. At that point knowing the code base helps a hell of a lot, and I would've been better off writing the entire thing by hand.
This resonates with me, but I quit programming about a decade ago when we were moving from doing low level coding to frameworks. It became no longer about figuring out the actual problem, but figuring out how to get the framework to solve it and that just didn't work for me.
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.
I’d been feeling this until quite literally yesterday, where I sort of just forced myself to not touch an AI and grappled with the problem for hours. Got myself all mixed up with trig and angles until I got a headache and decided to back off a lot of the complexity. I doubt I got everything right, I’m sure I could’ve had a solution with near identical outputs using an AI in a fraction of the time.
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 think the heart of the matter is this section in the blog:
> Yes, I blame AI for this.
> I am currently writing much more, and more complicated software than ever, yet I feel I am not growing as an engineer at all. [...] (emphasis added by me)
AI is a force multiplier for accidental complexity in the Brooks sense. (https://en.wikipedia.org/wiki/No_Silver_Bullet)
I’d love to be able to see statistics that show LLM use and reception according to certain socioeconomic factors.
Anything in particular you expect to see?
I'm thinking much more than ever, now that the coding agent is building for me.
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.
Many people here might be in a similar situation to me, but I took an online masters program that allowed for continuing education following completion of the degree. This has become one of my hobbies; I can take classes at my own expense, not worry about my grades, and just enjoy learning. I can push myself as much as I want and since the classes are hard, just completing 1 assignment is enough to force me to "think". Just sharing my experience for people who might be looking for ways to challenge themselves intellectually.
I think what plagues a lot of pure STEM types in this tumultuous period of AI (or "AI") is that they've spent a majority of their lives mulling over some problem until they've worked out every possible imperfection, and once they've achieved something they consider close to that level of perfection, that's when they say they're done.
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.
> I think what plagues a lot of pure STEM types in this tumultuous period of AI (or "AI") is that they've spent a majority of their lives mulling over some problem until they've worked out every possible imperfection, and once they've achieved something they consider close to that level of perfection, that's when they say they're done.
These people are miserable to work with if you need things done quickly and can tolerate even slight imperfection.
That operating regime is, incidentally, 95% of the work we actually get paid to do.
Maybe this is just me, but I don't miss thinking so much. I personally quite like knowing how to do things and being able to work productively.
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.
I see the current generation of AI very much as a thing in between. Opus 4.5 can think and code quite well, but it cannot do these "jumps of insight" yet. It also struggles with straightforward, but technically intricate things, where you have to max out your understanding of the problem.
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.
If you are thinking hard I think you are software engineering wrong. Even before AI. As an industry all the different ways of doing things have already played out. Even doing big reactors or performance optimizations often can not be 100% predicted in their effectiveness. You will want to just go ahead and implement these things over spending more time thinking. And as AI gets stronger the just try a bunch of approaches will beat the think hard approach by an even bigger margin.
Why do anything at all then? It's all been done before. This line of thinking sounds like depression to me. Why decorate my house? I know I could do it, but it's all been done before, why bother?
Just because we know the best way to add 2 ints together that doesn't mean it's pointless to do addition with ints. We don't need people trying to spend a lot of extra time to come up with alternate ways to do it. The right function using addition may be valuable to a certain population.
The answer to this is to shift left into product/design.
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.
> Good feature design is hard for AI
For now. Go back a year and take a look how the AI/LLM coding tools looked and worked back then.
The sampling rate we use to take input information is fixed. And we always find a way to work with the sampled information, no matter if the input information density is high or low.
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.
I had similar thoughts recently. I wouldn't consider myself "the thinker", but I simply missed learning by failure. You almost don't fail anymore using AI. If something fails, it feels like it's not your fault but the AI messed up. Sometimes I even get angry at the AI for failing, not at myself. I don't have a solution either, but I came up with a guideline on when and how to use AI that has helped me to still enjoy learning. I'm not trying to advertise my blog and you don't need to read it, the important part is the diagram at the end of "Learning & Failure": https://sattlerjoshua.com/writing/2026-02-01-thoughts-on-ai-.... In summary, when something is important and long-term, I heavily invest into understanding and use an approach that maximizes understanding over speed. Not sure if you can translate it 100% to your situation but maybe it helps to have some kind of guideline, when to spend more time thinking instead of directly using and AI to get to the solution.
"I don't want to have to write this for the umpteenth time" -- Don't let it even reach a -teenth. Automate it on the 2nd iteration. Or even the 1st if you know you'll need it again. LLMs can help with this.
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 were walking to your destination which was three miles away
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
but if you enjoy walking, what then?
You don’t use it, you lose it.
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.
I'm a DevOps/SRE and I've spent the past couple weeks trying to vibecode as much of what I do as possible.
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 think there's an argument where if Claude had the knowledge map of your personal one liners and a tool for using them, it would often do the right thing in those cases. But it's definitely not as able to compress all the entropy of 'what can go wrong' operations wise as it is when composing code yet.
My experience that with careful specs, Claude or Codex can whip up either CDK, Cloudformation, or Terraform code much quicker than I can and I’ve been using IAC for 8 years - developer/consultant specializing in development + cloud architecture
Personally: technical problems I usually think for a couple days at most before I need to start implementing to make progress. But I have background things like future plans, politics, philosophy, and stories, so I always have something to think about. Close-up technical thinking is great, but sometimes step back and look at the bigger picture?
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.
Instant upvote for a Philiip Mainlander quote at the end. He's the OG "God is Dead" guy and Nietzsche was reacting (very poorly) to Mainlander and other pessimists like Schopenhauer when he followed up with his own, shittier version of "god is dead"
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 believe it is a type of burnout. AI might have accelerated both the work and that feeling.
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...
This is not my experience with AI at all. The best thing that happened to me as a solo developer in a startup is Copilot in the Github mobile app.
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.
I've loved programming my whole life. Something happens inside my brain when I'm solving a problem. I think it's a release of endorphins or something that has a calming effect. When I was younger, it came easier. I used to be able to get "into the zone" and stay there for hours. Almost a constant stream of endorphins, almost a euphoria. Other things give me a similar feeling. Anything with numbers. I used to really love playing blackjack. Something about figuring out how to get to 21 just really did it for me. Or playing dominoes or other games that require me to solve something. I'm almost 65 now and it's just much more difficult to get there. I think I've been slow to adopt AI partly because I'm afraid it's going to take me further away from what I've loved. Friends tell me it's just a new tool to add to my toolbox. I'm giving it a try but I'm still skeptical.
I definitely identify with the "Thinker" described in this post, but I am routinely mulling over ideas and problems (multiple hours, days, and weeks) with the help of LLMs now.
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.)
I've had the completely opposite experience as somebody that also likes to think more than to build: LLMs take much of the legwork of actually implementing a design, fixing trivial errors etc. away from me and let me validate theories much more quickly than I could do by myself.
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 relate to the post, but I'm not sure it's hitting the nail on the head _for me_.
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).
That's exactly it for me. Coming up with a solution using my own brainpower is a large part of the pleasure of programming for me.
A silly example to illustrate the kind of guy I am: when I'm watching a show or movie, I'll often wonder where I've seen an actor before. A "normal" person, like my wife, would just look it up on IMDB and be done with it. But I almost always insist on rifling through all the dustiest corners of my brain to figure it out. Even if it takes me a day or two of thinking about it off and on. Because to me, the satisfaction of doing it myself is worth it.
I sympathize with this. I wonder if the author might find it helpful to reimagine the thinking they do as coming up with good questions, rather than good answers. I was inspired to try to do so myself after reading this essay: https://link.springer.com/article/10.1186/s13059-019-1902-1
"[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."
"When you change the way you look at things, the things you look at change." - Max Planck
I am thinking harder than ever due to vibe coding. How will markets shift? What will be in demand? How will the consumer side adapt? How do we position? Predicting the future is a hard problem... The thinker in me is working relentlessly since December. At least for me the thinker loves an existential crisis like no other.
There's an irony here -- the same tools that make it easy to skim and summarize can also be used to force deeper thinking. The problem isn't the tools, it's the defaults.
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.
I believe the article is wrong in so many ways.
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.
I agree with your points. I can clearly see the difference in myself between how I used to program before and how I do now.
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 vibe coding satisfies your need to build, then you're performing a deception on yourself. I guarantee it's still possible to satisfy one's need to create in the era of AI. Just switch off the autocomplete slot machine.
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?
The use of AI is a choice. You make that choice, no one else does it for you. I myself chose to act like AI does not exist. The author, evidently, did not. So it's odd, then, that they're complaining about the consequences of their own choices.
> At the end of the day, I am a Builder. I like building things. The faster I build, the better.
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.
Cognitive skills are just like any other - use them and they will grow, do not and they will decline. Oddly enough, the more one increases their software engineering cognition, the less the distance between "The Builder" and "The Thinker" becomes.
Thinking harder than I have in a long time with AI assisted coding.
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.
Dear author, I suggest trying out a job in a niche part of the field like firmware/embedded. Bonus if it's a company with a bunch of legacy devices to maintain. AI just hasn't quite grokked it there yet and thinking still reigns supreme :)
If you feel this way, you arent using AI right.
For me, Claude, Suno, Gemini and AI tools are pure bliss for creation, because they eliminate the boring grunt work. Who cares how to implement OAuth login flow, or anything that has been done 1000 times?
I do not miss doing grunt work!
One of the best programmers I know is a self declared thinker that also is loving this new wave of agentic coding.
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.
You can do all your thinking and minimal prompting.
I know Ralphs like to do all the prompting and no thinking.
You don't have to miss it, buy a differential equation book and do one per day. Play chess on hard mode. I mean there's so many ways to make yourself think hard daily, this makes no sense.
It's like saying I miss running. Get out and run then.
At the day job there was a problem with performance loading data in an app.
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 also recognise ‘thinking’ as a valuable and enjoyable activity - and have also obsessed about problems for days (even in my sleep)to reach a deeper understanding. But I think the issue here is the impact of AI on just that - ‘understanding’. It might be true that with AI we no longer need to have as deeper understanding in order to ‘ship’. And even if that is true I think there are plenty of other domains you can think deeply about without AI getting in the way e.g. mathematics or philosophy - where is object is often to understand in and of itself, not just the products it may generate.
Every time I try to use LLMs for coding, I completely lose touch with what it's doing, it does everything wrong and it can't seem to correct itself no matter how many times I explain. It's so frustrating just trying to get it to do the right thing.
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.
There's clearly a gap in how or for what LLM-enthusiasts and I would use LLMs. When I've tried it, I've found it just as frustrating as you describe, and it takes away the elements of programming that make it tolerable for me to do. I don't even think I have especially high standards - I can be pretty lazy for anything outside of work.
I don't view LLMs as a substitute for thinking; I view them as an aid to research and study, and as a translator from pseudocode to syntax. That is, instead of trawling through all the documentation myself and double-checking everything manually, an LLM can pop up a solution of some quality, and if that agrees with how my mental model assumes it should work, I'll accept it or improve on it. And if I know what I want to do but don't know some exact syntax, like has happened in Swift recently as I explore macOS development, an LLM can translate my implementation ideas into something that compiles.
More to the point of the article, though, LLM-enthusiasts do seem to view it as a substitute for thinking. They're not augmenting their application of knowledge with shortcuts and fast-paths; they're entirely trusting the LLM to engineer things on its own. LLMs are great at creating the impression that they are suitable for this; after all, they are trained on tons of perfectly reasonable engineering data, and start to show all the same signals that a naïve user would use to tell quality of engineering... just without the quality.
Honestly, it's about creating guardrails, and forcing the machine to stay within them.
You create the pattern. You describe the constraints. And then make it do the gruntwork.
If it's starting from nothing, and you let it be "creative" you will hate the results.
It's just a tool like any other. Hold the power drill firmly in hand and make sure you have your safety goggles on when playing with the band saw.
> My method was simply to think. To think hard and long... This method never failed me. I always felt that deep prolonged thinking was my superpower. I might not be as fast or naturally gifted as the top 1%, but given enough time, I was confident I could solve anything.
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.
Just yesterday I noticed I was mentally EXHAUSTED after building out a feature with Claude Code.
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.
So today are you doing it again? Or did you compress a week's worth of work into a few hours and the rest of the week is shot because you don't expand?
I did do it again, and spent time figuring out how to do it even more.
The cool thing though is that I could have chosen to do something else, too. I’m not at a loss for fulfilling, productive things to do. AI won’t change that.
Advent of Code (which given my schedule runs into January). That’s the last time thinking hard about a coding problem, I don’t remember exactly if it was day 10 or 11 that had me scratching my head for a while.
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.
This title and the first half of the post (before the AI discussion) just makes me miss the intellectual environment of college.
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.)
I think this problem existed before AI. At least in my current job, there is constant, unrelenting demand for fast results. “Multi-day deep thinking” sounds like an outrageous luxury, at least in my current job.
Which is a reason for software becoming worse across the board. Just look at Windows. The "go go go" culture is ruinous to products.
Even 30 years ago when I started in the industry, most jobs required very little deep thinking. All of mine has been done on personal projects. Thats just the reality of the typical software engineering job.
this is why productivity is a word that should really just be reserved for work contexts, and personal time is better used for feeding "The Thinker"
> I am currently writing much more, and more complicated software than ever, yet I feel I am not growing as an engineer at all.
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 don't. I miss being outside, in the sun, living my life. And if there's one thing AI has done it's save my time.
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.
Homeless people have the most sun and spend a lot of time outside. I hope that this is not where we are headed with AI
A lot of productive thinking happens when asleep, in the shower, in flow walking or cycling or rowing.
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.
I really don't believe AI allows you to think less hard. If it did, it would be amazing, but the current AI hasn't got to that capability. It forces you to think about different things at best.
You're extremely on point. I don't remember the last time I was able to sit around to think because at the back of my mind, I knew AI could help me generate the initial draft of ideas, logic, or structure that would otherwise require hours of my time.
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?
I heard this interesting quote about AI (paraphrasing): "We invented a cure for exercise, we should not be surprised later when we realize that we quickly run out of breath".
While I large agree, when I rely too much on agentic llm usage I come away feeling that I haven’t really learnt much over the session, and the code wasn’t really “mine”. It’s also easy to let your skills atrophy over time if you’re not careful, and for the hardest / interesting problems I often turn the llm off entirely and write out the code by hand, and come out a lot happier than just guiding Claude
After leaving my previous day job, I have some downtime to get back to thinking and realizing how much I love reading and thinking.
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.
This isn’t the point of the piece, but I have found that the thinker often gets in the way of the builder, because there’s always a better way to build, there’s always some imperfect subsystem you just want to tear out and rewrite and then you realize you were all wrong about this and that, etc.
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
LLMs haven't changed how hard it is to truly invent. What LLMs do instead is painfully rub it in that most problems already have their solutions.
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?
What a bizarre claim. If you can solve anything by thinking, why don't you become a scientist? Think of a theory that unites quantum physics and general relativity.
https://zenodo.org/records/18498514 GR is nonsense!
When people missed working hard, they turned to fake physical work (gyms). So people now need some fake thinking work.
Except for eating and sleeping, all other human activities are fake now.
you forget about fake sleeping being loaded with fake dopamine hits before sleep AND broken sleep schedules; and eating fake ultraprocessed food instead of wholefoods.
Thanks for correcting. That completes the fake life pattern.
So, people fake things to get a fake life. Reminds me a Russian joke about factory workers. "They pretend to pay, and we pretend to work".
We've always been doing fake thinking work since the beginning, see: puzzles
In my experience you will need to think even harder with AI if you want a decent result, although the problems you'll be thinking about will be more along the lines of "what the hell did it just write?"
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.
The friction didn't disappear with AI tools. It just shifted. It's now more so about knowing when to trust an AI system versus when to dig into things yourself. The key insight is this: don't devalue learning things on your own. AI is a tool, but if the tool messes up, you need other tools in your toolbox. If you've only ever leaned on the AI, you're in trouble the moment it fails on something subtle.
It's funny to think that all this discussion would not be happening if not for naive idealism embraced by software people fo decades, which enabled sharing everything they made after working hours for free and for everyone. That all it was hijacked by a handful of rich and not very altruistic people to enslave everyone comes as a big surprise. Who would have thought. I guess we arent that smart after all
I've found that AI still makes me think. Yes I use it as my 10x, but I still have to plan what I am going to do, call it on its bull, and keep it on track. AI just saves me from the tedium of typing (and lets be real, mistyping). I can't specialize in 13 different languages, but I can bring good architecture, and good practices to bear.
It's a different type of thinking in my opinion, more "systems" thinking.
I dont think LLMs really took away much thinking, for me they replaced searching stackexchange to find incantations. Now I can get them instantly and customized to my situation. I miss thinking hard too, but I dont blame that on AI, its more that as a dev you are paid to think the absolute minimal amount needed to solve an issue or implement a feature. I dont regret leaving academia, but being paid to think I will always miss.
It’s possible to be both.
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 getting back in touch with physics, reading old textbooks. But that wasn’t successful either. It is hard to justify spending time and mental effort solving physics problems that aren’t relevant or state-of-the-art
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.
Attention is squandered these days like free samples at a Costco run by raccoons. It's not hard to think hard. It's hard to have discipline.
I've missed the same even since before AI because I've done far too much work that's simple but time intensive. It's frustrating, and I miss problems that keep me up all night.
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!
You can't change the world, you can change yourself. Many people don't like change. So, people get frustrated when the world inevitably changes and they fail to adapt. It's called getting older. Happens to us all.
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.
While I see where you are coming from but I think what has really gone for a toss is the utility of thinking hard.
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.
Sometimes I miss thinking hard, but I also don't miss thinking really hard on a problem that seems difficult only to find out it was actually trivial and I was just looking at it the wrong way or overthinking it. We've all spent hours tracking down bugs that turned out to be silly syntax errors or spelling mistakes. It seems like that might be the trade off now.
On the other hand, those situations can be valuable learning experiences, and (even if subconscious) can help you learn to see things from more angles in the future.
Unfortunately, predicting which situations are worth it and which aren't is as hard as predicting anything else...
Listen... I'm just not going to use AI. This is a choice you can make kind of easily. I don't know why we have ten threads per day about AI angst. Just don't use it.
"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.
In reality, us thinkers will have to find other things to think about. Maybe not right now, but in the not-too-distant future we'll have to find other things that make us think and scratch that bit of our brains that need itching from learning new stuff and thinking hard about it.
It might be difficult to figure out what that is, and some folks will fail at it. It might not be code though.
Well, for programming work which is essentially repetition (e.g. making another website not unlike thousands of others), it's no surprise that AI programming can work wonders - you're essentially using a sophisticated form of copy paste.
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.
I guess it depends on what you build, i feel the most complex part of the deal, that makes me think the hardest, is to figure out what to build. Eg understanding the client, and creating a solution that fits between their needs and abilities. The rest is often a technical detail, yes sometimes you need to deep dive to optimize. Anyway if you miss debugging try debugging people;)
Rich Hickey and the Clojure folks coined the term Hammock Driven Development. It was tongue in cheek but IMO it is an ideal to strive towards.
I miss this too, I have had those moments of reward where something works and I want to celebrate. It's missing too for me.
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.
Make sure you start every day with the type of confidence that would allow you to refer to yourself as an intellectual one-percenter
He specifically wrote that his intellect was not in the "top 1%" of people who seemed to solve problems easily. His "1% status" was in the bullheadedness needed to pound away at a problem for days to find a solution.
The problem with the "70% solution" is that it creates a massive amount of hidden technical debt. You aren't thinking hard because you aren't forced to understand the edge cases or the real origin of the problem. It used to be the case that you will need plan 10 steps ahead because refactoring was expensive, now people just focus in the next problem ahead, but the compounding AI slop will blow up eventually.
would you agree that there's more time to think about what problems are worth solving?
When I wrote nimja's template inheritance. I thought about it multiple days, until, during a train commute, it made click and I had to get out my notebook and write it, directly in the train. Then some month later I found out, I had the same bug that jinja2 had fixed years ago. So I felt kinda like a brothers in hard thinking :)
I can relate to this. Coding satisifies my urge to build and ship and have an impact on the world. But it doesn't make me think hard. Two things which I've recently gravitated to outside of coding which make me think: blogging and playing chess.
Maybe I subconsciously picked these up because my Thinker side was starved for attention. Nice post.
I think for days at a time still.
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 think the author has discovered that coding is not what they actually enjoy.
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.
I'm not sure I agree. Actually, I don't agree. You only stop thinking hard if you decide to stop thinking hard. Nobody, no tool, is forcing you to stop thinking, pushing, reaching. If the thinking ceiling has changed, which I think it has, then it's entirely up to you to either move with it or stay still.
There are many difficult problems involved in building LLMs that I have to think about on a regular basis, which the models themselves cannot help me with. I think that just because the cognitive load has been taken off of some tasks does not mean that there is nothing that requires serious thinking anymore.
Great, so does that mean that it is time to vibe code our own alternatives of everything such as the Linux kernel because the AI is sure 'smarter' than all of us?
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.
Before I started using AI, I was already used to thinking abstractly. When I first got into AI, that way of thinking, combined with interacting with these models, really brought out the best in both. Honestly, I haven’t felt that “peak” in a while
It’s the journey, not the destination, but with AI it’s only the destination, and it takes all the joy.
AI doesn't remove difficulty so much as it removes friction, and friction was often what forced me into deeper conceptual understanding. When the path of least resistance is always "ask the model", my brain never has to build the scaffolding it used to
What OP wants to say is that they miss the process of thinking hard for days and weeks and one day this brilliant idea popping up on their bed before sleep. I lost my "thinking hard" process again too today at work against my pragmatism, or more precisely my job.
AI is way less of a problem in regards to thinking than digital media consumption is.
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.
> the number of times I truly ponder a problem for more than a couple of hours has decreased tremendously
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
Just because a problem takes more than a few hours doesn't mean you'll never get past it. And those are the problems that really grow your abilities.
The author clearly loves coding more than the output from coding. I'm thinking harder than ever and so grateful I can finally think hard about the output I really want rather than how to resolve bugs or figure out how to install some new dependency.
Then think hard? Have a level of self discipline and don’t consistently turn to AI to solve your problems. Go to a library if you have to! People act like victims to the machine when it comes to building their thinking muscles and AI and it confuses me.
To me thinking hard involved the following steps-
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.
Thinking hard and fast with positive results is like a drug, ah those were good and rewarding days in my past, would jump back into that work framework any time ( that was running geological operations in an unusually agile oil exploration programme )
I read something similar here https://open.substack.com/pub/strangeloopcanon/p/on-thinkers...
"Sometimes you have to keep thinking past the point where it starts to hurt." - Fermi
In my experience, the so-called 1% are mostly just thinkers and researchers who have dedicated a lot more time from an earlier age to thinking and/or researching. There are a few geniuses out there but it's 1 in millions not in hundreds.
If you miss challenge, the world has plenty more. Maybe it's not all your comfort zone, but if you try being a little ambitious and maybe use AI to understand a field you're not already deeply familiar with, you can continue to grow.
This reads like mourning the loss of _forced_ difficulty instead of taking responsibility for seeking _chosen_ difficulty.
Chosen difficulty is a huge part of being human (music, art, athletics, games, etc.). AI hasn't taken that away.
I have mixed feelings. On the one hand, I totally feel what this author is saying. On the other hand , I love that I am now able to push into areas that I could have never touched before, and complete successful projects in them.
I knew this sort of thing would happen before it was popular. Accordingly:
Never have I ever used an LLM.
"I still encounter those occasionally, but the number of problems requiring deep creative solutions feels like it is diminishing rapidly."
Just let it try and solve an issue with your advanced SQLAlchemy query and see it burn. xD
I feel that AI doesn't necessarily replace my thinking, but actually helps to explore deeper - on my behalf - alternative considerations in the approach to solving a problem, which in turn better informs my thinking.
This is less of a lament that software engineering was replaced by AI, and more that the challenging work has been cooped by large corporations. Mainly through weaponized bloat of platforms
Exactly what I've been thinking. outsourcing tasks and thinking of problems to AI just seems easier these days; and you still get to feel in charge because you're the one still giving instructions.
I do every day.
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.
Then work on hard problems in your free time. I've found myself clinging onto some fun ones after work lately, and I'm having fun building things in the weekends/evenings lately!
[dead]
I wrote a blog about this as well
Hard Things in Computer Science, and AI Aren't Fixing Them
https://blog.est.im/2026/stderr-04
i have often pondered if the (sometimes facetiously, sometimes seriously) postulated AI utopia scenario of humans who don’t need to work but can devote their time to art and recreational pursuits, might be a hellscape for many industrious people.
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.
I have a very similar background and a very similar feeling when i think of programming nowadays.
Personally, I am going deeper in Quantum Computing, hoping that this field will require thinkers for a long time.
I feel like I'm doing much nicer thinking now, I'm doing more systems thinking, not only that I'm iterating on system design a lot more because it is a lot easier to change with AI
It seems like what you miss is actually a stable cognitive regime built around long uninterrupted internal simulation of a single problem. This is why people play strategy video games.
I've been writing C/C++/Java for 25 years and am trying to learn forex disciplined, risk managed forex trading, It's a whole new level of hard work/thinking.
The author's point is, If you use AI to solve the problem and after the chat gives you the solution you say “oh yes, ok, I understand it, I can do it”(and no, you can’t do it).
In most research areas, if a few days thinking is good enough to reach a worthwhile conclusion, it's not "thinking hard". It's "low-hanging fruit".
man, setting up worktrees for parallelized agentic coding is hard, setting up containerized worktrees is hard so you can run with dangerous permissions on without nuking host system
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!
I definitely relate to this. Except that while I was in the 1% in university who thought hard, I don't think my success rate was that high. My confidence in the time was quite high, though, and I still remember the notable successes.
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.)
Last weekend, was struggling with traversing nested trees/recursion was funny. I did eventually solve it but probably shows my tier as a dev, not FAANG tier for sure.
That's why i'm still pushing bytes on C64 demoscene (and recommend such a niche as a hobby to anyone). It's great for the sanity in modern ai-driven dev-world ;)
> Yes, I blame AI for this.
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.
Just sit down and think hard. If it doesn’t work, think harder.
I think hard all the time, AI can only solve problems for me that don't require thinking hard. Give it anything more complex and it's useless.
I use AI for the easy stuff.
I usually think hard. I correlate subjects with different areas to find similarities.
What I miss is having other people who likes to think and not always pushing for shallow results
AI doesn’t eliminate deep thinking; mediocre companies and minds do. Don't blame everything to AI and find a true company and find a way to join them.
I always search the web, ask others, or read books in order to find a solution. When I do not find an answer from someone else, that's where I have to think hard.
That's weird as I do the opposite: think by myself, then look for help if I don't know.
The crowd that counterpoints with "just don't use it then" miss the point: The general population lacks the ability to judge when should use it and when they shouldn't. The average person will always lean towards the less effortful option, without awareness of the long term consequences.
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.
> Are we supposed to find the figurative "gym for problem solving" the same way office workers workout after work?
That's it, yeah. It sucks but it's part of the job. It makes you a better engineer.
You're absolutely right that this isn't sustainable however. In one of my earlier jobs - specifically, the one that trained me up to become the senior engineer I am now - we had "FedEx Fridays" (same day delivery, get it?). In a word, you have a single work day to work on something non-work related, with one condition: you had to have a deliverable by the end of the day. I cannot overstate how useful having something like this in place in the place of business is for junior devs. The trick is convincing tech businesses that this kind of "training" is a legitimate overhead - the kinds of businesses that are run by engineers get this intuitively. The kind that have a non-technical C-suite less so.
this also used to happened to me when I in a position that involved a lot of research earlier on and then after the product was a reality, and it worked, it tapered off to be small improvements and maintenance
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
I use Aider because it allows me to retain both personalities and still benefit from AI. It truly is the best assistant I've used.
you still can think hard but you can offload some parts to LLM when you're stuck. Then you can leave space for more hard-won inspiration. When you're faced with a high-stakes decision, evaluating all sorts of possibilities, it's really easy to maximize the utilization of your brain, so in those cases you have plenty of chance to think hard.
If you don't have to think, then what you're building isn't really news worthy.
So, we have an inflation of worthless stuff being done.
I specifically spend my evenings reading Hegel and other hard philosophy as well as writing essays just to force myself to think hard
If you miss the experience of not using LLMs, then just... don't? Is someone forcing you to code with LLM help?
I think a lot of people are struggling with this. Look at the obesity epidemic. Nobody is forcing you to buy ultraprocessed foods. Nobody is forcing you to overeat. You can still cook with fresh vegetables at home. But many/most people in Western countries struggle with their weight.
An even better analogy is the slot machine. Once you've "won" one time it's hard to break the cycle. There's so little friction to just having another spin. Everyone needs to go and see the depressed people at slot machines at least once to understand where this ends.
Nobody is "forcing" but billions of dollars on the best psychologists and marketing is doing their hundred year long best to get as close as they can to it.
They (collectively) have thousands of employees, billions of dollars, and tons of things to play with (taste, texture, appearance, mouthfeel, snappiness, salt, sweet, sugar, packaging colours and styles, slogans, marketing, brand associations, shop placement, advertising) all you have is willpower to fight against 4 billion years of evolution telling you that fatty, sugary, energy dense food is important, and a whole pile of biases and weaknesses that you aren't really aware of and they are very aware of and trying to maximally take advantage of.
Do you miss thinking hard or do you missing typing? GenAI can save you from lots of typing and stack overflow copy/paste but it’s not going to think for you. Further, think as hard as you want you’re perfectly free to do so. I get the feeling a lot of people are deep down upset that knowledge and speed with code that use to be theirs and theirs alone is now much more accessible to the unwashed masses.
Me: I put your text into AI and ask it to summarize. We really do have a critical problem of mental laziness.
My current workplace has a new mandate: All the new code must be 100% AI generated code by the end of Q1.
Best part is getting paid for that!
have a look at https://projecteuler.net/
for "Thinker" brain food. (it still has the issue of not being a pragmatic use of time, but there are plenty interesting enough questions which it at least helps)
Just work on more ambitious projects?
Exactly, go where the AI can't go.
I am building a project that AI is incapable of doing and I really need to think hard and progress slowly but hopefully it will create real value.
I, too, miss thinking hard, before I had children.
AI isn’t the only thing that changes how you attend to life.
Just give Umineko a play/readthrough to get your deep thinking gray cells working again.
I think AI didn't do this. Open source, libraries, cloud, frameworks and agile conspired to do this.
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.
I love thinking hard, it's genuinely my favorite thing, but ... we get paid to ship.
Maybe we get AI to handle the lightwork while we go on to think about different things?
Why not find a subfield that is more difficult and requires some specialization then?
> but the number of problems requiring deep creative solutions feels like it is diminishing rapidly.
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.
I wish the author would give some examples of what he wants to think hard about.
All the time. Been working on my own projects, they all require hard thinking.
> skipping the process of creation you trade the thing you could have learned
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.
Give the AI less responsibility but more work. Immediate inference is a great example: if the AI can finish my lines, my `if` bodies, my struct instantiations, type signatures, etc., it can reduce my second-by-second work significantly while taking little of my cognitive agency.
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.
This is the way I would consider using them; I just haven't really been able to figure out what I would need to get a reasonably fast and useful local setup without spending a ton of money.
Every day man... Thinking hard on something is a conscious choice.
You are doing something wrong. Ai has not taken away thinking hard
Why not think hard about what to build instead of how to build it?
"I always felt that deep prolonged thinking was my superpower. I might not be as fast or naturally gifted as the top 1%, but given enough time, I was confident I could solve anything. I felt a deep satisfaction in that process."
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.
Maybe. But I don't have trauma that causes me to tie my self worth to physical exercise. Yet when I can get myself to actually do it, I feel better. I'm not sure deep thinking is that different.
What are some thoughts for someone just getting into thinking?
The article is interesting. I don't know how I feel about it, though I'm both a user of AI (no choice anymore in the current job environment) and vaguely alarmed by it; I'm in the camp of those who fear for the future of our profession, and I know the counterarguments but I'm not convinced.
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 last year: I am now a mentor to a junior developer
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 think it's just another abstraction layer, and moves the thinking process from "how do I solve this problem in code?" to "how do I solve this problem in orchestration?".
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.
yes but you solved problems already solved by someone else. how about something that hasn't been solved, or yet even noticed? that gives the greatest satisfaction
Well thinking hard is still there if you work on hard abstract problems. I keep thinking very hard, even though 4 CCs pump code while I do this. Besides, being a Gary Kasparov, playing on several tables, takes thinking.
The ziphead era of coding is over. I'll miss it too.
Would like to follow your blog, is there an rss feed?
That’s funny cause I feel the opposite: LLMs can automate, in a sloppy fashion, building the first trivial draft. But what remains is still thinking hard about the non trivial parts.
Do some leetcode hard... you're welcome.
Many times, the really hard problems that I ask AI to solve, it solves it not so well, and that just makes me more frustrated. If you're building that just need to barely work, that's one thing. if you need things to work securely, scale, and be really efficient, I don't see how AI changes things. To the contrary, it might spit out test-cases and sample code to test your hypothesis with, saving you time and frustration, letting you focus on the architecture and problem solving.
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.
My favorite part of programming is thinking about the whole system before I write a single line of code. How will my data be structured? What does the UI look like? How do I structure the project? What tools do I use? What do I need to take out to make this simpler? Etc.
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.
reading this made me realize i used to actually think hard about bugs and design tradeoffs because i had no choice
Cognitive debt lies ahead for all of us.
AI is a cheat that ruins the game
I miss hard thinking people.
I think I miss my thinking..
“We now buy our bread… it comes sliced… and sure you can just go and make your sandwich and it won’t be a rustic, sourdough that you spent months cultivating. Your tomatoes will be store bought not grown heirlooms. In the end… you have lost the art of baking bread. And your sandwich making skills are lost to time… will humanity ever bake again with these mass factories of bread? What have we lost! Woe is me. Woe is me.”
That is a very good analogy - sliced shop bread is tasteless and not that good for you compared to sourdough. Likewise awful store bought tomatoes taste like nothing compared to heirloom tomatoes and arguably have different nutritional content.
Shop bread and tomatoes though can be manufactured without any thought of who makes them, though they can be reliably manufactured without someone guiding an LLM which is perhaps where the analogy falls down, and we always want them to be the same, but software is different in every form.
I 100% agree. Though i would argue that, like trash sliced bread, 99% of software is just CRUD reinvented over and over. Which, like a deli sandwich, is probably fine not to have artisanal bread for.
1 reply →
Man, this resonates SO MUCH with me. I have always loved being confronted with a truly difficult problem. And I always had that (obviously misguided, but utterly motivating) feeling that, with enough effort, no problem could ever resist me. That it was just a matter of grinding a bit further, a bit longer.
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.
Dude, I know you touched on this but seriously. Just don't use AI then. It's not hard, it's your choice to use it or not. It's not even making you faster, so the pragmatism argument doesn't really work well! This is a totally self inflicted problem that you can undo any time you want.
Spoken like someone who doesn't have their company measuring their AI usage and regularly laying people off.
Need to be in the top 5% of AI users while staying in your budget of $50/month!
I have a Claude code set up in a folder with instructions on how to access iMessage. Ask it questions like “What did my wife say I should do next Friday?”
Reads the SQLite db and shit. So burn your tokens on that.
And speak of the devil. Apparently the next round of layoffs had already started when I posted this, unbeknownst to me.
If you can't figure out how to game this, you're both not thinking hard and not using AI effectively.
That sucks, but honestly I’d get out of there as fast as possible. Life is too short to live under unfulfilling work conditions for any extended amount of time.
It's not hard to burn tokens on random bullshit (see moltbook). If you really can deliver results at full speed without AI, it shouldn't be hard to keep cover.
[dead]
I get it and somehow also agree with the division (thinker/builder) but I feel this is only the representation of a new society where less humans are necessary to think deeply. No offense here, it's just my own unsatisfacted brain trying to adapt to a whole new era.
I mean I spent most of my career been being pressured to move from type 3 to any one of the other 2 so I don't blame AI for this (it doesn't help, though, especially if you delegate to much to it).
Skill issue
The closing quotation from Philipp Mainländer introduces a serious conceptual mismatch with the argument it is meant to reinforce.
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.
"Before you read this post, ask yourself a question: When was the last time you truly thought hard? ... a) All the time. b) Never. c) Somewhere in between."
What?
Guy complains about self vibe coding.. stop doing it then!! Do you really think it's practical? Your job must be really easy if it is.
author obviously isn't wrong. it's easy to fall into this trap. and it does take willpower to get out of it. and the AI (christ i'm going to sound like they paid me) can actually be a tool to get there.
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.
another AI blame/praise/adapt.. you definitely didn't think hard about this one, did you
Just stop using AI, bro.
I am one of those junior software developers who always struggled with starting their own projects. Long story short, I realized that my struggle stems from my lack of training in open-ended problems, where there are many ways to go about solving something, and while some ways are better than others, there's no clear cut answer because the tradeoffs may not be relevant with the end goal.
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.
This is just the kind of thing that Dr David Burns' work on TEAM-CBT therapy deals with.
> "Long story short, I realized that my struggle stems from my lack of training"
you say, and then you explain exactly where your struggle is, and it's not lack of training:
> "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"
There you are. It's that fear. Fear comes from your brain modeling the world and predicting the future, and predicting a bad future and generating fear (or anxiety, or other bad feelings) to change your behaviour and avoid that future. So find why "doing something wrong" is making you predict a bad future, what bad future, and then find a way to fix that where you can be wrong but it isn't the end of your world, and then this fear and urge won't appear anymore.
1) one of those things like "finding out I've done something wrong" happens, or you imagine it happening.
2) you imagine some kind of negative future event that follows on from doing something wrong, this is a habit of thinking that you learned so it might be fast, almost sub-conscious, flicker of ideas and thoughts.
3) from those, your brain generates bad feelings (feelings are a high level sweeping way to change our behaviour without thinking about tons of details).
4) you get the urge to push it away and close the game, so you can avoid those future events happening, so that can save you from future badness, bad feelings calm down (but different ones may appear like guilt, shame, inadequacy, etc).
5) you don't consciously notice this happening, so you make up some other reason that sounds nice and plausible and doesn't involve changing anything ("lack of training").
6) repeat this mental habit for a long time, maybe the rest of your life.
> "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."
That's not where your problem is, you aren't lacking the ability to evaluate a trade-off, you're lacking the ability to go wrong. Being able to evaluate any situation so you never ever go wrong isn't possible, that can't be the answer. The only answer can be from becoming okay with going wrong [I hope you will feel an automatic rejection here, how can it possibly be OK to be wrong and screw something up? I don't want to be OK with going wrong! See?].
Step one of a fix is to focus your attention on "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" and push into that. Remember or find a specific example of that which makes the feeling come up - what task were going wrong brings up that feeling - write it down.
Step two, look at your thoughts at that moment, what are you telling yourself will happen next that is so automatic and habitual and reflex and fast that you can barely notice it happening, but is basically the horrible future you're always worrying about? [If it helps, imagine a cartoon character who is just like you, in that "oh no I screwed up" situation with a thought bubble above their head, and write in what they are thinking which is oh so very relatable to you].
It will be some typical human thing like "it will prove I'm not smart and my fiance or parents won't love me" or "I will become unemployed and homeless and get sick on the streets and die" or "it will prove my lifelong fear that I don't deserve respect and am inferior to everyone else" but the details will be unique to you and what you fear and worry about.
And the next Dr Burns specific step is that you need to see why you are holding onto that pattern of thought, it's not just stopping you from making progress in projects, it's got some silver lining that is protecting and upholding some other ideals you value, and you don't want to let this pattern change and let go of the fear if it means losing something else equally or more valuable (e.g. "if I don't fear becoming homeless then I won't push myself to work harder and will waste my life as a drifter", or what I said earlier "I don't want to be okay with going wrong, people who screw things up and don't care are LOSERS who make everything worse!", again, the details will be specific to you).
And then to do some therapy techniques to work out how to unpick all this, and change it, in a way that keeps the ideals you want, and releases the sticking points you don't want.
> "I cannot imagine how someone would claim that removing an exercise from my daily gym visit will not result in weaker muscles."
If you do weighted abs exercises first, then you can't do good squats because your abs hurt, removing the abs work might be an overall gain. If you do too much everyday so you can't recover properly in one night of rest, removing some more intense work might be an overall gain. If you try to do too many exercises in a rush so you can't do a good job on any of them, removing one so you can do fewer, better quality, might be an overall gain. If you hate one exercise and it puts you in a bad mood and every month or two you get a minor injury from it that knocks your progress back, removing it might be a mood boost and an overall gain. If you remove a small targetted exercise and replace it with a larger compound exercise, it might be an overall gain.
[dead]
I literally just went through this yesterday. Had a few failing tests in an unfamiliar domain. Took a cursory look, couldn't figure it out. Pasted the error messages into Claude to see if it could speed things up for me. We went back and forth for a while, pulling on different threads and trying various things. In the end, it gave up and essentially relaxed the test's assertions to make it pass.
I wasn't happy with that outcome, so I decided to invest some time in debugging through the test, tracing the flow of data, looking at the state of the stack frames and finally figured out what was wrong -- the solution was so simple and so obvious that had I just given the effort up front, it would have saved me some time and tokens.
It's a valuable lesson to take to heart. I think it's better to go from tinkering and trying it out yourself, than to go straight to AI and then giving it a go independently.
That reminds me of why I don't think that if err != nil in Go is actually a problem, because while it's annoying to have to pause each time an error can happen, it's actually very useful, because it forces you to consider all the possible failure states and it often lets you discover the flaws in your original design while you're typing in the code. This eventually leads to much better outcomes and allows for the tools I write to be much more resilient than they otherwise would.
Obviously it all goes out of the window as soon as AI coding comes into question, and that's why I learned that I actually _don't_ want AI to generate code for me. I would only ask it simple questions like "how do I do X in Go" or in some other system, but the implementation I do myself, otherwise I lose this "having to consider every error path" part, which is apparently very helpful when your goal is to write resilient software
I don't think the goal is to reject these tools, but to be more intentional about when we use them
I’ve given these sorts of haystack search struggles completely over to the LLM. Whether it’s finding a bug in code or searching documentation for the answer, I view it as a near-obsolete skill. The past couple of decades it was important to know how to chase down documentation and zero in on the one line of config you were missing. Now it’s not.
I don’t view this as a hollowing out of my skill tree, I view it as freeing myself to focus on modern skills I need to develop. Such as learning how to steer LLM context windows towards maintainable solutions in large codebases.
I’m sure I’ll be thankful now and then that I know how to manually sift through stack traces for answers. But I expect those moments to be rarer and rarer. I basically never look at machine code, but I bet that used to be an important skill for programmers many decades ago.
[dead]
[dead]
[dead]
[dead]
I refer to it as "Think for me SaaS", and it should be avoided like the plague. Literally, it will give your brain a disease we haven't even named yet.
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!!!
Short term thinkers versus long term thinkers. Just look at the end goal of these companies and you'll see why you shouldn't give them anything.
To say it will free people of the boring tasks is so short sighted....
I'm with you. It scares me how quickly some of my peers' critical thinking and architectural understanding have noticeably atrophied over the last year and a half.
Pre-processed food consumer complains about not cooking anymore. /s
... 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.
[dead]
[flagged]
[dead]
[dead]
> It (Software Engineering) satisfied The Builder (feeling productive and pragmatic by creating useful things) and The Thinker (solving really hard problems).
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. ;)
I feel tired working with AI much faster than I did when I used to code, dunno if it's just that I don't really need to think much at all other than keep in mind the broad plan and have an eye out if a red flag of the wrong direction shows in the transcript, don't even bother reading the code anymore since Opus 4.5 I haven't felt the need to.
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.
Something that people underestimate a lot is that we aren’t “brains in a jar” and the elevated states of consciousness, such as “flow”, require a deep involvement of the body. As such manual coding is much more likely to bring you into the zone than irregular interactions with an LLM.
I actually believe that there are much better ways to incorporate AI into software development than any of the mechanisms we’ve seen so far. For instance, it would make a lot more sense that you actually write the software manually and get the usual autocomplete suggestions, along with some on the fly reviews, an extension proposals, such as writing the body of a function that you’re calling from the core function you’re writing now.