I started programming when I was 7. I'm 50 now and the thing I loved has changed

>The thing and bothers me the most though is that computers increasingly act like humans that I need to talk to to get things done, and if that wasn't bad enough I also have to talk with people constantly.

Exactly how I feel. Mainstream tech has become increasingly frustrating for me to deal with, I can only assume because of its mass adoption and catering towards the average person.

I'm seeing processes that were difficult and involved humans in the past now be replaced not by better technical solutions, but by LLMs masquerading as the humans, making it even more difficult. Ex: a customer service phone call but now with a bot.

I used to hope that I would one day be able to make appointments using an online calendar, but now I'm expecting I'll still need to call, but "talk" to an AI, still during business hours.

I have seen coworkers, who are otherwise very nice people, become rather nasty when given some authority over other's code in the form of code reviews. The code review turns into "this is how I would have written it, rewrite it."

What we did before code reviews: we would get together with our fellow engineers in front of a whiteboard and knock out the structure of the code one was tasked with. We'd argue whether caching is necessary or if the framework provides it for us. We'd talk about concurrency issues and whether to use semaphores or locks…

Once the plan looked good, an engineer was trusted enough to go off and implement it.

Unit tests are fine. Before unit tests we had coworkers (QA) that did full test suites for integration, functional testing. At the more "unit level", robust param checking (with assertions, logging) happened early within the functions that could fail. (Obvious example: checking for zero in a function that might use that value to divide. Its a kind of unit test in situ.)

Of course when management uses unit tests as some kind of replacement for actual integration and functional testing they become an end unto themselves (bonus: the company is also able to lay off QA).

Before there was some understanding that at least they wrote and understood their own garbage code

Now it is not true. Someone can spend a few minutes generating a non-sense change and push for review. I will have to spend a non-trivial amount of time to even know it’s non-sense.

This problem is already impacting projects like curl who just recently closed their bug bounty because of low-effort AI generated PRs

> And I thought: mate, you were already so far up the abstraction chain you didn’t even realize you were teetering on top of a wobbly Jenga tower.

But AI is different. If I program in a high level language like Python, sure I don't know what's going on under the hood. But you get a 'feel' for it because the same code usually reproduces the same results. Does AI reproduce the exact same results when I ask the same thing? That I don't know.

> You are not understanding the point. AI has to be properly supervised because it makes mistakes.

It been well over a decade (ironically until AI) that I have been responsible for an implementation small enough that I could do with my own two hands within the allotted time by myself. People also require supervision.

Now if you are making more or as many mistakes as the AI, then you should look for a new career.

Right now in 2026, the code I write is dependent on the AWS SDK.

https://boto3.amazonaws.com/v1/documentation/api/latest/inde...

It’s the same surface area for every supported language - as new features come out AWS uses code gen tools to update the SDK and CLI based on a common set of specifications.

Consider it’s the same surface area as when I have to write IAC. Are you saying it should be faster for me to know that API and write it by hand than an LLM? Especially now that AWS has an MCP server that AI can use to know the latest documentation. The case was the same in 2000 when I had to write C and C++ against the Win32 APIs, DCOM etc or when I didn’t know the entire C++ STL and had to reference the “C++ programming language ”.

> You should understand the code better than the AI, because the AI has a limited context window, and for a large codebase, you should know that codebase better than the AI.

Every developer should know the entire codebase even when they first join a company? Even when I was working at a 70 person startup, that had three teams not one person knew the entire codebase.

> But you -- you as a developer -- need to understand your codebase. If you do not understand the codebase, you can't properly supervise the AI.

Again how large of a codebase is a developer suppose to know? S3 for instance is made up of 300 separate microservices. Is a single developer suppose to know how it all works?

Besides that’s why we have unit tests and should be writing modular code so you don’t have to worry about spooky action at a distance.

And people are so focused on “the code”. I have designed systems and architectures that include code and multiple teams and consulting companies. Am I suppose to know how all of the code works?

> And there is one efficient way for you to understand a big complicated codebase. The most efficient way possible for you to learn it. That is by you writing code in that codebase, and debugging that code, and learning how to code in that codebase.

Before AI, when coming into a team, I didn’t just start “coding” I would ask other people. Now I ask AI.

Are you really saying that you can keep more of the code in your head than AI with a one million token context window or that you can read and understand various markdown files in a repo faster?