skydhash

> All it takes is for a kid to borrow nuclear-engineer-dad's USB drive

Do nuclear-engineer-dads take work usb drive home. Are their computer even allowed to have usb. I'm typing this on a dell latitude, and you can disable usb and other peripherals inside the bios.

My last job, I had to apply for an exemption to use the USB ports. And it was run of the mill software engineering.

The battle tested part is the reason I suspect my code rather than theirs first. The trust part is in their engineering process. New project from OpenBSD or Debian, I’m ready to try. Random guy on Github, bring out the 10 foot pole.

> Can you say with your hand on your heart that the typical user experience was acceptable before AI arrived?

I remember using Windows XP (SP3) and Windows 7, Photoshop 7 and CS3, Office 2007, Blender, Winamp, Linuxmint and my computer was a joy to use (with HDD and slow ram)

The internet was mostly a repository of knowledge and communication. I was online maybe 30 minutes every few days. This was around 2010.

It is not. But there’s an element of trust being involved. Something like libflac or libcurl, I don’t read the code. I read the doc which does outline the behavior of each function and the conceptual model. If something break, it’s quite often my code. Why? because their code is battle tested. Which is quite different from AI generated code.

The vast majority of software is not that important. I don’t really care about easytag (which I use for flac metadata), but I do care about xterm and tmux.

> The thing is, before AI agents, I wouldn't have even attempted the work. I wouldn't have been able to afford the time.

Before AI agents, what we would have is maybe a line in the changelog, like “git support has been added” and maybe some post if there’s a substantial Ui/Ux improvement or novelty.

Now it’s just: I did something with AI (with no description of why it has been done, just what) and it was pretty fast (compared to an exaggerated estimation).

What I understood from TFA is that the author is complaining about formalism and bad abstractions. The latter is a real complaint, but I can’t understood viewing formalism as a burden.

At it’s core computing is about taking some information, encode it, transform it, and then decode the result. The latter can be interpreted by humans or used to drive some machinery. The value of computers is that they can do encoding/transform/decoding part reliably and really quickly. But it’s up to use to specify how.

One common trait I found with people that dislike formalism is that they have great reluctance to admit they’re wrong, or at least consider the possibility. And a formal system cleanly mark what is correct according to its axioms.

The issue with most AI practice is that they eschew reliability and guarantees of correctness (not there hasn’t been bugs previously). The proponents can talk about their goals, but they can’t explain the projects they’re working on and reason how it should be correct.

For them, it’s like seeing a chess game and deciding it’s ok if a pawn move like a knight to capture the king, because that’s the intended goal. Like “just move the piece with your hands”. Because it’s hard to devise a strategy that respect the rules. The bad play is obvious when it’s a real chess board, but imagine it’s a generic board where all pieces are little puck with a led fave for colors and types. They wouldn’t mind the pawn to change its type to knight for the illegal move and then revert to pawn once that’s done.

So something like Python and Go is pretty generic. You can code various domains with it (servers, games, apps,…), but it’s up to you to really follow the rules of that domain. Using AI code, there’s a non zero chance for a bit of cheating to happens. While it “works”, it’s not correct, and there’s some use cases that are totally wrong.

I follow mailing lists (emacs and openbsd) and sending a diff is kinda the boundary between wishing for something and making the something into a thing. It’s the difference between discussing a plot and discussinf a draft.

Sneding a PR should not be for understanding or just for rubber stamping. It’s about getting someone to look at your approach and helping you find flaws or proposing ideas that could make it better.

When I review PR, the primary question is: For the stated problem, is the diff a good solution? Sometimes I don’t know enough about the problem, so I just try to see if the code has glaring mistakes (mispellings, styles,…) but those are just comments, not suggestions.

Yep. For a lot of problems, I can build a prototypes with a few lines of bash, or spend the time to create a proper gui and have error handling. The first is not difficult’ no need for AI. And if I’m going to invest in the second, the “slow is fast” approach is often best

> constantly read these amazing stories of people vibe-coding some firmware/driver that just works, and honestly I’m starting to question whether I’m reading the posts of some promotional bot.

I don’t question those posts, but these days, I can code something with vi (nvi) and be ok with nothing other the small motion helpers. These days, whenever I see a project with more than a dozen files, my gut tells me there’s something in there that ought to be a library.

When I look around me, the only time people get their phone out of their pockets is either for youtube, some social media, or calling/chatting with people. It's very rare to even see them set reminders or use the calculator. It's look like you're in some tech bubble. People outside of that don't scripts or do repetitive and formalized stuff. The people that do create apps and services to sell.

> "Computer let's create a simulation to figure out the fastest way for me to get home. I want to take a route along the expressway and know whether to get off at Roosevelt, Madison, or Lake. I need to pickup my daughter when she has volleyball."

Imagine saying that to a random dude with a map and that should give you a good idea on how many info you're leaving out. You can say that the AI will infere those but that seems to be the common fallacy of AI enjoyers: They're always assuming the AI will magically find out the missing information from their prompt somehow.

I have Organic Maps installed on my phone and within a few minutes (faster than my car warming up) I can set a multi stop route (you can bookmark places). Training a random user to use such apps is also equally fast. The same happens with various pro tools: once trained, a user can be very fast with them.

I have a Suzuki Grand Vitara 2010, and from left to right, the essentials buttons are (grouped by location):

- Window controls and lock/unlock

- Power mirrors adjustment (after someone else has driven the car)

--

- Light stick/knob (it has auto mode)

- Steering wheel control for the head unit (vol +/-,...). It also has cruise but I don't use that

- Wiper and washers stick/knob

--

- AC adjustment. It's a knob for temperature with 2 buttons inside (auto mode toggle and off)

- Fresh/recycled air switch

- AC/ventilation switch

- Ventilation speed. It's also a knob with 2 buttons, but I only remember the mode one (to switch between front/front and feet/heater/...)

- A defrost button

- ESP (ABS) disable button

--

- Window/door lock/ on the passenger door.

There's nothing else. For any of those buttons I would hate to use a touch screen. With physical controls, I can rely on location, haptic, and muscle memory without using vision.

> Models are not 1.prompt->2.forward propagation->3.response->4.end.

> They are 1.prompt->2.forward propagation->3.partial response->if not done goto 2.-> end.

You know something else that follows the same pattern? Your A/C system.

1. set temperature ->2. Get diff of temperature -> 3. Response -> if not done go to 2. -> end

The difference is that both 2. and 3. are deterministic, while in the LLM case, it is statistical and textual.

It's hard to hack other computers on a air-gapped one.

> This the take of people who have stopped reading about LLMs in 2023 or so

Ad Hominem attacks make for great counterpoints /s

Whatever you may say, it's a text generators on top of a tool calling framework. Training may skew the text towards a particular text, but as with all ML technologies (and statistics based methods) there's always a good chance of errors on a particular sample task.

With standard control systems, we tried to incorporate the error into the actual control output in order to minimize it. This is done in a deterministic manner. There's still risk of failure so we design systems around them.

With control systems powered by LLM (agent harness), errors are often not taken into account and they are amplified in most sessions. Safety measures are close to nonexistent. The issue is not the failure mode, the issue is that it's preventable and there were not a lot done to prevent it.

> however, the mechanical grounds for it to happen are plausible

If you build a control systems for firing a gun, then coupled it with an RNG, the mechanical grounds for it to kill a person is plausible.

LLMs are text generators. They are not repositories of knowledge. The mistake is coupling them with actuators (tool call) or having humans interpreting the generated text as facts.

> Humans have been shipping systems that no one person understands for a long time

Systems of humans have been shipping systems that no one persons can understand. Take the nuclear aircraft, there’s no part on it that you can’t find someone that is accountable for that part. That is why we can still build them and improve on the design.

> So I think that software will be better in a certain way due to AI, because even a terrible developer can ask AI to identify the bottlenecks and solve them.

The root cause of the issue is not the bottlenecks or the ability to identify them. It’s about caring about doing a good job. Because once you start caring, you will need to exercise judgment. Better or worse only matters when you have goals.

This is one reason we have so much slop with AI. The cost of the journey has lessened, but you still need to have a destination and be willing to appreciate the journey to get there. Without, it’s just endless drifting.

> you have a passion for building things that solve problems

The AI hypers are more about “building things” than “solving problems”. When you analyze their comments and projects, they can barely articulate what the project’s purpose is about. Or even if it can be used by somebody else. It’s always about LoC, coding speed, and specs complexity.

If it’s B2B, the finance side (seller/customer) of the relationship can be totally different from the product side (developer/user). Evolution of the contract is often measured in quarters.

That’s merely code churn, which is not a good property. What you want in a codebase is something rigid enough to satisfy today’s constraints (including optimizing them) and flexible enough to be modified for some likely future prospects.

So for any current features, cost of fixing bugs and do trivial adjustments should be very low. But working on new things should have a great ROI, especially because what’s existing can be reused as a foundation.

> Combinatorial complexity. It's the essential problem with software systems

After using OpenBSD for a while, I fully adopted the “write less code” approach. Create the simplest solution and leave “features” out until you need them. Nice to have should be practically banned.

But code is the mean to get an idea across to someone. It’s the difference between “I think this can work” and “I’ve worked on this and it does work”. I’m part of the OpenBSD mailing list and it quite nice someone sharing a diff for an idea or experiment. It may not get merged, but it’s better than realm of deliberations.

The issue is with the people sending code for reviews, not people reading the slop commit message.

> as someone coming from software I find learning electronics pretty hard as it requires a completely different mental model and way to approach systems

I went from electronics to software and one thing that has puzzled me is how much people dislike reading docs as in reference manuals. People can get by with sloppy code full of hidden bugs and when those bugs arise they’re like deers frozen by headlights.

Imagine building a circuit without any ideas how it operates. I’ve encountered web devs that don’t understand how http works.

> Open source programs could be more like motivated explanations of computation.

It is already that. Every time a method/function is created, a structure is defined, a variable is added, a file is created or renamed,… It’s all for the purpose of human communication. The computer only need binary in a single file.

But people feels like they should be able to jumpninto curl code without any understanding of networking, or linux code with no knowlede of computer architecture. Few code are meant for total beginners.

We have good engineers that gave us curl, ffmpeg, the 4.4BSD, tmux, vim and emacs, x11,… To this day, no one can show any particular important software that comes from LLM assistance at scale. It’s all slop.

The thing is a text generator. It generates text. You can couple that with any code that gives rhe ikkusion of a normal decision workflow, but it does not make any decision more than a software like latex. According to your definition, the latter would “decide” the amount of words to put on a sheet of paper.

> I’m not saying gradient descent was empirically discovered, I’m saying that its use in machine learning is itself a form of empiricism. A repeated observe/adjust-based-on-data cycle

The data is the input, the output is to generally find the lowest amount of a loss function. It’s a greedy approach because brute forcing is inefficient.

It’s no more empirical than a greedy algorithm for scheduling.