An impressive effort, and better than I would have thought possible on this hardware -- but still pretty far short of what one needs for an satisfactory interactive session.

And it should be just fine for plenty of background use cases.

We once hired a very smart fellow to build out a media processing pipeline. He did with rxjs, but it wasn't scaling well. We tried to get with the paradigm for a bit and help scale it up, but flame graphs in profiler output were all crazy, and it was a pain to wire in timing traces, etc. We built a POC imperative version just to prove that we could indeed achieve the throughput we thought we could, and then we just said, well hey, this is faster and simpler, so... let's just go with this instead. And so we did.

Tools are all built around non-rx workflows. That means doing things like performance work is a lot harder. Especially because RX is working on message passing it can be really tricky to figure out when a pipeline is ultimately stalling.

You do ask hard questions up front, define boundaries, give lots of high level architectural guidance, declare interfaces, and bounds of abstraction... And then you ask the LLM to make it so, and it does. You give it the structure, and it fills in the implementation.

This is engineering, more or less.

I would love to see how perfect their “organic” code looks because I wont be surprised if its full of all sorts of issues, all in prod, for years, never known or spotted, just to be found and fixed by Claude in 15 minutes, with unit testing to test and ensure no regression is introduced.

There is no "correct" way to toss a coin. Some day people who are depending on LLMs blindly will understand that. All their notions of "correct use" is based on folk lore and...vibes, that is just maximizing token use under some misguided notion of "correctness"..

There is no correct use. There is no “correct” way to build systems. There is principled and disciplined use.

There is a pretty big difference. If you ask a human "Is X true", and they says "yes", you can be 100% sure that they will always behave in a way that is logically consistent with X being true (talking about a competent and honest human being here, and when the implication is obvious). But by their very nature, there is no reason to assume the same with the LLMs.

- Depending on the nature of your application, it may be very important to be able to audit the business logic and intended behavior. For compliance reasons, for operational reasons, for moral/ethical reasons -- you very well might want to affirm what the code is actually trying to do.

- A coding agent may get very creative in order to write code that passes a tightly-defined unit test. It may come up with approaches that technically pass, but work against the overall intention of the app in the first place. This becomes an arms race rather than a productive collaboration, where the agent's increasing creativity has to be matched by a sprawling test suite.

- Eventually, inevitably, business requirements will change, and the blob will need to evolve. It will be much easier for an agent or a human alike to understand how to safely make the change, if the existing implementation is transparent and understandable.

1. Your unit tests are exacting enough to fully specify the unit. In that case, congratulations, your unit tests are the code. They're also probably much more awkward to write, maintain, etc. Also, the compilation step to go from the unit tests to the actual code is now orders of magnitude more expensive, requires a SaaS to even work, etc.

2. Your unit tests are not that exacting and still leave ambiguity, edge cases, etc. In that case it very much matters what's in the blob of code, because while it could be a correct implementation of what you wanted, it could also be something else entirely that just happens to be correct for the part you did specify.

The more context an LLM gets, the more likely it will start to ignore instructions.

If the LLM runs a context compression, all bets are off. There's a reason Anthropic upped the context to 1M tokens to reduce the chance of this from happening.

The human. But only if you care about verification.

You can't call it "engineering" if you don't care about verification.

They're the ones checking that work matches the plan.

I mean, it's the same with building a bridge in the real world, right?

Someone has to check the work.

I use Cursor and Codex but the agents keep making regressions and breaking rules. They'll even take shortcuts sometimes, by doing things to make tests pass but with code that would be dangerous in prod.

Now, I use them file by file but it feels more like a typing assistant than something much more.

Right now they can be autonomous to finding bugs and inconsistencies. But not architecture or even just creating a long enough PR without any guidance and feedback.

[0] https://github.com/ChristopherKahler/carl

[1] https://github.com/ChristopherKahler/aegis

We have as much test code as deployable code because the AI keeps finding ways to do what we told it to, but not what we meant.

People who build bridges for a living shake their heads in dismay.

Software on the other hand...

You see, the difference is that with building bridges, there is no value in building a "Toy" bridge that does not require any real knowledge. But even toy software can bring huge value. But that does not mean it does not require engineering discipline to build non-toy software.

Software engineering is not about learning libraries or tools. It is the art and science of managing complexity under constant change.

    myFramework new myCoolStartup
    myFramework generate dataModel
    myFramework generate controllerForModel
    myPackageManager install coolViewWidgets
    # insert glue code I learned on Youtube here
    git push coolPaaS myBranch

You seem to be implying that since the current wave of AI started that things have gotten better. That is demonstrably, repeatedly, and completely false. Just cruise the HN front page and watch the AI fails scroll by.

That you point to Windows getting bad over the years, and the fact that it continues to get worse with the full AI buy-in of Microsoft, shows that AI is not some magical software savior.

Bash maintainer actually implemented the library feature I suggested and it's already dramatically cut down the amount of unsightly bash code I need to keep around and maintain.

I'm getting pretty tired of coping with old stuff just because it's there though. Went through this phase with GNU make too.

Doubt. I'm up to my neck in bashisms, and I require the very latest bash on top of that.

  import() {
    local f
    for f in "$@"; do
      [[ -v loaded[$f] ]] && continue
      loaded[$f]=1
      source -p "${HOME}/.local/lib/bash" "${f}"
    done
  }

  import arguments terminal

Nevertheless, a version of the feature landed in bash 5.3.

  source -p "${HOME}/.local/lib/bash" file

  import() {
    local f
    for f in "$@"; do
      [[ -v loaded[$f] ]] && continue
      loaded[$f]=1
      source -p "${HOME}/.local/lib/bash" "${f}"
    done
  }

  import arguments terminal

mixing shells is not as hard as some people claim. it's like switching programming languages. i do that all the time. but then, i avoid bash scripting as much as i can (or shell scripting in general). if you actually enjoy bash scripting then switching may be harder.

Fish scripting is limited to functions/aliases and this works out well since they're easy to read and tweak over time.

before fish basically noone dared to break bash compatibility. zsh is bash on steroids and other incompatible shells like csh, tcsh, ksh, etc were dead ends in that they kept a niche status.

fish was the first shell to break out of that and actually get noticed and gain a following. i believe that all other alternative shells after fish were encouraged only because of fish's popularity.

Well, that depends on who says you don't. If the government says so, they are wrong, because you do have a constitutional right enforceable against the government to post on Facebook.

The idea of saying "you don't have a constitutional right to post on Facebook" is that you don't have such a right enforceable against Facebook.

Which is true. But under current US law, you do have a civil right enforceable against any public accommodation to be offered the same service that they offer to the public generally.

Which is why OP describes the U.S. enacting legislation creating a statutory right.

Unfortunately, it could be around a decade before all three major browsers finally implement the standard, and the fix might not be quite as clean as you originally imagined.