In my 30's I really hit my stride as a developer and system architect. Enough experience, seniority, and autonomy to own and build out large complex systems.
Many, many mid career devs, I fear, will miss this window. They will become reliant on the LLMs more and more. 2 months back, I was asked to backtest an interview question and 2 out of our 3 most senior engineers (both in their 30's) could no longer write a generic method.
I liken this experience to learning cursive as a kid. It wasn't about writing cursive; it was about developing dexterity and hand-eye coordination. Getting the reps in, so to speak. Even if the future is all AI, that window of expanding one's knowledge and understanding of system design and architecture through hands-on experience (and failure!) facilitates the formation of "taste" through reps: why A over B or C. When B over A or C?
Many, many devs will end up "going nowhere". They will be able to prompt and push code with the façade of productivity, but I think building stable, scalable, complex systems requires knowing which angles to probe and which questions to ask; things learned via reps of trying, failing, learning, failing some more, thinking hard, drawing it out, and finally hitting the breakthrough.
I recently published a series of blog posts that focuses on the underlying architecture decisions that I think can help teams set a solid foundation for building with AI [0]. I think the guidance and patterns in it are unlikely to be emergent from an LLM without very explicit prompting. The goal is to share the thought process and intent for each technical decision. I think this type of thinking may become more rare as folks surrender their reps to LLM defaults.
The LLM providers will be delighted. Everyone and their grandmother donating their means of production to them so they can sell it back at a price must be a wet dream come true.
Then you will be like one of those old COBOL programmers circa 1997-2000. The only catch is that you will need to keep your skills sharp despite an ever decreasing pool of practitioners to share the ride to that inflection point.
Rather I'm pointing out that the mid-career devs are going to struggle advancing their foundational knowledge that is gained through hard won battles and reps; they're going to go nowhere in their careers.
There was always a shortage of capable developers coupled with abundance of unqualified (not to be confused with inexperienced). This explains both why development was so expensive and why the interviewing process was so ridiculous.
Yes, a true overabundance would bring salaries trending down (theoretically all the way down to minimum wage) until the overabundance is fixed by making people choose other careers.
> No one is going to write new UI libraries if SOTA models know React best, no one is going to bother with new languages if SOTA models know Python, Go, JavaScript, and so on the best.
And here I sit with my own native cross-platform GUI library, made with my own Lisp-To-Rust programming language... Tell me more about what we all are not doing :)
> And here I sit with my own native cross-platform GUI library, made with my own Lisp-To-Rust programming language...
Currently working on something like this. Do you have a writeup somewhere? Specifically how you solved cross platform rendering equivalence? Do you use an intermediate representation or just pure vis-a-vis splatting via native APIs?
I don't (yet), but do subscribe to the RSS feed on my website, I'll publish a writeup there once I've fleshed out exactly how it has to work for all the applications currently using it.
> Specifically how you solved cross platform rendering equivalence? Do you use an intermediate representation or just pure vis-a-vis splatting via native APIs?
In short, my current approach is something like a small renderer-neutral display-list IR, then each frame produces ordered DrawOps in logical coordinates, which then a shared renderer applies transforms, clipping, opacity, paths and whatever, which finally dispatches to platform canvas implementations backed by native APIs.
It's about ~50K LOC in total right now, to support Linux (Wayland + X11), macOS, Windows, iOS, Android, Sailfish OS and headless/offscreen rendering variants for each of those. This is like the 3rd iteration on this library, and for the first time I managed to get all the features in place without reaching +100K LOC, so feels like a pretty good approach so far.
The equivalence is semantic and conformance-tested essentially, not guaranteed pixel-perfect. For me, consistent design across the platforms is more important.
But who cares if they gain traction? I don't need it to gain traction for me to be able to make use of it correctly and efficiently. In fact, I probably need the opposite, for it to not gain traction, so I can focus on using it and improving it for myself only.
gist was certainly not implying that it was not possible to do it or that some people won't continue doing it but the point was rather that the pool of such people or such projects will significantly decrease because software has now (mostly) reached the abundance state where all of these technical details start to matter less and less for general consumption.
Libraries, languages, and all that good stuff are the stepping stones we use in service of building powerful abstractions that can then be used to expand software complexity. You cannot LLM your way out of that, I’m afraid.
> Software Engineering as science will be largely dedicated to AI development
Which will require fewer people.
Simple software engineers who work on CRUDs and are not PhD-s and stuff will go away. Most of software is like this. The few percent who work on kernels, AI models, etc. will still have work. The rest won't, or rather much less people will be needed to simply use AI to do that work.
Yep. The CRUD-ish part of CS is gonna end up like the typewriter pools from the '60s. Claude code is already way better than most subcontractors I've worked with, and without any weird interpersonal or contractual issues usually associated with whatever sketchy agreements their employers have with my employers.
I can see the ground crumbling in a linear fashion, moving straight towards my direction. In a sense, I've already made peace with that. I know what my skill ceiling is.
I'm decent enough to work on an ecommerce, customer portal or whatever. I'm also fully aware I'm never going to be able to write a kernel module, improve some low level loop in a database runtime in C, or do some sophisticated data analytics or fluid simulation modeling.
My time as developer is nigh. I won't really miss it one bit, to be honest.
Honestly I've been thinking about moving into hospitality, tourism or any other field where AI as zero chance of being able to make a serious dent. At least until robots will be able to give an interactive guided of a museum or a national park.
Sometimes I feel the same but then I sit in a refinement meeting and have to handhold the stakeholders through the process of finding out what they actually want, what they don't want, which trade offs they find acceptable and which they don't. And while AI is infinitely patient, my feeling is that being good at this is a super individual people skill and I know that more often than not the people I am talking to are kind of happy they are talking to a person instead of a machine. However when it comes to actually implementing the stuff, AI reliance is now necessary with the timelines given.
But right now AI assisted development isn't really making you more productive by an order of magnitude. It's easily a game of whack-a-mole right now. I estimate that an excellent programmer equipped with Claude Code only sees a 30-40% improvement in speed right now
What you speak of may happen, but I doubt it will happen in the next 10 years.
Sure that's a theory that sometimes plays out, but similarly one also sees almost exponential growth or improvement, yet followed by a plateau for a long time until the next breakthrough.
Software engineering has been getting more efficient for decades and over that time there’s been a massive increase in the number of software engineers.
The Mythical Man-Month describes teams of ten engineers operating before the Internet. Today (pre-LLMs) that’s probably 1-2 people.
> you might find the quality subpar, but in terms of cost ratio, it is commercially good enough. Business will accept 99.99 at fraction of cost of 99.999.
Personally, based on over a decade of professional software engineering experience at all sort of organisations, from small startups, Government, big tech, financial services of all scale.
In terms of literature, you can look into "enshiftication" as a starting point into research around cost savings and value extraction in business.
Also, about 7 years ago, I had some ideas about how AI will pan out, and here is the releveant excerpt from it:
> [S]oftware development industry, the very workhorse of automation and tools of efficiency is eating itself away. The outward image may look very different with the software development becoming an integral part of more and more industries, yet, the number of developers required for a project of given complexity is reducing at unimaginable rate.
It is helpful not to make unbecoming remarks. I know it is hard times for a lot of people in tech but it is important to remain mindful and separate your disagreement with the message from the messenger.
Despite your very poor remark in a sibling comment, I will respond with benefit of the doubt that you're just unhappy with the message and don't intend to be a prick.
You ask how are the numbers derived? Well, the numbers are not derived. My point is that an equilibrium exists where business is happy to pay y/x for 99.99 instead of y for 99.999; what is the actual value of x depends on specific enterprise and markets. What we know is that such x is no longer long term, let alone a theoretical proposition, but something approachable in the short term.
So to answer your question. The numbers are not derived.
It serves to aggrandize whatever softer basis might actually exist for the conclusion. Whether that's deliberate or the result of thoughtless use of useless platitudes, it's done with a disregard for honesty.
It is distasteful to make such accusations. Specially when the author has specifically left out the calculation and merely suggests of a “fraction” which is to be discovered with time.
It's not the only aggrandizing element of the blurb. The whole thing is baseless prediction presented as though it's hard truth, which is either deliberately dishonest or unconcerned with whether it's honest. If it's tasteless to point that out, I'll happily be crass about it.
It is based on Anthropic Uptimes. If anthropic wanted 99.999 they will have to acquire 10 times more GPUs/infra to match the traditional free resources of 99.999 services.
Now that there are many models on par for most day to day coding tasks, I think this will prove to be a complete fallacy. If anything, since LLMs, my tolerance for bad software has gone down.
Example- I'm no longer a Claude subscriber, but in the past it was the only game in town. Not any more: I'm simply done dealing with the countless issues in their client. With Pi, I'm no longer sitting there like an idiot slamming the enter key because ask_user_questions is broken again and I have to force quit the application (just to mention one of the countless issues). Hoping my org switches away from Claude too...
I mean, can't you just look around? Also from a business standpoint it just makes sense. Diminishing returns on product quality has been known for a long time. Look at Displays for instance. A set number of dead pixels is seen as okay, not because it is okay, but because the cost increase to have no dead pixels is extremely high.
We might not even need libraries after all, since APIs, libraries and abstractions in general exist for humans to grasp complexities. Abstractions have their merits, but they have downsides too, and AI might be a way to solve them. The interesting part for me is where that ends, because it's systems all the way down, and even on a higher level abstractions exist to allow humans to make sense of the world. Services, products, companies, political parties, what if in the future we don't need any of it anymore because the abstraction is obsolete?
Libraries do a LOT more than that. Abstractions also make LLMs more efficient, and lets some problems be handed off to much cheaper algorithms. They also mean that the way data is handled can be standardized which means you don't have to design an entire protocol from scratch every time you want to send data somewhere.
Every advantage libraries have given us still exists in the world of AI.
The efficiency argument I accept, it's surely one main driver why systems tend to form and centralize and one important factor in the balance. Still, one can observe the weird things humans and AIs do when trying to dance around the gaps in leaky abstractions. So there's a tradeoff between (the effort spent on) that, and dropping the abstraction completely, as soon as the abstraction stops being a necessary constraint (due to the limited capacity of a human brain).
The libraries are there for avoiding repetition. It is useful on its own without other benefits like implicit/explicit boundaries, readability by humans etc. If all lego(base unit software) pieces were unique shaped it might fit your requirements more efficiently but the cost of building those unique shaped legos explodes with the size of the lego piece required.
LLMs compress the known shapes well and fit them to solve for a problem but they are still not good enough to build from scratch a large new lego piece which fits a full problem perfectly. And such a large lego piece might not be the most efficient solution either and might be difficult to prove so.
> the cost of building those unique shaped legos explodes with the size of the lego piece required.
The cost of plastic injection molding is almost entirely due to the cost of creating the steel mold. My argument is: with LLMs we are entering a world which makes it cost effective to build many more things from scratch, which is akin to going from building things out of pre-fabricated lego pieces to 3D printing (agreeably not cost effective for everything, but for many things).
What about readability? Are people going to give up on reading and understanding the code? Maybe the abstractions aren't only necessary for writing the code?
I think the answer to this is yes, it'll be just like "reading and understanding your assembly". We just don't check what instructions your code compiles down to anymore, and I think the same will be for code.
Libraries contribute to the humans being able to review things well, so no, they may still have their use cases.
An AI might be able to create everything “from scratch”, sure - but I ain’t sitting there reviewing every bespoke thing it shits out. I want that offloaded to make it maintainable.
Btw, interestingly, I tried getting Ox Alpha to make Tic Tac Toe directly as a Linux ELF executable. It came up with assembly code (NASM syntax) and it just timed out when I asked for pure machine code.
Have no experience with Ox Alpha but Sol went to code it down in a .hex file that it then converted into an ELF executable.
The exact prompt was Create a simplest terminal based tic tac toe game. Generate executable ELF binary right away, without using existing or impromptu compilers.
An ai decompiles a binary to a human representation. Not even to a traditional programming language but just to an md file or infographic.
Probably terribly but probably good enough for some people to love it, and probably getting better over time.
Although I'm not sure who the user is when the world has been turned into power plants and chip fabs by then and there aren't any humans left since they need things like farms.
Tricky to make predictions based on costs or quality when the costlier parts, training and inference, are totally disconnected from reality thanks to VC money and when total cost of ownership over time is radically different.
1. LLMs will enhance the “normcore” - which is fine, and probably slow down churn (which may or may not be good - see JavaScript)
2. The problems are not how fast or how well people develop code. See https://youtu.be/5ybAhgAaEBo?si=C6q-fWXHlEO74kNi where an ex CTO of eBay is proud he doubled 3000 developers time to get out features while totally ripping into eBay’s pathological
Management etc
3. The problem has never really been “we cannot write software” - software that is actually in production and working is a tiny sliver of the phase space of software - if it’s in production and working the golden path that software is the top 1% of the 1%
4. The problem is the software that did not get made because the org does not know how to ask for it
That comes from three dimensions
- org pathology (people with the cash cannot agree on best approach)
- software literacy (people with cash don’t know that something is not only possible but common)
- org business model / mission (the guy in video made a deep point - eBay has not grown in real terms since 2008 and is getting its lunch eaten by more targeted competitors. So any CxO who plans to get their bonus based on “growing the revenue” is on a loser. So they fall back to “make a plan, follow the plan, get bonus for hitting your milestones”
This is partly why government departments seem awful and it takes politicians to change what is being measured
So incentives need to be aligned - so change the metrics internally to make them work for the mission.
If you don’t have a mission perhaps that’s where to start
Look at Microsoft - once “a PC on every desktop” was reached they really struggled for a couple of decades.
Perhaps we should just kill all companies once they stop growing …
Edit: One could see that startups are merely experiments in PMF - and once that has been reached, then a small cofe can be left to milk the cash cow while rest of the cash is returned for new experiments (perhaps even using medical drug “endpoint” measures
True intelligence should not have problems adapting to new programming languages. Especially with good TTD and other harnesses, current SOTA models are likely very capable of writing code in esoteric languages
I don't think "new libraries and languages, ... won't gain traction". I think that a higher standard is expected for a new library or language to gain traction.
I foresee the entire "technology adoption lifecycle" of innovators, early adopters, early majority, late majority, and laggards will be longer due to the relatively higher expense of adopting a new technology. I don't think it is a bad thing, but it might delay the adoption of promising tech in industries.
Meaningful library/language improvements will have their benefits, regardless if the user is a human or an LLM. Therefore, their adoption will see benefits as well, eventually.
Many, many mid career devs, I fear, will miss this window. They will become reliant on the LLMs more and more. 2 months back, I was asked to backtest an interview question and 2 out of our 3 most senior engineers (both in their 30's) could no longer write a generic method.
I liken this experience to learning cursive as a kid. It wasn't about writing cursive; it was about developing dexterity and hand-eye coordination. Getting the reps in, so to speak. Even if the future is all AI, that window of expanding one's knowledge and understanding of system design and architecture through hands-on experience (and failure!) facilitates the formation of "taste" through reps: why A over B or C. When B over A or C?
Many, many devs will end up "going nowhere". They will be able to prompt and push code with the façade of productivity, but I think building stable, scalable, complex systems requires knowing which angles to probe and which questions to ask; things learned via reps of trying, failing, learning, failing some more, thinking hard, drawing it out, and finally hitting the breakthrough.
I recently published a series of blog posts that focuses on the underlying architecture decisions that I think can help teams set a solid foundation for building with AI [0]. I think the guidance and patterns in it are unlikely to be emergent from an LLM without very explicit prompting. The goal is to share the thought process and intent for each technical decision. I think this type of thinking may become more rare as folks surrender their reps to LLM defaults.
[0] https://chrlschn.dev/blog/2026/08/the-unexpected-ai-stack-cs...