Originally published at: Decades After HyperCard, AI Is Democratizing Development Again - TidBITS
In TidBITS Talk, there was a recent discussion about when computers were fun. Although it’s easy for those of us who have been working with Macs for decades to get grumpy about the good old days, the discussion started me thinking about how AI-powered development is the most fun I’ve had with technology in ages.
I’m well aware of the ethical, societal, and environmental criticisms of AI, though I suspect they’re merely the latest in a long line of high-cost technological tradeoffs. Part of life is choosing which demons to dance with and which to deplore. Personally, I think social media is a blight responsible for innumerable social and political ills, but others are willing to submit to it so they can remain aware of the carefully curated lives of distant relatives and old school friends, or because everything happens on TikTok. In contrast, despite the downsides, I’m happy to use Claude and ChatGPT because they help me better understand and navigate my world, and now they’re helping me build the apps I could never have created before.
So yes, it’s clear that AI poses a significant threat to the profession of software development. One developer friend told me recently that he hasn’t written a line of code in six months—he has spent his time directing an AI to write the code, then evaluating and fixing it. That’s a tough change to navigate.
I know what it’s like to see your industry disintegrating underneath your feet—for about a decade starting in 1993, much of my income came from writing print tech books about Internet and Apple topics. At the height of the dot-com boom around 2000, tech books were a roughly $1 billion retail category in the US. Today, tech books are so rare that current public publishing statistics seldom even break out the category. Of the publishers I worked with—Hayden Books, Osborne/McGraw-Hill, Peachpit Press, and O’Reilly—the first two are gone; Peachpit appears dormant aside from a few books for the Adobe Press and New Riders imprints; and O’Reilly has become a “technical learning platform” that also publishes some print books.
But just as we computer book authors were able to put our skills to work in other ways, I remain optimistic that opportunities will emerge in a world where it’s more effective to have a skilled, thoughtful human direct an AI to write software. And perhaps more importantly, if AI truly democratizes development, those of us who have always wanted to turn our ideas into apps will have that opportunity. Tech thinkers have long promoted a future where everyone who wants to can code, but apart from a brief shining moment when HyperCard was ascendant, every initiative to democratize development has either faded away or evolved into something so complex and expensive that only professional developers could master it. With AI, perhaps that can change.
Here’s where I’m coming from, where I’ve seen the personal programming world evolve, and where I see AI development taking us with the kinds of apps and systems we use on our Apple devices today.
A Personal History of Failing to Become a Developer
As a teenager in the early 1980s, I spent much of my summer days on a Ford 8N tractor from the 1950s, driving slowly around hayfields in ever-shrinking circles as I tedded or raked hay before my father and I would bale it. This farm work gave me tons of time to daydream, and one of the main things on my mind was video games. I thoroughly enjoyed playing the Atari VCS’s cartridge-based games, and I spent hours designing games in my head. But I had absolutely no idea how to turn those ideas into reality.
Even after we got a Franklin ACE 1000—an Apple II+ clone—and I could start programming in BASIC, creating anything approaching a real game still seemed far out of reach. I could write simple programs, but unlike the origin stories of programmers who would go on to create world-changing apps, I never advanced much further. BASIC may have been designed to enable non-specialists to program computers—it was vastly easier than assembler!—but it didn’t help me become a programmer.
Thinking back, that may have been because I don’t enjoy abstract puzzles, even when I can solve them. I also found tiny syntax errors tremendously frustrating—I’d spend far too great a percentage of my time looking for missing punctuation. (In my memory, that annoyance has condensed into “failing to end a line with a semicolon,” which was probably Pascal, a language I didn’t encounter until college.) Plus, again with hindsight, my aphantasia probably prevented me from visualizing what an app would look like, making it difficult to get started. Finally, I learn best through repetition and iteration, but it was just too difficult to iterate my way into an app with a non-linear interaction model.
Thanks to my high school’s proximity to the IBM Owego and IBM Endicott plants, we were given a room full of original IBM PCs, and I took the first programming course offered, along with all my peers. (My class had only about 115 students, so I was in the same classes with the same people the entire time—we all knew each other’s abilities well.) Although I graduated as valedictorian, it quickly became clear in that programming class that some of my fellow students were better programmers than I was. I wasn’t terrible, but it was sobering to see people whose grades didn’t match up to mine in other classes quickly and easily solve programming challenges that I had to slog through.
But I was still a computer person, and when I went to Cornell University, I traded the Franklin ACE 1000 for an Atari 1040ST, a contrarian choice given that Cornell was one of the first Macintosh campuses. When, in my sophomore year, I decided to take Cornell’s CS100 programming class as part of my College Scholar major in Hypertextual Fiction, the class description led me to assume I could use Personal Pascal on the Atari instead of Lightspeed Pascal on a Mac. That turned out to be teenage hubris—I had to rewrite the code we were provided for the first assignment just to get it to compile, and a subsequent chat with the professor made it clear that code not written in Lightspeed Pascal was unacceptable. I dropped the course after the first week. Clearly, I wasn’t cut out to be a programmer.
However, I still had a computer in my dorm room and a modem to connect to Cornell’s BITNET-connected IBM mainframe, and later I talked my way into an account on a Unix machine operated by Cornell’s Theory Center, which gave me access to Usenet news. I may not have been able to program, but I knew more about computers than most computer science majors, and I learned even more when I got a job managing Cornell’s public computer rooms and had to solve real-world problems for others. A graduate student once gave me a bottle of wine for the time I spent helping her convert her dissertation from MultiMate to WordPerfect while I was managing a sleepy summer computer room.
That’s when I realized that what I found fascinating about computers was not how they were programmed, but how people used them, which was often poorly. I couldn’t write programs, but I could quickly figure out how they worked, explain them both in person and in documentation, and solve problems when things went wrong. I developed strong opinions about things like performance and interface design, but always from the perspective of how they affected users.
The Democratization of Development
The first time I was able to put any of those opinions into play came in the late 1980s, when HyperCard took off. Described by its creator, Bill Atkinson, as a “software erector set,” HyperCard was a revelation because it went far beyond earlier efforts to make programming more generally accessible, such as BASIC and Logo. With HyperCard, you could start by putting buttons and fields on cards and only later start wiring them up with scripts. Finally, I could start with an interface and iterate from there! Those HyperTalk scripts were tightly tied to their objects and more human-readable than any previous language I’d seen. Interface was king in HyperCard, but it also taught database principles and object-oriented thinking in a sneaky way.
In fact, TidBITS exists in large part because of HyperCard (see “TidBITS History,” 18 April 1994). Rather than just writing articles to be read in Usenet or on a mailing list, I wanted TidBITS to be something more, to be a thing. Publishing articles as cards in a HyperCard stack gave them a level of layout and interactivity that wasn’t possible any other way, but what I was most proud of was how each week’s stack could be added to a searchable archive of all the previous stacks. I was also indexing software reviews in the major print magazines in TidBITS at the time, so the TidBITS archive was an invaluable research tool.
I made one mistake in the TidBITS HyperCard stack that taught me the extent to which architecture matters. Something I did caused each week’s stack to increase the archive size by more than it should have. As the archive grew to 99 issues, the file size exceeded 10 MB in an era when hard drive sizes ranged from 40 to 160 MB, and merging became intolerably slow. Other issues also drove us to help develop and switch to setext, a plain-text markup format that helped inspire Markdown, but the bloated archive was a major factor.
HyperCard’s impact faded after 1992, when Apple replaced it on every Mac with the read-only HyperCard Player and started selling the HyperCard Development Kit for $199 through Claris (see “HyperCard Player Bundled with Macs,” 21 September 1992). Leading up to that move, I had argued in “QuickTime Rules” (20 January 1992) that HyperCard was a commercial failure because Apple had provided too much in the way of development tools. But as I clarified after sharing responses from HyperCard’s lead engineer and product manager in “HyperCard Confabulation” (10 February 1992), my real concern was that without a commercial market behind it, HyperCard would
cease to be a development platform of choice for the individual or may even disappear entirely, which I feel would be a tragic loss to Macintosh users, and even more broadly, to the entire computer community.
Unfortunately, whether my premise was correct or not, replacing HyperCard with HyperCard Player sucked the air out of the platform as a tool for non-programmers to create worthwhile stacks. Replacements such as SuperCard attempted to fill the gap, but without the audience provided by bundling with every Mac, none of these HyperCard replacements ever became a major player. Nonetheless, the dream of developing for non-developers lived in other guises, notably FileMaker, AppleScript, and HTML.
The database app FileMaker was introduced in 1985, began offering a runtime version in 1994, and became relational in 1995. FileMaker was entirely focused on database thinking, of course, but it offered enough interface tools that you could make something akin to a HyperCard stack. Unlike HyperCard, though, it was never bundled with every Mac, so it never had the same reach among ordinary users. In the late 1990s, Claris released FileMaker Developer Edition and reorganized around the app, focusing on professional developers who created and maintained database solutions for customers—a far cry from the promise of HyperCard.
AppleScript arrived in 1993, as HyperCard’s role as a development tool for the rest of us was waning. It promised a more human-readable language along the lines of HyperTalk, but its goal was to help automate tasks in other apps—it had essentially no interface beyond dialogs. In the mid-2000s, AppleScript was joined by Automator, which further simplified programming by enabling users to construct workflows by dragging predefined actions together. Worthwhile as both have been in tying apps together in interesting ways, neither really played in the space HyperCard had vacated—they were about automation, not app development.
The mid-1990s also saw the rise of HTML, which scratched some of the same itches as HyperCard. Anyone could make Web pages with nothing more than a text editor. Serving them required a Web server, but between Mac options like MacHTTP (later WebSTAR), basic hosting from Internet service providers, and Web hosting companies, it wasn’t too hard to publish a website. HTML was good at displaying text and graphics and offered some level of interface interaction through links, but it lacked HyperCard’s flexibility and database foundation.
Or at least it did until professional developers got involved. It didn’t take long for website development to become full-fledged development, with sites sitting on top of SQL databases, layouts controlled by dynamic CSS, and interfaces driven by JavaScript. You can still build and serve an HTML 2.0-based website, but the level of functionality users expect today requires knowledge and skills far beyond what the average user can pick up. That’s true even at the professional level—although “full-stack” developers exist, it’s common for a website development team to include specialists for user experience design, front-end development, back-end development, network engineering, security engineering, and more.
Numerous “low-code” and “no-code” solutions have emerged to make it easier to build dynamic websites and networked apps, and they do eliminate the need for coding. But they still require the user to learn programming abstractions within the system’s custom language or interface, and they usually require pricey monthly subscriptions. They aren’t aimed at individuals the way HyperCard was.
Enter AI-Powered Development
Like many people, I first dipped my toe into AI development by having ChatGPT do data analysis on spreadsheets (see “ChatGPT Proves Useful for Data Exploration,” 20 January 2025) and getting it to write simple AppleScripts (see “How to Identify Good Uses for Generative AI Chatbots and Artbots,” 27 May 2024). Then I decided to develop an iPhone stopwatch app to replace the Seiko printing stopwatches we use for backup timing. Although they’ve been largely unchanged since the early 1980s and are relatively simple technology (a clock chip with memory and a thermal printer), these stopwatches still cost about $500. Even repairing our old ones can cost several hundred dollars.
The problem was that a native iPhone app required using Xcode, and while I was willing to copy and paste small scripts into Script Editor, the prospect of doing that with all the files involved in a full-fledged Xcode project was daunting, to say the least.
Around that time, TidBITS reader Charlie Garrison asked if I’d like to try his Beyond Better AI tool, which was a Mac app that could mediate between an AI model like Claude Sonnet and local files. It was very early days for Beyond Better, and Charlie was looking for feedback, which I had a lot of. Between his help and Claude’s, I was able to set up an Xcode project and build a real iPhone app that worked the way I thought it should, rather than the incorrect ways all the other stopwatch apps on the App Store worked. Like the Seiko stopwatches, my app featured a button the user could press without looking at the screen (since they should be looking at the finish line) and a reset process that couldn’t be triggered with an accidental tap.
That’s when my imagination kicked in. What if my app—which would have to be called FreezeFrame—could take a picture of runners as they crossed the finish line? And overlay their finish time on the photo? Maybe it could capture video of the entire race so we could scrub back to untangle confusing finish groups? But wouldn’t it be great if it could capture only interesting moments when runners were in the screen, rather than all the dead time between finishers? Could the user trigger those photos with a Bluetooth button so the iPhone could be mounted on a tripod pointing at the finish line?
Unfortunately for me, that was a year ago, when the AI models weren’t nearly as good. I got the basic interface and guts built—FreezeFrame was able to take time-stamped photos triggered from a Bluetooth selfie stick button—but the Claude Sonnet model of the time struggled with camera orientation and other issues. The racing season ended, and I turned my attention to other projects.
This spring, however, faced with only a single working Seiko and buoyed by the reports exclaiming about Claude Code, I decided to give it a try, in part because some level of development is possible with a standard $20-per-month Claude Code subscription, whereas Beyond Better, like other tools built on the major frontier models, had to charge based on token usage, which is the economic unit of AI work. I hadn’t spent a lot on FreezeFrame—about $100 total over several months—but for a hobby project, I was willing to endure Claude Code’s limitations. It turned out Claude just made me stop for an hour or two occasionally when I used too many tokens in a 5-hour period. To switch, I merely explained what I had done with Beyond Better and asked Claude how to set up Claude Code in Terminal. It did an excellent job of walking me through the steps, after which I was able to pick up development where I had left off.
The capability difference between 2025 and 2026 was shocking. With the Sonnet model and occasional help from the higher-powered Opus and Fable models, Claude Code quickly solved problems that had stymied it the previous year. All those features I had imagined with finish-line photos, video, and Bluetooth buttons are now working, and a friend who was running FreezeFrame with a Flic Bluetooth button (a small programmable clicker) was giggling with pleasure as she used it at a race last week. The interface is still rough, but I’m now wondering if I can get it to record finishers automatically and do OCR on their bib numbers to associate them with runners. It would never be perfect—too many people walk in front of the camera, and runners will do the wackiest things with their bib numbers—but it’s a backup, not our primary timing system.
Around this time, I wrote “Yet Another Story of an iOS Update Silently Changing Settings” (10 May 2026), and as the discussion unfolded in TidBITS Talk, I found myself wondering if we could catch Apple in the act of changing settings. I spun up Claude Code again and asked it to write a shell script that could create and compare snapshots of macOS settings. Shockingly, it worked pretty well. But I really don’t like working at the command line, so I asked Claude Code to turn my shell script into a full-fledged Mac app, called SetShot.
Talk about addictive! It was a good thing I was working within Claude Code’s limitations, since they forced me to step back from development and get other stuff done. Even then, there were times I had to exercise non-trivial amounts of willpower to do work that wasn’t challenging me in nearly the same ways. At long last, I could make a Mac app that looked and worked exactly the way I wanted, with attention paid to niceties like where windows open and how multiple windows tile. I’ll write more about SetShot separately, but it has been an eye-opening experience.
Reflections on AI-Assisted Development
Perhaps the most interesting aspect of working on FreezeFrame, SetShot, and a more ambitious networked system I’m developing for managing track meets is how much I’m learning about software development as a field. If all you’re doing is having an AI whip up a folder action script to rename .jpeg files on your desktop to .jpg, you don’t have to think about much beyond how to keep it from renaming the wrong things.
But asking an AI model about the best ways to build my apps has pushed me toward a more formal process. First, I have it interview me about what I want to create specification and requirements documents. During—and after—that process, I’ve asked for explanations about anything I don’t understand, and I’ve pushed back whenever something doesn’t seem right for the user. I’ve always been a little vague on what automated tests are, exactly, so I asked for more information and directed the AI to create and run them. I can even ask for big-picture feedback on what I might be missing. AI is enabling me to participate in software development without ignoring the field’s professional practices.
Yes, the AI model is doing all the coding work, but it’s doing what I ask, quickly and agreeably. Sometimes it even tells me that something I’ve asked for is a bad idea. I’ve worked with developers over the years, primarily on large Web projects, and using an AI turns out to be a similarly collaborative experience. Except the AI responds within minutes instead of hours or days, does exactly what I ask, and never goes on vacation or takes parental leave during the process. And while I’m polite with AIs as a matter of policy, it is nice not to have to finesse communications when I don’t like the current direction of some interface. And all that for $20 per month, rather than $100+ per hour. I have often settled for results that weren’t exactly what I wanted because of the time, money, and relationships involved.
What I’m discovering is that building software and programming no longer have to be the same thing. The experience of building an app with AI is much more like being a product manager at a software company. Professional development involves far more than writing code: someone must also decide what the app should do, design the interface and workflows, make technical decisions, test the result, document it, and support users. In a large software company building corporate-scale software, those jobs are usually spread among numerous specialists, and human expertise will remain necessary throughout much of the process.
However, for the sort of human-scale software I’m talking about here—the kind of apps and systems whose purpose and behavior can be understood and directed by a single person—AI can take on many of those roles. It can build interfaces, choose development platforms, write code, run tests, document features, and help solve problems. But it can’t be the product manager. Someone, some human, has to have the vision for what the app will do, understand the problem to be solved, have a sense of how users will interact with the app, realize when an interface or workflow is wrong or could be better, and know when the app is done. AI can do a lot, but it can’t read your mind or invent your goals—only you can supply your intent.
The opportunity in human-scale software is especially interesting because even the best software doesn’t always work the way you want, and most software isn’t even that good. We put up with apps that are difficult to learn, have mediocre interfaces, require convoluted workarounds, and include numerous features we don’t need because our only real alternative is to switch to a competing app, which has its own cost. Sure, some problems can be fixed or glossed over with automation software that remaps keyboard shortcuts or chains together actions so we don’t have to repeat them ourselves. But such tweaks go only so far, and everyone thinks differently, has different needs, and works in a different digital environment.
There isn’t a single app that I use that I wouldn’t tweak in some way—except SetShot, because I’ve already implemented every change I’ve wanted. Taken to its logical conclusion, AI development could let anyone who wants an app customized to their exact needs and desires make it themselves.
We’re not there yet, but we’re getting close. That’s why I’m being inundated with pitches from indie developers looking for coverage in TidBITS—seriously, I’m getting three or four pitches per day now. Many of these apps are slightly different takes on existing app categories with some new feature, approach, or interface. I have no way of knowing how expert these developers would be without AI, but there’s no question that AI has given them capabilities, if only in the speed of development, that they never would have had on their own.
If someone like me—technical, but not a coder—can build an app like SetShot, it’s not hard to imagine a near future in which app development becomes easy enough for anyone who has the desire to build an app for their own use. While Claude Code and OpenAI’s Codex will talk you through everything, systems like Beyond Better and Bitrig offer additional focus—shared team workspaces and cloud data sources in Beyond Better’s case, and Swift apps for Apple devices in Bitrig’s. Even Apple’s Shortcuts in OS 27 can create workflows from your natural language descriptions. It’s just going to get easier.
Most people aren’t going to create their own email client or word processor, of course. Even if AI makes that technically possible, the project is likely still too large. However, there’s a possible future in which we start with apps—perhaps commercial, but likely open source—that expect to be customized by AI. Such apps would provide a solid foundation and safe extension points, along with documentation that would give an AI the information it needs to customize the interface and add features based on user conversations. Think of it as a modern take on Apple’s OpenDoc software framework from the 1990s, which was going to let us snap components together to customize apps.
Ultimately, the real breakthrough with AI development is not that it can generate code. That’s necessary, to be sure, but what’s truly new about building an app with AI assistance is that the interface has become ordinary human language. No longer do you have to learn an abstruse, formal programming language or wrap your head around a visual programming environment. For the first time in the history of software development, an everyday user can create real software primarily by expressing their intent in ordinary language.
I don’t regret not becoming a programmer when I was younger—it wasn’t the right path for me. But after all these years, I finally have a way to build the apps that appeal to me now, even if they’re a far cry from the Atari games I imagined while driving a tractor in circles around hayfields.
