Future shock

I wrote this talk for my employer, to follow a talk given the previous week by the product organization about how they intended to change their work to use the new generation of LLMs. Nobody asked me to. I requested the slot myself – the entire hour, speaking to the entire engineering organization of a bit over 300 people – and I was grateful they had enough trust in me to say yes and let me say what I wanted sight unseen.

There is of course a context in which I wrote this that deeply influenced what I chose to say: the audience is this specific group of people in this moment. This talk might not be something you need to hear or want to hear.

I’ll set some scene here. The industry is health-care adjacent. A software startup has recently been merged alongside enterprise companies that are not software startups at all. There is great discomfort on the non-startup side of the company about the changes they see in engineering. They just got access to Claude and were told in an earlier all-hands that it was somebody’s opinion that if they didn’t know how to use these tools they’d be unemployable.

Meanwhile, on the startup side, the engineers have been using LLM coding tools with open eyes for some time and are well aware of what they can do and what they can’t, well aware that the economic issues are going to be sticky, that this is not general AI, and that running inference and training models is destroying the environment. My team’s nickname for Claude is “the shoggoth” (thank you, James). We know the ride is going to be bumpy.

We also know that something really interesting happened in January, when Anthropic released Claude Opus 4.6, and that Claude got a lot better. It turned a corner in a way that is deep. If you are basing your opinion on anything you did before then, you need to retest and reconsider your opinion. Also: this technology is not going away.

In the middle of this mess: a talk. For me, the subtext is taking care of my people.

(here we might see a link to a video recording of me delivering the talk soon)

What follows is a blog version of the talk, drawn from the prose drafts I wrote, mashed up with my final slides and speaker notes. It includes material I cut for time. At one point I start using “Claude” as my word for “LLM tools”. You can fill in whichever tool you use there – we use Claude Code at my employer, so that’s the name I used.

Two shocks

Hello! It’s nice to talk to you again. Most of you have heard from me recently in my mode as manager of the core platform team. My title is officially “principal engineer”, however, and it’s nice to be able to wear the principal engineer’s hat now and then. I’m doing that today. When I wear this hat, I get to share things I know about this job with the people around me, which I think is important. I’ve been doing this for more than 30 years, so I’ve learned a few things along the way.

In particular, today I want to share with you some things I’ve been thinking recently about what’s been going on around us with our profession. I’m going to get a little philosophical, but I’m also going to give some advice, and hopefully I’ll have something useful to say to everybody in this room, not just engineers. Okay, ready?

Let’s talk about future shock. Alvin Toffler coined the term in a 1965 article for Horizon magazine, then wrote a book with that title in 1970, elaborating on the idea.

“With future shock you stay in one place but your own culture changes so rapidly that it has the same disorienting effect as going to another culture” —Alvin Toffler, 1970

It’s no coincidence that the 1960s moved somebody to reflect on this concept, because that decade featured a lot of drastic cultural change in a short amount of time. It went from suits and ties and short hair in 1960 to beards and long hair and the counter-culture in 1970. Americans sure felt the cultural whiplash.

I think we’re seeing two kinds of culture shock happening at our company right now. We’re getting a double dose.

First, there’s the shock of two different engineering cultures meeting. We use different operating systems. We use different programming languages. We use different words for “person who writes software”: developer vs engineer.

These are surface details that signal deeper cultural divides underneath: Silicon Valley startup culture versus enterprise software culture. In the country I come from, engineers have status and power. We expect transparency and flat hierarchies. We move fast. We set out to change the world and we expect to do it sometimes. We don’t look at a comfortable established business and say, “looks great to me!” We push. And to people from the outside, that pushiness sometimes gets a far less polite label.

But even with these two foreign countries meeting, this isn’t the big culture shock. The big culture shock– the one that’s really the future shock– is hitting both sets of strangers.

Programming culture is changing around all of us, rapidly. We didn’t ask for it. We didn’t do anything to cause it. Our culture simply changed on us. LLM coding tools arrived, and changed our profession.

What I want to do today is give you all a way to cope with this shock by putting another frame around it, and give us all another way to look at it. Technological change has happened before, and is going to happen again, and we have some patterns to apply. I know one metaphor people have been using is that it’s the biggest change since compilers, and yeah, it is. But I don’t think that gets at how disruptive this is going to be.

I think generative AI is the Industrial Revolution of computing, with all the implications you can imagine from that.

It’ll cause unpredictable and large economic change.
The software industry will be permanently changed.
Certain categories of jobs will vanish, and others appear.
The timescale will be vastly more compressed.
We sure are burning a lot of coal. (It’s environmentally destructive.)

Economic upheaval comes hand-in-hand with misery, of course. The word Dickensian exists to remind us how bad the real Industrial Revolution got. We’ll see some of this, too.

Because we’re in the middle of this transformation, I can’t predict where it’s going to land. I’m not a futurist. This is one of the reasons it’s causing so much anxiety, of course.

So your feelings are real. The shock and anxiety are real. You’re reacting to something that is in fact shocking. If you feel an urge to slow it down, or pretend it’s not happening, I get it. I also really get the impulse to respond like it’s another silly VC hype-fest like cryptocurrency or blockchain whatever: a stupid trend you can wait out.

And yes, there’s fear in the air. You’ve heard that if you don’t learn these tools, you’ll be unemployable. That sounds pretty awful to me. What if none of us have jobs at the end of this?

Here’s what I know about history. The industrial revolution didn’t eliminate human labor. It changed what human labor meant. Human labor still mattered at the end of it. The people who adapt to major technological shifts don’t just survive—they become more valuable, not less.

This technological shift is changing what developing software means.

I think the genie of LLMs has escaped the bottle, just like the genie of the Internet had by 2000. The concept of the Internet – of connecting all the world’s computers – survived the dot-com collapse and the popping of a hundred badly-conceived business bubbles. You can get groceries delivered today, by companies who understand logistics the way Webvan did not in 2000.

Gen AI and large language models will survive whatever happens to any specific company or any funding bubble. I have my own bets on which players will survive and which will fail – incredibly destructively – but whatever happens, the concept will stay with us, more sensibly and sustainably. Forever.

I’m here to tell you it’ll be okay. You are smart. You can adapt. I believe in you.

Now I’m going to share with you what I think you should do.

So if we’re living through an industrial revolution… How do you survive one? You learn to use the new tools. You learn what they’re good for and what they’re not good for. And then you do things that were never possible before.

(Look, it’s obvious. You go steampunk.)

What I’m going to do now is spin this entire discussion around. I want to change the frame that everybody puts on these tools. Claude is not a parrot for churning out thousands of lines of code and making programmers obsolete. Not even close. I’ll tell you what it is instead.

The reframe

Claude is a bicycle of the mind.

No more, and no less, just like a computer is. It’s more accessible, because the interface is human language, not a programming language. Today’s computers are orders of magnitude more capable than the computers Jobs was talking about. Put those two things together, and you have the revolution. But it’s still the same thing at heart: an amplifier for the human mind.

It amplifies your capabilities.
The more capable you are, the more is amplified.
It can amplify disasters as well as successes.
Your blast radius is larger, for good and for ill.

It is a personal amplifier, not a generic one. It’s my bicycle, and I’m the one riding it, going further because of the amplification. I still have to pedal! The bicycle goes in the direction I choose! But I’m going further and more efficiently than I could on foot.

When Steve Jobs said we were at the very early stages of this tool, and that the enormous changes were nothing compared to what’s coming, he didn’t know what shape it would take – he couldn’t. But I think this is another one of those leaps forward. The bicycle of the mind is more powerful than it was, and that’s still what it is.

Try some things

Here are some of the things it can amplify your ability to do.

Researching new topics.
Spiking on potential ideas.
Searching an entire corporate knowledge system.
Revising your product requirements doc.
Refactoring a large codebase.
Validating work through review and testing.
And yes, implementing features.

It’s not about 20x the number of lines of code you write, though you can do that. It’s about doing things you wouldn’t have attempted at all.

A refactoring you’d never have had time for.
An analysis you’d never have bothered with.
A prototype you’d never have built.

Yes, you go faster at existing tasks, but more importantly, the tool expands what’s possible for you. You can ride a century on a bike and be back for dinner.

The amplification goes beyond software, of course, and we’ll get better at using the tools to do things beyond writing code. These are large language models. They amplify our ability to do interesting things to whatever we can represent as text. Code just happens to be text, so it’s where we started.

Representing information as text-like-things is the underlying concept of the digital era. Your ability to manipulate any data at all has just been amplified. The implications are profound and I don’t think they’ve fully sunk in everywhere yet. I’m still reeling about this one.

If the medium is the message, the medium of the LLM is all information. Eventually.

Would you like to know what I think about this? Well, if you know me, you might be able to guess.

I think this is unbelievably awesome.

I love writing software. Claude Code is the best tool for thinking about software and writing software I’ve used in my life. The ability to write software to manipulate data is power. Claude extends my power unimaginably far. And know this: my skill set is critical to this extension. Everything I’ve learned over my career matters.

I’ve been doing this for nearly thirty-five years, and this is the most exciting time to write software I’ve seen. Yes, there are pleasures lost here. I love the flow state of writing code, just like I love printing black and white photographs in the darkroom. I don’t have to lose either one. I can still do both for pleasure. Black and white photography isn’t part of anybody’s journalism workflow any more, but people still do it. There’s a place for it all.

I’ll say one thing further, sincerely. My employer right now is a fantastic place to experience this change. We’ve had access to these tools since the beginning, when they were honestly terrible. We have access to the best of the tools today. We have leadership that wants us to take advantage of these tools pragmatically, in whatever way makes sense, not blindly demanding that we use them or else. We are encouraged to experiment and share the results of our experimentation. So my theory is: dive in. Take advantage of this opportunity. Learn some things. Figure it out here, because this is great.

(Psst! Take advantage of this. It’s a resume bonanza. Don’t tell anyone I said this.)

The advice

Let’s move into some practical advice for people in the virtual Zoom room. I’m going to make some suggestions and predictions next, for:

engineers
QA people
managers
product designers
executive types
the whole organization

These suggestions will be my best ideas for today. If they’re bad ideas in a year, that’s fine. Things are changing fast.

If this all just happened to you, if you’re on a Windows/.NET stack and none of these tools feel familiar yet, that’s not a failing. The tools are newer in your world. The learning curve is real. My team has been working on ways to use these tools effectively for nearly a year now. We have a big head start.

Remember this: your underlying skills—understanding systems, debugging, thinking about edge cases—those transfer completely. Everything you know about how to do your job is immediately useful.

Here’s one more thing I want to say before I go into advice. Being told to use a tool you don’t understand, on a timeline you didn’t choose, is terrible. I know. I see you.

The way through is together: pair with someone who’s further along. Ask for help. That’s strength, not weakness. You will have to do the work, but you won’t do it alone.

Advice for everybody

Start using Claude Code today.

You do not need to ask permission.
You already have permission.
Use it for whatever work you’re doing.
If anybody tells you not to use it, they’re wrong.

Somebody saying “I think that might not work here exactly; try this instead” is saying something different from “don’t use it.” If somebody is saying not to use it, we need to talk to that person.

Go for it.

Try Claude in the terminal.

The experience embedded in IDEs feels limited in comparison, particularly for context management. This might change some day, but right now, the terminal shows you more and gives you customization options you don’t have in IDE chat windows. I know that the terminal is an adjustment for some of us, particularly if you are new to MacOS or Linux: there is no version that works with PowerShell as I write this. However, I strongly suggest powering through this learning curve. You won’t get this capability any other way.

Here’s a warning for everybody. We’ve already learned what happens when we trust the LLM without verifying, even with good intentions. The tools make it easy to produce a lot of code fast. They do not make it safe to skip evaluating what it did. Nobody is exempt. Don’t make our security team have to file disclosure reports, or clean up our messes.

Two facts:

We are responsible for what we ship.
We can’t skip evaluating the work.

We all have large blast radii and we need to find a way to make our amplified selves safer than they are right now.

Claude is not magical. You must tell it:

why you are doing something
who you’re doing it for
the values you bring to choosing trade-offs
the business value of the work
how quality is defined, or what done looks like

This is why humans will always be present in the loop. Let me say it again: you will always be in the loop to tell Claude why.

Advice to engineers

All eyes are on you, and you probably feel the pressure. So get creative! Writing code is not the only thing to do! It’s not even the most important thing!

I’m going to tell you the world’s biggest secret about writing software. Are you ready? Here it is.

The hard part of writing software has never ever been about typing the code. The world thinks this is what we spend all our time doing; LeetCode interviews spend all their time testing for this; and it’s the thing I think is least important when I’m hiring people and when I’m trying to fix software development workflows.

The hard parts go like this:

talking > thinking > typing

in order of importance, volume, and difficulty.

We’ve automated away the easy part—the typing—and some of the thinking. But you can never automate away the talking and decision-making. Humans will always have to do this. Developing software is a multidisciplinary team sport. This is where creativity and skill come in. These tools contain no machine intelligence – not yet, anyway. It’s still just a bicycle, and it doesn’t go anywhere interesting unless you’re steering it and pushing the pedals.

Okay, so now we’re typing code at truly scary speeds. Why aren’t we shipping more software?

Ask where the bottlenecks are now that the typing part is faster. Do we just have engineers sitting idle and frustrated faster than ever? Look upstream and downstream.

Upstream: are product decisions happening fast enough?
Downstream: can you ship what you build? Can you test it?
Identify obstacles. Work with the rest of your organization to remove them.

This is probably where you think I’m about to tell you that writing great specs is where it’s at these days, and yeah, great specs help. Garbage in, garbage out will always be a valid maxim. But honestly, I think we’re past “write great specs” as being your number one engineering job as of Opus 4.6. We’re now at a place where agent orchestration and brainstorming skills mean that Claude can work with you to produce that full specification. You definitely need to provide all the information that comes from the humans-talking phase of spec-writing plus some of your thinking work. Your own hard-won skills can skip over quite a lot of the thinking and back and forth: I do quite a lot of telling Claude exactly what I already know a solution is shaped like.

You will work with Claude to write that spec, and then Claude will use its own spec to do the work.

Your skills as an engineer matter intensely, by the way. If you don’t know:

the criteria for decomposing software into modules, you’ll have bad module boundaries.
how to threat-model, your software will have security flaws.
how important error handling is, it will be error-prone.
how to make software resilient, it will be fragile.
how to identify edge cases, they won’t be handled.

This is why product managers aren’t vibe-coding production software, bless their hearts.

What about the less-experienced programmers among us? We have a responsibility to them, in my opinion. I mean, where do people think senior programmers come from? This is, as best as I have seen through the years, a profession we learn through apprenticeship and mentoring. It takes around ten years to turn a programmer with some decent skills into an engineer you can trust to ship production systems. (I’ve seen some people learn a lot faster. I envy them.)

I think that we, like any specialized athlete, need to build on a base of core strength. We need to do foundational exercises before we do the specialized ones. We have to know what programming is ourselves, what good architecture is, and all the things I mentioned above, and we have to learn those by doing them. If we don’t know what those are, we cannot evaluate what our LLM has done with them, or request that our LLM does them, or catch it when it short-cuts on doing them.

So if you are just starting out or want to gain more experience for whatever reason, pair program with more experienced people. Pair-programming has the highest information transfer rate of any activity I’ve ever done. It’s monstrously good at leveling people up.

Ask Claude to teach you things. You don’t have to ride a fully electrified bicycle. You can ask Claude to structure a task so that it coaches you through it, or sets you progressively more challenging tasks in a programming language, or with a concept. Have Claude walk you through one of the past years of Advent of Code, with hints when you get stuck. It’s pretty good at this! Don’t be just a passive user of this thing. Engage with it and see what you can make it give you. You might find yourself delighted.

And turning this around, if you have a staff-and-up title, leveling up the people around you is part of your job. Set up office hours. Say yes when somebody on your team asks to pair-program with you on a problem. This is one of the most fun parts of my job, far more fun than all the management paperwork.

Pair program to learn how to use these tools. Watch another Claude user use it their way. Have them talk you through what they do, which plugins they use, how they think about it. Then swap, and show them what you do! Lift each other up. One of us built a great screencast tool to share sessions: watch some! Learn from the smart people you work with! (Pro tip: I think you’re smart and I want to learn from you. This is not BS. I have learned from every single colleague I’ve ever spent time with.)

Above all else be an engineer!

Humans are tool builders. That’s what programming is. Trick out your bicycle.

Are you a witch or aren’t you, Hermione? Cast the spell! —Ronald Weasley

Advice to QA people

You’re engineers! Everything I just said applies to you. Claude amplifies your abilities too.

Specifically, I think you should leverage Claude to sharpen your work.

Code analysis, risk analysis: use Claude to target your scarce attention on areas that need testing more than others.
Implement testing you’ve been putting off.
Use Claude to turn specifications into test suites.
Use Claude to write missing specs from the code. The specs might be wrong in some places, but at least they exist.

A call to action for QA: You have a unique viewpoint. We need that viewpoint to balance out product design and engineering. If they’re writing more specs and shipping more product, you had better be out there being pessimistic at equal volume. Your ability to break things needs to be amplified too, or we’ll ship bad work.

Advice to managers

Now I take off my principal engineer hat and put on my manager hat. It’s real talk time, colleagues. I think we need to be more scared than our people are, because I think the manager’s role is the one that is going to transform the most.

Think about the systemic effects of development teams being single engineers with groups of agents. Think about what changes when one person is capable of doing all of the implementation work for a complex project in a shorter time than you thought possible. This is what keeps me up at night the most. What’s going to change when everybody is going this fast?

You will no longer be involved in that project in the small. You won’t be thinking about process, control, decision-making, sprints, sprint tasks.

You will be thinking about enabling that engineer to act in the large: career-building, delegation, trust, teaching the kinds of coordination skills that engineer will need to move fast. You’ll want your people operating as autonomously as you can enable them to act, and you’ll be coordinating things yourself at the project level. This is what I’m doing with my team today, and I think many other teams are not far away from this.

I return to this metaphor often through the years: the best role for a manager is as support. You’re a curling sweeper, clearing the ice in front of the stone for your people.

If you’re a tech-lead-flavored manager, you are the ideal engineer today. Every engineer today is a tech lead for a team that includes them + agents, and you already have the project-management and coordination skill sets that many engineers will need to learn. You might be too valuable as an engineer to stay as a manager. (I’m not sure if that’s good news or bad news for you. I guess it depends on how you feel about management right now.)

Learn and observe; don’t prescribe. Things are changing too rapidly for you to standardize on any processes prematurely. Avoid building process debt that will slow people down the moment anything changes, and it will change, I guarantee you, and more rapidly than you expect. Instead, learn to use the tools and identify the problems that need solving. You see things engineers don’t, because you’re above the fray and watching your whole team work. Use that.

Here are some creative LLM uses for managers to try:

Automate your busywork? Eliminate your busywork!
Write job descriptions by having Claude interview you first about what you need. Then write the job description based on what you learned.
Do the same for your interview script. (You interview using a script to reduce bias, right?)
Have Claude collect your employee brag files for upcoming review cycles. Goodbye recency bias.
Synthesize information across teams and spot coordination gaps.
Have Claude fix your calendar. (I had Claude do this the other day. It lectured me about maker mode vs manager mode. It chided me. It was awful, and I had to screenshot my calendar to do it, but my days are a lot better now.)

The theme of all of the above: Claude is a free personal assistant, the one your company will never hire for you, but whom you still need desperately.

A call to action for managers:

Give your team the breathing room to learn.
Protect their time for experimenting with Claude.
Promote sharing tips and tricks.
Be encouraging.
This investment will pay off.

Advice to product managers

Stop trying to be engineers: writing code is not the hard part. I have a 35-year head start on you, and you aren’t going to catch up. Instead, lean into what makes you distinct from engineering, and use Claude to extend your ability to do what makes you special.

Let go of the processes of the past. The sprint is a thing of the past, and you can no more run engineering than managers can. Product development will happen faster than that. You will not be handing engineers sprint tasks. You will be giving them product goals.

Write amazing specs/PRDs/whatever you want to call them. Broaden your research. Improve your product specifications. Use Claude to analyze weaknesses and improve them. You no longer have an excuse for hasty work or incomplete spec. Include those wireframes, those interaction sketches. Write that persona description. And yes, do that prototype that runs on your laptop to show off how it works with mock data.

Focus on information transfer to engineering. I cannot say this one often enough. What you want to work on is aligning with the engineers working on your products so tightly that they will finish your sentences for you when you’re talking about the product you’re working on together.

The reality is that products are too complex for any one person to make all the decisions on. There are hundreds of edge cases you won’t think of, error conditions you don’t want to slog through, and variations on UX interactions that need to be made to work. You rely on other people making those decisions the same way you would. In the future, you will rely on a handful of people instructing LLMs to make those decisions the way you would. They need to know what’s in your head.

The people executing the mission must fully understand the mission. Your product specs are the specs we need to be sweating on right now – or feel free to substitute in whatever you call the document you use to transfer information to engineering. The quality of that information transfer is maybe even more critical than it’s ever been, and it has always been critical.

Align with engineering as fully as possible about what you’re building, why you’re building it, and who it’s for. Claude is going to make them too fast to align along the way. Do it up front.

Advice for upper management

You should be using Claude too. Yes, you.
Learn the tools yourself, and understand why this is a revolution, not business as usual.
Explode the obstacles in front of your organization and let it move.
Promote experimentation.
You need the amplification it brings your company. Your competitors are already doing it.

Here’s a call to action for the whole organization:

Connect all corporate information. All of it. Make all of it accessible to Claude. Slack, GitHub, Notion, Jira, the on-call incident system, Grafana, calendars, email, anything. Make everything accessible to Claude, so you can do everything described above. (I’d like not to have to do a few clever things to get my calendar into Claude.) Allow every workflow to be transformed. Allow all information to be fed into the transformations. Rethink everything.

But what about security? Yes, there are genuine security constraints, especially in healthcare. But “we need to be careful” is different from “we can’t move at all.” If security requirements are making this impossible, that’s a problem to solve, not a reason to stop.

If we’re not doing this, our competitors are. Assume that we’re already falling behind.

At long last, a conclusion

The industrial revolution took decades. We won’t have that luxury. This is going to take a handful of years at best. (Disclaimer: I don’t know. My futurism qualifications are nil.) But I know that I want to be here with the tools in my hands, building whatever comes next. I’m not done yet; I want another 35 years of doing this! That is where I’ve always wanted to be, and why I’ve worked where I have through my career: at startups, on the bleeding edge.

This is opportunity. That’s my startup mindset, anyway.

None of us know where this is going to end up. I am making a few informed guesses here. It will change more and faster before it settles.

But know that the human is still in the loop. It’s you on that bicycle of the mind. It’s you being amplified by the tool. Make yourself worth amplifying.

You can choose whether you’re a power chord or a buzzing string.

Many thanks to Chris Dickinson for coal and condors.