Rendered at 05:48:04 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
recursivedoubts 6 hours ago [-]
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.
abirch 5 hours ago [-]
Thank you for writing this article.
1. my ignorance is massive so don't bet on my predictions. There's so much FUD. This is like the industrial revolution but on steroids.
2. I see the moat around software decreasing quickly. Therefore, I'm going to project that there will be fewer coders in software only companies (such as Adobe, SAS, or Intuit)
3. It will be easier to support software so I see the need for more technical entrepreneurs. Software is going to be an amenity with services, hardware, or support. The code itself isn't going to be valuable like its current form.
4. I would project there will be more programmers in the future, but not pure programmers. More like the 1970s programmers who had other professions but would create their own programs.
recursivedoubts 4 hours ago [-]
I'm not sure this is more significant than the industrial revolution, but it is certainly faster. I am withholding judgement until we start to see real world changes beyond symbol manipulation.
I agree there is little moat around code qua code now. I'm not sure that means there will be fewer coders, because the people in the best position to take advantage of this new technology are... coders.
I again agree that code qua code is becoming less valuable, but I think that ironically _understanding_ code (and systems) is going up in value. Complexity still grows super-linearly and so judicious technical decisions will need to be made.
I strongly agree with your last point and I am advocating for a "+CS" track here at Montana State, where non-CS majors can learn enough practical CS to be productive and then excel in their own major. I'm speculating a 3-4 class track with AI/vibe coding as part of it.
Imustaskforhelp 2 hours ago [-]
As someone who just started university studying CS as well, I really appreciate you writing this blog. I recently went into a bit of a p(doom) spiral worrying about CS, uni and maybe sort of an existential crisis and I had an discussion on HN with a more experienced person about it which went into similar topics[0]
Also, I wish for your son to have a good university experience and hope he makes great friendships and connections which help him throughout his life and I wish the best for his future and to enjoy the present as it happens :-D
> 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.
glimshe 7 hours ago [-]
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.
fragmede 1 minutes ago [-]
You can vibe code without knowing what a function or a variable is. What is an int vs a bool vs a string. You can absolutely build something useful with today's technology without knowing how any of it works underneath. If you know how it works underneath you'll have a leg up on someone who doesn't, but what's the opportunity cost of knowing how that all works underneath. What are you missing out on and not learning while you're learning and reasoning about the aforementioned 1 & 3?
Exoristos 7 hours ago [-]
I agree it can feel like working with a team sometimes, but I wouldn't liken it to a macro. That seems much too idealized.
edflsafoiewq 7 hours ago [-]
I think this narrow view on determinism comes up a lot. Essentially any program can be made deterministic over single inputs by fixing all side-inputs. But there is determinism over classes of inputs too, eg. an algorithm given input X deterministically outputs X+1.
I think the wider view is usually what people mean when they talk about nondeterminism in LLMs. Maybe because computers are traditionally so deterministic the wide view is almost taken for granted by programmers.
orbital-decay 6 hours ago [-]
It's not the narrow view, it's the only actual definition of determinism. Words have meaning. Determinism means "same cause = same effect". If the cause is underspecified and requires interpretation that varies depending on the interpreter, the whole concept is meaningless. Intelligence (human or machine) operates in an underspecified domain, it makes sense to talk about undefined behavior, misinterpretation, alignment, anything really, but not determinism.
yells at cloud
warkdarrior 5 hours ago [-]
Random number generators are deterministic. If you give it the same seed, you get the same result. But that does not mean that a human can predict, for a new seed, what the result will be.
thothless 4 hours ago [-]
psuedo-random number generators are deterministic.
a human can predict that the number that is generated will be suitably random.
a human can predict the result from a pseudo-random generator with enough knowledge of seed/program state/etc.
now I can't say this holds for a TRUE random number generator. nor do I know where we were going with this.
7 hours ago [-]
w4yai 7 hours ago [-]
> You can predict which changes in the source code will lead to which exact changes in the behavior of the compiled program
Can you really ?
tkzed49 6 hours ago [-]
only a Sith deals in absolutes. There's a big difference in the strength of the connection from input to output between LLM edits and writing the code.
NichoPaolucci 3 hours ago [-]
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...
vips7L 1 hours ago [-]
I write everything by hand still. I don’t believe speed vs quality trade offs are worth it. Somehow I’m still shipping as fast as my peers. Where LLMs have saved me time is in research and finding the right documentation.
3 hours ago [-]
gorgoiler 46 minutes ago [-]
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!)
tengbretson 10 hours ago [-]
> 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.
JodieBenitez 38 minutes ago [-]
Reading code was always much harder than writing it and it's certainly the root of many NIH syndrome disasters. Writing helps, but you're right that these are two seperate and related skills.
JSR_FDED 4 hours ago [-]
Reading code is very hard because you have to build a mental model from code that others wrote. You’re trying to understand what they wrote, the intent behind that, and what’s wrong or missing - that’s just a fundamentally hard thing.
But building mental models based on data and communications from others is one of the most valuable problem solving and communication skills there is in business, precisely what Carson is getting at in his essay.
rspeele 6 hours ago [-]
Strong agree. School had me writing stuff myself on the order of a few KLOC at most, and maybe collaborating with a "group" in which at most 2 people actually did anything. What little exposure I got to reading a large codebase I didn't write, was all in personal projects trying to mod open source video games. I'm sure some people had more extensive experiences but that was my bachelor's.
First job had me using a programming language I wasn't super familiar with and trying to add a feature to a codebase 100s of KLOC, all written by other people. Definitely a sink-or-swim moment. My skills of reading and navigating the dreaded Other People's Code were all honed over the next dozen years.
That being said AI is a lot better at reading code than I am, as demonstrated by its ability to find incredibly subtle bugs in huge codebases. So I'm not even sure those code reading skills are all that useful now. When I have to review somebody else's code I get more mileage from pointing an AI at it and asking targeted questions like "how does this handle when a Foo's approval is revoked" than reading it myself line-by-line. I'm not saying I never use those reading skills but the ability to get the big picture, chase down deep callback chains, know where to look... those skills are likely to atrophy.
It's like using GPS vs. knowing the roads as well as a cabbie. GPS gets you pretty damn far for zero effort.
Exoristos 7 hours ago [-]
> It certainly feels like its possible to learn to write it without learning to read it.
There's a perhaps subtle difference between possible and viable.
jeremyscanvic 7 hours ago [-]
Would you mind sharing some of the insights you gained on reading code? It could be useful for the more junior of us!
skydhash 5 hours ago [-]
Not GP, but the main thing is that there is always some conceptual model being a good codebase. Meaning there’s the problem, then a given set of data structures and algorithms that forms a solution for that model.
It’s often hidden behind the syntax and implementation because of the layers of abstraction. A single operation (semantic wise) may be scattered over many statements, and some definition may be important in several subconcepts. It helps to be familiar with various technical concepts as possible. basic data structures like lists and trees, more advanced concepts like scheduling and concurrency, as well as platform concepts like files, process, networking,…
Why? Because they are implementation details that distract from the main conceptual model. It’s like how OpenBSD handle device discovery and configuration. Once you know that it’s a tree, you just need to remember how you build a tree and then most of the code are obvious. You can then discern the traversal stuff from the actual device configuration easily and know how to focus your reading.
skydhash 6 hours ago [-]
I don’t think so. I strongly believe that writing and reading is pretty much the same, because they are strongly related to thinking. They are even secondary to the latter. I often interacted with juniors and other colleagues and those that do have issue with writing and reading often struggle with formalized thinking.
Taking a problem or a wanted behavior and dissecting it down to logical manipulation is hard for those people. They can go down one or two layers but then they got lost while building the necessary abstraction. You can observe it pretty much in real time as they’re losing track of assumptions for the current context. Thinking that way is a skill and once you can do it, reading and writing code is pretty much effortless.
Both learning to write and learning to read is merely a proxy of learning to think. Doing one while not doing the other is handicapping yourself for no reason.
johsole 9 hours ago [-]
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.
omoikane 7 hours ago [-]
> 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.
icedchai 7 hours ago [-]
AI will maintain the features, unless you think we're going back to the old days? The job of a developer will become 1) writing and refining specs, 2) "managing" agents by answering questions, evaluating new models, new tools, etc, 3) testing and validating AI output.
a1o 3 hours ago [-]
Hey just because you mentioned specs, we went back from the huge amount of md files to no md files at all and having the code being self documented for our AI based workflow (we have projects using AI and others with human workflow).
If necessary there is tooling to generate docs from the code itself. There is also tooling for code quality and other things. You can also use AI to help build deterministic tools for specific code quality verification you may want - all major languages have established ways to parse the code and generate easy to inspect AST and code metrics that can be used for arbitrary quality measurements.
The entire “API” (all the code objects and functions interfaces) were carefully architected so their “contracts” are well determined, with very explicitly defined types. The machine written code now can evolve it directly and it has much less impact on context, which allows using very cheap and fast models and reduce a lot of expense while producing quality and predictable code output. Just a heads up if you are still using many md files and relying too much on the big frontier models.
vinyl7 7 hours ago [-]
Have we coined the term Slopgineer yet?
6 hours ago [-]
simonw 9 hours ago [-]
I think people who understand how computers and software work will be better positioned to generate those new ideas.
benatkin 6 hours ago [-]
It will be faster to understand it, which will make it less valuable. I think I could point something like this to a curious AI software builder without a CS degree and tell them to have AI explain it and they could make up a significant chunk of what they're missing by not having a CS degree. https://www.cs.yale.edu/homes/perlis-alan/quotes.html
bluefirebrand 8 hours ago [-]
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
jodacola 8 hours ago [-]
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!
yolp5 8 hours ago [-]
> 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.
jodacola 8 hours ago [-]
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.
notpushkin 5 hours ago [-]
Which is also a good thing to learn. I think way too many devs think 100% of the world’s problems can be fixed by software.
My experience (as someone who has almost exclusively worked as a software developer in non-software companies) is that my primary value add is the ability to recognize things that a computer can do easily, versus problems that are not solvable by throwing software at it.
For example, when I was working in a finance team, I'd come across all sorts of situations where someone had a task of "once a week, download this data from this application, apply the following transformations, then upload the results to this other application". Anybody reading this site would think "ah, that's like a dozen lines of code! We should automate that". But that thinking is incredibly rare outside of our field.
On the flip side of that, you'll have the people who think they can simply buy software that will solve all their problems. "No, ma'am, buying a fancy new Spend Management System will not magically make everyone know or care about the difference between 'GL 10754 - Employee Appreciation: Meals' and 'GL 10822: Employee Meals (Discretionary)'".
My take on it is that the ability to recognize automatable problems boils down to 1) having an intuitive understanding of algorithmic reasoning ( this solution comes in 4 parts, the first part can be divided into 3 separate problems, which...) 2) having an up-to-date understanding of the extant capabilities of computers. 3) having the kind of bull-headed hubris that makes someone say "Sure, we currently do it this way, but I can do it better".
And at the end of the day, those features end up meaning you need some sort of engineer.
jeremyjh 6 hours ago [-]
This isn’t a skill exclusive to software developers though - there are a lot of domain experts who can identify these opportunities as well. Not a majority perhaps - it seems like 15-20% at my company - but more will develop this skill by working with AI.
notpushkin 5 hours ago [-]
If they can reason about software engineering enough to be able to successfully develop software, then they are software developers. (I’ve yet to see a person who can say “we can automate this!” without actually thinking like a programmer and yet reliably be correct about that.)
simonw 5 hours ago [-]
One of my hobbies is telling people with extremely elaborate Excel spreadsheets (the kind that companies run on) that they're programmers even though they didn't think they were.
jeremyjh 5 hours ago [-]
Right, I work with several of these people, but they understand this. There is a real intimidation factor with general purpose languages, with all their tools and elaborate rituals. I feel the same way about alien platforms like z/OS. Oddly enough, many programmers are intimidated by Excel or at least never use it even when it is clearly a better tool for a particular task than the ones they are familiar with.
simonw 8 hours ago [-]
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.
whstl 7 hours ago [-]
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.
dirtbag__dad 4 hours ago [-]
This resonates with me. I joined a climate tech company to help save the world. I built data pipelines like anywhere else
dkarl 8 hours ago [-]
> 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.
Buttons840 8 hours ago [-]
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.
tombert 7 hours ago [-]
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.
dirtbag__dad 4 hours ago [-]
> I also see a lot of Devs simply trusting that the code is correct, they are losing touch with the code.
My team has a non-engineer vibe coder who doesn’t know how to even use git, but managed to put together a large application that serves enterprise customers better than the real SWEs we had working on the project.
We’re in the process of porting their code into the main codebase, and it’s obvious to me, not so much them, that there is an insane amount of waste. But I’m not sure whether that’s a bad trade off, the end product works and llms get whatever he needs done.
OTOH, I’m an experienced SWE who is taking a stab at writing dev tooling in rust, which I don’t know and don’t have the time rn to learn. I am very aware there is a lot of waste, the project is obviously moving slower than if I was more involved with design. I was ok with the trade off but I’m growing antsy now.
All to say, it feels to me that vibe coded tech is a viable path so long as you accept what you’re going to get.
The one exception I see rn is when we try to do brownfield work, LLMs get very confused and simply cannot manage an old dog shit human written system with a new set of concepts floating in. Jury is out whether this will also happen with ai slop, but again maybe it just doesn’t matter
wildzzz 7 hours ago [-]
I've been managing a software project for several years now. It's gone through a few major iterations but those have only coincided when I've had other engineers to help me. The code is for testing new devices against a couple racks of equipment. What I had a few months ago has worked pretty well but there's been some issues with error handling and limit checking. I basically just work on the thing when I have time, amongst being a hardware development/production/test engineer. Little changes are easy but something like adding in a bunch of error handling is a lot for me. It's relatively easy with python but I'm an electrical engineer and this thing is so spaghettified that it's really difficult to crack into these crust test scripts to structure them the right way.
Over the past year, I've been trying to better document the equipment according to new QA standards. This also means I need a way to test the racks without production hardware. Everything goes hand-in-hand, how do you test a car without an engine? We finally got access to an approved IDE with a built-in AI model so I figured I'd try that out. I had been using our ChatGPT-equivalent tool for a few months for little scripts and questions but that's pretty ineffective for a major code base. That new IDE cranked out a slick certification application that does everything I need in about a day. I turned it back to my existing codebase for the production testing and gave it my wishlist of upgrades and features. Took about two weeks but I'm ready to push v1.0.
One of the main issues is that I'm not the one usually testing new devices, technicians are and they aren't always familiar with the software or equipment. Automating an entire test was a big effort a couple years ago and I got to the point where after a bunch of setup, you just click the GO button and sit back to watch. But now, AI has automated even more of the process so all of the stupid config files one had to setup previously are now automated. The various apps you had to run in the background are all built into one package. The silly little bugs I was dealing with for years have totally been wiped out with better error handling and monitoring of connections. It's amazing how well this new thing works and how much it actually looks like a real software engineer made it. It's even got simulators built in so we can test every part of it without needing actual equipment or the production units.
I've been wanting to find a new job for a while but this automation project has been holding me back. I've so badly wanted to complete it because I'm the one that wanted it in the first place. If I had like six months of dedicated time with the equipment (impossible, at best I get a couple weeks of downtime), I maybe could have made something similar but it would have been lousy code. With just two weeks of working with AI, I'm over the big hurdle. I've still got a few things to clean up before its ready for production but I'm basically 40 hours of work away from being at the point where I could just walk away. Hell, I just realized I could even have the AI write the manual as well.
gregwebs 3 hours ago [-]
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.
geraneum 16 minutes ago [-]
> it's that it will be like writing assembly- something that's unsafe and needs to be justified
I don’t see how that’d make sense. Can you elaborate how exactly this will be the case, specifically about safety?
za3faran 2 hours ago [-]
LLMs will always be biased by the training set used on them. I don't see how they will become an entity that knows everything there is to know about a domain to make the correct decisions.
samstress 20 hours ago [-]
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.)
geraneum 10 minutes ago [-]
> If you extrapolate from the improvements we've seen in coding AI over just the last 12 months
This is the achilles heel of your argument. I think people sometimes conflate realizing unmet potentials of LLMs with significant improvements, since there’s not been a fundamental change in how LLMs work as significant as the advancements we see in their application.
notpushkin 5 hours ago [-]
You’ve missed the point. You can’t reliably use AI to generate code if you can’t understand code.
jeffreyrogers 2 hours ago [-]
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.
MentalM 1 hours ago [-]
but I do wonder what the long-term affects of this decrease in coding fluency will be.
Why there should be any long-term affects? That is simply the new reality of job interviews, and that's it. Coding fluency and leetcoding on interviews became worse because it's role in successfully passing the interviews has significantly decreased.
ivanjermakov 7 hours ago [-]
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?
smcg 10 hours ago [-]
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.
trentnix 8 hours ago [-]
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.
chaps 8 hours ago [-]
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.
shaewest 8 hours ago [-]
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.
chaps 8 hours ago [-]
risks you take when you commit a crime worthy of jail.
A friend's mom went to jail for having too many dildos in her purse. Do you count her in this?
wildzzz 7 hours ago [-]
How many is too many?
bluefirebrand 8 hours ago [-]
> 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?
easterncalculus 8 hours ago [-]
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.
psygn89 8 hours ago [-]
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.
wildzzz 7 hours ago [-]
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.
ibejoeb 6 hours ago [-]
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.
sippeangelo 8 hours ago [-]
> 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?!"
SahAssar 7 hours ago [-]
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.
sajithdilshan 7 hours ago [-]
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.
prpl 6 hours ago [-]
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.
Exoristos 6 hours ago [-]
> 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?
broodbucket 5 hours ago [-]
>And companies: you must let juniors write the code.
This is just not going to happen.
a1o 4 hours ago [-]
I watched that Ted Lasso episode too!
dzonga 6 hours ago [-]
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.
sergiotapia 7 hours ago [-]
> “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.
Exoristos 6 hours ago [-]
I don't think college is "suffering" for everyone. In fact, for many, it's a very enjoyable challenge and experience.
lemming 6 hours ago [-]
Yeah I've always said that the main skill needed to be a software developer is frustration tolerance. Personally I'm very glad to see so much of the ridiculous crap we put up with just disappear.
B1FF_PSUVM 6 hours ago [-]
I'm struggling for a clever analogy with manual screwdrivers and electric drills ...
(I know, I'll ask ... oh well ...)
nektro 6 hours ago [-]
Yes.
iAMkenough 8 hours ago [-]
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
draw_down 9 hours ago [-]
[dead]
landdate 20 hours ago [-]
[dead]
Kuyawa 2 hours ago [-]
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
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.
I agree there is little moat around code qua code now. I'm not sure that means there will be fewer coders, because the people in the best position to take advantage of this new technology are... coders.
I again agree that code qua code is becoming less valuable, but I think that ironically _understanding_ code (and systems) is going up in value. Complexity still grows super-linearly and so judicious technical decisions will need to be made.
I strongly agree with your last point and I am advocating for a "+CS" track here at Montana State, where non-CS majors can learn enough practical CS to be productive and then excel in their own major. I'm speculating a 3-4 class track with AI/vibe coding as part of it.
Also, I wish for your son to have a good university experience and hope he makes great friendships and connections which help him throughout his life and I wish the best for his future and to enjoy the present as it happens :-D
[0]: https://news.ycombinator.com/item?id=49981023
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.
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 think the wider view is usually what people mean when they talk about nondeterminism in LLMs. Maybe because computers are traditionally so deterministic the wide view is almost taken for granted by programmers.
yells at cloud
a human can predict that the number that is generated will be suitably random.
a human can predict the result from a pseudo-random generator with enough knowledge of seed/program state/etc.
now I can't say this holds for a TRUE random number generator. nor do I know where we were going with this.
Can you really ?
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...
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'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.
But building mental models based on data and communications from others is one of the most valuable problem solving and communication skills there is in business, precisely what Carson is getting at in his essay.
First job had me using a programming language I wasn't super familiar with and trying to add a feature to a codebase 100s of KLOC, all written by other people. Definitely a sink-or-swim moment. My skills of reading and navigating the dreaded Other People's Code were all honed over the next dozen years.
That being said AI is a lot better at reading code than I am, as demonstrated by its ability to find incredibly subtle bugs in huge codebases. So I'm not even sure those code reading skills are all that useful now. When I have to review somebody else's code I get more mileage from pointing an AI at it and asking targeted questions like "how does this handle when a Foo's approval is revoked" than reading it myself line-by-line. I'm not saying I never use those reading skills but the ability to get the big picture, chase down deep callback chains, know where to look... those skills are likely to atrophy.
It's like using GPS vs. knowing the roads as well as a cabbie. GPS gets you pretty damn far for zero effort.
There's a perhaps subtle difference between possible and viable.
It’s often hidden behind the syntax and implementation because of the layers of abstraction. A single operation (semantic wise) may be scattered over many statements, and some definition may be important in several subconcepts. It helps to be familiar with various technical concepts as possible. basic data structures like lists and trees, more advanced concepts like scheduling and concurrency, as well as platform concepts like files, process, networking,…
Why? Because they are implementation details that distract from the main conceptual model. It’s like how OpenBSD handle device discovery and configuration. Once you know that it’s a tree, you just need to remember how you build a tree and then most of the code are obvious. You can then discern the traversal stuff from the actual device configuration easily and know how to focus your reading.
Taking a problem or a wanted behavior and dissecting it down to logical manipulation is hard for those people. They can go down one or two layers but then they got lost while building the necessary abstraction. You can observe it pretty much in real time as they’re losing track of assumptions for the current context. Thinking that way is a skill and once you can do it, reading and writing code is pretty much effortless.
Both learning to write and learning to read is merely a proxy of learning to think. Doing one while not doing the other is handicapping yourself for no reason.
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.
If necessary there is tooling to generate docs from the code itself. There is also tooling for code quality and other things. You can also use AI to help build deterministic tools for specific code quality verification you may want - all major languages have established ways to parse the code and generate easy to inspect AST and code metrics that can be used for arbitrary quality measurements.
The entire “API” (all the code objects and functions interfaces) were carefully architected so their “contracts” are well determined, with very explicitly defined types. The machine written code now can evolve it directly and it has much less impact on context, which allows using very cheap and fast models and reduce a lot of expense while producing quality and predictable code output. Just a heads up if you are still using many md files and relying too much on the big frontier models.
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
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!
90% of the time when you really break down the "real" problems. You learned they aren't gon a be fixed by fucking software.
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.
For example, when I was working in a finance team, I'd come across all sorts of situations where someone had a task of "once a week, download this data from this application, apply the following transformations, then upload the results to this other application". Anybody reading this site would think "ah, that's like a dozen lines of code! We should automate that". But that thinking is incredibly rare outside of our field.
On the flip side of that, you'll have the people who think they can simply buy software that will solve all their problems. "No, ma'am, buying a fancy new Spend Management System will not magically make everyone know or care about the difference between 'GL 10754 - Employee Appreciation: Meals' and 'GL 10822: Employee Meals (Discretionary)'".
My take on it is that the ability to recognize automatable problems boils down to 1) having an intuitive understanding of algorithmic reasoning ( this solution comes in 4 parts, the first part can be divided into 3 separate problems, which...) 2) having an up-to-date understanding of the extant capabilities of computers. 3) having the kind of bull-headed hubris that makes someone say "Sure, we currently do it this way, but I can do it better".
And at the end of the day, those features end up meaning you need some sort of engineer.
If I was going through university right now I'd want to double-major in computer science and something else.
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'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.
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.
That's what I'm hoping at least.
My team has a non-engineer vibe coder who doesn’t know how to even use git, but managed to put together a large application that serves enterprise customers better than the real SWEs we had working on the project.
We’re in the process of porting their code into the main codebase, and it’s obvious to me, not so much them, that there is an insane amount of waste. But I’m not sure whether that’s a bad trade off, the end product works and llms get whatever he needs done.
OTOH, I’m an experienced SWE who is taking a stab at writing dev tooling in rust, which I don’t know and don’t have the time rn to learn. I am very aware there is a lot of waste, the project is obviously moving slower than if I was more involved with design. I was ok with the trade off but I’m growing antsy now.
All to say, it feels to me that vibe coded tech is a viable path so long as you accept what you’re going to get.
The one exception I see rn is when we try to do brownfield work, LLMs get very confused and simply cannot manage an old dog shit human written system with a new set of concepts floating in. Jury is out whether this will also happen with ai slop, but again maybe it just doesn’t matter
Over the past year, I've been trying to better document the equipment according to new QA standards. This also means I need a way to test the racks without production hardware. Everything goes hand-in-hand, how do you test a car without an engine? We finally got access to an approved IDE with a built-in AI model so I figured I'd try that out. I had been using our ChatGPT-equivalent tool for a few months for little scripts and questions but that's pretty ineffective for a major code base. That new IDE cranked out a slick certification application that does everything I need in about a day. I turned it back to my existing codebase for the production testing and gave it my wishlist of upgrades and features. Took about two weeks but I'm ready to push v1.0.
One of the main issues is that I'm not the one usually testing new devices, technicians are and they aren't always familiar with the software or equipment. Automating an entire test was a big effort a couple years ago and I got to the point where after a bunch of setup, you just click the GO button and sit back to watch. But now, AI has automated even more of the process so all of the stupid config files one had to setup previously are now automated. The various apps you had to run in the background are all built into one package. The silly little bugs I was dealing with for years have totally been wiped out with better error handling and monitoring of connections. It's amazing how well this new thing works and how much it actually looks like a real software engineer made it. It's even got simulators built in so we can test every part of it without needing actual equipment or the production units.
I've been wanting to find a new job for a while but this automation project has been holding me back. I've so badly wanted to complete it because I'm the one that wanted it in the first place. If I had like six months of dedicated time with the equipment (impossible, at best I get a couple weeks of downtime), I maybe could have made something similar but it would have been lousy code. With just two weeks of working with AI, I'm over the big hurdle. I've still got a few things to clean up before its ready for production but I'm basically 40 hours of work away from being at the point where I could just walk away. Hell, I just realized I could even have the AI write the manual as well.
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 don’t see how that’d make sense. Can you elaborate how exactly this will be the case, specifically about safety?
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.)
This is the achilles heel of your argument. I think people sometimes conflate realizing unmet potentials of LLMs with significant improvements, since there’s not been a fundamental change in how LLMs work as significant as the advancements we see in their application.
Why there should be any long-term affects? That is simply the new reality of job interviews, and that's it. Coding fluency and leetcoding on interviews became worse because it's role in successfully passing the interviews has significantly decreased.
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.
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.
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?
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.
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?!"
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.
Isn't there a counter-argument to be made that those should go to team members who enjoy them?
This is just not going to happen.
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.
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.
(I know, I'll ask ... oh well ...)
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
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