I am Graham Mitchell, a software engineer in Austin, TX. I am also the author of the books "Learn Java the Hard Way" and "Learn Object-Oriented Java the Hard Way".
https://keybase.io/grahammitchell
Prior to becoming a developer, I spent twenty years (1997-2017) teaching Computer Science at Leander High School.
It is (or was, at least -- I haven't looked since I left) a pretty good school; consistently ranked near the top 5% of public schools nationally. I had a lot of students who were exceptional but most of my students were regular kids with no particular aptitude for programming. I taught over 2000 students.
[ my public key: https://keybase.io/grahammitchell; my proof: https://keybase.io/grahammitchell/sigs/fFa_yO52UWi27swZ6hzR5gE-KWge1dNmSFxSgl5Jl10 ]
I'm quite certain I formally verified that two processes were both able to get into the critical section WITH THE ALGORITHM I WAS VERIFYING, but this was 35 years ago, so details are fuzzy.
Remember that this is long before Wikipedia and even before Google, so I have no idea where I'd have gotten the alleged Baker's algorithm from.
Also you're right that this isn't much of an issue in practice, but that's not what formal verification is about, now is it? :)
I've been following Bob Cringely for nearly 30 years and he's always written like this.
This is almost certainly not AI-generated text, and he's not saying Claude is wrong.
He's saying something different that is probably true (that LLMs can't produce facts, no matter how much they are trained). It is also not that interesting (LLMs hallucinating sometimes doesn't mean they're not useful).
I'll grant you the self-aggrandizement, but he's come by it honestly.
I actually did take a formal verification course in college. Our final project was to use the techniques we'd been learning to verify some classic critical-section locking algorithm. I chose to verify an implementation of Lamport's bakery algorithm[0] in C (this was the 90s -- a lot of code was still being written in C).
The problem is that Lamport's algorithm makes an assumption that the "ticket number" is unbounded and any finite implementation in C will almost certainly use a value which is limited to 32 bits or so.
So I was able to formally verify that the algorithm fails to protect the critical section if enough processes are kept waiting to overflow the counter. :)
This probably just means that Lamport's algorithm isn't a great choice for such environments, but I'm still bummed that the professor gave me a B.
It's interesting that your experience/workflow is so much different than mine. This (claims to) solve a real problem that I deal with every day.
My company is remote-only, and my coworkers mostly don't live anywhere near me. We see each other a couple of times a day on video chat, but communicate mostly during the day via Slack.
We're also, uh, pretty far along the curve in adopting LLM agents to write good code for us. With a good model and the extremely good guardrails our of specific coding harness, LLMs are writing the majority of our code these days.
So on a typical day I'll grab a ticket off the top of the stack, point my LLM at it, and start working with it to solve the problem. We'll make architectural decisions, etc, create a plan and execute the plan. The feature I shipped most recently cost $19 in tokens and the LLM was churning without my input for like half an hour at one point in the thick of it.
MAYBE if there's a question I'm not sure which way is best I'll post a question in the team chat for my teammates to weigh in on. But a lot of my tickets are done completely autonomously.
Then I'll open a PR, and post a link to the PR in Slack, requesting their review and my teammates will see the implementation for the first time. They sometimes have questions! Often, they'll post these questions in the Slack thread rather than as PR comments, because we're having a fast real-time conversation and GitHub comments aren't a great fit for that.
These questions have answers in the chat log with the LLM that lives on my laptop, but I can't trivially show it to them.
So I end up playing telephone with the LLM -- copying my teammate's questions from Slack to the LLM chat, pasting the answers back, etc
The idea that my coworkers and the LLM and I can all be more easily a part of the same conversation appeals to me greatly
None of this means the Zed team is on the right track. Nor that my team might work better in a different way! But we're too "successful" with this approach for there to be much institutional pressure to change our ways at the moment.
In my case it's exactly that. I have a Linux gaming workstation, a work-issued (and managed) MacOS laptop and a Google-branded (Pixel) Android phone.
Bitwarden just works in all those places and the tech was, by all accounts, rock solid. AND I can pay for it instead of trying to leech off some privacy-ambiguous free tier.
I definitely trust my local LLM where I know the prompt that was used. Even if the code generated ends up being near-identical, it'll be way faster to review a PR from someone or something I trust than from some rando on the Internet
This isn't especially related to the article, but when I was at university my first assembler class taught the Motorola 680x0 assembly. I didn't own a computer (most people didn't) but my dorm had a single Mac that you could sign up to use so I did some assignments on that.
Problem is, I was just learning and the mac was running System 7. Which, like MS-DOS, lacked memory protection.
So, one backwards test at the end of your loop and you could -- quite easily -- just overwrite system memory with whatever bytes you like.
I must have hard-locked that computer half a dozen times. Power cycle. Wait for it to slowly reboot off the external 20MB SCSI HDD.
Eventually I took to just printing out the code and tracing through it instead of bothering to run it. Once I could get through the code without any obvious mistakes I'd hazard a "real" execution.
To this day, automatic memory management still feels a little luxurious.
Dumb question, but if this is "open source" is there source code somewhere? Or does that term mean something different in the world of models that must be trained to be useful?
I've seen this story making the rounds, but this isn't news, is it?
All self-driving companies maintain teams that make a decision when the cars get confused or stuck, and they report the number of such handoffs to NHTSA.
Is it just that there are teams in the Philippines specifically?
https://keybase.io/grahammitchell
Prior to becoming a developer, I spent twenty years (1997-2017) teaching Computer Science at Leander High School.
It is (or was, at least -- I haven't looked since I left) a pretty good school; consistently ranked near the top 5% of public schools nationally. I had a lot of students who were exceptional but most of my students were regular kids with no particular aptitude for programming. I taught over 2000 students.
[ my public key: https://keybase.io/grahammitchell; my proof: https://keybase.io/grahammitchell/sigs/fFa_yO52UWi27swZ6hzR5gE-KWge1dNmSFxSgl5Jl10 ]