6,484 karma · joined April 24, 2019
For a tool to be deemed useful, the benefits needs to be generally applicable while the cons needs to be accidental or be reduced enough to not be immediately harmful.
I believe the same happens with artists and writers. If you’re good at it, you don’t need a whole studio to draw or a special word processor to write. It will scale down the scope of your work or make it more difficult, but you’re not suddenly incapable of doing new work.
I can write a program with ed(1) or with intellij idea. The only thing that changes is the easiness. The act of programming is orthogonal to the tooling.
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.
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.
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).
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.
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.
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.
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.
- 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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.