Decades After HyperCard, AI Is Democratizing Development Again

Article Comments
41

Last time the tech bros told us social media was going to be great. They didn’t let their kids use it, but they got rich when they got everybody else addicted to it. And what followed was Jan 6 and the state we are in today.

Now the same poeple are telling us that huge data centers and LLMs are going to allow us to just get rich idly while bots take over the mundane work and that all’s going to be great. The same people who drive huge trucks in dense inner cities and have 10x the environmental footprint of the average Austrian are swearing that these data centers and their environmental impact are just a bump on the road and all will be great.

I’m aware of human history. I do see these AI-fueled changes as a new version of developments we have in the past already experienced and successfully weathered, be it steam engine, telegraph, or TV broadcasting. So while I remain extremely skeptical as to the interests of big data being well aligned with those of the everyday American (or European or whatever), I will not condemn the development at this early stage.

I will however say that the tech bros arguing for this, and the empty Wall Street suits preaching the AI kumbaya, those guys I don’t trust for a second. They have none of my interests at heart and nothing they argue for will benefit me or any other US taxpayer. Those guys can go pound sand for all I care. These no-goods are what used car dealers were to the 80s and lawyers to the 90s. If they all disappeared in a big hole tomorrow, the world would undoubtedly be a better place.

2 Likes
42

Yes, and in fact, that’s the standard approach for race timing already—it’s called chip timing and works with an antenna off to the sides of a finish line or in mats that runners cross. The problem for us is that the tags are essentially single-use since they have to be coded to (and stuck onto) the bib number, which is single-use. It’s not that expensive—less than $1 per—but we’re somewhat offended at the waste, and for the size of most of our races (under 150 people), it’s not enough easier to use chip timing.

As for concerns about AI, I’m in no way dismissing them. As others have noted, this sort of response happens with every new technology. It’s essentially impossible to stop technological growth, so I prefer to focus on the positive uses in the hope that they’ll outweigh and thus outcompete the negative ones. Sometimes that happens (personal computing, the Internet), sometimes it doesn’t (social media, in my opinion).

And yes, I’m extremely perturbed by the people who are leading some of the major AI companies. But I’m even more perturbed by many other public figures, and I don’t have solutions to any of it.

1 Like
43

And it doesn’t need them to have a battery? I guess the antenna off-sides is transmitting with enough power to turn on the tag.

Looking at the Wikipedia article (thanks), it appears that both kinds exist.

What is the cost for the non-disposable tags (that have a battery, I presume)? Probably enough that you’ll want the runners to return them after each race, but maybe it’s a viable option.

44

Yes, that’s the standard approach. They’re small, foam-backed tags that stick on the back side of race bibs. The antennas have enough power to read the non-powered tags.

I haven’t looked into non-disposable tags in a long time—they aren’t used in running races anymore because the return rate is too low and there’s a lot of extra labor in reprogramming them for the next race. I last used one of those in the 2008 New York City Marathon. They weren’t battery powered even then, but they were zip-tied into your shoelaces. The race had to have volunteers who would cut them off afterward—it was a royal pain. (And I could barely lift my foot to the little step they were using to not bend over all the way.)

I’m not sure where battery-powered tags would be used at this point.

45

Seems to me like a barcode flag attached to the runner’s nose by a short pole might be a better solution.

:smiling_face_with_sunglasses:

Dave

2 Likes
46

I guess I am in the category of people”who don’t understand! I’ll start with the term LLMs. What do the letters stand for?

PS Remember: if you are going to throw around acronyms of something in a post, at least put what it stands for in parenthesis the first time you use it. RO! (Rant Over!)

1 Like
47

Large Language Model. A kind of neural-network model trained on massive bodies of text for natural language tasks. That is, so it can understand questions and write replies in human languages.

They have become very popular as the back-end for many chatbot-type apps.

1 Like
48

One other comment: There are many algorithms and technical approaches which reasonably can be called forms of A.I., at least how the term “A.I.” is used today. Right now, when most laypeople use the term “A.I.,” they typically are referring to LLMs without realizing that LLMs are just a sub-category of A.I.

3 Likes
49

“Hysteria”?

Seriously?

You should also look up “false equivalence” because that’s what literally all of your examples are.

50

Your article resonated strongly with me—particularly your distinction between programming and building software and your description of the human as the product manager who still has to understand the problem, the user, and when the interface or workflow isn’t right.

I relate to your experience. My own path beginning in college passed through many of the same mileposts—Pascal, HyperCard, AppleScript, FileMaker Pro, HTML—without my ever developing real programming skills.

This summer I’ve been experiencing much of what you describe while building DeftBrain (DeftBrain.com). AI has made it possible for me to spend my time deciding what a tool should do, how little it should ask of the user, what should happen behind the scenes, and whether the result actually helps the person who came looking for it. That sounds very much like the product-manager role you describe.

But building it has made me wonder whether there’s a second kind of democratization happening alongside the one you describe.

AI development lets people who don’t know how to program turn ordinary-language intent into software. But on the other side, using AI through a blank chatbot still leaves something to the user: recognizing that AI might help, knowing what to ask, what context matters, and how to evaluate and refine the result.

DeftBrain grew out of a desire to remove more of that burden. Instead of presenting someone with a blank chatbot and asking, “What would you like me to do?”, a DeftBrain tool starts with a recognizable human problem—preparing for a difficult conversation, understanding a suspicious email, deciding between two possible futures, figuring out what to ask before an appointment. The interface asks only for what that particular problem requires; the more complicated AI interaction happens behind it.

Your observation that, in development, “the interface has become ordinary human language” made me wonder whether something analogous is possible on the user side. Perhaps the user shouldn’t have to translate a problem into a request for AI at all—the problem itself can be the starting point.

Someone shouldn’t have to think, “I need to use AI for this,” any more than they think, “I need to use a database” when they look up a contact. That’s the idea I’m exploring with DeftBrain: not merely making AI easier to use, but making the machinery of using it largely disappear, so that people who might never use a chatbot can still discover what AI can do for them—and perhaps some of its wonder along the way.

And AI-assisted development is what has allowed me to build it in the first place. So there’s a recursion in it: the democratization you describe on the development side has enabled me to experiment with another on the user side. In both cases, AI absorbs complexity the human previously had to master.

1 Like
51

Given recent news coverage describing opposition to “data” centers across the country and across political divides, I’m going to take a wild swing and guess that this movement transcends any of the above attempts to silo the opposition. Though “fringe suburbs,” if it refers to location rather than political tendencies, probably describes the likely location of most proposed data centers.

52

There’s a wonderful piece by Jasmine Sun where she talks with people in Michigan and Wisconsin who are fighting against data centers.

Her summary of what’s driving this backlash against data centers is toward the end:

And if you want to hear an excellent interview about it, she talked with Derek Thompson.

or on YouTube

1 Like
53

Just noting that the biggest race registration and timing company just introduced the photo-based timing feature I’ve been working on in FreezeFrame. Their approach will work only with races on their platform, so I see this mostly as validation that I’ve been on the right track all along.

1 Like
54

Adam — thank you, that’s generous of you.

Since you mentioned bib numbers, let me leave the measurements here rather than in a DM, because they apply to anyone pointing Vision at digits.

I ran a small bench today: synthetic bibs, bold digits on white, then the same images with CIMotionBlur (radius 9) to imitate a runner going past. VNRecognizeTextRequest, .accurate, usesLanguageCorrection off.

Clean digits are fine. Every bib read correctly, and language correction made no difference — I expected it to mangle numbers and it didn’t.

Motion blur is where it gets dangerous, and not in the way I assumed:

1408 sharp → “1408” confidence 1.000
1408 blurred → “408” confidence 1.000
0071 blurred → “00” confidence 1.000
8156 blurred → “8156” confidence 1.000

It doesn’t fail. It drops digits and reports full confidence anyway. “408” is a perfectly plausible bib number, so nothing downstream can tell that it used to be 1408 — and in a timing app that means a runner gets credited with someone else’s result. Confidence is not a usable filter here; I’d been assuming it was.

Two things that would catch it, neither of them clever:

Bib numbers have a known length for a given race. If the recognised string isn’t that many digits, throw it away rather than trust it. That single check kills both failures above.

And you have something most OCR problems don’t: the set of valid answers exists before the photo does. You know every registered bib. Validating the read against the roster turns “what does this say” into “which of these known numbers is it”, which is a far easier question and it can’t invent a runner who isn’t in the race.

That second one is the same shape as the guard I ended up needing in my own app for a different reason: the model kept inventing words for filenames, and no amount of prompting fixed it, so now every word in a generated name has to exist in the document or the name gets thrown away. Constrain the output to a set you already trust, and the failure mode goes from “wrong and confident” to “no answer”, which is the one you can actually handle.

One more, in case it saves you time: .fast is not worth it for digits.

1 Like
Document scanners: More complicated than "Just get the Fujitsu"?
55

(Bringing the post above over here to keep things on topic—it can break out to a new topic if the discussion expands.)

Luckily, I think your intuition about bib numbers is correct. We do always know the bib number range for a particular race, and they’re always 1, 2, or 3-digit numbers. (We could only get 3-digit numbers if it became important.) 4-digit numbers are larger than we need for any one race and slower to tap in for hand timing, so we always just reorder 3-digit sets.

56

Good news, then — the range does most of the work. I ran it to see how much.

400 three-digit bibs, 100–499, rendered and pushed through CIMotionBlur (radius 9) to stand in for someone crossing the line. Vision, .accurate, language correction off:

309 read correctly (77%)
57 wrong but out of range — your check catches every one of these
32 no reading at all
2 wrong and inside the range: 347 → “341”, 445 → “145”. Both at confidence 1.000.
So the range filter catches 57 of the 59 errors. It’s the last two that matter: each is a valid bib belonging to another runner, nothing flags it, and the confidence tells you nothing. At that rate a 400-person race hands two people someone else’s time.

The cheap fix that worked here: don’t accept a bib until two frames agree. I re-rendered those two with the blur at a different angle — effectively a different frame — and both readings changed. 2 out of 2 discarded. You’re getting many frames per runner anyway, so it costs nothing and closes the hole the range check can’t.

One caveat on my bench: synthetic digits in the system font, uniform blur. Real bibs are folded, angled and half-covered by an arm. My guess is the raw accuracy drops and the shape of the failure stays the same.