The compiler was supposed to end programming too

You also don't hear much about VB specifically, because of evolution, nowadays the modern equivalent of Visual Basic and Delphi, are OutSystems, Power Platform, Workato, Boomi, Sitecore AI, Optimizely Opal,...

If you go to squarespace domain management website you will see it is utter garbage in terms of experience. It doesn’t have to be like this but the people that make it just aren’t good enough or don’t care.

Unfortunately it is same with blockchain and LLMs soon.

Blockchain can be super useful but there are hard problems that need to be solved and people that vacuum the investment up just aren’t interested in solving problems.

I see the same problem with LLMs because big companies want to pump horror stories and vibe coding instead of code review or security review or cost stabilization/profitability etc.

The people that behave this was just don’t have a chance of long term success imo.

These technologies could have been so much better if they were developed by different people

I think Entertainment creatives have a similar field to software developers. The average exceptional creative could express something completely unique precisely but will actually have a tough to impossible time reaching anyone given the levers a creative that uses remixes at the edge of fair use has to hold the audience attention. It is like asking someone to give up multiple addictions at once (and while concentrating more than they are used to.)

I _want_ to write code for my job.

Unfortunately, this is exactly the direction the industry is heading.

This is repeated in a lot of comments here but hasn't really been true for a while. I remember, c. 2010, Kenton Varda complaining to Google's internal compiler team about how it generated some particularly non-intuitive assembly code out of the protobuf generated code, and the response was "Yeah everything is adaptive optimization now. Benchmark it and give us a profile and we'll put it in the compiler test suite. Trying to reason about what the compiler is doing and micro-optimize accordingly hasn't worked since the mid-90s."

I do think that LLMs are a step change in how we program computers, but the main step change is that the source language is now English, which opens up programming to a wider market accordingly. And this'll come with all the downsides of English: the ambiguity, lack of precision, multiple meanings, and so on. If you try to recover that control over what the computer generates, you end up reinventing computer science. (Which isn't that far off from how I use LLMs to program: anything that has widely accepted "best practices", I'll just let the LLM do, but if there's anything novel or requiring high-precision, I'll tell it "leave that function body blank; here are the inputs and outputs to the rest of the program; I will fill in the algorithm details myself.")

I also think that people are underselling the extent to which compilers were a step change to previous practices of programming. For someone accustomed to C, try doing register allocation or inlining yourself; you will suck at it, and it will take up the vast majority of your head space that could be spent on better things. For someone accustomed to a garbage-collected language like Python, try doing manual memory allocation and object ownership yourself; you will suck at it, and it will take up the vast majority of your head space that could be spent on better things.

People tend to overestimate change in short term, and underestimate it in long term. AI hasn't replaced programmers yet, but I believe it will replace most white collar workers in 20 years.

Opus 5.5 produces code far better than 95% of professional devs, and it only stands to get “worse” from here on out.

Quite where this leaves any of the people in these information processing jobs is anyone’s guess.

Well if you think that's what it's doing - that's on you.

For gosh sakes, start with Claude Shannon's 'noisy channel problem' and consider why the notion of idea -> program is a fallacy.

That's for the Wix, Lovable and Shopify - wherein AI is only a component, and where the conditions are highly constrained.

To manage the output in detail, we need abstractions ... which do not exist.

Code -> Machine Instructions is not a noisy channel - it's deterministic.

Idea -> Code is theoretically not possible at any scale in a stable scenario because it's not deterministic, it won't make 'what you want' - then you have to spend a Million Mythical Man Hours to get it to do what you want.

Given that only a small portion of a developers job was ever 'writing code' in the first place - and that we write on average a fairly small number of 'usable lines of code' per day, the 'coding' was never it.

Research, prototypes, corners cases, help, bug fixes, ideation - so many ways it's powerful ... but not like a compiler.

Ignoring AI is like ignoring the industrial revolution, but AI is something very different than.

Also while some jobs are going to go - software hiring is up, not down - that should be a clue.

The 1:1 is long gone, that is the UNIX K&R C days.

Modern compilers are full of heuristics, PGO driven optimizations, machine learning compiler passes, JIT compilers, and various kinds of GC implementations, the time of 1:1 mappings is long gone.

It’s basically moving from chat (conversational copiloting) to result driven agent harnesses, exactly what happened with code. To us.

The reason it happened so fast with code is because: - anthropic is a software company and scratching their own itch - open source codebases in training input - vast amount of books and docs too - real-time linters and tests provide confident feedback for closing the loop quickly

Other occupations will want to limit their public knowledge sharing (sadly) and avoid formal specification / standardization of their unique workflows. And definitely avoid equivalents of realtime linters and tests.

LLMs are not this, and they cannot be this because it is their ability to operate on vague instructions that make them as powerful as they are. They can take an imprecise natural language description of a process and realize it as a process in a programming language. The problem is that understanding and manipulating the precise problem description is your job as a software engineer. The LLM can and will make its best attempt based on what exists in its training data, but it cannot know what is the precise behavior that actually fulfills goals and I think, contrary to the parent article, it cannot determine where the edges are to ask you with enough certainty that you will be able to take your hands completely off the wheel.

I think the nature of LLMs also explains why it is good at the verticals it is good at. Porting is an extremely well defined, replicate the behavior on another platform. There are far fewer vagueries in that. Game dev is not extremely well defined, but the consequences of imprecision do not have a lot on the line. Furthermore, games are pretty self-contained, so there's not a lot of guessing about what could happen or what the behavior of a counterparty system could be. With some pretty big exceptions, it is all there for the LLM to see in C++ (or whatever).

when is it going to happen already? OpenAI says Astra is AGI. why hasn't your prediction already come to pass? it's not early, it's late, these companies owe $1.5T. It's time for your side to start explaining why exactly GPT 3 or 4 or 5 or Astra hasn't already caused this in the way it's been predicted over and over by the labs

Those who spend time thinking about a problem, then writing design notes, specifications, and test plans, and focus on the implementation last. For these people, AI agents primarily act like an extension to their existing toolchain, and thus like the analogy of "AI as the new compiler".

The other side are people who don't like writing specifications and such, and rather prefer to sit down figure things out as they start coding. For them, an agent feels radically different from a compiler.

In both instances the AI agent is still the same tool, with the same real-world capabilities and limitations. It is not like one camp is blind, they just have very different workflows.

It also seems to me like many in the "sit down and code" camp then slowly figure out that doing some planning ahead of time helps them get better results, and they see this as another AI-led paradigm shift, when in reality it is how many other programmers have worked for decades.

Maybe if you are using a compiler to provider a portable assembler (i.e. C) where ~1:1 mapping is the whole point. But in that case you'd be actually be using assembler instead in a world where all CPUs were the same.

That is very narrow view, though. Often — and I'd say most often — people use compilers so they can think in higher levels of abstraction, like SQL. Taking SQL and adding millions or billions of additional keywords doesn't really change anything with respect to the concept. Its still the same thing at the end of the day, even of those millions/billions of additional keywords are much more powerful than a small set of keywords.

I appreciate the rose-tinted, high-agency historical take, but I think the factors that led to computer science/programming becoming male-dominated were largely external to and independent of the preferences of women themselves.

AI generation isn't an abstraction because you have to wrestle with the nitty-grittys of the output.

And that output is what you retain.

You can't clone someone's repository of nothing but prompts and rebuild from scratch.

Abstraction means that I trust the toolchains so much that I think of the source code as the software, and in the right kind of environment/ecosystem such as open source distros, I can actually ship that to the downstream users as my product.

Abstractions are based on very detailed and rigid logical contracts.

This is in contrast with general purpose agents like Meta Muse that make some amusing and horrifying errors. These kinds of agents don't have the interfaces and guardrails that were built for human coders. They use a lot of ad hoc screen scraping and guessing at what APIs do.

That's also why Apple and Google haven't shipped fully general purpose agents that use their new app tool calling interfaces yet. For example Google only released their Gemini agent that uses AppFunctions to enterprise customers. Presumably because MDM tools can be used to monitor agents' actions.

But a good programmer given agency to solve the higher order problem will always have a path to rewrite, because any "simple CRUD app" exists to serve human purposes, and in order to meet those needs the human interface need to be legible, and to be legible there have to be tight enough inputs and outputs that you can create a parallel implementation without the incidental complexity.

Now you might say this won't be the case for large multi-party distributed systems, and that is true, but that is also true today where all manner of insane cruft and non-sensical logic and workflows exist. But even where things appear totally intractable due to legacy requirements and conflicting logic, there still is a human backstop where if the pain is big enough, any process can be fixed. In practice competing interests may prevent such fixes for a long time, but that is political problem not a technical problem, and it's not inevitable as things can flip very quickly due to the dynamics of human attention and power.

    float constant(void) {
      return 3.1f;
    }

Option 1 (loading high 16 bits and low 16 bits, then moving to fp register):

    movw     r3, #26214
    movt     r3, 16454
    vmov     s15, r3
    vmov.f32 s0, s15

    ldr     r3, .L3
    mov     r0, r3
    .L3:
        .word   1078355558

    vldr.32 s0, .L3
    .L3:
        .word   1078355558

You can enter this as is on an Workato or Boomi agentic workflow.

For plenty of people this is how programming looks like in 2026.

Also your example has multiple translations into Assembly, depending on the optimizations levels, and where the statement happens to be located, it might even be part of auto vectorisation, or completely thrown away.

    In [1]: def f(x: int) -> float:
       ...:     return f"the input was {x}"
    In [2]: f(b'deadbeef')
    Out[2]: "the input was b'deadbeef'"