> 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 LLM’s 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.
But you're comparing vibe coding to using a compiler. This is an important comparison but you don't need to use LLMs this way; that's why, I think, senior engineers are more effective with LLMs than juniors.
When coding, a few things are happening. You build a representation of what you want to achieve in your head and translate that to code, aka "typing the code", which is actually a pretty complicated process but certainly not all of the entirety of the software engineering process. Then you review what you wrote and commit.
With LLMs you still maintain steps 1 and 3. you reason about the solution, translate it to English and then let the LLM do the "typing the code". Finally you review the output.
The output review is completely deterministic and you have the opportunity to even tweak the LLM's output to match your mental model. The nondeterministic nature of the LLM isn't super relevant because it just changes how much work you do in this step. At this point it's just like standard coding minus the typing. Ultimately it's still an objective relationship with the compiler. It's very much like how tech leads engineer a system through their teams.
Assuming that you truly understand and own every line of the LLM's output, the model is almost working like a macro.
> 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.
But who will maintain those features going forward?
> I also see a lot of Devs simply trusting that the code is correct, they are losing touch with the code.
My worry is that developers can't outsource their understanding to AI forever. It's a lot of risk for companies to be accumulating code faster than developers can understand them.
In my experience, new ideas are mostly generated by people who are involved in non-software stuff
A software engineer isn't going to come up with a revolutionary new mining technique or robot or something. But someone who works at a mine might. Previously those people would go find a software engineer to try and validate their idea. Now they will go to AI
I dunno. Maybe I'm wrong, but I just don't see software engineers as being the best people to generate a lot of new ideas for domains outside of software engineering
This is why I have always advocated for getting my software engineers away from code occasionally and out into the field into whatever domain in which we're working.
We need to experience and see how the world actually works, the pain people are actually experiencing. I deeply believe we build better software that way.
Have a software engineer working for a mining company that's a good candidate to drag out into the field for a bit? Get 'em out there, encourage them to ask tons of questions.
Real example: my wife is a nurse who works for an insurance company to coordinate care for injured workers to help maximize their recoveries. I hear a ton about the stuff she has to do, and just having her tell me about how things work has given me a glut of ideas of how I could help her bypass all the administrivia so she can focus on helping the folks she's really passionate about helping. Wouldn't have had any idea about any of this, otherwise. Unfortunately for her, I don't work for her company so can do nothing about it, but the ideas!
> We need to experience and see how the world actually works, the pain people are actually experiencing. I deeply believe we build better software that way.
90% of the time when you really break down the "real" problems. You learned they aren't gon a be fixed by fucking software.
I wholeheartedly agree with you that software isn't the answer for everything; engineering teams get so deep in building that's all they can think of when faced with a business problem.
Less software coupled with operational changes would have helped many organizations I've witnessed across my career, but that's not politically palatable in a lot of places.
Domain expertise is good, but coupled with software knowledge is almost a superpower, when it comes to software projects.
I have seen projects that took 6 months when done by 1 expert + 1 engineer taking mere weeks when done by a single person who were good at both, in a competitor.
It could be that because we can rapidly generate customized programs that the dedicated software industry shrinks, but companies might stop buying/licensing software and instead bring more software engineers in house.
> 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?!"
But with a compiler you can see why the compiler did what it did, with AI you have a black box. Even if you fixed the AI model to be deterministic you could still not see why it produced the specific output for that specific input.
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.
Definitely, that's an immediate test for whether or not you actually did any of your work. Even just asking for some basic pseudo code would be a good check.
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.
I think you have a pretty narrow view of things if you consider "family or friends who work in the industry" as the only form of networking. Clubs, conferences, online communities, and build-and-release-useful-things are all effective forms of networking.
The job market is the pits and feels more like a game of musical chairs than an evaluation of aptitude and ethics. Lots of old paths are getting very narrow. Some are closing.
But we now have tools that let you just build big things, all by yourself. In this new world, bonafide coding expertise is helpful. But it's not required. New graduates should just get out there and start making things.
I think you have a significantly narrower view than them. Consider someone moving to a new city or someone getting out of jail. It takes time to do the networking you're talking about. People need to eat and networking doesn't fill your stomach.
And that's one of the risks of moving to a new city, and arguably one of the risks you take when you commit a crime worthy of jail.
As for the new city risk, you take that risk with the potential upside it could bring, but everyone will be wary. People new to a city are a risk because of all the reasons they might've left an old city.
The author shows his age by recommending that student to go into a cost center at Costco. In AI resume land you really need the keywords more than ever to both start and keep a career in this industry.
> “Yes, AI can generate the code for this assignment. Don’t let it. You have to write the code.”
I wrestle with this: In what world will _anyone_ suffer what we suffered by coding manually, reading docs, and posting in forums to learn when there's a magic "do it" button?
I don't think it's realistic that a 19 year old kid is going to troubleshoot some horrendous SQL query for 3 hours to figure out what's wrong when an AI can fix it in 3 seconds.
I don't know what the answer is tbh. Perhaps software engineering just "ends" with this latest batch of people. It's a game of chicken: can ai get good enough before the final wave of devs dies.
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
> 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 LLM’s 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.
But you're comparing vibe coding to using a compiler. This is an important comparison but you don't need to use LLMs this way; that's why, I think, senior engineers are more effective with LLMs than juniors.
When coding, a few things are happening. You build a representation of what you want to achieve in your head and translate that to code, aka "typing the code", which is actually a pretty complicated process but certainly not all of the entirety of the software engineering process. Then you review what you wrote and commit.
With LLMs you still maintain steps 1 and 3. you reason about the solution, translate it to English and then let the LLM do the "typing the code". Finally you review the output.
The output review is completely deterministic and you have the opportunity to even tweak the LLM's output to match your mental model. The nondeterministic nature of the LLM isn't super relevant because it just changes how much work you do in this step. At this point it's just like standard coding minus the typing. Ultimately it's still an objective relationship with the compiler. It's very much like how tech leads engineer a system through their teams.
Assuming that you truly understand and own every line of the LLM's output, the model is almost working like a macro.
> 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.
> increase in speed of new features
But who will maintain those features going forward?
> I also see a lot of Devs simply trusting that the code is correct, they are losing touch with the code.
My worry is that developers can't outsource their understanding to AI forever. It's a lot of risk for companies to be accumulating code faster than developers can understand them.
I think people who understand how computers and software work will be better positioned to generate those new ideas.
In my experience, new ideas are mostly generated by people who are involved in non-software stuff
A software engineer isn't going to come up with a revolutionary new mining technique or robot or something. But someone who works at a mine might. Previously those people would go find a software engineer to try and validate their idea. Now they will go to AI
I dunno. Maybe I'm wrong, but I just don't see software engineers as being the best people to generate a lot of new ideas for domains outside of software engineering
This is why I have always advocated for getting my software engineers away from code occasionally and out into the field into whatever domain in which we're working.
We need to experience and see how the world actually works, the pain people are actually experiencing. I deeply believe we build better software that way.
Have a software engineer working for a mining company that's a good candidate to drag out into the field for a bit? Get 'em out there, encourage them to ask tons of questions.
Real example: my wife is a nurse who works for an insurance company to coordinate care for injured workers to help maximize their recoveries. I hear a ton about the stuff she has to do, and just having her tell me about how things work has given me a glut of ideas of how I could help her bypass all the administrivia so she can focus on helping the folks she's really passionate about helping. Wouldn't have had any idea about any of this, otherwise. Unfortunately for her, I don't work for her company so can do nothing about it, but the ideas!
> We need to experience and see how the world actually works, the pain people are actually experiencing. I deeply believe we build better software that way.
90% of the time when you really break down the "real" problems. You learned they aren't gon a be fixed by fucking software.
I wholeheartedly agree with you that software isn't the answer for everything; engineering teams get so deep in building that's all they can think of when faced with a business problem.
Less software coupled with operational changes would have helped many organizations I've witnessed across my career, but that's not politically palatable in a lot of places.
I think the best ideas come from people who have both domain knowledge and an understanding of what's possible. Computer science gives you the latter.
If I was going through university right now I'd want to double-major in computer science and something else.
I agree.
Domain expertise is good, but coupled with software knowledge is almost a superpower, when it comes to software projects.
I have seen projects that took 6 months when done by 1 expert + 1 engineer taking mere weeks when done by a single person who were good at both, in a competitor.
It could be that because we can rapidly generate customized programs that the dedicated software industry shrinks, but companies might stop buying/licensing software and instead bring more software engineers in house.
That's what I'm hoping at least.
> I also see a lot of Devs simply trusting that the code is correct, they are losing touch with the code
It'll be interesting to see if this is sustainable. I could see it going both ways, and I honestly don't know which is most likely.
There can't really be valuable ideas that are quick to implement with few programmers.
Well, if there are, I know what I'll do over the next long weekend...
As the number of programmers decrease, the value of computer related ideas decrease.
> 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?!"
But with a compiler you can see why the compiler did what it did, with AI you have a black box. Even if you fixed the AI model to be deterministic you could still not see why it produced the specific output for that specific input.
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.
Definitely, that's an immediate test for whether or not you actually did any of your work. Even just asking for some basic pseudo code would be a good check.
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.
I think you have a pretty narrow view of things if you consider "family or friends who work in the industry" as the only form of networking. Clubs, conferences, online communities, and build-and-release-useful-things are all effective forms of networking.
The job market is the pits and feels more like a game of musical chairs than an evaluation of aptitude and ethics. Lots of old paths are getting very narrow. Some are closing.
But we now have tools that let you just build big things, all by yourself. In this new world, bonafide coding expertise is helpful. But it's not required. New graduates should just get out there and start making things.
I think you have a significantly narrower view than them. Consider someone moving to a new city or someone getting out of jail. It takes time to do the networking you're talking about. People need to eat and networking doesn't fill your stomach.
And that's one of the risks of moving to a new city, and arguably one of the risks you take when you commit a crime worthy of jail.
As for the new city risk, you take that risk with the potential upside it could bring, but everyone will be wary. People new to a city are a risk because of all the reasons they might've left an old city.
How many is too many?
> People new to a city are a risk because of all the reasons they might've left an old city.
What do you mean? You go to a new city in search of new opportunities, not to escape anything bad. The same reason you go to a new country, right?
The author shows his age by recommending that student to go into a cost center at Costco. In AI resume land you really need the keywords more than ever to both start and keep a career in this industry.
> “Yes, AI can generate the code for this assignment. Don’t let it. You have to write the code.”
I wrestle with this: In what world will _anyone_ suffer what we suffered by coding manually, reading docs, and posting in forums to learn when there's a magic "do it" button?
I don't think it's realistic that a 19 year old kid is going to troubleshoot some horrendous SQL query for 3 hours to figure out what's wrong when an AI can fix it in 3 seconds.
I don't know what the answer is tbh. Perhaps software engineering just "ends" with this latest batch of people. It's a game of chicken: can ai get good enough before the final wave of devs dies.
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