Rendered at 23:37:10 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
fpaf 12 hours ago [-]
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.
Yokohiii 10 hours ago [-]
But we are kind of in a inverse situation, a huge amount of software is a one size fits all solution. Probably every small SaaS starts out with a number of extremely happy customers, but scaling means you can't satisfy everyone, so happiness turns into frustration. Big tech also supplies a lot of software that is one size fits all and not everyone is perfectly happy with.
If creation of customized software solutions is consistently getting cheaper and good enough in quality, the near future is about creating much more custom solutions for considerable smaller customer or consumer groups.
Mind that we still need people who understand tech and verify that a system does what it claims to do, in a safe and efficient way. Every non-technical vibe coder will at some point realize, that he maybe can prompt away every problem he has, but that is still considerable effort and also includes all the mistakes a professional already eradicated from his habits. Many vibe coded projects will also collapse under their own weight, rethinking a strategy - with tech in mind - is also professional effort.
Even if LLMs would produce perfect, high quality code all the time, instructing the "perfect" prompt is still a human problem. LLMs cannot mind read and fully understand the environmental and social circumstances. Understanding these things and model them into solutions, are also human problems.
All this still requires profound technical knowledge, even more now considering security is under fire.
piloto_ciego 8 hours ago [-]
This is because the ticket is “don’t scale.”
You’re not going to be a billionaire, just be happy doing a good job making niche things for companies. You don’t need 800,000 users. You need 8 small businesses that are paying you $2000/mo.
tripleee 7 hours ago [-]
No-one's paying you $2000/mo for something they can build in-house now, probably better suited to their needs.
hwntw 5 hours ago [-]
They very well might when it's outside the core remit of the company. Companies do this all the time - outsource/subcontract work so they can focus on what they're good at.
Yes, they might be able to build software that works for (relatively) close to free now. But that still has marginal cost in terms of extra resource to build it. Then it needs to be maintained, upgraded to meet changing internal requirements, it needs to be secure, they need to be able to trust it does what it's supposed to.
Sure, the cost of all of that has come down, but it's still a lot of work when they could just entrust another company to do that for a cost they're willing to pay. And companies are often happy to pay a lot in B2B contracts.
Just to reinforce this: look at the cost savings from cloud-exits - yet companies still readily build out in the cloud. FOSS has existed for decades, yet companies still pay for proprietary alternatives. Build vs buy exists on more dimensions than just cost alone.
piloto_ciego 6 hours ago [-]
Lolz, I’m literally doing this right now for a living.
When a software suite costs a company $70-100k per year that does a bunch of stuff they don’t want, they’ll definitely pay you to build bespoke tools for $24k per year.
Literally doing this now.
tripleee 6 hours ago [-]
How do you find clients for this? Sounds like a pretty nice gig
Maybe I'm overthinking things. There were companies paying out the ass for relatively basic WordPress sites in the past (and probably still)
piloto_ciego 5 hours ago [-]
All word of mouth so far from an industry I’m intimately familiar with. So maybe YMMV, but I started by saying, “hey, let me build something for you, if you like it we can figure out how to pay for it” then I started just doing things and they’ve kept happily paying the invoices.
I’m on vacation right now, but my main customer is constantly adding new feature requests, etc. and until I went on vacation their work was as good as 2 or 3 customers per month, “oh can you do this? What about this?” I honestly am looking forward for them to throttle back a little because I could use another similar volume customer, but I hardly have enough time to really invest to make that happen until they get all the things they want and while they’re paying me I ain’t going to stop.
It was also pretty cool, because there’s a young engineer working there in a non-engineer role as a human forklift. I said, “hey, I need help implementing all this stuff” now he has a raise, and he is kind of like an embedded customer support person, and I don’t have to stress about it so much.
Regardless, just build.
The phone call automation for their front desk saves something like 40 hours of work a month just of people looking up customers to call about their schedule etc. And that’s just one tool and I deployed it in like 4 days. It’s really not that hard, just go out and make people’s lives easier and stop trying to scale or whatever.
jaapz 4 hours ago [-]
How do you handle maintenance of these tools?
piloto_ciego 4 hours ago [-]
It’s incredibly easy; when something breaks I fix it. 95% of the time that is just me pointing Claude or usually codex at the problem and drinking coffee.
jzemeocala 2 hours ago [-]
I personally worked for a company in mountain view whose main product was an automated form filler for pest control operators and there cali EPA documentation.
It was something that looked like it was originally written in visual basic and than rewritten in react for tablet devices.
I'm still under NDA but the above figures related to per company\ per month sales are about right
bluefirebrand 1 hours ago [-]
24k per year is poverty levels though?
Am I missing something, are you juggling like 5 or more of these types of jobs?
mediaman 1 hours ago [-]
And no-one pays $2k/mo for marketing consulting, which they could do in-house.
No-one pays $2k/mo for a fractional CFO.
No-one pays $2k/mo for a fractional sales head.
No-one pays $2k/mo for environmental paperwork consulting for a manufacturer.
They can do it all in house. Why would they?
Right?
Except all of these actually do happen, of course, and each is a big industry.
As soon as this industry lost the inscrutability of the syntax of the work product, it began catastrophizing about the total end of any commercial demand at all.
Yet by this logic there should be almost no service providers at all for any industry that lacks legal certification barriers.
willismichael 7 hours ago [-]
Who are they paying to build it in-house?
piloto_ciego 6 hours ago [-]
You think a construction company or an air taxi has an in house engineering team?
Good lord guys…
what 7 hours ago [-]
I very much doubt many companies want to build and maintain clones of every piece of software the use in day to day operations when they can just drop a bit of cash.
tempestn 6 hours ago [-]
There is of course also a middle road, where you make not necessarily bespoke, but niche software. The former can also lead into the latter.
mpweiher 10 hours ago [-]
> Even if LLMs would produce perfect, high quality code all the time,
They should have introduced this for normal programs.
oblio 10 hours ago [-]
It looks really cool but it's a weird design. It's a library you include with your application? Why not an external layer?
Yokohiii 9 hours ago [-]
This is missing the point. If you want to run a software solution, application security still must be properly done.
pydry 9 hours ago [-]
I crave more reliable software more than I do software that is infinitely customizable.
Spinning jennys are neat but if theyd been invented in a world where use of star trek replicators was routine I think theyd be more curiosity than revolutionary.
"Artisanal code" would definitely die off if the cp command didnt work perfectly or cost thousands of dollars to run but it doesnt hence why the metaphor is at best mistaken (and at worst dishonest, e.g. when frontier labs are desperately pushing it).
And, the flip side is that artisanal clothes would probably make a huge comeback if star trek replicators were invented and nobody would want cheap sweatshop made crap any more. Why would you when handmade Gucci silk clothing could be yours for a couple of bucks?
agons 12 hours ago [-]
Is it possible the size of the market for hand woven rugs has actually stayed the same, and the mass produced variety has simply filled the void for the large segment who were never able to afford them?
bojan 9 hours ago [-]
I think that's exactly what happened.
Except it doesn't seem the software is getting cheaper for the end user, even though it is arguably getting cheaper to build.
Paradoxically, the costs of running the software seem to keep rising, both for running it on a local machine or as a subscription.
tripleee 6 hours ago [-]
Ironically AI companies driving up the price of components might increase the demand for efficient software to save costs
ac29 11 hours ago [-]
Yeah, the small, useful bits of code I've made this year at work could have been contracted out in years past (we're a tiny non-tech co). But in addition to expense, there's the hassle of coordinating it, QA, etc. Really dont need all that for a project that connects a couple APIs with a minimal UI to help automate something previously done by hand.
sebbul 10 hours ago [-]
It would’ve been done with a coding agent anyway if contracted out.
tripleee 9 hours ago [-]
With software I'm seeing a lot of people who would never have been able to build something, and wouldn't have hired a developer now try their hand at selling it
Some of those will go on to be successful and need technical people to support it
throwaway132448 12 hours ago [-]
Absolutely. Thinking in zero-sum terms seems to be this community’s default now and that’s a sad situation given where we came from.
piloto_ciego 8 hours ago [-]
People are scared is why.
matkoniecz 11 hours ago [-]
For rugs especially it is definitely not true. Most ultra-premium projects are also using machine-made rugs and carpets.
If handmade one appears it is as some centerpiece, and remaining ones are machine-made.
pjm331 11 hours ago [-]
I don’t write the same program over and over again so I am always confused by how exactly this industrialization metaphor is supposed to map on to software development
Cthulhu_ 11 hours ago [-]
Think of it this way, the Persian rug isn't the same pattern every time either. The base job is the same, but the implementation requires planning and the like. A rug making machine is good at creating the same thing over and over again, but not very good in being flexible.
Software... a lot of software is basically the same thing (database, api, frontend), the only difference is what data and business rules. But the act of writing code isn't very different. It's the what code to write where software engineers come in.
singron 6 hours ago [-]
A better analogy is that software dev is more like making the rug making machine. If you were doing that, it would be useful to be intimately familiar with precisely how rugs are made, and you might want to make a bit of one by hand in order to get that experience. Then when you design the machine, you use gears, 4 bar linkages, and other mechanisms that you are already familiar with because you carefully studied those concepts earlier, likely with some hands-on exercise. Then you draw a design, simulate it, and send it to a machine shop and can possibly never touch the machine itself (although I think in practice these kinds of bespoke first-gen machines need debugging after manufacturing).
I.e. in order to get to the point where you didn't have to manually touch this thing, you likely did have to learn deeply about its underlying concepts by manually doing things.
Operating machines doesn't always have the same phenomenon. E.g. experience with a hand-powered drill is unnecessary to use an electric drill.
dnikolovv 11 hours ago [-]
> the only difference is what data and business rules
The "only" difference? Wow.
HPsquared 11 hours ago [-]
Database, API and Frontend are tools and generic raw material that need to be whittled down into the final shape.
airstrike 9 hours ago [-]
for all the CRUD apps out there, which are not the full set of software programs
realusername 10 hours ago [-]
Most of the software which was the same thing has been abstracted already in CRM, WordPress, content builders, website generators...
What's left is a lot of very different software which have very few things in common.
threecheese 8 hours ago [-]
In this analogy, a programmer who cannot understand their workload is like a rug QA tester with eyes but not feet; or a safety inspector who doesn't know that the red dye is corrosive to skin, or that corrosiveness is possible, or even that it exists as a concept. Or that the "red" is a dye, and what a dye does.
Currently, learning programming is the lever to unlock architecture understanding. We will need a few new layers of abstraction before this changes.
hammock 10 hours ago [-]
> 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.
Yes, and it’s worth pointing out the class of people buying ikeas rugs were NOT buying Persian wool/silk rugs before…they had bare floors or make coverings out of cloth or woven grass.
Also worth pointing out that since 1979, regardless of whether it is secondhand or not and which country you are procuring it from, rugs made in Iran (Persian rugs) have been totally banned for import to the U.S. Tribal rugs now come more from places like Turkey and India. So the market is being extremely artificially suppressed, boosting ikea rugs even more.
AspireOne 4 hours ago [-]
> it’s worth pointing out the class of people buying ikeas rugs were NOT buying Persian wool/silk rugs before
Can you expand on this please? I don't see the reasoning trace that got you to that conclusion.
dofm 6 hours ago [-]
Properly handmade Persian and Afghan rugs are no more expensive than they have ever been, I think.
I am not even sure the market has shrunk, because most people never owned them.
But indeed, the answer in the article’s context is no, probably not. And don’t go to university at all, because you will burn through money you will never replace and develop debt you will never pay off.
Learning a physical skill, or at least a physically based skill, is better, as is learning a skill that is chartered as a profession or at least where there are functional unions.
The future is bad. Really, really bad. Only learn jobs an AI can’t ruin.
geraneum 5 hours ago [-]
I know what you want to say, and not disagreeing/agreeing but on your anecdote about Persian rugs, the master turns out to be right. People who buy machine made rugs are not really target customers for hand weaved Persian rugs, and I suspect they’ve never been.
inanutshellus 12 hours ago [-]
OP says the article is to help CS majors soldier on.
... and I'm reminded of all the folks that have Accounting degrees. Their degrees ended up being proof that they could track a lot of rules.
That proof meant they got hired and their job was not to ... "account", but to "fit into our business".
Perhaps that's the majority of CS folks going forward?
"Your CS degree proves you can help me not get stuck in technical problems so I can go solve [business/engineering/scientific/...] problems"...?
jshen 6 hours ago [-]
Rugs aren't live running systems, so not analogous.
recursivedoubts 23 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.
antihero 14 hours ago [-]
It’s good but I kinda disagree with them stuck issue. Getting stuck is frustrating and having an easy way to get unstuck seems good.
However, the skill of having to try many different things and have patience and deal with an unproductive day and sleep in stuff, being able to pull yourself out of a hole, bootstrap deeper understanding in times when you feel helpless…it’s character building and incredibly valuable.
I feel like AI will allow people to have less resolve and determination, like looking at the crossword answers.
Silagi 12 hours ago [-]
Yes, but they're still going to encounter those moments, just at different points.
The same way we never stopped encountering "Wait, what the hell?" moments when we had the internet and could search for problems instead of digging through textbooks or --help, they'll just run into those blocking moments at a higher level of abstraction, then have to backtrace the problem down to the level they need to understand to resolve the issue. Curious people continue to be rewarded with a higher ceiling, but the floor to get something functional is brought down.
The alternative is that AI just deletes software engineering as a discipline and everything gets vibecoded, which still seems unlikely even if the improvements continue to accelerate.
kajumix 12 hours ago [-]
So even if the improvements continue to accelerate, even when you get to a point when an agent not just codes but also designs, optimizes for complexity and maintainability, you don't think software engineering as a human discipline gets deleted?
bentt 11 hours ago [-]
I am in a similar position. My son is a talented high school programmer considering colleges. He has expressed Anti AI sentiment to me. This article gives us a useful lens and I appreciated it a lot.
globular-toast 13 hours ago [-]
Yeah. I have worked with people who have a very low threshold for struggling and reach out the moment something isn't obvious. They never learn anything. They can go for years and years never growing or improving in any way.
The problem is AI lowers all barriers to reaching out. Previously you'd have to ask a real person, which might be embarrassing. I do wonder if I would have struggled as much if I didn't have to. I look at what's happened to people's bodies when they no longer have to do physical labour and I wonder if the same thing will happen to their minds.
kajumix 11 hours ago [-]
The struggle is necessary to grow, sure. But we're free to choose and upgrade our struggles. After calculators and then computers, struggle in math levelled up.
Ekshef 8 hours ago [-]
Man, I am so torn and this article doesn't help. But in a good way?
I'm a middle age guy who has no degree and taught myself to program during the pandemic. By now Ive created websites, built a game(well not finished but most of the mechanics), finished a ml pipeline project, and of course started so many side projects that may never get finished as is expected. But in this market I can't get hired because, well only on part, no degree.
I need to get out of my current career for mental health reasons and have decided to go back to school to get a degree and have chosen my secondary choice for a degree instead of going CS. Now I read this article and feel torn. I want to get to work coding and create something great, work with driven people and solve problems, but I also need income and a path forward so I've chosen another degree to pursue.
I'm torn because either outcome that occurs is bitter sweet for me. Either the market picks up and so many talented, bright minded, and younger engineers will get hired and go on to create amazing things, or the market will stay stale and so many will get jobs not doing what they love.
This is kind of a ramble at this point. I'm summation I love to code so I'll code, and hope that this article it correct and others can get hired quickly and the market turns.
willtemperley 16 hours ago [-]
> I think that knowing how code (and technical systems) work is going to continue to be valuable and perhaps even more valuable.
I think the art of refactoring will be more valuable than ever.
I'm having an LLM free day today, going through a lot of generated code, de-duplicating and making the abstractions more usable. It's quite enjoyable and improves my understanding of the code significantly.
akshitgaur2005 13 hours ago [-]
Thank you for the article but what about students who truly have no connections? It seems like a bleak time for us, none in my family work in even a corporation that would need tech people and my friends are in similar boat.
Luckily I was able to complete an internship lately (implemented EEVDF scheduler for Redox OS) but even then, the amount of Rust Junior jobs are so rare that it is proving to not be of much help.
sameerds 12 hours ago [-]
"friends" is not limited to people that you grew up with, or studied with, or people that your parents knew. They can also be contacts that you made by reaching out, in social circles or through shared interests or tecnhical workshops, etc.
recursivedoubts 9 hours ago [-]
I think the first thing to do is to recognize the need for forming connections and start working on the skills that foster those. Technical people tend to not be great at softer people skills & communication, so that's something you can start working on. I advise against just starting to reach out to people, that isn't effective usually, but to start working on the skills necessary and start looking for the situations you have access to that do foster connections.
Also, when you are on the other side, recognize that offering connections to unconnected people is a wonderful act of charity.
ptidhomme 17 hours ago [-]
Thanks for these insights. They made me think of AI as what a mechanic is for your car. He knows more and is more capable than you, and he can save you a lot of time vs if you had to do the dirty work yourself.
However, the more you know yourself about car maintenance, the more you will trust his diagnosis, solutions and the fairness of the money he asks for it. More generally, the more you will trust him to act in your interest instead of only his (or someone else's).
The edge in the AI future will be ownership.
wyclif 13 hours ago [-]
Did you tell him that one day, he can be the CEO of HTMX?
In all seriousness though, thanks for writing this, I found it helpful.
ubercore 16 hours ago [-]
Out of school for awhile, but covering low-level topics, down to logic gates, assembly, and doing floating point math manually, is not something I _use_ every day, but was crucial both when programming in higher level languages, and now using AI tools to write code in higher level languages.
It feels like there will be a beefy "middle" where people can probably drop some of that context, and get a lot of productive things done with AI. But there will still be a need for people more deeply knowledgeable and educated. It's probably just not in the proportions we have today.
_Kind of_ like the boom of coding bootcamps. A lot of people got good work done going through a coding bootcamp, but didn't get the deep background that a CS major would.
Coding bootcamps didn't mean we don't need CS education, and neither will AI, I expect. But the numbers and jobs are definitely going to change.
bentt 11 hours ago [-]
Great point about the value of knowing the deep stuff.
abirch 23 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 22 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.
stefanka 14 hours ago [-]
Thank you for this article (and the agents.md)! It's not easy to give students a good answer to such questions.
jstummbillig 14 hours ago [-]
Thanks for your thoughts! Can you explain why in your model being able to read code will stay any more important for tomorrow's coders than it is for today's managers? Is it resting on the assumption that tomorrows models will be worse at that than tomorrows coders?
jorisw 17 hours ago [-]
> AI is a great TA
TA meaning...
sham1 16 hours ago [-]
Teaching Assistant. Fairly common jargon in academia, but yeah, the GP should have macroexpanded that.
fercircularbuf 17 hours ago [-]
Teaching Assistant
16 hours ago [-]
17 hours ago [-]
Imustaskforhelp 20 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
I think you’re underestimating how bad the job market is right now, everything else I kind of agree with. You should spend a few months applying to jobs (even if you don’t need one), just to see how dire it is out there. I’ve been working almost 20 years and the last 6-7 have been brutal job market but the last year has been extra-brutal. Another thing you may be discounting: your network connections don't go very far if most of them have retired or left the industry.
layer8 1 days 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.
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 1 days 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.
layer8 8 hours ago [-]
> Assuming that you truly understand and own every line of the LLM's output, the model is almost working like a macro.
I don’t have to review the output of a macro invocation once I’ve convinced myself that the macro’s definition is correct, similar to how I don’t have to review a compiler’s output. That’s the difference we are concerned with here.
For comparison, consider the statement “Assuming that you truly understand and own every byte of the compiler's output, […]”. The point of a compiler is that we can depend on it without having to impose such an assumption.
airstrike 9 hours ago [-]
Great points, but I'd wager step 3 is not being maintained. I definitely do not read every line produced by the LLM. I read the critical parts for critical software, but that's probably not even 5% given the sheer number of lines written
Exoristos 1 days 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.
TZubiri 18 hours ago [-]
It comes up a lot, it's almost not worth arguing as it detracts.
I might take on to saying that compilers are more deterministic than vibe coding, that should stop the vibecoders from arguing about how technically 1+1 is not deterministic because of UB in C or whatever.
That said, they'll probably start debating that something is either deterministic or it isn't, and we can answer that they couldn't be more wrong, and they'll answer that wrong is an absolute state and not subject to gradation, , and we can answer that of course it's relative, it's wrong to say a tomato is a vegetable, but it's more wrong to say it's a suspension bridge, and then we can finally go to bed because the online arguments have all been solved, the end, it's done.
fragmede 18 hours 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?
sampullman 17 hours ago [-]
You can build lots of interesting things now without understanding the code, but the maximum complexity of what you build will always be defined by what the latest model and harnesses are capable of without architectural guidance.
otterley 16 hours ago [-]
If whatever you built is good enough for you, then the model was ipso facto sufficient. This has been true for many small projects since the first coding agents came out over a year ago.
Capricorn2481 2 hours ago [-]
> If whatever you built is good enough for you, then the model was ipso facto sufficient
You literally don't know what it does, though. And it's not a given that QA testing the program will lead to an answer before it leads to a bad outcome. There's an understanding, when we use software we can't read, that some humans looked at it and talked to other humans about how it works. Maybe got calls from customers about bugs, made workarounds.
If I'm just vibecoding stuff for me, and I don't understand any of it, I would not feel safe running it on my computer. And I'm not convinced a lot of people are even going to do this, because non-technical users seem to intuitively understand they are rolling dice in some way.
Capricorn2481 3 hours ago [-]
> You can vibe code without knowing what a function or a variable is
You certainly can, but you can't tell people anything about how it works, if it's safe, whether it spies on people, when it needs to be upgraded, etc. Is there going to be a market for vibe coders who sell services they don't understand? I don't know.
For documenting business logic, code is highly specific and dependable even with non-deterministic compilers. We can look at code and say "Yes, we can connect this to our Stripe account, because we have reviewed what it actually does." We can mock services and test that it works. We can do all of that without reading build output
The same, obviously, cannot be said of LLM prompts. And due to the flaws (and strengths!) of Natural Language, I'm not sure that will change. If someone told me their vibe coded app was safe because they politely asked it to be, I obviously wouldn't use their service. If they told me they asked it to write tests and do mocks, I wouldn't know if it actually did. A pure vibecoder can, at best, reread the prompt they gave, and maybe ask the LLM if there are vulnerabilities, hoping that it finds something.
Maybe we will get to a point where people are feeding 80 page specifications to LLMs as the input, but I'm not sure a person who is capable of writing that level of detail but incapable of learning to read code really exists. I don't think it will get that far. I think people will keep their prompts short and just roll the dice, QA testing.
kelnos 15 hours ago [-]
Thank you for this; I think you've hit on a problem I have explaining this point. I tend to lean on the determinism aspect, but it never felt right.
As a sibling commenter said, I agree that the concept here is "chaotic". A small change in the input (the prompt) can create large (or not!), unpredictable changes in the output. And variations on that small input change can have wildly different effects on the output.
But a change (large or small) to C code will create predictable (large or small) changes to the assembly output.
gf000 16 hours ago [-]
I think the correct word to use is "chaotic", in the mathematical sense (e.g. double pendulum).
A tiny change in the inputs can result in a large (and hard to predict) change in the output. Non-determinism is a different axis completely, and some compilers are (semi-accidentally) NOT deterministic either (two runs are not byte identical)
VectorLock 8 hours ago [-]
>You can predict which changes in the source code will lead to which exact changes in the behavior of the compiled program.
A vanishingly small percentage of coders are thinking about this when they're coding. Compilers do so many optimizations that most work-a-day programmers don't think about as well. If you're one of those people who care about the exact instructions coming out of your compiler, you're just inlining assembly.
layer8 8 hours ago [-]
Maybe read my comment again. I was making a point that the exact machine code output by the compiler isn’t relevant to the argument.
VectorLock 8 hours ago [-]
Maybe read my comment again. I wasn't disagreeing with you.
js8 11 hours ago [-]
I think you're wrong, the compilers are already unpredictable (or chaotic, better to say than nondeterministic, as someone pointed out). However the classical compilers limit the effect of unpredictability to resource use (such as CPU, memory and binary size), and not the "result" of the program.
Although even program results are not guaranteed, famously C standard leaves some things undefined and up to implementation.
So the analogy works as long as you understand that natural language itself (aka the prompt) doesn't give complete specification, and it's the LLM itself which selects a particular formalization. But in principle it's not much different from compiler electing to use an optimization and making program faster. Or using a particular flavor of stdlib.
In fact today even the execution itself is unpredictable. For example, a different input can cause cache eviction or branch misprediction, making a loop much slower. Or a different thread might execute on hyperthreading core, affecting the performance.
I think with LLMs, we will be in a long tail of finding those scenarios (where natural language leads to big misunderstanding) and fixing them.
layer8 8 hours ago [-]
Just to address this point:
> famously C standard leaves some things undefined and up to implementation.
And the language specification lets you reason about when the code will invoke undefined behavior and when not. You can ensure that you’re on safe ground by reasoning about the code in accordance with the language specification. With LLMs, such rigorous reasoning is not possible. The very fact that the C language specification does define when UB occurs is what lets you reason about it.
> I think you're wrong, the compilers are already unpredictable (or chaotic, better to say than nondeterministic, as someone pointed out).
I made the point in the root comment that the compiler may be non-deterministic and that this doesn’t matter for the argument. Because the point isn’t about determinism, it’s about being able to reason with high precision about the program’s behavior based on the source code.
mlinksva 1 hours ago [-]
The simile works for me, illustrated by something earlier in the blog post:
> If a junior programmer does not learn to write code and simply generates it, they are robbing themselves of the opportunity to develop the visceral understanding of code that comes with being down in the trenches.
I never learned to write any assembly language and am pretty sure as a result I do not viscerally understand what a compiler generates, though I enjoy recreationally looking at godbolt as much as the next person. Given a lot more time I'd get to assembly (and below) but I don't feel that I robbed myself.
There's a difference in how you can reason about a nondeterminstic system from how you can reason about a determinstic one, but you can reason about both, and you can develop a visceral understanding of both.
layer8 21 minutes ago [-]
Regarding the assembly language (or equivalently, the machine code), I was trying to make the point that yes, you don’t need to understand it to be able to reason about how the source code affects program behavior. (The entire point of a compiler is that you don’t need to understand machine language.) I was also trying to make the point that it isn’t about determinism vs. non-determinism. Nevertheless, there is dramatic difference in the way one can reliably reason about the precise effects of source code versus doing the same for LLM prompts.
edflsafoiewq 1 days 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.
tatjam 6 hours ago [-]
If I was Stephen Wolfram, i'd be screaming (in a very academic way) "you are just talking about computational irreducibility!!" LLMs are very close to computationally irreducible, no chance you can predict its output from the prompt alone. Source code meanwhile is fairly reducible (and is typically reduced to machine code by the compiler). And even complex source code is intentionally designed to be highly reducible via abstractions. Good luck making prompts that reduce the complexity of the LLM behavior!
orbital-decay 1 days 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 23 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 21 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.
1 days ago [-]
doug_durham 17 hours ago [-]
Very few working developers "reason" about their code. We are just trying to build things.
kelnos 15 hours ago [-]
Speak for yourself; reasoning about code is essential to maintainership and being able to modify it.
layer8 10 hours ago [-]
My working experience is different.
girvo 14 hours ago [-]
I don't think that is true at all.
mrheosuper 17 hours ago [-]
Another thing about compiler, if your input(source code) is stupid and not follow the expected format, it will outright refuse to generate output for you, no matter how much you ask or whatever trick you pull.
With LLM, if your input is stupid, the llm may/may not nudge you and happy to continue with that input and gives it 100% effort.
w4yai 1 days 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 ?
layer8 10 hours ago [-]
Not in full generality, of course, because you can formulate an LLM as a program, so LLM behavior is a subset of program behavior. But we generally strive for writing programs such that we can reliably reason about their behavior. We don’t always succeed (it’s the topic of software engineering how we can succeed), but it’s close enough, and enabling that is what programming languages with precise semantics are designed for. With LLMs, on the other hand, there is no path to such reliable reasoning on their behavior.
tkzed49 23 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.
brabel 17 hours ago [-]
If you could , bugs wouldn’t exist.
NichoPaolucci 21 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 19 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.
vconnor 17 hours ago [-]
This is exactly the approach I’m limiting myself to: LLMs as a very smart rubber duck to assist in research and understanding complex systems. I have no interest in it writing the code for me, just like I have no interest in another person doing the same.
I am the engineer, I am the one that has the vision, and I am the one that needs to understand the thing down to the minute details.
That said, most systems I still write are not so complex I need a very smart assistant, so I rarely use LLMs at all; it is still a valuable skill being able to research and think hard for yourself. An LLM cannot think out of the box (of its training dataset), and there lie the discoveries and paradigm shifts that move tech forward.
vips7L 8 hours ago [-]
It’s nice to see some sanity in an insane world.
dsego 15 hours ago [-]
I could keep pace until about half a year ago. But it meant hands-on typing code for the full work day. Now with claude I can produce similar output in 1-2 hours, most of the time is spent on iterating and having the LLM review the code and fix it by itself and then me testing everything. There is more risk of letting the LLM make judgements and building the wrong thing and me having a smaller chance of discovering holes in the requirements because claude is happy to confidently make the wrong decisions.
8 hours ago [-]
brabel 17 hours ago [-]
You should be careful. It’s not just about being faster. LLMs can write more tests, more reliably, and find things that must be changed following a change that you might overlook, and find contradicting requirements so much better than humans. You can probably keep up in terms of speed , though I doubt it for nearly every programmer I’ve ever met including myself… but almost certainly not with the same level of quality and thoroughness, despite what people on HN seem to think.
vips7L 15 hours ago [-]
I’ll be ok, I produce higher quality work than any LLM ever will. And if that time ever comes, which I seriously doubt, it’s not like it’s that hard to prompt.
LLMs will hallucinate edge cases or worry about things that just aren’t possible within context. It results in more tests than are needed. I personally dont think LLMs are any good at all.
fingerlocks 14 hours ago [-]
I can’t believe I’m writing this comment.
A month ago I was still talking like you. Then I said to an insisting colleague, “watch I’ll try to vibe code a game engine and show you the crap it produces.”
Granted, this wasn’t my first game engine so I knew exactly what to say, but I was completely floored. GPT Sol & Astra at max effort was flawless at nearly everything I threw at it. I’m talking fully ground up, zero dependencies, just the primitives and SIMD. Fully featured engine done in two weeks with deferred 2-stage render pipeline, shadow maps, mesh shaders, MSAA, post processing, collision, physics, the works.
I even intentionally skipped a few important optimizations and went back to refactor them in, thinking there’s no way it can do a wholesale rewrite of major systems, but it did it. I got dry mouth from all the jaw dropping. My prompts got shorter and more ambiguous, so it would ask me clarify. I audited every line of code, and it was good (after adding two skills.md). I gave up. I’m a reluctant believer.
It sucks, but sadly these things are really good. Don’t be last contrarian, there’s nothing to gain. You’re just lying to yourself
NichoPaolucci 9 hours ago [-]
I think this is the part that stumps me. I've done similar things, I'm not math heavy but "vibecoded" a full physics simulator. It wasn't 100%, but it was 90% or 95%. Wild!
But I dropped it and will probably never touch it again.
Are you going to do anything with that game engine? I'm sure there are thousands of others who've written a game engine with the tools. What are they being used for? Is it just to "try it out"? I see people producing a LOT of software. Sure, the code is good, but was it needed? Are people using it?
And maybe that's OK - we're just writing software for ourselves now, because it's so cheap + fast to produce.
pests 5 hours ago [-]
> Are you going to do anything with that game engine? I'm sure there are thousands of others who've written a game engine with the tools. What are they being used for? Is it just to "try it out"? I see people producing a LOT of software. Sure, the code is good, but was it needed? Are people using it?
You can ask the same about hand written code too.
Dzugaru 13 hours ago [-]
Have you tried creating something that doesnt have HUNDREDS of existing implementations on the Web already?
vips7L 8 hours ago [-]
Maybe I’m just better than you? It’s something to consider. Your whole point here is that astra could pump out something faster than you ever could at a quality level _you_ think is good. It might be worth some reflection that _your quality level_ is not _my quality level_.
I have no pressure to use this stuff. I’m still getting paid. I’m still shipping higher quality software at the same speed as the rest of my peers. Why should I sacrifice quality for speed?
shadow28 27 minutes ago [-]
I'm quite curious to know what kind of systems / software do you work on?
sgt 16 hours ago [-]
> LLMs can write more tests
In fact, sometimes LLMs write too many tests to the point it significantly slows down your test runs and CI!
vips7L 15 hours ago [-]
Too many tests and hallucinates edge cases and “security” flaws.
sgt 14 hours ago [-]
Good point. Might be good on a weekly basis to purge / look for stale and unnecessary tests.
vips7L 8 hours ago [-]
Shouldn’t that be caught at review time? Or by the sad little ai driver that submits the pr? ;)
wvenable 7 hours ago [-]
I had that issue so I told it to refactor the tests to a smaller more concentrated significant set.
girvo 14 hours ago [-]
And yet LLMs still seem to write the same kind of crap brittle mock-the-world tests that average developers do, drives me nuts.
vips7L 8 hours ago [-]
Of course. LLMs only produce the average. Most of the time if you think you need to mock you should probably just do the real thing. It’s mostly an antipattern.
OtomotO 17 hours ago [-]
I really and unironically applaud you, when the code you're writing has higher quality than the average AI produces AND it means something.
In the domains I get paid to work in, it simply doesn't matter.
The code was shit to begin with, because of hundreds of hacks due to underspecified or simply wrong requirements, bad code practices, architecture that couldn't keep up but was never fixed due to stubbornness...
Not saying we humans would do better or worse in general, just sharing my experiences.
I have customers where AI usage is absolutely forbidden and others where it's totally fine and colleagues vibecoded mess will come to bite them/us all.
vips7L 15 hours ago [-]
I enjoy programming and producing high quality work. Why would I want to give up the thing I find fun and produce something subpar?
> The code was shit to begin with, because of hundreds of hacks due to underspecified or simply wrong requirements, bad code practices, architecture that couldn't keep up but was never fixed due to stubbornness...
My coworkers have always produced slop, even before LLMs. Unfortunately, as the lead on the project it’s still my responsibility to get that up to a certain quality level or at least make it isolated and malleable enough that it can be changed and we all won’t have a bad time doing it.
I guess what I’m saying is.. I get it. It’s hard to work with other people who are just pushing whatever is given by the LLM. But I still have fun doing it myself.
orlp 12 hours ago [-]
> I enjoy programming and producing high quality work. Why would I want to give up the thing I find fun and produce something subpar?
No one who cares wants to. That's not the question.
The question is whether you can continue to get paid doing so.
vips7L 8 hours ago [-]
I seem to be continuing to get paid. What’s your next excuse about why you’re sacrificing quality?
OtomotO 14 hours ago [-]
I also still enjoy it. In my spare time.
I've always enjoyed it. In my spare time.
Also I wouldn't go as far to say that I myself produce higher quality code than my peers.
I am between a 5/10 and a 7/10 programmer at best.
I bring other valuable skills though.
21 hours ago [-]
johsole 1 days 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 1 days 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 1 days 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 21 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.
mrheosuper 17 hours ago [-]
if an agent so capable of maintaining the mess of AI slop, i bet it can also do these
>1) writing and refining specs, 2) "managing" agents by answering questions, evaluating new models, new tools, etc, 3) testing and validating AI output.
icedchai 9 hours ago [-]
To some extent, but people still need to ultimately decide what to build, if it's being built correctly, etc. The accumulation of crappy code / slop is an issue, but it's going to improve. We're just getting started in all this, people are figuring things out.
mrheosuper 3 hours ago [-]
Is that fundamental problem with AI, or it's just because we are not throwing enough GPU into chatbot ?
vinyl7 1 days ago [-]
Have we coined the term Slopgineer yet?
24 hours ago [-]
17 hours ago [-]
simonw 1 days ago [-]
I think people who understand how computers and software work will be better positioned to generate those new ideas.
kelnos 15 hours ago [-]
There are certainly lots of product-minded developers, but there are also lots of developers who couldn't design a product or come up with useful product features if their lives depended on it.
I do think perhaps LLMs could give product-minded developers more time to think about and refine those ideas, though.
bluefirebrand 1 days 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 1 days 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 1 days 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.
notpushkin 23 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.
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.
simonw 1 days 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 1 days 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.
OkayPhysicist 1 days ago [-]
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 1 days 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 23 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 23 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 22 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.
dirtbag__dad 22 hours ago [-]
This resonates with me. I joined a climate tech company to help save the world. I built data pipelines like anywhere else
benatkin 23 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
dgfgdfgdf 14 hours ago [-]
[dead]
Cthulhu_ 11 hours ago [-]
You can achieve similar increases in speed by for example working faster, using a more expressive programming language, omitting things like unit tests, or adding more developers - the real question or test is whether the pace is sustainable, if the output is functionally and non-functionally correct, things like that. Software engineering problems that aren't actually new but the awareness of which has been given a boost with the advent of LLMs and their (perceived, short-term) productivity and output boosts.
dkarl 1 days 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 1 days 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 1 days 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 22 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
dgfgdfgdf 14 hours ago [-]
[dead]
Uptrenda 12 hours ago [-]
They already got rid of junior devs. You don't need them to get better as you're already right. Idk how the author can recommend comp sci. Juniors are more likely to win the lottery at this stage than get an offer.
wildzzz 1 days 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.
tengbretson 1 days 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.
rspeele 23 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.
Cthulhu_ 11 hours ago [-]
Yeah I agree that reading is a different skill from writing, especially reading someone else's code - I think doing code reviews is a great and valuable skill that should be taught alongside but separately from writing code. Can you reason about someone else's code without immediately rewriting it or jumping to "Well I would have written it differently"?
It's an important skill to learn, as a lot of software developers enter the market as "selfish", thinking they should understand and / or own all code, and if there's too much code or too many other people, they will advocate for microservices so they can once again own their slice of code.
But that's coding; software engineering is coding at scale, over time, and for the last two you need a different (albeit complementary) skillset of both hard and soft skills (hard skills being reading / understanding / reasoning about code, soft skills being letting go of your own ego and giving constructive feedback)
JodieBenitez 18 hours 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 21 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.
doug_durham 17 hours ago [-]
Don't think you can be a mature developer unless you can fluently read code. I tell everyone learning to code that reading code is equally important. In our world of AI tools reading code is turning out to be a key skill.
Exoristos 1 days 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 1 days 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 23 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 23 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.
gregwebs 21 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.
dsego 15 hours ago [-]
How do you know it's better if you are not a good programmer, do you trust it blindly?
Cthulhu_ 10 hours ago [-]
You don't need to be a good writer to recognize good writing, the same goes for code.
Okay bit of nuance; this applies to fiction / nonfiction writing based on writing style, not so much correctness - for judging correctness you don't need to be good at writing code (or legalese, or fiction), but you need to understand what's written on the one hand and what the writing should express on the other.
H1Supreme 8 hours ago [-]
> You don't need to be a good writer to recognize good writing, the same goes for code.
I don't see how these are comparable. Let me re-word that statement with analogous disciplines: You could argue one doesn't need to be a chef to recognize good food, the same goes for building blueprints.
geraneum 18 hours 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?
brabel 13 hours ago [-]
I agree with OP. It’s already the case that when I write code by hand I forget to do stuff that an AI with good instructions would never forget. I struggle with Boolean conditions that get more complex than a few operators while the AI can easily explain and track things like that. Debugging in your head was necessary sometimes to figure out why something was doing unexpected things, now you ask an AI and explain the strange behavior and it will tell you exactly what the problem was in seconds. In summary, at least let the AI review your work, you will be surprised how many issues it finds. At some point it’s just not worth it trying to do things manually, it’s even becoming irresponsible, like not using a type system ( though even that argument was polemic once)
geraneum 13 hours ago [-]
You are explaining why it’s safer “for you” to let AI write code for you, considering the safety here is being put forward in comparison to coding in assembly. That’s fair.
But it still doesn’t explain based on what principle and logic this is the case with regard to coding in a higher level language vs. assembly.
Let’s reframe the question: why do you think writing in assembly is less safe? Do the same reasons apply to AI coding? What are those reasons?
Don’t get me wrong, I think it’s good to let AI have a pass at the code, but this doesn’t lead to the above conclusion IMO.
za3faran 20 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.
dsego 15 hours ago [-]
I know from experience that Claude will be confident about something, but when I push back it will concede quickly. And it will happily overly complicate the code, come up with made up requirements or rules that it inferred but are completely bogus.
fxwin 14 hours ago [-]
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.
bborud 3 hours ago [-]
Hmm. I think I understand where you are going but given that LLMs appear to need injected randomness to work effectively, determinism isn't really on the table so we kind of stop talking about the LLMs we use when we (strictly speaking) consider the case where they could generate deterministic sequences?
Not that this in any way takes away anything from your argument that "it's that language is imprecise". That still holds true, but it is on the input side.
aucisson_masque 1 hours ago [-]
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.
Wowfunhappy 10 hours ago [-]
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.
wvenable 7 hours ago [-]
> 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.
This is the reason why there are billions upon billions of dollars being invested in AI. There isn't enough return if it just replaces software developers.
I'm not saying that it will replace software developers and/or everyone else but that's the implication behind the investment.
Wowfunhappy 7 hours ago [-]
Right, and I'm coming to the point where I think the AI companies might be correct! But under that scenario, I'm not really sure what career advice to give anyone about anything. Unless maybe you're interested in becoming a plumber, and even that might not save you.
No matter what happens, I think there will be as much demand for programmers as anything else.
wvenable 5 hours ago [-]
I think the current world economic situation is clouding the actual economic impact of AI. People are losing their jobs due to the poor economy in all sectors, including software development, so how much of that is exclusively due to AI? We have no idea. It might be fuelling additional job-impact pessimism.
tripleee 9 hours ago [-]
How many people will we need in those positions of oversight, though? If the demand doesn't expand we might see 95% of developers out of work regardless
Wowfunhappy 8 hours ago [-]
I really have trouble imagining a world in which a drastic decrease in the cost of software development doesn't lead to a drastic increase in demand for custom software.
I remember when I worked at a design agency, we spent so much time trying to select project management software, but nothing ever really fit our specific needs. We never considered trying to commission something custom, because a decade ago, that would have been totally nuts for a 20 person company. Nowadays I absolutely think we would have just made something in-house.
I was a teacher at a K-12 school last year. The admin team was trying to select new curriculum mapping software (a system which lets teachers see what kids are learning across different grades and subjects at various levels of granularity). The standard solutions for this all suck. The admin eventually decided to just create something custom, using AI.
I suspect that every company is going to want bespoke systems which are perfectly tuned to their needs, once it becomes financially viable to do so.
tripleee 8 hours ago [-]
Will software developers be the ones making it, or will it be the experts in the relevant domain?
I've been on a vibe-coding binge to create a bespoke tool for myself over the last week. I haven't looked at the code once. Couldn't tell you how it's designed, because I never needed to look, despite having over a decade experience developing software professionally.
I struggle to see this process from a less technical person's eyes so it might not be this easy for everyone, but it really feels like we're close to the point where deeper software skills are only going to be valuable for either very large codebases or ones that require scaling, which doesn't apply to most of that bespoke internal software.
The hiring for those roles might be closer to "knows our domain well" than "knows the tech stack"
Wowfunhappy 7 hours ago [-]
Well that's why I said I think there's two possible outcomes. If the AI is so good that you don't need to think about the code or architecture at all (which isn't quite the same thing as whether you looked at the code or not) I think most work goes away in general. In this case there may be less demand for software because there will be little to use software for in the first place.
> The hiring for those roles might be closer to "knows our domain well" than "knows the tech stack"
This does seem likely to me, no matter what. But:
> Will software developers be the ones making it, or will it be the experts in the relevant domain?
In World #1, I imagine there will be someone whose job it is to produce the software, yes, and they'll probably do a much better job if they have a strong conception of how software and computers work.
flowerlad 6 hours ago [-]
> they will also be capable of virtually any other job
... that only requires intelligence. Some jobs require more than just intelligence—for example, nurses, judges, reporters, teachers, caregivers, therapists, social workers, paramedics, firefighters, police officers, electricians, plumbers, mechanics, trial lawyers, managers, and diplomats. These roles also depend on some combination of physical skill, human connection, trust, judgment, accountability, and the ability to act in real-world situations.
Culonavirus 17 hours ago [-]
> 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.
otterley 16 hours ago [-]
That’s just silly. It’s like saying that people who don’t have a legal background are incapable of understanding that the law will impact their decision making.
What I’m seeing is that managers understand the problem but are purposely ignoring it in the short term because they’re trying to stay competitive. It’s just another kind of technical debt but in different clothing.
Culonavirus 15 hours ago [-]
It not silly at all. I'm not even saying it's a bad thing. From their point of view, they would rather have increased error rate if it means faster shipping speed. This is nothing new, AI just multiplied it. Startups especially want to ship fast and look at longevity later. Unless this drive is countered by someone up the chain who wants to do things properly, it will naturally happen and you can't do anything about it. Well you can, but then you will be explaining to your manager why your tasks are done so slowly when Chad Vibeson over there shipped 5 features and 100k lines of code last month alone.
samstress 2 days 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 18 hours 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 23 hours ago [-]
You’ve missed the point. You can’t reliably use AI to generate code if you can’t understand code.
smcg 1 days 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 1 days 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 1 days 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 1 days 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 1 days 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 1 days ago [-]
How many is too many?
bluefirebrand 1 days 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 1 days 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.
vulk 8 hours ago [-]
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.
Baguette5242 11 hours ago [-]
> 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.
markus_zhang 5 hours ago [-]
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.
ivanjermakov 1 days 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?
Cthulhu_ 10 hours ago [-]
> LLMs make making computer programs more affordable and efficient
In the short term I'm inclined to agree, but the total cost of computer programs (i.e. affordability) is something that can only be determined over time (and with a lot of effort! Although with LLMs it's easier as you can easily measure and manage cost over time I suppose).
sarreph 10 hours ago [-]
> 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.
wiremine 5 hours ago [-]
> "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.
markus_zhang 5 hours ago [-]
I think it makes sense.
I believe humans learn by thinking through the problem, making implementations, and iterate on them. Maybe some smart guys can implement once and get a perfect result —- for example Dave Cutler famously said that he always ran the code in his head a few times before he actually ran the code on the machine.
However, for the majority of us, the common people, thinking through a problem usually doesn’t work like that. I wrote a shadow casting algorithm a few years ago and that took me half of a night to get it right. I did think through before every implementation, but each “thinking through” actually left some gaps which were only discovered by actually writing and running the code.
Now that I admit that I’m not smart enough and do not have a very big short term memory pool as some of the top guys. I have to write, run and debug the code even after thinking through the problem, and I believe that’s true for most of us out there.
And that’s why I think what OP said makes sense —- especially for juniors —- you can’t expect juniors just sit there, think through the problem, write down some pseudo code and call it a day.
gorgoiler 19 hours 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!)
jeffreyrogers 20 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 19 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.
jeffreyrogers 8 hours ago [-]
I think being able to read a spec and implement business logic to that spec is a basic coding skill, just like being able to read and summarize an argument is a basic literacy skill. If people are worse at that it means they are less proficient at programming than they used to be. It might not matter since LLMs are very good now and will continue to improve, but it's strange to see the quality decline.
blixt 14 hours ago [-]
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.
geraneum 14 hours ago [-]
Following this logic, why teach math and multiplications at school when calculators and software have been doing the numerical work in engineering?
disgruntledphd2 14 hours ago [-]
> 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 mean, I benefited massively from reading Vol 1 of TAOCP and understanding Knuth's new assembly. Like, it hasn't been directly useful but I now have a deeper understanding of how my code actually executes, which has helped me contextualise performance problems.
So, I guess that I'm with the OP on this (this may change if we can figure out automated verification for software, at which point I'd be happy to mediate most things through an LLM with tools).
jenningsh 16 hours ago [-]
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)?
chaosharmonic 10 hours ago [-]
> 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
riantogo 17 hours ago [-]
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.
amelius 15 hours ago [-]
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.
psygn89 1 days 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 1 days 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.
frmrtntn 12 hours ago [-]
Basic programming classes are like the baby steps of programming. Huge gulf between that and being able to write and understand complex software.
RomanPushkin 9 hours ago [-]
> 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.
dsego 15 hours ago [-]
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.
ibejoeb 1 days 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.
iamgopal 10 hours ago [-]
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.
trixn86 12 hours ago [-]
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.
martinjc 6 hours ago [-]
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. :)
freehorse 15 hours ago [-]
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.
password54321 13 hours ago [-]
Open weight models at a minimum are not going anywhere. It is delusional to think we are going back from this.
freehorse 11 hours ago [-]
I never said sth about "going back" but we can have all the "skills" related to current models/agents completely replaces by new skills in a completely different paradigm in 5 years. The same way that the early "prompt engineering" skills are irrelevant now. But understanding how a computer and a program works in a fundamental level has stayed more around than any other trend.
manoDev 7 hours ago [-]
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
DeusExMachina 7 hours ago [-]
There are a thousand steps between models generating machine code and the future you envision, none of which is necessary, especially since there will be humans involved that will prefer alternatives.
rglover 7 hours ago [-]
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.
hobo123 12 hours ago [-]
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.
sippeangelo 1 days 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 1 days 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.
sippeangelo 15 hours ago [-]
As the lowly programmer, rather than a compiler engineer or a CPU architect, I will never dig into the reasons why my tools decided to do something crazy. I'm much more likely to just try random things until it works. How is that different to how people use LLMs? Even here the opposite is true, the LLM enables me to ACTUALLY dig into the lower levels and work around those issues! It will happily dig into the Chrome source to find exactly why my page rendered weirdly, or why an optimization didn't kick in!
kelnos 14 hours ago [-]
I mean, that's kinda on you, though, right? If you're just going to poke at your code until it works, that's your choice, I guess, but I wouldn't call it good programming.
The point is that it's reasonable and possible to predict the compiler's assembly output from high-level source. Maybe each individual can't do it, but they could, with a little learning.
With LLMs, you just can't predict the output for a given prompt, and can't predict how changing that prompt will change the output (or how much it will change the output). Even the people who build and work on LLMs every single day and know them intimately can't.
aryehof 17 hours ago [-]
> 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.
aklein 11 hours ago [-]
> 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.
jagadaga 15 hours ago [-]
> 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.
No, LLMs will do it for you.
> 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!”
We won't need either.
> 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.
No, LLMs will do it. It's no harder than solving complex math problems, so why wouldn't they?
> 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.
Then you'll be left behind by those who do, because they'll ship faster. And surprise, the quality won't be any worse than yours.
It's over. Accept it.
nine_k 15 hours ago [-]
> because they'll ship faster
They will ship faster what? Different software requires different levels of diligence. A pop-up web site for an event and a piece of foundational infrastructure code have almost nothing in common.
> the quality won't be any worse than yours.
Does the current practice support this claim? My claim is that with a kind word and a gun, I mean, with human expertise and LLM's ability to do intellectual legwork, it is possible to achieve more than with just an LLM.
>> we don’t need business people!
> We won't need either.
ROTFL. Did you see what e.g. good salespeople do? Very often they are more important for success than engineers, and I say it as an engineer.
>> the ability to write, think and communicate clearly
> No, LLM will do this for you
I hope this is said in jest. If not, I rest my case and just wait for the reality to land its sobering uppercut.
brainwad 14 hours ago [-]
>> No, LLM will do this for you
> I hope this is said in jest. If not, I rest my case and just wait for the reality to land its sobering uppercut.
The ASI believers would say exactly the same back to you. If a machine can think better than humans, then outsourcing thinking to it will get better outcomes, however degrading it is to humanity. Presuming, of course, the machines still listen to us when they are superior to us in all ways.
Cthulhu_ 10 hours ago [-]
How will LLMs "do it for you" if you don't tell them what you want / need? I don't think they have the ability to read my mind. They might advance (or, the companies may build products that do it) to the point where they can make assumptions about what might be good or helpful, but that might end up with a lot of guesswork, churn, and throwing spaghetti at a wall to see what sticks.
Shipping faster I believe, but we've seen plenty of startups in tech since the late 90s that all "shipped fast" but ended up bankrupt because shipping fast isn't the same thing as shipping what is good, neccessary, helpful, or profitable. That said, those were things made by humans so I'm not saying human-built is good by default.
But shipping more and / or faster is not the solution. I'm not even sure what the problem it's trying to solve would be.
jagadaga 3 hours ago [-]
> How will LLMs "do it for you" if you don't tell them what you want / need?
You tell them what you want, yes. You just won't need to be a software engineer to do it.
> shipping fast isn't the same thing as shipping what is good, neccessary, helpful, or profitable
LLMs will warn you if something isn't good, helpful, or profitable, etc.
> But shipping more and / or faster is not the solution. I'm not even sure what the problem it's trying to solve would be.
There are plenty of ideas in the world to implement. Current software development is slow and expensive. That's a real problem, and LLMs are helping solve it.
x62Bh7948f 10 hours ago [-]
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.
broodbucket 23 hours ago [-]
>And companies: you must let juniors write the code.
This is just not going to happen.
jiaosdjf 13 hours ago [-]
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
sajithdilshan 1 days 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.
JeremyHerrman 6 hours ago [-]
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.
xyproto 13 hours ago [-]
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.
globular-toast 12 hours ago [-]
Do you have any experience doing coding tasks with temp 0?
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.
MotoriX 11 hours ago [-]
AI is a great tool, but you still need to know how to do things yourself to avoid mistakes.
Kuyawa 20 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
Exoristos 24 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?
kelnos 14 hours ago [-]
Sure, but it's not always feasible to divide work like that. If I'm working on a big problem and 2% of it is writing regexes, I'm not going to farm that work out to someone on my team who likes crafting regexes. That feels inefficient and kinda annoying. I'm either going to slog through it myself, or ask an LLM.
prpl 24 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.
cush 10 hours ago [-]
I think this is terrible advice. Going into computer science right now is super risky. If anything maybe learn real Engineering, not Computer Science
sergiotapia 1 days 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.
vconnor 17 hours ago [-]
You might not know this, but there are people for whom writing code was not suffering.
You might have chosen CS because it’s a popular career that makes you a lot of money, but some of us genuinely enjoyed writing code.
kelnos 14 hours ago [-]
I'm right there with you, but I think we are in the minority. There aren't enough of us to sustain software development unless LLMs get good enough so this doesn't matter.
Exoristos 1 days ago [-]
I don't think college is "suffering" for everyone. In fact, for many, it's a very enjoyable challenge and experience.
lemming 24 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 24 hours ago [-]
I'm struggling for a clever analogy with manual screwdrivers and electric drills ...
(I know, I'll ask ... oh well ...)
dzonga 23 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.
vouaobrasil 8 hours ago [-]
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.
a1o 21 hours ago [-]
I watched that Ted Lasso episode too!
redwood 10 hours ago [-]
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
Uptrenda 12 hours ago [-]
"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...
iAMkenough 1 days 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
tucnak 15 hours ago [-]
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.
kelnos 14 hours ago [-]
I think you underestimate the difference between white collar and blue collar work. The trades are not for everyone, and it's not a simple substitution to just pick another career track and be fine with it.
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.
"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.
If creation of customized software solutions is consistently getting cheaper and good enough in quality, the near future is about creating much more custom solutions for considerable smaller customer or consumer groups.
Mind that we still need people who understand tech and verify that a system does what it claims to do, in a safe and efficient way. Every non-technical vibe coder will at some point realize, that he maybe can prompt away every problem he has, but that is still considerable effort and also includes all the mistakes a professional already eradicated from his habits. Many vibe coded projects will also collapse under their own weight, rethinking a strategy - with tech in mind - is also professional effort.
Even if LLMs would produce perfect, high quality code all the time, instructing the "perfect" prompt is still a human problem. LLMs cannot mind read and fully understand the environmental and social circumstances. Understanding these things and model them into solutions, are also human problems.
All this still requires profound technical knowledge, even more now considering security is under fire.
You’re not going to be a billionaire, just be happy doing a good job making niche things for companies. You don’t need 800,000 users. You need 8 small businesses that are paying you $2000/mo.
Yes, they might be able to build software that works for (relatively) close to free now. But that still has marginal cost in terms of extra resource to build it. Then it needs to be maintained, upgraded to meet changing internal requirements, it needs to be secure, they need to be able to trust it does what it's supposed to.
Sure, the cost of all of that has come down, but it's still a lot of work when they could just entrust another company to do that for a cost they're willing to pay. And companies are often happy to pay a lot in B2B contracts.
Just to reinforce this: look at the cost savings from cloud-exits - yet companies still readily build out in the cloud. FOSS has existed for decades, yet companies still pay for proprietary alternatives. Build vs buy exists on more dimensions than just cost alone.
When a software suite costs a company $70-100k per year that does a bunch of stuff they don’t want, they’ll definitely pay you to build bespoke tools for $24k per year.
Literally doing this now.
Maybe I'm overthinking things. There were companies paying out the ass for relatively basic WordPress sites in the past (and probably still)
I’m on vacation right now, but my main customer is constantly adding new feature requests, etc. and until I went on vacation their work was as good as 2 or 3 customers per month, “oh can you do this? What about this?” I honestly am looking forward for them to throttle back a little because I could use another similar volume customer, but I hardly have enough time to really invest to make that happen until they get all the things they want and while they’re paying me I ain’t going to stop.
It was also pretty cool, because there’s a young engineer working there in a non-engineer role as a human forklift. I said, “hey, I need help implementing all this stuff” now he has a raise, and he is kind of like an embedded customer support person, and I don’t have to stress about it so much.
Regardless, just build.
The phone call automation for their front desk saves something like 40 hours of work a month just of people looking up customers to call about their schedule etc. And that’s just one tool and I deployed it in like 4 days. It’s really not that hard, just go out and make people’s lives easier and stop trying to scale or whatever.
It was something that looked like it was originally written in visual basic and than rewritten in react for tablet devices.
I'm still under NDA but the above figures related to per company\ per month sales are about right
Am I missing something, are you juggling like 5 or more of these types of jobs?
No-one pays $2k/mo for a fractional CFO.
No-one pays $2k/mo for a fractional sales head.
No-one pays $2k/mo for environmental paperwork consulting for a manufacturer.
They can do it all in house. Why would they?
Right?
Except all of these actually do happen, of course, and each is a big industry.
As soon as this industry lost the inscrutability of the syntax of the work product, it began catastrophizing about the total end of any commercial demand at all.
Yet by this logic there should be almost no service providers at all for any industry that lacks legal certification barriers.
Good lord guys…
Microsoft just introduced MXC:
"...for running untrusted code (model output ..."
https://github.com/microsoft/mxc
Spinning jennys are neat but if theyd been invented in a world where use of star trek replicators was routine I think theyd be more curiosity than revolutionary.
"Artisanal code" would definitely die off if the cp command didnt work perfectly or cost thousands of dollars to run but it doesnt hence why the metaphor is at best mistaken (and at worst dishonest, e.g. when frontier labs are desperately pushing it).
And, the flip side is that artisanal clothes would probably make a huge comeback if star trek replicators were invented and nobody would want cheap sweatshop made crap any more. Why would you when handmade Gucci silk clothing could be yours for a couple of bucks?
Except it doesn't seem the software is getting cheaper for the end user, even though it is arguably getting cheaper to build.
Paradoxically, the costs of running the software seem to keep rising, both for running it on a local machine or as a subscription.
Some of those will go on to be successful and need technical people to support it
If handmade one appears it is as some centerpiece, and remaining ones are machine-made.
Software... a lot of software is basically the same thing (database, api, frontend), the only difference is what data and business rules. But the act of writing code isn't very different. It's the what code to write where software engineers come in.
I.e. in order to get to the point where you didn't have to manually touch this thing, you likely did have to learn deeply about its underlying concepts by manually doing things.
Operating machines doesn't always have the same phenomenon. E.g. experience with a hand-powered drill is unnecessary to use an electric drill.
The "only" difference? Wow.
What's left is a lot of very different software which have very few things in common.
Currently, learning programming is the lever to unlock architecture understanding. We will need a few new layers of abstraction before this changes.
Yes, and it’s worth pointing out the class of people buying ikeas rugs were NOT buying Persian wool/silk rugs before…they had bare floors or make coverings out of cloth or woven grass.
Also worth pointing out that since 1979, regardless of whether it is secondhand or not and which country you are procuring it from, rugs made in Iran (Persian rugs) have been totally banned for import to the U.S. Tribal rugs now come more from places like Turkey and India. So the market is being extremely artificially suppressed, boosting ikea rugs even more.
Can you expand on this please? I don't see the reasoning trace that got you to that conclusion.
I am not even sure the market has shrunk, because most people never owned them.
But indeed, the answer in the article’s context is no, probably not. And don’t go to university at all, because you will burn through money you will never replace and develop debt you will never pay off.
Learning a physical skill, or at least a physically based skill, is better, as is learning a skill that is chartered as a profession or at least where there are functional unions.
The future is bad. Really, really bad. Only learn jobs an AI can’t ruin.
... and I'm reminded of all the folks that have Accounting degrees. Their degrees ended up being proof that they could track a lot of rules.
That proof meant they got hired and their job was not to ... "account", but to "fit into our business".
Perhaps that's the majority of CS folks going forward?
"Your CS degree proves you can help me not get stuck in technical problems so I can go solve [business/engineering/scientific/...] problems"...?
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.
However, the skill of having to try many different things and have patience and deal with an unproductive day and sleep in stuff, being able to pull yourself out of a hole, bootstrap deeper understanding in times when you feel helpless…it’s character building and incredibly valuable.
I feel like AI will allow people to have less resolve and determination, like looking at the crossword answers.
The same way we never stopped encountering "Wait, what the hell?" moments when we had the internet and could search for problems instead of digging through textbooks or --help, they'll just run into those blocking moments at a higher level of abstraction, then have to backtrace the problem down to the level they need to understand to resolve the issue. Curious people continue to be rewarded with a higher ceiling, but the floor to get something functional is brought down.
The alternative is that AI just deletes software engineering as a discipline and everything gets vibecoded, which still seems unlikely even if the improvements continue to accelerate.
The problem is AI lowers all barriers to reaching out. Previously you'd have to ask a real person, which might be embarrassing. I do wonder if I would have struggled as much if I didn't have to. I look at what's happened to people's bodies when they no longer have to do physical labour and I wonder if the same thing will happen to their minds.
I'm a middle age guy who has no degree and taught myself to program during the pandemic. By now Ive created websites, built a game(well not finished but most of the mechanics), finished a ml pipeline project, and of course started so many side projects that may never get finished as is expected. But in this market I can't get hired because, well only on part, no degree.
I need to get out of my current career for mental health reasons and have decided to go back to school to get a degree and have chosen my secondary choice for a degree instead of going CS. Now I read this article and feel torn. I want to get to work coding and create something great, work with driven people and solve problems, but I also need income and a path forward so I've chosen another degree to pursue.
I'm torn because either outcome that occurs is bitter sweet for me. Either the market picks up and so many talented, bright minded, and younger engineers will get hired and go on to create amazing things, or the market will stay stale and so many will get jobs not doing what they love.
This is kind of a ramble at this point. I'm summation I love to code so I'll code, and hope that this article it correct and others can get hired quickly and the market turns.
I think the art of refactoring will be more valuable than ever.
I'm having an LLM free day today, going through a lot of generated code, de-duplicating and making the abstractions more usable. It's quite enjoyable and improves my understanding of the code significantly.
Luckily I was able to complete an internship lately (implemented EEVDF scheduler for Redox OS) but even then, the amount of Rust Junior jobs are so rare that it is proving to not be of much help.
Also, when you are on the other side, recognize that offering connections to unconnected people is a wonderful act of charity.
However, the more you know yourself about car maintenance, the more you will trust his diagnosis, solutions and the fairness of the money he asks for it. More generally, the more you will trust him to act in your interest instead of only his (or someone else's).
The edge in the AI future will be ownership.
In all seriousness though, thanks for writing this, I found it helpful.
It feels like there will be a beefy "middle" where people can probably drop some of that context, and get a lot of productive things done with AI. But there will still be a need for people more deeply knowledgeable and educated. It's probably just not in the proportions we have today.
_Kind of_ like the boom of coding bootcamps. A lot of people got good work done going through a coding bootcamp, but didn't get the deep background that a CS major would.
Coding bootcamps didn't mean we don't need CS education, and neither will AI, I expect. But the numbers and jobs are definitely going to change.
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.
TA meaning...
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 don’t have to review the output of a macro invocation once I’ve convinced myself that the macro’s definition is correct, similar to how I don’t have to review a compiler’s output. That’s the difference we are concerned with here.
For comparison, consider the statement “Assuming that you truly understand and own every byte of the compiler's output, […]”. The point of a compiler is that we can depend on it without having to impose such an assumption.
I might take on to saying that compilers are more deterministic than vibe coding, that should stop the vibecoders from arguing about how technically 1+1 is not deterministic because of UB in C or whatever.
That said, they'll probably start debating that something is either deterministic or it isn't, and we can answer that they couldn't be more wrong, and they'll answer that wrong is an absolute state and not subject to gradation, , and we can answer that of course it's relative, it's wrong to say a tomato is a vegetable, but it's more wrong to say it's a suspension bridge, and then we can finally go to bed because the online arguments have all been solved, the end, it's done.
You literally don't know what it does, though. And it's not a given that QA testing the program will lead to an answer before it leads to a bad outcome. There's an understanding, when we use software we can't read, that some humans looked at it and talked to other humans about how it works. Maybe got calls from customers about bugs, made workarounds.
If I'm just vibecoding stuff for me, and I don't understand any of it, I would not feel safe running it on my computer. And I'm not convinced a lot of people are even going to do this, because non-technical users seem to intuitively understand they are rolling dice in some way.
You certainly can, but you can't tell people anything about how it works, if it's safe, whether it spies on people, when it needs to be upgraded, etc. Is there going to be a market for vibe coders who sell services they don't understand? I don't know.
For documenting business logic, code is highly specific and dependable even with non-deterministic compilers. We can look at code and say "Yes, we can connect this to our Stripe account, because we have reviewed what it actually does." We can mock services and test that it works. We can do all of that without reading build output
The same, obviously, cannot be said of LLM prompts. And due to the flaws (and strengths!) of Natural Language, I'm not sure that will change. If someone told me their vibe coded app was safe because they politely asked it to be, I obviously wouldn't use their service. If they told me they asked it to write tests and do mocks, I wouldn't know if it actually did. A pure vibecoder can, at best, reread the prompt they gave, and maybe ask the LLM if there are vulnerabilities, hoping that it finds something.
Maybe we will get to a point where people are feeding 80 page specifications to LLMs as the input, but I'm not sure a person who is capable of writing that level of detail but incapable of learning to read code really exists. I don't think it will get that far. I think people will keep their prompts short and just roll the dice, QA testing.
As a sibling commenter said, I agree that the concept here is "chaotic". A small change in the input (the prompt) can create large (or not!), unpredictable changes in the output. And variations on that small input change can have wildly different effects on the output.
But a change (large or small) to C code will create predictable (large or small) changes to the assembly output.
A tiny change in the inputs can result in a large (and hard to predict) change in the output. Non-determinism is a different axis completely, and some compilers are (semi-accidentally) NOT deterministic either (two runs are not byte identical)
A vanishingly small percentage of coders are thinking about this when they're coding. Compilers do so many optimizations that most work-a-day programmers don't think about as well. If you're one of those people who care about the exact instructions coming out of your compiler, you're just inlining assembly.
Although even program results are not guaranteed, famously C standard leaves some things undefined and up to implementation.
So the analogy works as long as you understand that natural language itself (aka the prompt) doesn't give complete specification, and it's the LLM itself which selects a particular formalization. But in principle it's not much different from compiler electing to use an optimization and making program faster. Or using a particular flavor of stdlib.
In fact today even the execution itself is unpredictable. For example, a different input can cause cache eviction or branch misprediction, making a loop much slower. Or a different thread might execute on hyperthreading core, affecting the performance.
I think with LLMs, we will be in a long tail of finding those scenarios (where natural language leads to big misunderstanding) and fixing them.
> famously C standard leaves some things undefined and up to implementation.
And the language specification lets you reason about when the code will invoke undefined behavior and when not. You can ensure that you’re on safe ground by reasoning about the code in accordance with the language specification. With LLMs, such rigorous reasoning is not possible. The very fact that the C language specification does define when UB occurs is what lets you reason about it.
> I think you're wrong, the compilers are already unpredictable (or chaotic, better to say than nondeterministic, as someone pointed out).
I made the point in the root comment that the compiler may be non-deterministic and that this doesn’t matter for the argument. Because the point isn’t about determinism, it’s about being able to reason with high precision about the program’s behavior based on the source code.
> If a junior programmer does not learn to write code and simply generates it, they are robbing themselves of the opportunity to develop the visceral understanding of code that comes with being down in the trenches.
I never learned to write any assembly language and am pretty sure as a result I do not viscerally understand what a compiler generates, though I enjoy recreationally looking at godbolt as much as the next person. Given a lot more time I'd get to assembly (and below) but I don't feel that I robbed myself.
There's a difference in how you can reason about a nondeterminstic system from how you can reason about a determinstic one, but you can reason about both, and you can develop a visceral understanding of both.
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.
With LLM, if your input is stupid, the llm may/may not nudge you and happy to continue with that input and gives it 100% effort.
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...
I am the engineer, I am the one that has the vision, and I am the one that needs to understand the thing down to the minute details.
That said, most systems I still write are not so complex I need a very smart assistant, so I rarely use LLMs at all; it is still a valuable skill being able to research and think hard for yourself. An LLM cannot think out of the box (of its training dataset), and there lie the discoveries and paradigm shifts that move tech forward.
LLMs will hallucinate edge cases or worry about things that just aren’t possible within context. It results in more tests than are needed. I personally dont think LLMs are any good at all.
A month ago I was still talking like you. Then I said to an insisting colleague, “watch I’ll try to vibe code a game engine and show you the crap it produces.”
Granted, this wasn’t my first game engine so I knew exactly what to say, but I was completely floored. GPT Sol & Astra at max effort was flawless at nearly everything I threw at it. I’m talking fully ground up, zero dependencies, just the primitives and SIMD. Fully featured engine done in two weeks with deferred 2-stage render pipeline, shadow maps, mesh shaders, MSAA, post processing, collision, physics, the works.
I even intentionally skipped a few important optimizations and went back to refactor them in, thinking there’s no way it can do a wholesale rewrite of major systems, but it did it. I got dry mouth from all the jaw dropping. My prompts got shorter and more ambiguous, so it would ask me clarify. I audited every line of code, and it was good (after adding two skills.md). I gave up. I’m a reluctant believer.
It sucks, but sadly these things are really good. Don’t be last contrarian, there’s nothing to gain. You’re just lying to yourself
But I dropped it and will probably never touch it again.
Are you going to do anything with that game engine? I'm sure there are thousands of others who've written a game engine with the tools. What are they being used for? Is it just to "try it out"? I see people producing a LOT of software. Sure, the code is good, but was it needed? Are people using it?
And maybe that's OK - we're just writing software for ourselves now, because it's so cheap + fast to produce.
You can ask the same about hand written code too.
I have no pressure to use this stuff. I’m still getting paid. I’m still shipping higher quality software at the same speed as the rest of my peers. Why should I sacrifice quality for speed?
In fact, sometimes LLMs write too many tests to the point it significantly slows down your test runs and CI!
In the domains I get paid to work in, it simply doesn't matter.
The code was shit to begin with, because of hundreds of hacks due to underspecified or simply wrong requirements, bad code practices, architecture that couldn't keep up but was never fixed due to stubbornness...
Not saying we humans would do better or worse in general, just sharing my experiences.
I have customers where AI usage is absolutely forbidden and others where it's totally fine and colleagues vibecoded mess will come to bite them/us all.
> The code was shit to begin with, because of hundreds of hacks due to underspecified or simply wrong requirements, bad code practices, architecture that couldn't keep up but was never fixed due to stubbornness...
My coworkers have always produced slop, even before LLMs. Unfortunately, as the lead on the project it’s still my responsibility to get that up to a certain quality level or at least make it isolated and malleable enough that it can be changed and we all won’t have a bad time doing it.
I guess what I’m saying is.. I get it. It’s hard to work with other people who are just pushing whatever is given by the LLM. But I still have fun doing it myself.
No one who cares wants to. That's not the question.
The question is whether you can continue to get paid doing so.
I've always enjoyed it. In my spare time.
Also I wouldn't go as far to say that I myself produce higher quality code than my peers.
I am between a 5/10 and a 7/10 programmer at best.
I bring other valuable skills though.
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.
>1) writing and refining specs, 2) "managing" agents by answering questions, evaluating new models, new tools, etc, 3) testing and validating AI output.
I do think perhaps LLMs could give product-minded developers more time to think about and refine those ideas, though.
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.
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.
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.
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.
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.
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.
It's an important skill to learn, as a lot of software developers enter the market as "selfish", thinking they should understand and / or own all code, and if there's too much code or too many other people, they will advocate for microservices so they can once again own their slice of code.
But that's coding; software engineering is coding at scale, over time, and for the last two you need a different (albeit complementary) skillset of both hard and soft skills (hard skills being reading / understanding / reasoning about code, soft skills being letting go of your own ego and giving constructive feedback)
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.
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.
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.
Okay bit of nuance; this applies to fiction / nonfiction writing based on writing style, not so much correctness - for judging correctness you don't need to be good at writing code (or legalese, or fiction), but you need to understand what's written on the one hand and what the writing should express on the other.
I don't see how these are comparable. Let me re-word that statement with analogous disciplines: You could argue one doesn't need to be a chef to recognize good food, the same goes for building blueprints.
I don’t see how that’d make sense. Can you elaborate how exactly this will be the case, specifically about safety?
But it still doesn’t explain based on what principle and logic this is the case with regard to coding in a higher level language vs. assembly.
Let’s reframe the question: why do you think writing in assembly is less safe? Do the same reasons apply to AI coding? What are those reasons?
Don’t get me wrong, I think it’s good to let AI have a pass at the code, but this doesn’t lead to the above conclusion IMO.
> 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.
Not that this in any way takes away anything from your argument that "it's that language is imprecise". That still holds true, but it is on the input side.
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.
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.
This is the reason why there are billions upon billions of dollars being invested in AI. There isn't enough return if it just replaces software developers.
I'm not saying that it will replace software developers and/or everyone else but that's the implication behind the investment.
No matter what happens, I think there will be as much demand for programmers as anything else.
I remember when I worked at a design agency, we spent so much time trying to select project management software, but nothing ever really fit our specific needs. We never considered trying to commission something custom, because a decade ago, that would have been totally nuts for a 20 person company. Nowadays I absolutely think we would have just made something in-house.
I was a teacher at a K-12 school last year. The admin team was trying to select new curriculum mapping software (a system which lets teachers see what kids are learning across different grades and subjects at various levels of granularity). The standard solutions for this all suck. The admin eventually decided to just create something custom, using AI.
I suspect that every company is going to want bespoke systems which are perfectly tuned to their needs, once it becomes financially viable to do so.
I've been on a vibe-coding binge to create a bespoke tool for myself over the last week. I haven't looked at the code once. Couldn't tell you how it's designed, because I never needed to look, despite having over a decade experience developing software professionally.
I struggle to see this process from a less technical person's eyes so it might not be this easy for everyone, but it really feels like we're close to the point where deeper software skills are only going to be valuable for either very large codebases or ones that require scaling, which doesn't apply to most of that bespoke internal software.
The hiring for those roles might be closer to "knows our domain well" than "knows the tech stack"
> The hiring for those roles might be closer to "knows our domain well" than "knows the tech stack"
This does seem likely to me, no matter what. But:
> Will software developers be the ones making it, or will it be the experts in the relevant domain?
In World #1, I imagine there will be someone whose job it is to produce the software, yes, and they'll probably do a much better job if they have a strong conception of how software and computers work.
... that only requires intelligence. Some jobs require more than just intelligence—for example, nurses, judges, reporters, teachers, caregivers, therapists, social workers, paramedics, firefighters, police officers, electricians, plumbers, mechanics, trial lawyers, managers, and diplomats. These roles also depend on some combination of physical skill, human connection, trust, judgment, accountability, and the ability to act in real-world situations.
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.
What I’m seeing is that managers understand the problem but are purposely ignoring it in the short term because they’re trying to stay competitive. It’s just another kind of technical debt but in different clothing.
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.
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?
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.
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.
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.
In the short term I'm inclined to agree, but the total cost of computer programs (i.e. affordability) is something that can only be determined over time (and with a lot of effort! Although with LLMs it's easier as you can easily measure and manage cost over time I suppose).
> 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.
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.
I believe humans learn by thinking through the problem, making implementations, and iterate on them. Maybe some smart guys can implement once and get a perfect result —- for example Dave Cutler famously said that he always ran the code in his head a few times before he actually ran the code on the machine.
However, for the majority of us, the common people, thinking through a problem usually doesn’t work like that. I wrote a shadow casting algorithm a few years ago and that took me half of a night to get it right. I did think through before every implementation, but each “thinking through” actually left some gaps which were only discovered by actually writing and running the code.
Now that I admit that I’m not smart enough and do not have a very big short term memory pool as some of the top guys. I have to write, run and debug the code even after thinking through the problem, and I believe that’s true for most of us out there.
And that’s why I think what OP said makes sense —- especially for juniors —- you can’t expect juniors just sit there, think through the problem, write down some pseudo code and call it a day.
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!)
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.
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 mean, I benefited massively from reading Vol 1 of TAOCP and understanding Knuth's new assembly. Like, it hasn't been directly useful but I now have a deeper understanding of how my code actually executes, which has helped me contextualise performance problems.
So, I guess that I'm with the OP on this (this may change if we can figure out automated verification for software, at which point I'd be happy to mediate most things through an LLM with tools).
Do you have a way I can subscribe to anything you write in future (RSS feed/Atom/mailing list)?
> 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
It is certainly learning faster than any student I've ever seen.
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.
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.
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 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.
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?!"
The point is that it's reasonable and possible to predict the compiler's assembly output from high-level source. Maybe each individual can't do it, but they could, with a little learning.
With LLMs, you just can't predict the output for a given prompt, and can't predict how changing that prompt will change the output (or how much it will change the output). Even the people who build and work on LLMs every single day and know them intimately can't.
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.
I agree with most of the observations, but this statement already hasn’t aged well.
It's over. Accept it.
They will ship faster what? Different software requires different levels of diligence. A pop-up web site for an event and a piece of foundational infrastructure code have almost nothing in common.
> the quality won't be any worse than yours.
Does the current practice support this claim? My claim is that with a kind word and a gun, I mean, with human expertise and LLM's ability to do intellectual legwork, it is possible to achieve more than with just an LLM.
>> we don’t need business people!
> We won't need either.
ROTFL. Did you see what e.g. good salespeople do? Very often they are more important for success than engineers, and I say it as an engineer.
>> the ability to write, think and communicate clearly
> No, LLM will do this for you
I hope this is said in jest. If not, I rest my case and just wait for the reality to land its sobering uppercut.
> I hope this is said in jest. If not, I rest my case and just wait for the reality to land its sobering uppercut.
The ASI believers would say exactly the same back to you. If a machine can think better than humans, then outsourcing thinking to it will get better outcomes, however degrading it is to humanity. Presuming, of course, the machines still listen to us when they are superior to us in all ways.
Shipping faster I believe, but we've seen plenty of startups in tech since the late 90s that all "shipped fast" but ended up bankrupt because shipping fast isn't the same thing as shipping what is good, neccessary, helpful, or profitable. That said, those were things made by humans so I'm not saying human-built is good by default.
But shipping more and / or faster is not the solution. I'm not even sure what the problem it's trying to solve would be.
This is just not going to happen.
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
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.
- 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.
> 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.
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
Isn't there a counter-argument to be made that those should go to team members who enjoy them?
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.
You might have chosen CS because it’s a popular career that makes you a lot of money, but some of us genuinely enjoyed writing code.
(I know, I'll ask ... oh well ...)
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.
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...
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
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.
There was an article posted here recently that dives into this in more detail, and was eye-opening for me: https://asteriskmag.com/issues/15/so-you-think-you-could-be-...