agentultra

Archive link: https://archive.is/HuNjT

Or it’s a fabrication of some kind. Some times people lie to make themselves look good. Or the omit important details.

So is honey? And red food colouring used in a ton of products is made out of beetles or something. We eat bugs and bug stuff.

Something like this for me. I was on an Amiga. Later “downgraded,” to Intel PCs. But by that point i was already hooked.

BBSs were how I learned everything because there wasn’t really anybody near me in my little rural area of the world that had a computer let alone knew how to program them. Internet wasn’t public yet, just getting out of the lab.

What I grew up in was the counter-cultural era of tech. Distrust of authority. Freedom of expression. Queer. Weird. Against the War on Drugs, neoliberalism, police, all that.

Demos were huge. Scrolls were also huge. Mods were huge. Good times. When I think of back then I still hold out hope for today.

Truth. And a shame. True piece of art. Doesn’t deserve to be locked down like it is.

People are also concerned about those losses of forest too. And they do make the news. The rapid increase in rainforest loss in Brazil is often in the news.

Loss of forests affects us all. And they’re not as renewable as people think.

Not wholly. It’s under study. I don’t mean in the sense that you can’t read words anymore. I mean in the sense that comprehension and attention go down.

> Get rid of all those pesky nerds, and the MBAs can just create whatever grift pops into their head.

They have a hard time dealing with those people that tell them their ideas are bad, unethical, or illegal.

Now they have their Fisher-Price steering wheel hooked into the drive train of the business!

https://doctorow.medium.com/https-pluralistic-net-2025-08-18...

Every time you don’t write the script you lose a little of the ability to do so.

Just like if you don’t read you will lose the ability to.

These skills are not innate to us and can be forgotten over time.

I wonder if it will get to the point where people don’t even know what to ask for. Or how to judge if what the machine produces could have been better. Or if it does what they think it does.

They exceed us in a sense. They can generate the kind of proofs that a computer scientist could love: it doesn’t matter how elaborate, long, or obtuse the proof is as long as the checker says it holds. Many proofs that people consider elegant and have expanded human knowledge tend to have qualities designed with intent for an audience to communicate the idea, motivation, and result. They exceed us in the sense that Alpha Go exceeds most players of the game.

These planets are also so damn far away that we’d never hear from any ship we could possibly send out there again. Even if we could send information at the speed of light. It would be pointless.

Given that after arriving everyone could just die from some weird protein floating around in the air and you might want to look before you spend the entirety of our economic efforts reaching it… erm, look before you leap.

You can probably still find the leaked code online. It’s not exactly a bastion of software engineering. Plenty of folks have reviewed it deeply.

Maybe. I’m not certain the pages and pages of informal markdown specifications for the agents really add anything for me.

Knowing what your software does is such a hard problem. Most developers have an idea but if you ask, how are you sure?, the answers reveal how little they know.

Most often we’re satisfied with signals and indicators that it works and we build theories and mental models that use to try to avoid the effort of proving anything.

Worse is what happens when you start using LLM models to generate the code for you. I find you start losing the mental model short-cuts; you start to trick yourself into understanding the code. You understand little.

And what few studies there are of code review suggest that we have very little impact on code quality after reading more than a couple hundred lines of code over an hour.

So the current mental leap is, “the AI is a better programmer than I am.”

I think it’s still worth becoming a better programmer regardless. And there’s no royal road. You just have to write code and struggle with writing bad code.

If you want to create a programming language, create one. Do it because you enjoy it and because you have to answer a burning question. Learn how to formalize a language. Decide on whether to do that with operational or denotational semantics. Understand IR, optimization pipelines, and all that. Every moment spent on acquiring this knowledge is not lost and the time is not wasted. You’re enriched by it!

There are other people out there doing the same thing. Share with them. They’re more than happy to find like minded people.

Choosing to give up is not the answer. Claiming that engineering is, “solved,” is promoting a false narrative. It’s almost nihilist. Defeatist at least. Don’t even admit it or repeat it. It’s just not true.

All of the crypto bros told us how inevitable their technology was. We didn’t have to argue. Their constant chirping just got annoying and now look. They’re basically gone having exhausted the well.

A lot of LLM technology is in the same boat. You have a bunch of noisy people lying and hyping up the technology to line their pockets. History will sort them out too. You don’t have to give bad arguments space.

I think the worst effect AI has had on our industry is this malaise that has settled in and convinced so many people to give up, stop contributing, and accept the future that the hype bros have made up. They’re the ones getting rid of jobs, telling everyone they’re gonna get replaced, that there’s no need to learn programming or how to do software engineering.

Software engineering is going to be more important than ever. Despite the astonished claims of the intermediate beginners that Claude one-shotted the app they couldn’t be bothered to learn how to build for six years… it doesn’t magically generate good software. It can do a lot but at the end of the day it still needs a human operator to understand its output and direct the harnesses.

The thing to watch out for is people giving up on engineering as a profession. Software has barely entered that arena. But if we start vibe coding air traffic control software, it’s probably time to stop flying.

The point of software engineering hasn’t been to generate code. It’s to understand what the heck we are building. To develop the processes, techniques, wisdom, and knowledge to direct the work. To bounce between theory and application and back again. To better ourselves and make computers do useful things.

Yes, precisely.

People can choose to stop practicing it. Like they choose to not learn cursive or shorthand and they choose to stop reading long form books and essays. If people stop practicing software engineering then yes, it will disappear.

AI won’t replace it. It’s not human. It doesn’t think, feel, reason, care about, have thoughts or visions of the future. It doesn’t wake up in the morning or dream at night. It doesn’t get inspired. It doesn’t talk with other people and collaborate and share stories with them in the evenings about the struggles they’ve had working on a hard problem.

It’s an algorithm that runs on a machine that performs query analysis and inference on a model.

It can’t tell you what you want, that your specification is wrong, that you’re better off choosing a different avenue.

It doesn’t enrich your own knowledge and practice using it.

Sure, it can be used to generate lots of code. We can tweak the harnesses and parameters to optimize it to solve many classes of problems. But what do you think engineering is?

I don’t think AI is going to replace people. People are going to choose to do that. And some of use are going to believe them. Some of us aren’t.

The premise here is that, “software engineering is solved.” That is not a valid statement. There is nothing to, “solve.” Engineering is a practice; not a game or puzzle with a solution. It is a way of developing software.

I take the view that we should continue to practice software engineering. Every time you let an LLM generate some code for you is one opportunity you’ve missed to flex your muscle. If you don’t use it, you lose it. Just as you can lose vocabulary and the ability to read over time: these are not skills inherent to us! They’re learned and they must be practiced or else they will disappear.

There are ways to use these systems, if you find them ethically agreeable, in the practice of software engineering. But it cannot replace it. That part is the shared legacy inherited and preserved by each of us practicing it.

It remains viable as long as frontier models remain subsidized, too. How long will it take before these providers have to raise the prices to such a degree that such attacks would be reduced to only the most determined, financially capable attackers?

And even then there is the risk that the frontier model providers collapse. There’s no indication yet that these companies are going to become profitable. And open source models simply piggy back on frontier ones and are generally not powerful enough for this level of adversarial attacks as far as I know.

And finally are LLMs the only method to hardening software? There is still a lot left on the table that could still allow a project to resist attacks from a frontier model.

Sure, humans are bad at catching this stuff. But in order to drive an LLM you have to be able to catch this stuff. Otherwise your only option is to trust the model and give up.

Claude can’t one-shot a C compiler.

None of these systems can. They need enormous training. They need alignment and reinforcement. They need harnesses. And most importantly they need a human that knows how to write and develop a C compiler.

The ISO specifications are not sufficient. Neither are the System V guidelines. Not even spec tests and compcert.

They seem to be doing fine. Tigerbeetle and Ghostty are two projects that continue to do well and are written in Zig. The foundation’s funding also seems to be doing well. They are continuing to make releases.

I’ve toyed around with parsing the TLA+ spec and generating property based test assertions from the invariants.

It doesn’t fully close the specification gap but if it could be made robust it might be a good tool.

Generating code directly from the high level specification is called, synthesis, and is still in research mode.

Projects like Synquid[0] have come a ways but are still far from being able to express even trivial programs.

[0] https://www.csail.mit.edu/research/synquid-synthesis-liquid-...

Yes, exactly. Playing along with anti-cooperative and anti-progressive behaviour is not on the agenda. The goal isn’t to get along with everyone.

Canada isn’t that great either. We say one thing then do the opposite of that. Google is moving in to do age verification for Canadian services.

Yeah, you can go pretty far with JS performance. I’ve been a fan. I find it’s harder to maintain than C, Zig, C++, Rust, etc. It’s really easy to break performant JS code. No types, allocations are hard to control without extreme discipline. It’s so flexible and you have to give up a lot of that to get performance out of JS.

React is a whole beast.

It would be neat to see some JS devs killing some benchmarks.

You can wait for slow programs that use a ton of excess memory, sure.

Or, you can have fast programs that use memory efficiently.

You just can’t do it in JavaScript. You can get really performant with JavaScript with careful engineering for sure… but there’s a big wall of diminishing returns even with all of the JIT compilation and tracing garbage collection.

Nothing stopping those same JS developers from learning some Zig or Rust or whatever. It might actually be easier to learn than memorizing all of JavaScript’s implicit coercion rules.

But if that’s too much to ask then stay in JS land and make sure there are JS devs to write tools for!

AI isn’t replacing people. Managers and executives have been sold a product that they believe they can use to replace people. Some of them probably still hold some enthusiasm for these products. But there seem to be some that are getting wise to the fact that they’ve been duped.

An AI system cannot replace professional people. It doesn’t replicate or do the work that they do. That’s not what it is for and it is incapable of performing these tasks.

If you are using these systems you still need to know what you want and how to specify it. You can use agents to automate much of the work but it can’t tell you that your ideas are bad, that there’s a better way to accomplish your goals; it can’t tell you what you want. And if you can’t understand what it is outputting you’re failing in your primary task as a developer: understanding the problem.

I agree with the title. I just don’t think these systems will ever be capable of replacing humans. As much as product managers and executives would love it and not have to deal with us; they’ll just be shooting themselves in the foot if they try to replace professional developers with AI harnesses and fire all the people with the institutional knowledge and skill.

I think it might be possible to write a TLA+ parser and generate QuickCheck tests from it that will exercise invariants at least.

In my experience, it depends a lot on the language and the folks you work with. I’ve gotten an eyebrow and a stern talking to for using ‘map’ in JavaScript once. Some people are die-hard about statements and keywords and imperative programming and their world view and be myopic.

“We can’t have map in our codebase, we need to be able to hire anyone off the street and have them comfortable in our codebase.”

Well… since when did we hire random people off the street?

I’m used to functional programming. For me, reduce is perfectly normal. Fewer intermediate variables. No pesky statements, just a nice expression. Great.

Buuuut… some languages think implementing tail call optimization is too hard or bad or for ivory tower academics. Or they’re dynamically typed. And then reduce does become difficult to special case and make performant. So even if you like the juice it’s probably not worth the squeeze.

It was a great time working with Haskell professionally. I didn’t have to constantly defend my style of programming! But in “everything” languages… well you do. Everyone has to agree on which subset to use. And programmers are like cats. Good luck getting them to agree on anything. Even once you agree there will always be that one challenging the decree.

Hundred percent. All about trade-offs.

Although proof techniques such as proof repair have come a long way, it’s still impractical for a lot of scenarios.

TLA+ is great for systems design and such. Quick check style tests are awesome and a very low bar to clear from unit tests.