Code at the speed of my understanding

We are getting dramatically better at producing software whilst removing the activity through which we learned to produce good software.

The internet seems to be filled with articles about tokenmaxxing¹, software factories² and arguments that software engineers are cooked³. This piece is not about how good coding agents are or will become. I am personally more concerned that there is not much discourse about the fact that so many of us are outsourcing the thinking⁴, whilst also removing our primary source of on the job learning.

My favourite thing about being software engineer has been learning new things. Whenever I knew that I need to learn a new database, framework or language - I would get extremely excited! I would spend hours pouring over all the beautiful abstractions someone else had developed. It is not the reading of the documentation which was great, it was the fact work forced me to encounter abstractions, form models of them, make decisions, get them wrong and revise my understanding. I never needed to set aside time to learn, it was an unavoidable by product of doing the job.

Today that is not how we work. We are shipping 24/7, everything is about pure speed. We are optimising IDEs for management of multiple agent streams. We jump between tabs and screens pretending to make "higher order decisions"⁵, which is basically just means agreeing to whatever Claude or Codex have suggested. AI does implementation, humans do judgment. Sounds great, but where did our judgment come from?

Occasionally something breaks. So you may ask you agent to debug and report back to you "the smart human" what is up.

`invalidate(key)` doesn't fence pending `getOrLoad()` promises, so a pre-commit
read can resolve after eviction and call `cache.set(key, v_old)`, violating
read-after-write consistency until the TTL expires.

The words we can understand, but we can no longer map them to a mental model of the system⁶. Why? Because you do not know your system anymore. You are no longer the expert in how your code works. You have stopped learning at work and traded this for dopamine hits from rapid shipping using the AI slot machine⁷.

Research into learning makes an important distinction, performance is not the same as learning ⁸. We can get dramatically better at completing a task without getting better at doing it ourselves in the future.

Research into AI assisted programming is already showing this. In a recent study, developers using AI completed tasks faster, but scored worse on a subsequent test of their understanding, especially on debugging ⁹. The interesting part is that people who used AI to ask conceptual questions learned much more than those who delegated the work.

So yes, AI can be a tutor. But only if we use it like one. If every interaction starts with “do this for me”, we should not be surprised when we get the work done without having learnt anything.

If we stop learning, and fail to grow our expertise, where is the next set of novel ideas going to come from? Are we happy to let our own mental capabilities degrade whilst AI continues to make progress? If yes, one must ask themselves what you plan on doing with your time once that boundary is crossed from which there will be no easy way back.

I am now optimising my engineering environment for learning. I do not want to code slowly. I want to learn and code faster, but I do not want the codebase to outrun my understanding. I want to code at the speed of my understanding.

Syntax may well be cooked. But the need to think slowly and deeply enough to build a theory of how our systems work ¹⁰ are not inefficiencies I want to automate away.

I hope to share more about how I am approaching this over the coming weeks. If you share these concerns, I would love to hear from you!

References