> Is Coding → Prompting like Assembly → High Level Coding? […] I do not agree with this simile. Compilers are, for the most part, deterministic in a way that current AI tools are not.

It’s not quite about the determinism. It’s about being able to reason about the relationship between source code and compiled program with formal precision. You can predict which changes in the source code will lead to which exact changes in the behavior of the compiled program. The same isn’t the case about changes to an LLM prompt and the LLMs output.

You could make an AI deterministic by fixing its source of randomness. That still wouldn’t allow you to reason about how its output will change when (for example) you add or remove a word in the prompt. The only way to find out is to run the LLM (= have the prompt run through the model and observe what comes out).

That is the fundamental difference. Changes to source code have predictable and reason-able outcomes. You generally don’t have to compile the code and test it to know how precisely the change will affect the behavior of the compiled program according to the semantics of the programming language. That’s the case even if the compiler uses some probabilistic heuristics for trade-offs in code generation, and hence isn’t deterministic on the machine code level.

To repeat, the difference is how you can reason about a compiler’s behavior versus an LLM’s behavior. Programming languages are designed such that you can reason about it. With LLMs it’s always an experiment.

> Is Coding → Prompting like Assembly → High Level Coding? […] I do not agree with this simile. Compilers are, for the most part, deterministic in a way that current AI tools are not.

I have a very different view of this, coming from C++. "Undefined behaviour". Compiler optimizations that only kick in if you align your chakras just right. Memory alignment and cache locality being completely vibe-based, relying on hopes and prayers that the CPU actually does what your mental model thinks it will.

In many ways it's EXACTLY like C++ -> Assembly. You never know what you ended up with until you run the benchmarks, just like you never know what your AI generated until you look at it!

"What do you mean? This worked in the debug build! Why does it crash in release?!"

> I explain that, if they don’t write the code, they will not be able to effectively read the code. The ability to read code is certainly going to be valuable, maybe more valuable, in an AI-based coding future.

I'm not certain of this. Thinking back to when I first started in my career after graduation- I remember feeling like my ability to write code had improved greatly during my time in school. Meanwhile, my ability to read code felt like it had barely improved at all. Even now, after over a decade in the industry, while both skills have improved tremendously, I still feel like my ability to read and internalize code is not at the level I would like or assume it to be simply as a result of my experience.

It could very well be that reading and writing are two separate (though related) skills that require intentional practice and honing on their own. I can't speak for everyone, but reading code as a skill, for me, only really began to develop once I had a job where it was expected of me.

Maybe it's possible to learn to read code without learning to write it. It certainly feels like its possible to learn to write it without learning to read it.

I disagree with the author. I think as LLMs get better at coding it will be more likely that that fewer devs will be required to keep systems running and progressing, the bottleneck at my company is already new revenue generating ideas. We've seen a roughly 30% increase in speed of new features, so the same number of devs are building a lot quicker. I expect that to continue to increase. I also see a lot of Devs simply trusting that the code is correct, they are losing touch with the code.

I don't think I would encourage my kids to get involved with programming, instead I would encourage them to become entrepreneurs who might use some coding.

No, but... is the better answer in my mind. Learning to code is a considerable commitment. It takes years to get good enough to produce professional-grade software. If you extrapolate from the improvements we've seen in coding AI over just the last 12 months, this is just a bad allocation of your time.

Instead, as the article points out, learn to become a translator between the real world and AI code generation. Learn about industries that are relatively underserved by technology. Don't build tools for developers or engineers. Learn about construction, mining, waste management, oil and gas, manufacturing, logistics, government... then become the link between that industry and AI's ability to add value.

(Emphasis on relatively underserved — all of these have high-tech versions in some places, but the future isn't distributed evenly.)

Didn't you guys have to handwrite your code during exams, at least the basic programming classes? I feel like that's an immediate reason you need to know how to code.

Well, it's sad that the professor's advice for how to get a job today is "networking", same as it always was. I feel bad for those who don't have family or friends who work in the industry.

On the advice to junior devs to work intentionally and slower than their vibe-coding peers, I see an analogy to the advice given to student journalists at the start of newspaper subscriptions being replaced with online news access.

There will be a few developers that will work slowly and have the best understanding of the work at hand, but in my opinion the majority will be stuck at companies churning out whatever gets them paid.

Fast vibe-coded solutions that frees up time to work on more and more paying projects is what capitalism demands.

The Capitalism motivator rarely slows down by choice, because capitalism only cares about numbers going up, not people or their determination

[dead]

[dead]