As a leader, I can just tell people literally that: if you can't go away and work independently on a problem, it puts a ceiling on how well you're going to do. Then I ask people what they've tried before asking me.
Just being upfront with people can break low performance patterns of behavior.
It appears that you are saying that because someone is an Afrikaner, they must be a member of the apartheid regime or a proponent thereof.
If you are not saying this, then it's unclear how this is related to your previous comment.
You could write a comment that makes sense by saying "Afrikaners usually believed in weird corporal punishments because that was normal in their culture" or something and that would be perfectly acceptable.
Or perhaps, you have some specific knowledge that this guy was actually a proponent of apartheid, which you should share.
The primary way to increase reliability is to automate. Instead of humans producing some output manually, humans producing machines which produce that output.
I've seen a disturbing trend where a process that could've been a script or a requirement that could've been enforced deterministically is in fact "automated" through a set of instructions for an LLM.
Sure, when that is possible. However, there are lots of processes we don't know how to automate in a deterministic way. Hence the vast amount of investment in building organisations of people with mechanism to make peoples output more reliable through structure, reviews, and so on.
Large parts of human civilization rests on our ability to make something unreliable less unreliable through organisational structure and processes.
We resolve that through liability, penalties, trust, responsibility, review and oversight.
At the end of the day, if I am spending X$s for automation, I want to be able to sleep at night knowing my factory will not build a WMD or delete itself.
If its simply a tool that is a multiplier for experts, then do I really need it? How much does it actually make my processes more efficient, faster, or more capable of earning revenue?
There is a LOT that is forgiven when tech is new - but at some point the shiny newness falls off and it is compared to alternatives.
Liability, penalties, trust, and responsibility are means we use to try to influence the application of the processes that do. They do not directly affect reliability. They can be applied just as much to a team using AI as one that does not.
Review and oversight does address reliability directly, and hence why we make use of those in processes to improve the reliability of mechanical processes as well, and why they are core elements of AI harnesses.
> If its simply a tool that is a multiplier for experts, then do I really need it? How much does it actually make my processes more efficient, faster, or more capable of earning revenue?
You can ask the same thing about all the supporting staff around the experts in your team.
> There is a LOT that is forgiven when tech is new - but at some point the shiny newness falls off and it is compared to alternatives.
Only teams without mature processes are not doing that for AI today.
Most of the deployments of AI I work on are the outcome of comparing it to alternatives, and often are part of initiatives to increase reliability of human teams jut as much as increasing raw productivity, because they are often one and the same.
> Liability, penalties, trust, and responsibility are means we use to try to influence the application of the processes that do. They do not directly affect reliability. They can be applied just as much to a team using AI as one that does not.
Yes and no. see next point.
> You can ask the same thing about all the supporting staff around the experts in your team.
I have a good idea of the shape of errors for a human based process, costing and the type of QA/QC team that has to be formed for it.
We have decades, if not centuries of experience working with humans, which LLMs are promising to be the equivalents/superiors of.
I think you and me, would both agree with the statement "use the right tool for the job".
However, the current hype cycle has created expectations of reliability from LLMs that drive 'Automated Intelligence' styled workflows.
On the other hand:
> part of initiatives to increase reliability of human teams
is a significantly more defensible uses of LLMs.
For me, most deployments die on the altar of error rates. The only people who are using them to any effect are people who have an answer to "what happens when it blows up" and "what is the cost if something goes wrong".
(there is no singular thread behind my comment. I think we probably have more in agreement than not, and its more a question of finding the precise words to declare the shapes we perceive.)
> (there is no singular thread behind my comment. I think we probably have more in agreement than not, and its more a question of finding the precise words to declare the shapes we perceive.)
I moved this up top, because I agree, despite the length of the below:
> However, the current hype cycle has created expectations of reliability from LLMs that drive 'Automated Intelligence' styled workflows.
Because for a lot of things it works. Today. I have a setup doing mostly autonomous software development. I set direction. I don't even write specs. It's not foolproof yet by any means - that is on the edge of what is doable today. Dial it back just a little bit, and I have projects in production that are mostly AI written, that have passed through rigorous reviews from human developers.
The key thing is that you can't "vibecode" that. I'm sure we agree there.
There needs to be a rigorous process behind it, and I think we'll agree on that too.
Those processes are largely the same as the processes required for human developers. Only for human developers we leave a lot of that process "squishy" and under-specified.
We trust our human developers to mostly do the right thing, even though many don't, and to not need written checklists and controls, even though many do.
What is coming out of this is a start of systems that codify processes that are very much feels based with human teams. Partly because we still need to codify them for AI, but also because we can - most people wouldn't want to work in the kind of regimented environment we can enforce on AI.
Sure, there is a lot of hype from people who just want to throw random prompts at an LLM and get finished software out. That is idiocy. Even a super-intelligent future AI can't read minds.
But there are a lot of people building harnesses to wrap these LLMs in process and rigor to squeeze as much reliability as possible from them, and it turns out you can leverage human organisational knowledge to get surprisingly far in that respect.
> Because for a lot of things it works. Today. I have a setup
> There needs to be a rigorous process behind it, and I think we'll agree on that too.
I would simplify it to: “I have a setup” is the part that is doing the actual heavy lifting.
From my very unscientific survey / extensive pestering of network, the only people getting lift out of AI are people with both domain expertise/experience and familiarity with the tooling.
The types of automation I see people wanting though are fully automated customer support systems, fully automated document review - essentially white collar dark factories. (Hey thats a good term). The need is for a process that is stable, and behaves the same way every time.
It seems actual AI use cases are more like sketching - if you have enough skill you can make out the rough sketch is unbalanced and won’t resolve into a good final piece. Non experts spend far more time exploring dead ends because they don’t have the experience.
In my opinion, it’s a force multiplier for experts or stable processes, and it’s presented as Intelligence.
I feel your examples fit within these boundaries as well as the ones you have described.
I would agree with all of this. We could argue over whether/when there's sufficient intelligence for fully autonomous systems, but those systems will keep being tools for experts for the foreseeable future, and the question is just how small or large the autonomous components of that are, not whether or not you still need experts to wield them.
it's strange to see software engineers using skills aka human description of small scripts instead of scripting things directly. often there were cli / tools / libraries to do what a skill does for many years. maybe it's culture issue, people who enjoy automation / devops / predictability will naturally help themselves, but other people just want to "delegate" and be done without trying.
When people do that they are using skills wrong. The best way to use a skill is as a means to give targeted instructions on how to make use of cli / tools/ libraries, with the skill just covering the "squishy bits" that aren't easily encoded into something deterministic.
If you are saying that what we had previously was actually as easy as literally writing "make me a web app for arranging seats at a wedding and put it on Vercel" then you are very divorced from reality.
I know how to do all of these things and even find them easy, but it's just much faster now. These are personal one task toy apps, but they are useful.
AI is a tool that may make copyright violations more likely, but whether the output violates copyright is a property of the output, not how it was produced.
If you copy and paste leaked closed source code or if your AI produces it verbatim, you're in trouble either way. Change it up a bit and you're fine in practice in both cases.
Workers are necessary but not sufficient for most businesses. You also need capital. This can be provided by the workers and is for many worker owners businesses, but when the business is very capital intensive that's just not feasible.
Are workers going to be able to fund Apple's factories or ExxonMobil's oil exploration? No, so they're not in charge.
You absolutely can start a worker owned business right now, or go work for one.
Of course. That is why state guided worker coops are a good idea. Or state incentives to provide loans at good interest rates to worker coops.
The state provides capital, the workers operate the business, make management decisions, and have democratic input like the public does.
You might say, that kind of system isn't a perfect solution, but currently we have a dictatorship of wealthy individuals and businesses who are wholly unaccountable.
If you want a certain app with a feature and the app isn't open source, then you may as well just clone the app and add the feature.
Claude Code and Codex (and other tools) have computer use and are perfectly capable of navigating, experimenting, cloning functionality, writing tests...
If the app is open source it's probably easier to just fork and add your features though. And cheaper.
Hell, I use the (closed-source) app Smart Audiobook Player and I wanted Audiobookshelf integration. I asked Claude, it decompiled the app, added the extra code, recompiled the APK and it works perfectly, syncing my book's progress with the server.
I could write something, but it would be "I told Claude to do this and it did, I'm happy", there isn't really much more detail to write about. What would you like to see?
Maybe they mean you can be not employed and build products yourself? Technically true, but that's like running your own surgeries or something, you're still doing surgery.
Just being upfront with people can break low performance patterns of behavior.
reply