I spent a long time honing my trade and I did learn a lot in the process, so I want to believe this argument, I really do. But then I imagine it applied to a lot of pre-industrial era jobs and I am not so sure.

"Master, should I still learn to weave our beautiful Persian rugs by hand?"

"Yes, and... Have you seen one of these mass-produced rugs? They all look the same and their quality is terrible! And how would you ever operate one of those new machines if you don't know a good rug from a bad one? By learning to weave manually, you are also learning about choosing the right yarn, negotiating the right prices with the merchant down at the market, selecting a good apprentice to pass down the trade. All these things will always be useful!"

Yes, there are still artisans making and selling beautiful rugs at premium prices. But most people now are content with resting their feet on a cheap Ikea thing that they can replace every few years, so that market has shrunk to almost nothing.

Hello all, I wrote this article to help students considering CS as a major.

My own son has just started university studying CS, so I have skin in this game.

I continue to believe in what I've said in this article despite being startled (like most people) by the advances in AI recently.

One thing that I have noticed since writing this article is that the most effective vibe coders are already excellent developers, which I think is in keeping with the themes I discuss here. While I do expect the amount of hand-written code to decline, I think that knowing how code (and technical systems) work is going to continue to be valuable and perhaps even more valuable. I have no crystal ball, but that's what I'm seeing right now.

> 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.

Vibe coding has always existed,

it wasn’t written by llm, it was called spaghetti coding, permanent “hot” fixes, absence of commenting, etc…

developers already provided quick programs that were riddled with bugs and insecurities, and guess what, companies didn’t care because you earn more money by outputting lot of shit than one polished diamond.

I read this when it first came out (Feb 2026) - I agreed with it then, and I still agree with it now. But I also just think that knowing the fundamentals is important, some people really believe we're "skipping a step" and that won't be important. Either way, people who already have good fundamentals are probably going to be using them WITH LLMs, and it doesn't take a ton of practice to "keep up" with fundamentals (see an expert jazz guitarist play a C scale, rudiments come back quickly when they're engaged).

Are people still writing any code by hand? My VP doesn't even READ code anymore. I rarely write code, but I've found a great spot between "full offloading" and staying really in tune with the "actions" I'm taking as together they form the "whole" deliverable at the end of a project / task. I still try to understand what the problem is, I draft a solution to solve it, then sometimes I'll give that solution to AI, and other times I'll compare my solution with the AI solution.

But, for the most part, I believe I'm somewhere in the middle? (Yes it's faster to use AI to generate code, but I still want to see that code when it's done and make sure it matches the broader system)

I'm mostly curious what other devs experience is...

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.

> 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.

This article was similar to what I told people a year ago. A year later and AI used properly is a better programmer than I am. Used properly means given meticulous guidance to write production quality code. I see very few people using AI properly now, but that will change soon, particularly if lower cost options become widespread (you need to spend a lot of time and tokens on testing and verification). It's not that delivering hand-written code will just decline, it's that it will be like writing assembly- something that's unsafe and needs to be justified.

The job of a programmer is now to be a technical lead and work through technical decisions with AI, write specs, and review work. But as AI gains intelligence and organizations figure out how to give it access to the information it needs, it will make better technical decisions than humans.

As long as a programmer can in some way produce more value/$ using AI then someone that doesn't know programming, then there's a huge value to programmers. But I don't see the place where AI can't go up the chain and do that itself as it gains more intelligence.

This is effectively true of any job that can be done at a computer. Although programming is one of the more difficult jobs its also one that is easy to train on. My advice if one's main goal is job security would be to do something in the physical world.

I agree with basically everything said here, BUT i wish people would stop (mis)using the word "deterministic" in this way:

> Compilers are, for the most part, deterministic in a way that current AI tools are not. Given a high-level programming language construct such as a for loop or if statement, you can, with reasonable certainty, say what the generated assembly will look like for a given computer architecture (at least pre-optimization).

> The same cannot be said for an LLM-based solution to a particular prompt.

This is the correct and meaningful difference to point out here, but it has nothing to do with determinism. LLMs could be perfectly deterministic and still suffer from the same problem. The problem isn't that LLMs themselves are nondeterministic, it's that language is imprecise, and language models themselves are (for the most part) black box text processors. An imagined piece of functionality ("feature") has to pass through both of these somewhat opaque steps before it ends up as code, unlike code that is processed by a compiler, where both the constraints and the structured /formal understanding of the input are much stronger which allows us to reason about and trace the relationship between inputs and outputs in ways that we can't for LLMs and natural language.

I really think there are two possibilities here.

Either we'll still need humans with an understanding of the code to oversee the agents and guide the overall architecture

or

Agents will be able to do the oversight as well, and humans will truly need to do almost nothing. But if LLMs are capable of that, they will also be capable of virtually any other job, and the entire way we think about the economy and work is going to fundamentally change.

I don't really see a middle ground where AIs can take over every aspect of software development but not other fields. Maybe blue collar work will remain, assuming the ability to create virtually infinite amounts of software doesn't lead to major advances in robotics. Either way, there is no reason for software engineers to be uniquely worried, at least over the long term.

> However, I think that this is a temporary situation and that soon companies are going to realize that vibe coding at speed suffers from worse complexity explosion issues than well understood, deliberate coding does.

If you're working for a company where the the top level of management doesn't have a CS background, don't expect this to happen.

More often I read everywhere that people barely write code anymore but somehow it is still important that you know what the code do.

I don't think this is true in any shape of form.

If you are not writing code no matter what kind of seniority or edge you think you might have you too are going to be obsolete in maybe 4-5 years or less.

I really wanted to become software engineer/developer whatever, this is a dead dream now it is like the great depression. The market is absolutely brutal and I don't see a way that things are going back to normal or pre LLMs, especially given how to industry reacted and followed the hype and everything around it.

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.)

Completely agree with the “You must write the code” sentiment.

Even leveraging the power of AI, I still write the code, but ask AI to clarify concepts and plan things out if it’s completely new to me. In that perspective, AI is the senior programmer who assign tickets to me, a junior who writes code by hand, at least as much as I can.

I also purchased many technical books (one of them, I’d like to brag, has a personal signature of Dave Cutler himself, which I just found out a few days ago, which is very encouraging to me while recovering from a surgery) to read slowly and loudly and repeatedly, to make sure I fully understand the knowledge.

Perhaps this is not really good career wise, so I leave this style of learning to my hobby projects.

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.

> Maybe they don’t start as a “computer programmer” there, maybe they start as an analyst or some other role. But the ability to program on top of that role will be very valuable and likely set up a great career.

I believe this is the best advice in the thread. The ability to build custom programs that solve real corporate problems is an invaluable skill: - An accountant who can code is a 10x accountant. - An analyst who can code is a 10x analyst. - A procurement manager who can code is a 10x procurement manager. The list goes on.

You don't need to be part of some new 21st-century enlightenment of Rust programmers. A bit of JS, Ruby, or Python here and there, layered on top of an existing corporate skill, is so valuable to a company it's crazy. I think this is a way to be explored for juniors struggling on the job market today.

Programmers make computer programs. LLMs make making computer programs more affordable and efficient, resulting in more computer programs and higher demand in programmers. We don't know what programming would be like in 10 years, but why would demand in well functioning computers go down?

> Some people say that the move from high level languages to AI-generated code is like the move from assembly to high level programming languages.

> I do not agree with this simile.

I spent a while believing that the transition to AI-based development was similar to the shift to lower → higher level programming languages. However, like the author I now believe that this is an apples to oranges comparison, albeit with a slightly different take.

Chiefly it's because working with an LLM is working with output that is stochastic by nature and involves a different kind of broader, systems kind of thinking. The LLM ultimately outputs a deterministic product: code. You can decide (as a junior or newcomer) if you want to understand the code, or not.

I don't think it will matter that much in the end -- in the general sense -- whether software developers take it upon themselves to understand code though. I think if you want to become a well-rounded craftsperson or a "true engineer", you are always doing yourself a service to understand inner workings and "how the sausage is made".

Plenty of roles today which are instrumental to software products do not rely on code understanding. Product managers, Product designers, Designers (in general).

Somebody who designs an object or appliance made by injection-moulding plastic doesn't need to understand how to create moulds or make a model using wood -- but it sure helps them, as a thinking person, understand their products and the world better.

> "you must write the code."

Maybe? I think _understanding_ code is the ultimately goal, so that you can direct the effort of AI (and humans).

There's an assumption that writing code is the only way to truly understand it. That may be true... but maybe not. I think writing code is still part of the journey, but it might be a lot less writing and a lot more reading.

Either way, I think there's a bias of us gray hairs we need check at the door.

AI programming is like the wind.

Do you take your hot air balloon up and trust where the wind takes you?

Do you sail across, into, and down the wind, using its power but still choosing where you go?

Do you cycle under your own power, lifting your saddle, tucking your head down, and trying to avoid the wind’s effects as much as possible?

All three are valid! Most people can’t sail or produce 400W with their legs, but most people can operate a hot air balloon burner. The capital expenditure part of this analogy might work as well:

the balloonists spends a reasonable amount of money to ride where the wind takes them;

the yacht crews spends fortunes to conquer the world as first-class wind masters;

the cyclists go it alone through sheer human strength and persistence, with a handful of them being astonishingly good at it.

(I cycle to work btw, albeit on a 50lb Pashley cruiser. Bike level autonomy at, erm, hot air balloon speed!)

I've programmed for 30 years so I'm probably mentally locked into thinking about the code underneath it all. But I never understood the details of the electrons moving around in the computer, and it took a long time to even consider what happened as my code trickled down the compiler/JIT, into the OS, down to the CPU.

I don't think it's productive to tell students today they must spend all their time understanding the code. Because it's clear now so many people will bypass that, even myself included. Some of the most fun I have with software these days is figuring out how to make it without looking at the code (for now on side projects only, see below).

I agree we're not quite all the way there yet to do this with large production systems. Yes, LLMs are highly fuzzy and non-deterministic things, but so are electrons! As computers improved we handled random bit flips that would occur due to a large number of unpredictable reasons. In either case, we have to reach a high enough confidence and redundancy bar that it doesn't hinder our productivity.

Raising confidence and redundancy in code output from LLM is still a nascent field. We're learning some things like "maybe unit tests don't work as well for LLMs as they did for humans", and "if the AI can self-evaluate in a loop against a factual number, it does a lot better".

But yeah, in this rapid wave of change I would consider "write the code yourself" more and more similar to "know how your CPU does branch prediction so your loops perform better", and the majority of our efforts will need to go into raising our confidence in this new fuzzy shape of software.

I do a lot of interviews for my employer and anecdotally the current batch of college hires seems worse at answering the questions I give them than prior groups. I try to avoid leetcode style questions unless they tell me they've done competitive programming. Typically I ask a somewhat open ended question that requires implementing some complicated but not particularly tricky business logic. I used to be able to ask a few follow-up questions that added additional requirements but lately I've found candidates struggle to even finish the original question. It may not matter since the reality is LLMs could handle the sort of questions I ask just fine, but I do wonder what the long-term affects of this decrease in coding fluency will be.

> AI is a great TA

> Another thing that I tell my students is that AI, used properly, is a tremendously effective TA. If you don’t use it as a code-generator but rather as a partner to help you understand concepts and techniques, it can provide a huge boost to your intellectual development.

I've found this useful myself here and there in picking up new concepts and just generally working my way around their basics. If you toy with this around cybersecurity stuff in particular, you can also test different models for guardrails this way.

I actually put together a writeup[1] a while back on using this and my own logging data to give myself a crash course on SQL. (And still end up referencing it semi-frequently...)

[1] bhmt.dev/blog/osquery

I agree with practically everything you wrote here! I wrote a piece on how software engineering is changing and might continue to change, which makes some similar points, but less eloquently/concisely (https://henryarmburgjennings.com/blog/splitting-software-eng...)

Do you have a way I can subscribe to anything you write in future (RSS feed/Atom/mailing list)?

I'm in the other camp. I do think we have achieved abstraction of what we know as code (and gaps are being filled rapidly). Today I'm able to build, improve, and maintain programs of decent complexity, all without writing or reading a single line of code. Programs that could have easily taken 6+ months is ready in hours. Determinism or not, I'm able to ship useful solid programs without coding. I even have an online course for non-coders to build and launch their ideas in under an hour.

> I do think AI is going to change computer programming. Not as dramatically...

Well, academia is the last industry that is going to change.

People pay for education regardless of how employable they're in the end. So the whole field is pretty much detached from the rest of the world. They're not interested in change, it would undermine their job security.

My employment has been terminated multiple times in the past. I _had to_ change. There is no other way to be marketable.

Academia is not that. Their business is to fill you up with obsolete tech and take your money. Don't trust them.

At this point I see no reason why Claude cannot become a great software engineer in a few years.

It is certainly learning faster than any student I've ever seen.

I can compare this to my early days. At first I was using Visual Studio like everyone else and relying on auto-complete and built-in symbols to figure out how to make something, or I would just copy and paste examples from the internet, and then tweak until something works. But what actually made me understand what I was doing was switching from an IDE to a simple code editor. Because then I couldn't use auto-complete as a crutch, I had to actually read the documentation, understand how a library is structured, which methods are supported, what the parameters are. This helped me slow down, learn the concepts, instead of blindly throwing things at the problem and seeing what sticks. And I'm having a similar experience with the AI now, it's easier to just prompt continuously, feels productive, but then I find a bug or bad logic and trace it down to a prompt where the LLM made a mistake that I wasn't aware of, and this happens a lot. The solutions it provides are rarely optimal and it's easy to fool yourself that it handles everything.

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.

It's the architecture. That's the correct answer here. The current models produce good implementations. They're also quite good at identifying and planning for edge cases. But, today, a successful software project requires picking the right atoms for the job.

Some of the calculus for that picking will change, since volume of code that must be produced becomes less of an issue. And I don't doubt that models next year and year after will be able to make better formative architectural choices. But as it is now, I'm certain that actual systems handling real workloads require a human designer.

Someone who knows what good software looks like is empowered with agents. Someone without that knowledge isn't going to create a high quality system yet.

The one thing that we should look at given recent advance in maths using lean is, computer science will ( and should be ) used to create appropriate language for other fields ( biology, process, chemistry, games, movies etc ). ( hammer / nail analogy ). Science <-> Engineering used to be about representing anything in math so as to define and solve it, now onwards it will be about representing it in a language.

Weird that is exactly the theme in Ted Lasso Season 4 Episode 7 but the article seems to have been released February 27, 2026 while the Ted Lasso Episode was released September 16, 2026. Who's original idea was this?

I disagree that one needs to read the code to understand the system. I think eventually AI agents can form a layer of abstraction above it.

Given the writers domain, and ease of getting high quality answers for free. I will turn it around. You may get my reply, for a fee of 25000 euroes. :)

I fear new models will eventually gain the ability to generate straight machine code, or some frontier lab will introduce their own compact (in terms of tokens) intermediate language as a competitive advantage, at which point "software development" will completely collapse, because:

1) humans won't write or understand code anymore, and current programming languages will be obsolete like COBOL

2) "open source" will be dead

3) developing software will necessarily mean relying subscribing for a model from a oligopoly

4) the AI labs will control what kind of software gets developed (including, not being able to use a model to develop a model) because it will be strongly regulated, citing security risks, China, or whatever

I have no no need for this, but I guess beginners could ask AI about a programming task and instruct it to ask them questions on which step to implement next, so they learn how to write and architect good code. Basically have the AI walk you through it and make you think.

> I do think AI is going to change computer programming. Not as dramatically as some people think, but in some fundamental ways.

I agree with most of the observations, but this statement already hasn’t aged well.

I wish I could tell my PM let’s go back to the old delivery schedule so I can read the whole thing and not just generate code, tests and documentation at breakneck speed.

> Computer programming is, fundamentally, about two things: 1. Problem-solving using computers 2. Learning to control complexity while solving these problems

Pretty sure your forgetting more than half of computing…

… 3. The modeling of external systems into code.

Modeling isn't solving a problem, it’s representing an external systems with a degree of fidelity. That’s different from solving a problem through transformation, albeit far harder to teach.

> 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?!"

  > For example, the ability to write, think and communicate clearly, both with LLMs and humans seems likely to be much more important in the future.

  > Some business folks look at AI and say “Great, we don’t need programmers!”, but it seems just as plausible to me that a programmer might say “Great, we don’t need business people!”

  > I think software architecture will become a more important skill over time: the ability to organize large software systems effectively and, crucially, to control the complexity of those systems.

  > I try not to use LLMs to generate full solutions that I am going to need to support. I will sometimes use LLMs alongside my manual coding as I build out a solution to help me understand APIs and my options while coding.
  > I never let LLMs design the APIs to the systems I am building.

It's over. Accept it.

One annoying trend in frontier models which contributes to the brainrot is:

- agent loops for a long time (minutes to hours), writing a lot of code

- agent gives high level summary of the outcome of the work, not the work itself, i.e. "Implemented and pushed feature XX. Focused tests and checks passed."

- requires detailed review of the large changes which can be exhausting, so just accepting it becomes easier

I really wish the models would explain more of the "how" and "why" of the implementation decisions. To combat this, I usually to bug the agent to discuss more including what assumptions it made and alternatives it considered.

Sure, this can be added to AGENTS.md but I view overengineered AGENTS.md as an antipattern and can work against us especially given the rapid advancements of the models.

What does seem to work is planning first via a very synchronous back and forth with an expensive model before tasking 1+ cheaper models to implement in parallel, then getting an expensive model to review while I look over things manually.

That's great but in the corporate world nobody cares about anything but ticking the boxes, shipping features and covering ass.

They will all virtue signal about how they're an "ethical" corporation that "prioritises humans" and "puts safety first". In reality they outsourced you to India because it was cheaper and now they're going to outsource you to AI because it's cheaper still.

The social contract is broken, there is no career in anything anymore, every single skill you can learn will be commoditised and automated and unfortunately thats a necessary evil. You will have to fight corporations and private equity for every scrap tho.

The only jobs that AI cannot take, by definition, are:

- Government mandated roles with legal accountability such as C-suite (all decisions will be made by AI but a human CEO/CFO must be legally accountable), various safety monitor roles that will likely be nothing more than Homer Simpson clicking Ok.

- Any job where the market is prepared to pay specifically for a human (think higher end daycare, nursing, waiting etc where wealthier customers will pay more for the status of having a real human)

- Ownership of a company, assets, anything - AI will never be allowed to own anything otherwise whats the point. The only way you'll be able to make money as a human doing something you might enjoy is if you start a company

>And companies: you must let juniors write the code.

This is just not going to happen.

I think in few years LLMs would be so good that the programming language used by humans to build software would be natural human language. LLMs would abstract out high level programing languages the same way where we don't write assembly code today. Hence, I'm not sure how important it would be to learn programing languages.

However, it's totally make sense to learn theories and concepts behind computer science and engineering like networking, encryption/cryptography, etc. if someone wants to be a software developer in the future.

AI tools can be deterministic by setting the temperature to 0. This does allow it to behave as a high level programming language, contrary to what the article claims.

It was always and will always be the case that you "futureproof" yourself in a field by getting the basics, not by following the latest trend that may or may not be relevant in a few months or years.

I would like the article to be true, but I am disappointed it provides no justifications for key assertions:

> I have a hard time imagining a future where knowing how to solve problems with computers and how to control the complexity of those solutions is less valuable than it is today, so I think it will continue to be a viable career even with the advent of AI tools.

We all have a hard time imagining a future where intelligence is in oversupply. And yet we are hurtling headlong into that future. Burying our heads in the sand like ostriches won't make it disappear.

> It is no secret that the programmer job market is bad right now, and I am seeing good CS students struggle to find positions programming. While I do not have a crystal ball, I believe this is a temporary rather than permanent situation.

Again, no good justification is provided for this assertion.

> LLM generated code, on the other hand, often does not eliminate accidental complexity and, in fact, can add significant accidental complexity by choosing inappropriate approaches to problems, taking shortcuts, etc.

LLM generated code can indeed be more complex than necessary. But this is not a fundamental issue with LLMs that cannot be overcome. LLMs are getting smarter at breakneck speed, and will soon be able to make judicious choices to deliver the desired functionality while limiting complexity.

In short, a bet that human minds will always have better judgement than LLMs is likely to be a losing bet.

Understanding can only come from repeated exposure. The less exposure, the less understanding. You certainly don't have to write code by hand any more (standards and quality aside), but it feels like gambling to say or even suggest that understanding how stuff works is a thing of the past (the increasingly popular counter-argument to OP).

I feel like most ghosts of our ancestors are screaming "you can't be fucking serious!" across the void. I'm routinely shocked by just how many people anecdotally seem to be clamoring to think less and do less, oblivious to the reality that those are the things which animate us. Without those, we're husks.

AI is a great tool, but you still need to know how to do things yourself to avoid mistakes.

Programming is dead, learning to program is useless. You will never fix a single line of code produced by AI. You don't need to understand what AI delivered, or what language it used, you just need to run it to see it delivered what it was asked to build

Architecting is the new programming. Apps are a dime a dozen now, you can have your own excel, word, photoshop, quake, anything you want at the snap of your fingers, so apps worth will approach zero. What you do with apps is another story and there exactly is where value is

Business intelligence to use apps to increase productivity

> To generate code that I don’t enjoy writing (e.g. regular expressions & CSS)

Isn't there a counter-argument to be made that those should go to team members who enjoy them?

I feel like the better value will be in physical sciences where you are also solving problems, sometimes concretely and sometimes abstractly, or even philosophy.

I think this is terrible advice. Going into computer science right now is super risky. If anything maybe learn real Engineering, not Computer Science

> “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.

a lot of very useful advice given in this article

e.g with regards to job search - one has to be open to possibilities when starting out for you never know where the world takes you.

Keep in mind this guy is a prof teaching computer science and is likely to leave his sons a decent inheritance. Not knocking on that but the situation is likely to be a lot different if you don't have that security, and the advice you give to your children could be a lot different too if you can't leave them a lot.

I watched that Ted Lasso episode too!

While traditional software was absolutely more deterministic than modern AI tools I do think this concept can get overplayed particularly when even deterministic systems exposed to real world inputs and realities particularly human beings as users for example not to mention many distributed systems realities all make determinism theoretically true but highly chaotic anyway

"It is no secret that the programmer job market is bad right now, and I am seeing good CS students struggle to find positions programming.

While I do not have a crystal ball, I believe this is a temporary rather than permanent situation."

Yep, any day now people will stop using AI and all the jobs will come back. Of course the author believes this if they're a professor. If students didn't think they had a job they wouldn't want to study comp sci and there would be no reason for professor for it, either. Even though they have a kid doing comp sci, gotta call them out of touch if they're not steering away that choice given what tech is today...

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

Yes, and a lot of cope. No young person will read this, and "yeaah I should go to college to study for a CS degree." Job security is going to shit in most university specialties.

Unis are eating themselves alive; you have to be brain-dead to go there (maybe only to pursue a military officer career, as the world war ramps up) when the trades are so hot right now.

The target audience of this post is boomers and, I guess, some millenials not-yet-disu illusioned with, who look fondly back on their education.

Yes.

The instinct to control complexity becomes vitally important in an age where AI junior coder can create millions of lines of redundant slop if not properly guided and limited.