From AOL to AI: How Building Software Became More Accessible

AOL made getting online easier

I remember when getting online took work. You needed a modem, a phone line nobody else in the house wanted, the right dial-up number, and patience. I was still in high school and spent my time online on BBSs and IRC, but for a lot of the people around me, America Online was the internet.

Looking back, I’m struck by how often the important change was who could use the technology. Getting connected became simpler, software became available without large license bills, and starting a service no longer required buying servers. AI is making another part of the work more accessible: turning an idea into an implementation.

The internet was already there. What AOL did was make being online ordinary. Steve Case sold AOL as the online service for people unfamiliar with computers, the trial discs turned up everywhere, and the subscriber count grew into the tens of millions. People who would never have configured a modem by hand were sending email and sitting in chat rooms.

AOL was one of several services that helped more people get online. As that audience grew, so did the opportunities to build businesses for it. I doubt I could have pictured the range of services we now use every day. I wrote about those decades from the user’s side in From DOS to AI. Here, I’m interested in how those changes affected what a small team could build.

Open source gave small teams more to build on

Commercial licenses for operating systems, databases and server software could be a substantial expense before a company had its first customer. Linux, Apache, MySQL and PHP changed the math. A writer for a German computer magazine, Michael Kunze, gave the bundle a name in the late 1990s, LAMP, to argue that free software could stand in for expensive commercial packages. Frameworks like Ruby on Rails later cut how much code a small team had to write before it had a working web application.

I’ve built on that foundation for most of my career. The global communications platform I co-founded ran on open-source VoIP, with Asterisk and OpenSIPS handling the calls. I’ve shipped a startup’s mobile app on a LAMP backend, and I moved a media publisher’s sites onto Rails.

Open source reduced what we needed to spend on licenses and gave us code we could inspect and modify. We still needed people who understood the stack. Community help and commercial support could be available, but we remained responsible for diagnosing failures and keeping the service running.

Faster internet, cheaper computing and the cloud

Faster connections and cheaper computing made richer applications practical. Virtualization let us run several isolated systems on one physical server. Cloud services offered another option, with AWS launching storage and then rented computing capacity in the mid-2000s, starting with S3. As smartphones and mobile networks improved, those applications could reach people away from a desk too. These changes overlapped; they did not arrive in a tidy sequence.

I’ve done this work both ways. I racked the servers and ran the cabling for my own company, then moved the platform into cloud regions to lower our cost structure and route users to the nearest region. I wrote about how the cloud turned capital into consumption. A small team could rent the capacity it needed to try an idea, with an operating bill instead of the same upfront hardware purchase.

Each of these shifts moved the work up a layer. Fewer engineers needed to configure a switch. More needed to understand distributed systems, cloud costs and failure modes in a data center they would never see.

AI is lowering a different barrier

AI can help someone get a first implementation working before they have learned the language or framework in depth. Earlier tools, including website builders, already made some kinds of software accessible without programming. AI extends that help to a wider range of tasks, though a working prototype still needs careful checking.

I see it in my own work. With an AI assistant in the terminal, I build products like FedPath and Useful Little Tools faster than I could alone, and I learn an unfamiliar technology in days instead of weeks.

Someone who runs a clinic, manages construction projects or works in federal contracting may understand a workflow better than an outside software team. An assistant can help them test an idea before they can justify hiring developers. That first version may be fragile, but it gives them something concrete to evaluate and discuss.

The implementation may take less time, while the work of checking permissions, data handling and failure recovery still needs someone’s attention.

Will developers forget the fundamentals?

Abstraction has always been how this field moves forward. Most web developers have never written a TCP stack, a database storage engine or a garbage collector, and they don’t need to. I’m not worried that a new engineer can’t recite command flags. I still look things up all the time, and memorizing syntax was never the same as understanding engineering.

What worries me is losing the practice of reasoning through a problem independently. Debugging, networking, databases and security take time to understand. If the assistant handles every difficult step, a junior engineer can finish the task without learning much about the system.

When AI-generated software fails in production

Consider a service that runs out of database connections. Increasing the pool might help, or it might hide a connection leak and put more pressure on the database. Someone needs to read the logs, form a hypothesis and test it. An assistant can help with that investigation, but accepting its next fix without understanding the cause can leave the underlying fault in place.

There’s early evidence that the way people use AI matters. In a small randomized study by Anthropic, engineers who learned a new library with an AI assistant scored lower on a quiz afterward than those who coded by hand, with the biggest gap on debugging. Participants who sought explanations tended to score higher than those who delegated the task. That comparison was observational within the study, and the quiz measured understanding shortly after the exercise, not long-term skill development. I went through the study in what happens to junior engineers.

Use AI to understand the system

I want developers to use the assistant to explain unfamiliar code, compare approaches and investigate why a fix works. Then check that explanation against documentation or an experiment. Generating a change and understanding it are separate tasks; reviews need to make room for both. I can see how much this could have helped me when I was learning, though I would still have needed to do the work of checking my understanding.

AI can handle much of the typing and lookup in programming. Engineers still need to understand system behavior, investigate failures and weigh security, reliability and cost. As implementation gets easier, those decisions account for more of the work I need to do myself.

The possibilities I’m curious about

AI feels to me a lot like the internet in the AOL years: useful, uneven, and mostly unbuilt. Predictions made from that position tend to age badly, mine included, so treat these as possibilities I’m watching.

• Smaller teams building larger businesses, because one engineer with good judgment can cover more ground.
• Nontechnical founders shipping a first version themselves and hiring engineers once they’ve found demand.
• Industry experts building specialized applications for problems too small for a software company to notice.
• Business software shaped around one company’s workflow, where today a general product fits nobody exactly.
• Business models and industries that sound strange today, the way search advertising would have sounded to someone installing AOL from a trial disc.
• Engineering roles that shift toward architecture, judgment, reliability and problem-solving.

I expect some useful ideas to come from people outside software engineering, because they encounter problems I never see. I don’t know which of those ideas will turn into lasting products or businesses.

What this means for engineering leadership

When writing software gets cheaper, the bottleneck may shift from writing software to understanding and trusting it. Engineering leaders are responsible for making sure AI raises a team’s engineering capability instead of replacing its critical thinking.

Keep hiring and developing junior engineers, and design their learning on purpose: debugging without the assistant, explaining their own code in review, owning small pieces end to end. I wrote about why mentoring matters to me, and it matters more now.

Keep accountability with people. The engineer who opens the pull request owns the change, whoever drafted it, and “the AI wrote it” doesn’t answer a review question. I think code review starts with the plan, before any code exists.

Require understanding before merge. If nobody on the team can explain how a change works, it isn’t ready. Knowing what AI-generated code tends to get wrong helps reviewers ask better questions.

Hold AI-generated code to the same security, reliability and maintainability standards as any other code. More code, faster, means more surface to protect and more to maintain.

Hire for reasoning and problem-solving. Ask candidates how they would track down a failure or weigh a tradeoff, and pay less attention to what they’ve memorized. Hiring is hard enough without testing the part AI already does well.

Balance speed with quality by matching review to the risk of each change. A copy change and a change to payments shouldn’t get the same scrutiny, whether a person or a model wrote them.

Short answers