Knowing what your software does is such a hard problem. Most developers have an idea but if you ask, how are you sure?, the answers reveal how little they know.

Most often we’re satisfied with signals and indicators that it works and we build theories and mental models that use to try to avoid the effort of proving anything.

Worse is what happens when you start using LLM models to generate the code for you. I find you start losing the mental model short-cuts; you start to trick yourself into understanding the code. You understand little.

And what few studies there are of code review suggest that we have very little impact on code quality after reading more than a couple hundred lines of code over an hour.

So the current mental leap is, “the AI is a better programmer than I am.”

I think it’s still worth becoming a better programmer regardless. And there’s no royal road. You just have to write code and struggle with writing bad code.

When I started working in the 80s in my first job, the head of department had banned the PC for administrative tasks. He thought that the old manual process was more reliable and allowed him to better control what was going on. He retired one year later and the PC were introduced successfully shortly after. Was he wrong to push back ? At that time, that was what I thought. But now, 40 years later, I don’t think so anymore. I think that that delay gave the proponents of the PC the time to prepare themselves a lot better and is a reason for the success.

I can’t help drawing a parallel with what is going on now. Even though I’m pro AI, I understand why QGIS is stepping back. There are a lot of places where the processes and tools are not ready yet to fully embrace it and you need time to prepare.

> the bottleneck is no longer writing code but staying aligned with it, knowing what it does and whether it does what you meant.

Perfectly and succinctly said.

Agreed.

The way I like explaining this to people is that I don't think I build products anymore. Now I build the harnesses which build the product. And a massive part of that is ensuring that I can make the AI remain aligned with my way of thinking.

I think the economics just change drastically. A few years ago a helping programmer was great help and would implement something that was agreed to be needed to be done by the project or something very important for the contributor (the reason they spent the time to contribute). Now anyone can get a 20$ subscription and prompt away, but so do the project's core developers. So why should they bother separating the wheat from chaff? I totally understand that.

I fully agree with you. But I feel like I have taken the opposite approach. Staying aligned with the code is such a burden that I don't think AI is making my job easier so I stopped using it.

> but staying aligned with it, knowing what it does and whether it does what you meant

That’s the old “Programming as Theory Building” stated by Peter Naur. Writing code, once you learned a language and a few libraries has always been easy and can be made easier by using tooling. Having a good understanding of what has been written and what needs to be added is the difficult part.

I think for every line of code I’ve written, I spent 2 to 5 hours reading specs and docs. Creating software is always about understanding. If you’re thinking too much about syntax and libraries symbol, you’re just at the beginner phase of coding. Like thinking about grammar when learning a second language or being hyperaware of the car as a beginner driver.

> the bottleneck is no longer writing code

The bottleneck has never been the writing of the code. It's all the rest that takes the majority of the time. Of course, it is often the writing which lets you expand your understanding or your awareness of challenges and pitfalls, which then puts you back on the drawing board.

It is honestly impossible to review the amount of code that AI generates and we dont know how to adapt yet, review line by line is already outdated imo, we just don't know what should replace it.

My prediction is that in the future we are going to be more focus in the testing part (that should be more human readable) than the code itself.

Whatever it is, the only thing clear to me is that the tooling will have to change.

That's why I'm now considering what are the ratio for each language in term of exposing the business logic nub that human can grab (mostly) correctly vs all the clutter that is here mainly to bring additional type safety and please the compiler in some way.

One approach that Ruby took for type introduction was to put that in a different file. That comes to my mind.

Typescript brings some niceties, but also some boilerplate all other the place. Combined with something like Effect, Zod, and the like and line count explode. Not sure OCAML or Haskell would provide more compactness for equivalent safety.

So, you ask an LLM "what does this code do?" and it spits back a long list of things.

Is the fear that it is (maybe wilfully) misinterpreting the code, being too general, not going into specifics or is just not smart enough to catch all the nuances, privacy issues and hidden mistakes? Is it a token issue? A combination of all this?