We are not going anywhere

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.

What you speak of may happen, but I doubt it will happen in the next 10 years.

Comparing AIs of a few years ago to the ones today there is a good chance they will improve enormously.

Some humans will always be needed for handholding, but not as many as employed today to churn out run of the mill code.

The Mythical Man-Month describes teams of ten engineers operating before the Internet. Today (pre-LLMs) that’s probably 1-2 people.

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.

Every advantage libraries have given us still exists in the world of AI.

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

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.

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

What is this based on?

It might turn out AI does all programming in future. But it also might turn out that it's incapable of long term maintenance. We don't know yet.

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.

https://gist.github.com/omeid/9a180f9acccc8409d6c5f3e7fa1a77...

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.

AI becomes godlike and does everything for us.

N years down the road, 3 year old children can just tell AI to generate a custom game or cartoon for them on the spot.

What's left for humans to do?

Live on UBI, explore this wonderful world, colonize other planets..

And along the way, while anyone can make anything they can think of, it'll come down to who has the better idea, we might enter an Economy of Ideas, and maybe the Idea Guys™ will finally have their day :)

As soon as AI can tell original hilarious jokes, I am going to shut my doors and laugh myself to death.

> This might sound obvious, but it is worth putting it down, Software Development going forward will be largely done by AIs, 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. It is all about general consumer expectations, which will shift.

This is correct but a misunderstanding of "who does software development". It's no different to claiming "compilers will do software development from now on". LLMs are simply a metaprogramming tool.

> But most of all, not just that we are not going back, we are also not going anywhere. Software Engineering as science will be largely dedicated to AI development and outside of this discipline, it will slow down to a grinding halt.

Wrong. In fact due to the advances in LLMs we finally have the tools to optimize the underlying foundations. Historically, writing something from scratch or messing around with low-level implementations was out of the question for anyone but the most massive tech firms. Now a small(ish) team can experiment with building a custom VCS and CI/CD pipeline from scratch, without relying on Git. In fact, I'd argue that most current software is _no where close to the optimum yet_.

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

Dead wrong, on all fronts. And it shows that the author doesn't even understand what LLMs do. I wrote a custom DSL Lisp like language (entirely custom forms and relatively custom syntax) that the LLM understands perfectly through BNF forms + examples. And the domains it's used in (robotics) gives absurd results. Literally outperforming the competition by miles. Pre-LLM this wouldn't be doable without sinking years of dev time.

> Yes, it will be easier for people to build new libraries and languages, but they won't gain traction. This might be different for large corporations who can afford to train and finetune models on their new fangled technology, but that will be the exception, and likely struggle with building a community and talent pool outside of this developing organisation as other people may not fancy using or even have access to their internal models.

Irrelevant. In fact, custom building specific purpose code is far more attractive than it ever was. Why do I care how widely used a library is if it serves my use case perfectly? Historically, again, you had to wrestle with library conventions and styles just to get something to work. Now you can have a microoptimized library built _exactly_ for your use case. " This might be different for large corporations who can afford to train and finetune models on their new fangled technology" -- wrong, you don't need to retrain models at all to understand custom libraries. Again, I have a near entirely in-house written stack (proprietary, never seen the light of day) and LLMs understand it _perfectly_. In fact they can even write perfectly idiomatic code in them, despite it being obscure as all hell, example

  ox::app app;
  app.add_resource<users_view>(ox::sv{ "/users" });
  app.add_resource<user_view>(ox::sv{ "/users/:id" });

  auto admin = app.group(ox::sv{ "/admin" });
  admin.use(ox::basic_auth(ox::sv{ "admin" }, [](ox::sv u, ox::sv p) { return u == ox::sv{ "root" } && ox::ct_equal(p, ox::sv{ "toor" }); }));
  admin.get(ox::sv{ "/stats" }, [](context &c) {
    micron::string b{};
    b.append("hello ", 6);
    const ox::local_value *who = c.get_local(ox::sv{ "user" });
    if ( who && who->is<micron::string>() ) {
      const micron::string &s = who->cast<micron::string>();
      b.append(s.c_str(), s.size());
    }
    b.append(", here are the admin stats\n", 27);
    c.text(200, ox::sv{ b.c_str(), b.size() });
  });

Sounds like OP and you mostly agree on this, although you both make the same point in different ways. If everyone is building specific internal libraries, no library is going to take public traction like it used to happen. But yeah I agree with you that now specific internal ad-hoc tooling is much easier to achieve also for small shops than before.

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

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

In my experience, there are far too many 9s in that sentence. But the sentiment absolutely holds.