Skip to content

Essay · SEP 2026

Learn to code, they said. Now the code writes itself.

On changing careers, the future of software development, and trying to figure out where I fit in a world increasingly built by AI.

Joel Hart29 min read

I spend most of my day at a desk, staring at a screen, trying to keep up with the ridiculous pace of change in tech. A few years ago, that meant being locked into my IDE, writing code. These days, I’m often running a prompt factory, directing AI agents while reading articles, watching videos, scrolling through X, and trying to understand what the hell is happening to software development.

Spend half an hour on X and you’ll see a story about a 16-year-old who supposedly vibe-coded an app making a million dollars a month. Scroll a little further and there’s a developer who says they’ve been looking for work for three years and has decided to become a bus driver. One person supposedly built a million-dollar business without knowing how to code. Another spent their career learning to code and can’t find a job.

What the fuck does any of this mean?

The machines are coming, and I’m scared. Or at least, I was a lot more scared than I am today.

A few years ago, while working at my first startup, Devtst, I started seeing headlines declaring that software development was dead. I’d worked hard to become a developer, and the idea that AI could replace those skills terrified me. So I started using GitHub Copilot and went all in. But the results were underwhelming. I often spent more time fixing AI-generated code than I would have spent writing it myself. With encouragement from my colleagues, I stepped back and focused on learning the fundamentals rather than chasing every new tool.

Then, over the past year, everything changed. The models got dramatically better, and developers at some of the biggest software companies began letting AI agents write much of their code. I started to realize that maybe software development wasn’t dying. It was evolving, and I needed to evolve with it.

But what does that mean for everyone whose livelihood depends on skills AI is rapidly learning to perform? The junior developer trying to get their first job? The designer, writer, or customer service worker who can’t simply reinvent their career every few years? And what happens to our relationships when we start replacing human interactions with machines? Some days it feels like we’re racing to automate humanity itself.

I started researching because I was afraid of what AI might mean for my career. I’ve been reading employment studies, looking at historical examples of automation, and talking with everyone I know about how AI is changing their work. I wanted to understand what being a developer might look like in five years. Somewhere along the way, I realized I was asking a much bigger question about the kind of future we’re building for ourselves.

How I got here

In 2020, I was working as a fundraiser for a nonprofit in Vancouver’s Downtown Eastside. My days consisted of managing a database of more than 50,000 donors, sending thank-you emails, and repeating many of the same tasks.

I was burnt out. I cared about the organization’s work, but I wanted to spend more time solving problems and creating things.

Then COVID hit. The BC government was projecting a need for thousands of technology workers, and grants were available to help people retrain. I’d always been curious about how things were built, so I signed up for an introductory JavaScript course on Codecademy.

I loved it. For the first time, I could sit at a computer doing something that was technically work and completely lose track of time. I’d spend hours trying to solve a problem, and when I finally figured it out, I wanted to keep going. So I applied to Lighthouse Labs.

The next four months were some of the hardest of my life. Twelve-hour days trying to understand JavaScript, arrays, objects, callbacks, asynchronous code, and why changing a value in one object somehow changed another object I thought I’d copied. I spent an embarrassing amount of time debugging problems that turned out to be nothing more than a misspelled variable name.

And at the time, it seemed like a pretty good career decision. Software was everywhere. Companies were hiring developers. From the outside, it looked like people were getting paid $200,000 a year to change a React button from blue to pink and adjust its padding. Obviously, that’s not what most developers were doing. But the industry was booming, and software development offered something I hadn’t found in my previous career. I could solve problems, build things people used, and hopefully make a decent living doing it.

I had no idea how quickly the work itself was about to change.

Something is happening, and it’s happening fast

Over the past year, the way I build software has changed dramatically. Today, AI is involved in almost every part of my development process. I can explore unfamiliar technologies, build prototypes in an afternoon, or have an agent investigate a problem that might have taken me hours to figure out. I’m writing less code by hand, but I’m building more than ever. And I’m enjoying it.

Curious whether others were experiencing the same shift, I started reaching out to friends working at Microsoft, Clio, and Gumloop. Some describe workflows where they’re barely writing code themselves anymore. I’m hearing similar stories in interviews and podcasts featuring developers at companies like Linear and Ramp. These are individual experiences, not necessarily a reflection of how every developer works. But they mirror what I’m seeing in my own work.

AI is changing how software gets built. So I started looking at the numbers.

AI is everywhere. Except it isn’t.

According to Microsoft’s AI Economy Institute, an estimated 18.8% of the world’s working-age population used generative AI during June 2026. That’s roughly one in five people.

Fig / 01Estimate

About one in five used generative AI in June 2026

Used it in June 2026
18.8%
Everyone else
81.2%
Microsoft AI Economy Institute · estimated usage during June 2026, modelled from usage telemetry. Not the share of people who have ever tried AI. 1 dot = 0.1 percentage point. Source ↗ (opens in a new tab)
Fig / 01 · Estimate · play

About one in five used generative AI in June 2026

Users start scattered through the crowd, the way they really are. Gather them and one in five becomes a block.

Scattered

Microsoft AI Economy Institute · estimated usage during June 2026, modelled from usage telemetry. Not the share of people who have ever tried AI. 1 dot = 0.1 percentage point.

I find this fascinating. I spend so much time reading about AI, listening to podcasts, and talking to developers that it’s easy to forget how small my bubble really is. Every week brings another model, another benchmark, and another headline declaring that everything is about to change. But nearly 80% of working-age people worldwide weren’t counted as generative AI users during that period.

We’re talking about a technology that’s already transforming how I do my job, while much of the world is only beginning to use it. And I can’t help wondering what happens as adoption grows.

Am I actually getting better at this?

After months of working with AI agents, my confidence was through the roof. I felt like I could build almost anything. And to some extent, I could. I’d gone from spending hours figuring out relatively simple problems to building entire applications with the help of AI.

But I was starting to question whether I was actually becoming a better developer. Was I learning how these systems worked, or just getting better at telling a machine what to do?

There was another side to all this productivity, too. I’d spend evenings building side projects like TapBill, completely lose track of time, and suddenly realize it was three in the morning. I was building more than ever, but sleeping less, and my health was starting to suffer.

The strange thing was that I wasn’t staying up late because I was stuck. I was staying up because I could actually build the things I’d been thinking about. There was always another feature to try, another problem to solve, or another idea I wanted to explore. At some point, I started wondering whether all this productivity was actually good for me. Nobody was asking me to go this fast. The tools just made it feel like I should.

Earlier this year, I participated in the State of AI developer survey. I was curious how other developers were using these tools and whether they were questioning some of the same things I was. When the results came out, they were later discussed on one of my favourite development podcasts, Syntax, hosted by Wes Bos and Scott Tolinski.

What stuck with me wasn’t just how much AI developers were using. It was the discussion about the mental side of working this way. The hosts talked about having more ideas than ever, the difficulty of switching off, and the stress that can come from working with tools that make almost anything feel possible. One of them even described the experience as brutal for his mental health.

I could relate. The survey itself also revealed concerns about job displacement, negative cognitive impacts, and AI overuse.

And then there were the numbers. The 2026 State of AI survey collected responses from 7,258 developers. In 2025, respondents estimated that AI generated an average of 28% of their code. In 2026, that number had climbed to 54%.

Fig / 02Estimate

Developers say AI now writes about half their code

2025
2026
2025 average
28%
2026 average
54%
State of AI 2026 · 7,258 developers · self-reported estimates from a voluntary survey, so people interested in AI are likely over-represented. Not a measure of all code written. 1 dot = 1 percentage point. Source ↗ (opens in a new tab)

More than half. That doesn’t mean AI is writing half of all software in the world. The survey was voluntary, and developers interested in AI were probably more likely to participate. But it’s still remarkable. A few years ago, I was afraid to let AI write relatively simple functions. Now developers are reporting that it generates most of their code.

I love what these tools make possible, but I also worry about what happens when we become so productive that we stop learning, stop questioning, or forget to close our laptops. And if the way we produce software is changing this quickly, what does that mean for the people whose livelihoods depend on building it?

What happens to the jobs?

This is the part that worries me most. I didn’t become a developer just because I enjoyed writing JavaScript. I wanted a career that could support me and my family. I’d already changed careers once, and I thought I was entering an industry with decades of opportunity ahead of it.

We trained a lot of people to become developers

The number of US bachelor’s degrees awarded in computer and information sciences rose from 56,055 in 2014 to 121,836 in 2024. That’s more than double.

Fig / 03Measured

Twice as many graduates in ten years

2014
2024
2014 degrees
56,055
2024 degrees
121,836
NSF / NCSES · U.S. computer and information sciences, a category broader than computer science alone. 1 dot ≈ 5,000 degrees. Source ↗ (opens in a new tab)

For years, we encouraged people to learn to code. Governments invested in retraining programs. Universities expanded their programs. Bootcamps offered people like me a way into an industry with an enormous appetite for talent. And now we’re watching the work change just as another generation is preparing to enter the profession.

The job market is giving mixed signals

According to Indeed’s Hiring Lab, US software development job postings increased by almost 15% from late February 2025 to June 2026, while overall postings declined by 7%. That sounds encouraging. But software postings were still approximately 27.5% below their February 2020 level. And 71% of the increase between May 2025 and May 2026 came from senior roles.

Fig / 04Derived

A recovery, but from a much lower floor

Software
Feb 2020
All postings
Software
≈+15%
All postings
−7%
Software vs Feb 2020
−27.5%
Indeed Hiring Lab · Feb 2025 → June 2026, seasonally adjusted. A 15% rise is not a return to 2020 levels. Endpoints derived from reported changes, not raw series. Source ↗ (opens in a new tab)

Are we experiencing a correction after years of aggressive hiring? Are companies becoming more selective? Or are they discovering they can accomplish more work with fewer developers? Probably some combination of those things.

A Stanford analysis of payroll data found that employment among workers aged 22 to 25 in AI-exposed occupations was approximately 19% below the level implied by employment trends among similarly aged workers in less-exposed occupations. The researchers did not claim that AI caused the entire difference. In fact, they found no evidence of widespread, economy-wide job displacement. But the employment gap for younger workers is concerning.

Fig / 05Measured

Early-career jobs in AI-exposed work: about 19% below trend

Comparison trend
100
Relative level
81
Stanford Digital Economy Lab · revised Aug 2026 · ages 22–25. A gap from a comparison trend, not evidence that 19% of jobs disappeared, and not proof that AI caused it. 1 dot = 1 point on the index. Source ↗ (opens in a new tab)

If AI can handle many of the smaller tasks junior developers traditionally learn from, how do they gain experience? What happens when companies increasingly want experienced developers but become less willing to hire beginners? And who teaches the next generation?

It’s difficult to look at these numbers without wondering what the profession will look like in another five years.

The strange part is that AI makes me want to build more

For all the uncertainty, I love what AI makes possible. I can take an idea that’s been sitting in my notes for six months and turn it into a working prototype in an afternoon. I can experiment with technologies I wouldn’t previously have had time to learn, build something, discover what’s wrong with it, and start again. And increasingly, I can spend more time thinking about the problem I’m trying to solve rather than getting stuck on every implementation detail.

I didn’t get into development because I wanted to type every line of code by hand forever. I wanted to solve problems and create things. AI has made that easier than ever.

Which brings me to an economic idea that initially made me feel a little more optimistic.

Jevons Paradox: Trying to be optimistic

In 1865, economist William Stanley Jevons observed something counterintuitive about coal. As steam engines became more efficient, they needed less coal to perform the same amount of work. You might expect coal consumption to decrease. Instead, greater efficiency helped make coal-powered work cheaper, expanding its use and increasing total consumption. This became known as the Jevons Paradox.

And I wonder whether something similar could happen with software. For most of modern computing history, building software has been expensive. You need developers, designers, infrastructure, testing, maintenance, and people who understand what the software is supposed to do. Many ideas never get built because the cost is simply too high.

But what happens when that cost drops dramatically? A nonprofit might finally afford a custom tool. A small business might build software around how it actually works. Someone with a useful idea might create a product without raising money or hiring an engineering team. We could end up building far more software than we do today.

Fig / 06Concept

When making software costs less, more ideas become possible

  1. 01 Cost falls
    Less effort from idea to working software.
  2. 02 More ideas fit
    Smaller problems, smaller budgets, more experiments.
  3. 03 More software?
    A possible rebound, not a guarantee of jobs.
Conceptual · Jevons, The Coal Question (1865), discussed by Blake Alcott (2005). Illustrative, not a forecast. Source ↗ (opens in a new tab)
Fig / 06 · Concept · play

When making software costs less, more ideas become possible

Slide the cost of building one thing down. One expensive bubble splits into a crowd, and together they cover more.

ExpensiveCheap

Conceptual · Jevons, The Coal Question (1865), discussed by Blake Alcott (2005). Illustrative, not a forecast.

Here’s the catch.

“More demand for software doesn’t necessarily mean more demand for developers.”

If a team of three can accomplish what previously required thirty, we might build an extraordinary amount of software while employing fewer people to do it.

Fig / 07Concept

Five times the software can still need half the developers

Today
10× productivity, 5× demand
Labour today
1×
10× productivity, 5× demand
0.5×
Illustrative model, not a prediction: labour needed = demand ÷ productivity. Real employment also depends on new tasks, prices, adoption and business models. 1 dot = 5% of today's developer labour.
Fig / 07 · Concept · play

Five times the software can still need half the developers

Make developers more productive, then make the world want more software. Whenever productivity grows faster than demand, fewer people are needed to do the work.

Developer labour needed:

1×20×
1×20×

Illustrative model, not a prediction: labour needed = demand ÷ productivity. Real employment also depends on new tasks, prices, adoption and business models. 1 dot = 5% of today's developer labour.

On the other hand, cheaper software might create entirely new markets, products, and jobs that don’t exist today. We might be entering the greatest period of software creation in history. That doesn’t guarantee it will be the greatest period for software employment.

We’ve been here before. But is this different?

When technology automates part of a job, does the job disappear, or does it change? History offers some interesting examples.

Spreadsheets changed the value of accounting work

When VisiCalc arrived in 1979, it automated work that previously required people to manually recalculate financial tables. According to an NPR Planet Money analysis, the United States lost roughly 400,000 bookkeeping and accounting clerk jobs since 1980, while the number of accounting jobs increased by approximately 600,000.

Fig / 08Measured

The spreadsheet took the recalculating, not the accounting

Bookkeeping and accounting clerks · lost
Accountants · gained
Clerks since 1980
−400,000
Accountants since 1980
+600,000
NPR Planet Money (2015), U.S. jobs since 1980. Two different occupations: this doesn't mean the clerks became accountants. A single historical source. 1 dot = 20,000 jobs. Source ↗ (opens in a new tab)

The spreadsheet didn’t eliminate the need for financial understanding. It changed what people could do with it. Instead of spending hours recalculating figures, people could explore scenarios, analyze information, and make decisions.

I’ve spent time building financial tables and writing program management reports. The valuable part of that work wasn’t always producing the table. It was understanding what the numbers meant and helping people make decisions.

ATMs changed banking. Then banking changed again.

ATMs automated a significant part of what bank tellers did. But economist James Bessen described how reducing the number of tellers needed per branch also made branches cheaper to operate. Banks expanded their branch networks, and teller employment grew slightly for a period. Then online and mobile banking transformed how people interacted with banks, and teller employment eventually declined.

Fig / 09Measured

Tellers grew after the ATM. Then the bank moved into your phone.

197020102022
1970
≈250k
2010
556k
2022
352k
1970: about a quarter of a million, from census data (James Bessen, as cited by David Autor). 2010 and 2022: BLS Occupational Employment and Wage Statistics, May 2010 and May 2022. Different series, so read the shape, not the exact gap. Branch growth also had regulatory and economic causes. 1 dot = 20,000 tellers. Source ↗ (opens in a new tab)
Fig / 09 · Measured · play

Tellers grew after the ATM. Then the bank moved into your phone.

Before the ATM spreads. Every bit of cash goes over a counter.

≈250kTellers

197020102022

1970: about a quarter of a million, from census data (James Bessen, as cited by David Autor). 2010 and 2022: BLS Occupational Employment and Wage Statistics, May 2010 and May 2022. Different series, so read the shape, not the exact gap. Branch growth also had regulatory and economic causes. 1 dot = 20,000 tellers.

Technology can create opportunities for decades and then change again.

“A job can survive one wave of automation and still be disrupted by the next.”

AI was supposed to replace radiologists

In 2016, Geoffrey Hinton famously argued that we should stop training radiologists because AI would soon become better at reading medical images. AI has since become remarkably capable at certain imaging tasks. But radiology involves more than identifying abnormalities in scans. Radiologists interpret findings in clinical context, communicate with other medical professionals, and take responsibility for their conclusions.

The profession has continued to experience substantial demand. This doesn’t prove radiologists will always be safe from automation. It demonstrates that automating an important task isn’t necessarily the same thing as replacing an entire profession.

But AI might be different

An ATM automated a relatively narrow set of banking tasks. A spreadsheet automated calculations and made financial analysis easier. AI can work across programming, writing, research, design, analysis, and an increasing number of other activities. It isn’t a single-purpose tool.

Maybe the historical pattern will repeat itself, with new work emerging as old tasks disappear. Or maybe this transition will be much more disruptive. History helps us understand what’s possible. It doesn’t guarantee what happens next.

We’re probably going to create an enormous amount of software slop

If AI makes software dramatically easier to produce, we’re probably going to build a lot more of it. But does the world actually need all that software?

We’ve already seen what happens when the cost of producing online content approaches zero. We get more content. A lot more. And not necessarily better content. I worry software could follow a similar path: more dashboards nobody opens, more apps that solve problems nobody actually has, and more features that look impressive in a demo but fall apart when real people depend on them.

I’ve experienced this myself. An AI agent can generate something that appears to work perfectly. Then you review the implementation and discover unnecessary database queries, missing error handling, accessibility problems, or decisions that make the system harder to maintain. Sometimes the code is perfectly reasonable, but it solves the wrong problem. And sometimes nobody stopped to ask whether the feature should exist in the first place.

One thing I learned in fundraising and program management is that what someone asks for isn’t always what they need. Someone might ask for a dashboard when what they really need is a clearer process. They might ask for automation when the underlying problem is poor communication. They might ask for a new system when a small change to the existing one would solve the problem.

AI makes it easier to build what someone asks for. But it doesn’t make understanding the problem any less important. If building becomes dramatically cheaper, perhaps deciding what deserves to be built becomes an even bigger part of the work. I don’t know whether the market will reward that kind of thinking. But it’s the kind of work I want to do.

That kind of work takes time. You have to slow down long enough to ask a question and actually listen to the answer.

“Speed is the one thing these tools give us for free. Care is the part we have to choose.”

What does being a developer even mean anymore?

When I started learning to code, the path seemed relatively straightforward. Learn a programming language. Understand the fundamentals. Build projects. Get a job. Keep learning until you become an experienced developer who can solve increasingly complicated problems.

But what happens when an AI agent can write code faster than you?

A developer’s work has never been limited to writing code. It includes understanding requirements, designing systems, making architectural decisions, communicating trade-offs, reviewing implementations, testing, deploying, and maintaining what gets built. AI is already assisting with many of these responsibilities.

Fig / 10Concept

Writing code is one part of a much bigger job

  1. Requirements
  2. Architecture
  3. Implementation
  4. Testing
  5. Security
  6. Deployment
  7. Maintenance
  8. Communication
Concept · how AI can help, where people matter, and what might change, for each part of the work. Exploratory, not a prediction or a measurement.
Fig / 10 · Concept · play

Writing code is one part of a much bigger job

Pick a part of the job. AI touches all of them, but in different ways.

How AI can help today
Turning rough notes into a brief, spotting gaps and edge cases, drafting questions to ask.
Where people matter
Sitting with the person who has the problem and hearing what they actually need, which is often not what they first ask for.
What might change
Less time writing specs by hand, more time in conversation with the people the software is for.

Concept · how AI can help, where people matter, and what might change, for each part of the work. Exploratory, not a prediction or a measurement.

Are we actually getting faster?

In a 2025 study by METR, experienced open-source developers working on real tasks were approximately 19% slower when using the AI tools available at the time. Interestingly, those same developers believed AI had made them about 20% faster.

I had to read that twice. The developers felt more productive. But when researchers measured how long the work actually took, they were slower.

The study was relatively small, involving 16 experienced developers working on familiar codebases. It tested tools available in early 2025, so its findings shouldn’t be generalized to every developer or every AI workflow. Still, I keep thinking about it. I know how easy it is to feel productive when an agent is generating code at incredible speed.

“Generating code isn’t the same as completing useful work.”

You still need to understand the implementation, review it, test it, and make sure it solves the problem. And sometimes the time you save writing code gets spent fixing or validating what the model produced.

The 2025 Stack Overflow Developer Survey found that 84% of respondents were using or planning to use AI tools, while more developers distrusted the accuracy of AI-generated output than trusted it.

That tension feels familiar. I love how quickly AI can produce something. But I also want to understand what it created. If an agent gives me a confident-looking answer, I want to know enough to challenge it. If it introduces a security vulnerability, I want to recognize it. And if someone asks me to build something, I want to explain the trade-offs rather than simply trusting whatever the model suggests.

Maybe the job becomes something different

I’ve been reading about developers considering entirely different careers. Some are looking at trades. Others are moving toward sales, product management, consulting, or roles that combine technical knowledge with working directly with customers. And I’ve been wondering whether my own career might move in a similar direction.

Maybe I’ll be a developer who also manages projects. Maybe I’ll spend more time talking with clients, understanding their problems, and designing technical solutions. Maybe I’ll be a freelancer who handles everything from the initial conversation to building, deploying, and maintaining the product. Or maybe I’ll spend most of my time directing agents and reviewing the systems they create.

Some of those possibilities sound pretty exciting. But I don’t want to leave software development. I love solving problems, understanding how systems fit together, and building things people can use. I don’t particularly care whether I write every line of code myself. I care about what I can create.

There are a few possibilities I keep thinking about.

Smaller teams might build much bigger things. If a few developers can accomplish what previously required a much larger team, we could see more small companies, independent builders, and specialized software businesses. That could create incredible opportunities while also reducing traditional development jobs.

Developers might work much closer to customers. If implementation becomes cheaper, understanding what people need could become a larger part of the role. More developers might combine engineering with product management, consulting, or sales.

The next generation might learn differently. I learned by struggling through broken JavaScript, misunderstanding object references, and debugging things for hours. Those experiences were frustrating, but they helped me understand how software works. If AI handles more of that work, how will new developers build the same foundations? Maybe they’ll learn faster and differently. But I hope they still learn to question the systems they’re creating.

And perhaps the definition of a developer becomes much broader. Someone who understands a problem, designs a solution, uses AI to build it, and takes responsibility for the result might still be a software developer, even if they rarely write code by hand.

I’m not confident enough to call any of these predictions. They’re possibilities I’m trying to understand while figuring out where I might fit.

What I’m betting on

After all the research, the conversations, and the countless hours experimenting with AI, I still don’t know what software development will look like in five years. But I do know what I’m betting on. I’m betting on my ability to understand people and care about the problems they’re trying to solve.

Before becoming a developer, I worked in fundraising and program management. I’ve managed budgets, built financial tables, written reports, and worked with people trying to solve complicated problems. Since learning to code, I’ve built websites, software products, APIs, dashboards, and tools that people actually use. All of those experiences have shaped how I think and how I work. They’re part of who I am, and I believe they have value beyond the code I can write.

Maybe AI will eventually be better than me at most of the technical work. Maybe it will become better at explaining complicated systems, identifying problems, and proposing solutions. But having access to knowledge isn’t necessarily the same as understanding it. And I wonder what happens when we become increasingly comfortable accepting answers we don’t understand. Will we simply trust the systems providing them? Maybe one day we will.

But I hope we continue to value people who understand the work they do. People who can think critically, ask difficult questions, explain complicated ideas, and have honest conversations when something doesn’t make sense. I hope we continue to want relationships with the people building the things we depend on.

“These tools were built by people, for people.”

It’s worth remembering that, because some days the goal seems to have quietly shifted from helping humans to replacing them. I don’t think we have to accept whatever pace the industry sets. We can push back. We can take the time to understand what we’re making, do it well, and keep the people it’s for at the centre of it. That’s the craft I want to protect.

I’m not betting that JavaScript will save my career or that AI will stop improving. I’m betting on myself, my experiences, and my ability to adapt. I’ve done it before. I believe I can do it again.

And while I have real concerns about what all of this means for my future, I’m also grateful to be here. I’m grateful that I had the opportunity to learn to code and build things for people. I’m excited about what these new tools make possible, and I want to keep finding creative ways to solve problems.

There will be another model tomorrow. Another benchmark. Another announcement about how everything is about to change. I’ll probably read about it, get excited, and immediately tell my wife, who has already heard enough about AI to last several lifetimes.

But I’m trying to remind myself why I wanted to build things in the first place. I wanted to solve problems for people. I still do.

And whatever happens to software development, I don’t want to spend so much time worrying about the future that I forget to enjoy the life I have right now. Sometimes that means closing my laptop, spending time with my family, and going outside to touch some grass.

There are some things in life I don’t want to make more efficient. And that’s okay.

Research notes

This is a personal interpretation, not an employment forecast. Every figure says what kind of number it is: measured, estimated, derived or a concept.

  • Global AI adoption. Microsoft AI Economy Institute, September 21, 2026. Estimated 18.8% of the working-age population used a generative AI product during June 2026; not the share who have ever tried it. Report · Data and methodology.
  • AI-generated code. State of AI 2026, 7,258 respondents. Self-reported average share of code generated by AI: 28% in 2025, 54% in 2026. A voluntary survey, so likely skewed toward developers interested in AI. Survey · Risks and pain points · Syntax #1009 · Transcript.
  • CS degrees. NSF / NCSES, State of U.S. Science and Engineering 2026, IPEDS completions for computer and information sciences (broader than computer science alone). Figure.
  • Job postings. Indeed Hiring Lab, July 8, 2026; seasonally adjusted U.S. postings, about +15% software against −7% overall since late February 2025, still about 27.5% below February 2020. Fig 04 indexes February 2025 to 100 from the reported changes, not raw daily observations. Analysis.
  • Early-career employment. Stanford Digital Economy Lab, revised August 2026. An observational 19% relative gap for 22–25-year-olds in AI-exposed occupations, not a causal estimate. Research.
  • Jevons Paradox. Blake Alcott, Ecological Economics (2005), on Jevons’ The Coal Question (1865). The software application is a reasoned possibility, not a demonstrated law. Fig 07 is a simple illustration (labour = demand ÷ productivity), not a model of the job market. Paper.
  • Spreadsheets. NPR Planet Money, Episode 606, “Spreadsheets!”: about 400,000 fewer bookkeeping and accounting clerks and about 600,000 more accountants since 1980. A single source. Transcript.
  • Bank tellers. James Bessen on automation and occupations, and on tellers per branch (about 20 to 13 in urban branches, 1988 to 2004). Paper. The 1970 total (about a quarter of a million, census data) is Bessen’s, as cited by David Autor. The 2010 (556,310) and 2022 (352,440) totals are the BLS Occupational Employment and Wage Statistics for tellers (43-3071), May 2022.
  • Radiology. Hinton’s 2016 remark, and Fortune (2026) on residency positions, vacancies and pay. Fortune.
  • Developer speed. METR (July 2025): 16 developers, 19% slower with early-2025 AI tools while believing they were about 20% faster. A small study. Report.
  • Trust in AI tools. Stack Overflow Developer Survey 2025: 84% using or planning to use AI tools; 46% distrust their accuracy against 33% who trust it. Survey.
0%
Home