Lots to criticize here.

> 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() });
  });