A few weeks ago, I caught up with a former coworker. We hadn’t talked in several years.
She’s still working in software development. I’ve moved on, but I still have fond memories of working with really smart people to solve really hard problems. Looking back, I think that’s what I enjoyed most about software engineering. It wasn’t the code itself. It was collaborating with creative people who cared about solving real problems.
As we talked, I asked what her job looks like today compared to when we last worked together.
The answer surprised me.
She told me she isn’t writing nearly as much code as she used to. Designers are using AI tools to generate code. Programmers are reviewing it before it gets committed. She uses AI to understand unfamiliar code bases and make changes faster. And like many people in technology, she wonders whether software developers will even have jobs in the future.
This wasn’t the first conversation like that.
I’ve spoken with other former colleagues who are using AI to build software faster than they ever thought possible. Some are nearing retirement and are relieved they won’t have to figure out what the next twenty years of software development might look like. They worry AI is getting close to replacing them.
So what if it is?
What if AI makes it easier to create software?
Is that really a problem, or is it an opportunity?
Every Generation Thinks the New Tool Is Worse
The history of computing is full of examples of people worrying that making programming easier would somehow make programmers worse.
In the early days of computing, programs were often written directly in machine language or assembly language. Programmers needed a deep understanding of the hardware they were working with.
Then, in 1954, IBM introduced FORTRAN.
Today, that sounds unremarkable, but at the time many programmers were skeptical. Why would anyone trust a compiler to generate machine code? Surely hand-written assembly would always be better.
And sometimes it was.
But that wasn’t the point.
FORTRAN allowed people to focus more on solving scientific and mathematical problems and less on the details of computer hardware. Productivity exploded. Scientists could spend more time doing science and less time worrying about processor architecture.
The same thing happened a few years later with COBOL.
COBOL Was Supposed to Be Too Easy
By the late 1950s, organizations were spending enormous amounts of money rewriting software every time they bought new computers.
The solution proposed by the creators of COBOL sounded almost ridiculous for its time.
They wanted a programming language that looked more like English, worked across different computers, was easy to learn, and allowed more people to write software.
Many programmers viewed those goals with suspicion.
Today, they sound completely reasonable.
COBOL went on to become one of the most successful programming languages in history. Decades later, it still runs critical systems in banking, insurance, government, healthcare, and countless other industries.
Despite predictions of its demise, COBOL still processes an enormous percentage of the world’s financial transactions. Much of the infrastructure we rely on every day depends on software written in a language that many programmers spent decades mocking.
That success didn’t stop criticism.
In 1975, the famous computer scientist Edsger Dijkstra wrote that “the use of COBOL cripples the mind.”
That’s a harsh statement.
It’s also a reminder that smart people can be spectacularly wrong about the future.
Looking back, it’s hard not to notice a pattern. Every time programming became easier or more accessible, someone predicted disaster. FORTRAN was criticized. COBOL was criticized.
And then came BASIC.
BASIC Was Supposed to Ruin Programmers
BASIC was originally created in 1964 at Dartmouth College by John Kemeny and Thomas Kurtz. Their goal was simple but ambitious: make computing accessible to people who weren’t computer scientists.
At the time, computers were expensive and intimidating. Most people who used them were scientists, engineers, or trained specialists. BASIC was designed to change that.
The language quickly spread beyond Dartmouth.
By the late 1960s and early 1970s, BASIC was running on many of the minicomputers that were becoming increasingly common in schools, universities, and businesses. These machines were still too expensive for most people to own, but they were far more accessible than the room-sized mainframes that had come before them.
Because BASIC was available on those systems, an entire generation of future computer pioneers grew up using it.
People like Bill Gates and Paul Allen were familiar with BASIC long before personal computers existed. When the Altair 8800 microcomputer appeared in 1975, they immediately recognized that BASIC would be an ideal programming language for it. Their company, then known as Micro-Soft, created an implementation of BASIC for the Altair. It became the company’s first product.
That decision helped shape the personal computer revolution.
As home computers appeared in the late 1970s and early 1980s, BASIC became almost impossible to avoid. The TRS-80, Commodore PET, Apple II, Commodore 64, and countless other systems either shipped with BASIC built in or made it readily available.
Turn on the computer and there it was.
You didn’t need to buy a compiler.
You didn’t need to install development tools.
You didn’t need a computer science degree.
You could simply start typing.
Computer magazines published complete BASIC programs that readers could type in themselves. Schools used BASIC to teach computing. Hobbyists modified programs and shared them with friends. For many people, BASIC wasn’t just a programming language. It was their introduction to computing itself.
Not everyone thought that was a good thing.
Edsger Dijkstra certainly didn’t.
In one of the more famous examples of computer science elitism, he wrote:
“It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.”
Apparently, learning BASIC didn’t just make someone a bad programmer. It permanently damaged them.
And yet BASIC introduced millions of people to computing.
Including me.
How BASIC Changed My Life
I started learning BASIC in elementary school.
By a fortunate combination of circumstances, I had nearly unlimited access to an Apple II computer throughout the school day. As a blind student, that computer helped me complete assignments independently using a speech synthesizer and printer.
I also had access to simple BASIC programs in textbooks.
So I typed them in.
Then I modified them.
Then I broke them.
Then I fixed them.
Eventually, I started understanding them.
The reason that was possible is the same reason BASIC became so influential in the first place. The language was simple enough for beginners to experiment with, and it was available on the machines people actually had access to.
Schools had Apple II computers.
Home computers came with BASIC built in.
Computer magazines published programs that people could type in and customize themselves.
When my parents got their first IBM-compatible PC in the early 1990s, it came with QBasic. It wasn’t exactly the same as Apple BASIC, but it was close enough that I quickly felt at home.
Thanks to friends I met through ham radio, access to a few books and magazines, and plenty of time experimenting on that computer, I continued teaching myself how software worked.
That accessibility mattered.
Without it, I probably wouldn’t have become interested in programming at all.
Instead, BASIC gave me a way to explore how software worked. It gave me permission to experiment. Meeting other people who were experimenting too gave me permission to be me.
Later, I learned Pascal, C, C++, Java, assembly language, and many other technologies. I went on to earn degrees in computer science and software engineering and spent twenty years building software professionally.
None of that would have happened if I hadn’t started with BASIC.
So when I read Dijkstra’s claim that BASIC users were “mentally mutilated beyond hope of regeneration,” I can’t help but laugh a little.
I certainly don’t feel mentally mutilated, and I don’t think Bill Gates is either.
In fact, I think my experience illustrates exactly why Dijkstra was wrong. BASIC didn’t prevent me from learning more sophisticated languages. It gave me a starting point. It gave me a reason to be curious. Most importantly, it made programming feel accessible.
Which brings me back to AI.
What If AI Is the New BASIC?
Computer programs today are dramatically more complex than they were when I was learning to code.
Modern applications include networking, security, databases, cloud infrastructure, mobile devices, accessibility requirements, artificial intelligence, and integrations with dozens of other systems.
Learning all of that can feel overwhelming.
But what if AI lowers the barrier?
What if someone who has never written software can describe an idea and create something useful?
I know people who are already doing exactly that.
One friend missed a game that had disappeared from an app store. She described it to an AI tool and created her own version.
Is that really a problem?
Or is that someone solving a problem they care about?
Years ago, she would have needed to hire a programmer.
Today, she doesn’t.
Good for her.
The more I think about it, the more AI reminds me of BASIC.
BASIC didn’t eliminate professional programmers. It created millions of hobbyists, students, and future professionals. It gave people a way to experiment with computing without first earning a computer science degree.
AI may do the same thing.
Some people will use AI to automate repetitive tasks. Others will build small applications that solve problems in their own lives. Most will never become professional software developers.
A few, however, will become curious.
They’ll start asking questions. They’ll learn how software works. They’ll discover the limitations of AI-generated code and begin learning how to solve those problems themselves.
Some of them will become the next generation of software engineers.
That’s not the destruction of programming.
It’s the expansion of it.
AI Doesn’t Replace Creativity
I use AI regularly in my writing.
Not because it has better ideas than I do.
Because it helps me organize my ideas.
It helps me identify unnecessary details. It catches spelling mistakes. It suggests ways to improve transitions. Sometimes it helps me see a better structure for something I’ve already written.
The ideas are still mine.
The experiences are still mine.
The opinions are definitely still mine.
AI simply helps me express them more effectively.
When I eventually write software again, I expect AI will help there too.
It will remind me of things I’ve forgotten. It will explain technologies that emerged while I was away from the field. It will help me explore ideas more quickly.
That won’t make me less capable.
It will make me more capable.
The Hard Problems Are Still Hard
The fear that AI will replace software developers assumes that programming is mostly about writing code.
In my experience, it isn’t.
The hard part has always been understanding the problem.
What does the customer actually need?
Why is the system failing?
What tradeoffs matter?
How should competing priorities be balanced?
What unintended consequences might appear?
Those are human problems.
The code is important, but it’s only one piece of the puzzle.
AI is getting very good at producing code.
It is nowhere near as good at understanding messy human situations.
And messy human situations are where the most valuable work happens.
AI Will Help Modernize Old Systems
One thing that often gets lost in conversations about AI replacing programmers is just how much existing software still powers the world.
Many businesses, banks, insurance companies, and government agencies still depend on software written decades ago. A lot of it is written in COBOL, a language that few people learn today. The people who originally built those systems are retiring, and replacing them has become increasingly difficult.
For years, organizations have tried to rewrite these systems in modern languages. The results have often been expensive, slow, and risky.
AI may change that.
AI is remarkably good at reading and explaining existing code. It’s becoming increasingly capable of translating code from one language to another. It can help programmers understand systems that would otherwise take months to learn.
That doesn’t mean modernization suddenly becomes easy.
A translated program still has to be tested. Bugs still have to be found. Business rules still have to be understood. The people reviewing the work still need enough knowledge to recognize when the AI got something wrong.
In other words, AI may make modernization faster and less expensive, but it’s not going to eliminate the need for skilled people. It will simply allow those people to focus more of their time on solving difficult problems and less time on deciphering decades-old code.
AI Can Improve Accessibility
I’ve often said that accessibility is easiest and least expensive when it’s included from the beginning.
Throughout my software development career, I found that adding accessibility to an existing application usually cost more than designing it with accessibility built in from the start.
AI has the potential to change that too.
Today, AI can already identify many accessibility issues in code. It can suggest improvements. It can generate alternative text for images. It can recommend better labels for controls. It can help developers understand accessibility requirements that they might not have considered otherwise.
That’s exciting.
But it won’t be perfect.
AI doesn’t use software the way blind people, deaf people, or people with other disabilities do. It doesn’t have lived experience. It can’t always recognize when something technically passes a test but still creates a frustrating user experience.
We’re still going to need programmers who understand accessibility. We’re still going to need experienced accessibility testers to find problems that automated tools miss.
What AI can do is help more developers learn accessibility. It can shorten the learning curve. It can make accessibility guidance available to programmers who might never have worked with a disabled user before.
That won’t replace accessibility expertise.
It will help spread it.
Opportunity, Not Threat
I think AI is the new BASIC.
Like BASIC, it lowers barriers.
Like BASIC, some experts will dismiss it.
Like BASIC, it will allow people who were previously excluded to participate.
AI won’t eliminate programmers any more than BASIC did.
It will create millions of people who can solve problems they couldn’t solve before. Some of them will stop there. Others will become curious. And a few will become the people who build whatever comes next.
Technology moves forward when more people can participate, not fewer.
AI isn’t the end of programming.
It’s just another step in making computing accessible to more people.
And history suggests that’s usually a very good thing.
Have you tried AI and found it useful? If so, what have you done with it? If not, what’s holding you back?
Remember that, if you subscribe to my email newsletter, you can simply reply to the email to leave a comment. I’d love to hear your thoughts.
I’m also trying to expand the audience for Permission to Be You, and I need your help. If you enjoyed this essay, please share it with your friends. Share it on social media. Forward the email to someone who might find it interesting. Word of mouth is still one of the most powerful ways for independent writers to reach new readers, and every share helps.
Leave a Reply