It may be a byproduct of my ADHD and general anxiety, or it's a common trait among all of us workers of computers, but I am thinking almost all the time. It's one of the beautiful things about the gig to be able to be completely engrossed in something else and then have an inspired thought hit you, some solution that took you not looking at it for a moment. AI now helps me turn those thoughts into action faster than I ever could. Without it, I'd lose the thread before it ever got off the ground sometimes. Now a thought can be made at least partly real from my phone in minutes, then I can go back to what I was doing without feeling like I might lose it if I look/think away again. Just my two cents on what the technology has enabled for me.

These services are designed for that engagement loop. If they were designed to be tools to help you think, they would be much less front and center, like autocomplete or refactor tools in IDEs. This reminds me of how Google used BERT models (precursor to LLMs) to highlight relevant snippets of web pages in search results based on a search query. "Assistant-" type LLMs would be more like that (or early implementations of code assistants, like Roo or Aider).

Same way everyone gives lip service to reviewing output. I know for a fact that at work most don't, not deeply/properly. You basically can't and hit the volume that's been demanded.

> Is this replacing my thinking?

I'm extremely confident the answer is yes.

But we have to judge how much value that particular thinking has.

As an instructor, I've implemented linked list functionality a zillion times. I'm on the long tail of skills-gain from each reimplementation. But every time I implement it, I'm gaining a little more.

Now, is it worth it? Probably not. The time spent on that marginal gain would be better spent implementing something more novel by hand. So punting to an LLM, while it costs me, might be a net gain in that case. But implementing another compiler? Hell yeah, that would be replacing my thinking. I've only ever made one PL/0 compiler plus that one yacc thing in compiler theory class, and those were a long time ago.

We should quantify the loss of thinking when we decide how much to punt the code creation to someone or something else.

I too worry about the aspects that using AI is replacing in my thought process. I've built a sophisticated enough system to where agents can go out and determine the changes that need to be made for entire features and pretty much nail it out of the box. Everything is laid out in high detail during the planning phase. The implementation phase of actually writing the code is almost always unremarkable.

I have found myself going out and actually reading code less and less over the past year. I would be lying if I said that there are not fairly regular moments where I question the comfort level I have obtained with the system that I have built. I've seen it work with such a high accuracy and success rate so many times that my instinct at this point is to not question it. I keep waiting for this to really bite me in the ass somehow, but it just keeps not happening. Sure, there have been minor issues that have slipped through the cracks that caused me to backtrack, but that is nothing new. The difference is that with the previous way, I had painstakingly written that code and had a much more personal relationship with it. The code was the problem. Now whenever that does happen, I'm going back to the system and figuring out why it didn't get the answer right on its own, or why it didn't surface the whole thing in the plan to me prior to implementation.

I wrote tens of thousands of lines of code before Google and SO.

I also enjoy using AI. It makes it easier to get mundane work done quickly. Junior devs who never get tired is a great analogy. It's a force multiplier and for people with limited time (meetings, people management, planning etc.) they enable doing a lot in limited time. I can relate to more junior people being worried and/or some senior people concerns of quality though. I get a task done, review it, get another task done. I won't let it build something large on auto-pilot.

One thing that should be noted is that life was simpler back then. You could know the syntax of C or Pascal. You knew all the DOS calls or the standard libraries. You knew BIOS and the PC architecture. I still used reference manuals to look up some details I didn't have in my head.

Today software stacks tend to be a lot more complicated.

Funnily enough, I learned to code “depth first” by putting together enough documentation examples and stackoverflow answers to reach a working Android app, long before I learned to code “breadth first” in school.

> No one misses coding in assembly.

It's only your opinion that is provably false.

First, there are still people who don't like high level languages and don't use them, because they find assembly better.

Second, I personally work in a field where I need to consult the source of truth, the actual binary, and not the high level source code - precisely because the high level of abstraction is obscuring the real mechanics of software and someone needs to debug and clean up the mess done by "high level thinkers".

High level programming languages are only an illusion (albeit a good one) but good engineers remember that illusion is an illusion.

You can write unambiguous (UB-free) code and the compiler's output will be deterministic. There will even be a spec that explains how your source maps to your program's behavior. LLM has neither.

Also, if you need to control performance, you still need to know how CPU cache and branch prediction works, both of which exists at the abstraction level of assembly.

Compilers are a layer of abstraction that we can ask another human about. Some human is there taking care of it. Until we get to the point where we trust AI with our survival it would be good to be able to audit the entire stack.

I suspect there are at least as many programmers working as the ASM level today than there ever was - they're a lower proportion, but the total number of programmers has increased dramatically.

I wonder if this sort of trend will continue?

Look at the comments about MSVC removing inline assembly as a supported feature for a counterexample. :D

(A competent assembly programmer can go miles around a competent high-level programmer, that's still true in 2026...)

At a high level of abstraction, the product owner can talk to the LLM directly by themselves. The "engineers" will have abstracted themselves out of a job.

This isn't just another translation layer, though. It's squishy and stochastic. It's more like saying "managers think at a higher level of abstraction". Which is true, but it's not the same as compiled code.

GenAI is like a non-deterministic compiler. Just like your manager's reports except with less logical thinking skill. I'd argue this is still problematic.

> Creating a full plan by yourself feels like a waste of time, since you know the AI can create the same or better plan in a split second.

It IS a waste of time if your only goal is the creation of the plan. However, one must be very self-aware of their goals because if one of the unacknowledged ones is to retain the ability to create plans, then you must continue creating plans yourself.

It’s because senior management builds processes with a base assumption of unreliability because a good chunky of employees are.

Thats why they’re relaxed - it’s just switching from one sort of unreliability to a slightly different flavour