Programming

Roman builders were masters of concrete. That was how they built enormous structures like the Colosseum. They even had a special type of concrete for harbors, that would form a chemical reaction with sea water, and create an underwater concrete so hard that it's still in use.

Then Rome slowly collapsed, and the secrets of concrete were lost, and weren't rediscovered until centuries later. Scientists just figured out the thing with the sea water concrete a few years ago, but they still don't know the formula.

History is riddled with lost and rediscovered stuff.

There is a fundamental difference this post is pretending doesn't exist.

Trusting the abstractions of compilers and fundamental widely used libraries is not a problem because they are deterministic and battle tested.

LLMs do not add a layer of abstraction. They produce code at the existing layer of abstraction.

True, but my compiler isn’t demanding a $200/month subscription from me.

Compiling code to machine instructions is deterministic. That's not the case with LLMs.

I remember talking to Brendan Gregg about how he conducted technical interviews, back when we both worked at Netflix. He told me that he was interested in identifying the limits of a candidate’s knowledge, and how they reacted when they reached that limit. So, he’d keep asking deeper questions about their area of knowledge until they reached a point where they didn’t know anymore. And then he’d see whether they would actually admit “I don’t know the answer to that”, or whether they would bluff. He knew that nobody understood the system all of the way down.

I think this is the nut of building out a skilled development team. You need different people at different levels who know their area of expertise well and who are willing to admit where it ends, such that they can reach out to the next guy to step in and assist.

But also, you need the Full Code Stack as it were. Or, at least, you need a way to know where your blind spots are and understand the limit of your capacity. Otherwise, you run the risk of an "innovator" asking why they can't just dump canola oil into their gas tank or how come you can't just use hydrogen instead of helium for your balloon. And worse - plowing ahead because nobody outside of their cubicle stepped in to stop them.

You run the risk of destroying a lot of your own hard work - and possibly a lot of other people's hard work - because you didn't realize your own limits or know where to go to exceed them.

As a senior developer, I use the new AIs. They're absolutely amazing and a huge timesaver if you use them well. As with any powerful tool, it's possible to over-use and under-use it, and not achieve those gains.

However, I disagree with the comparison to knowing how hardware works. There's a pretty big difference between these 2 things:

Letting a company else design and maintain the hardware or a library and not understanding the internals yourself.

Letting a someone/something design and implement a core part of your code that you are responsible for maintaining, and not understanding how it works yourself.

I am not responsible for maintaining ReactJS or my Intel CPU. Not understanding it means there might be some performance lost.

I am responsible for the product my company produces. All of our code needs to be understood in-house. You can outsource creation of it, or have an LLM do it, but the company needs to understand it internally.

Author should probably read "I, Pencil"