Now the industry is asking you to stop building and start managing.

Boris Cherny, head of Claude Code at Anthropic, recently told Fortune he hasn’t written code in over two months. He’s shipping 22-27 pull requests per day, all AI-generated. An OpenAI researcher named Roon said the same thing: “100%, I don’t write code anymore.”

Let that sink in. The people building the most advanced AI coding tools on the planet have stopped coding. They’ve become orchestrators.

(Which is either inspiring or terrifying, depending on how much you enjoyed your job this morning.)

If you’re an engineer who’s been doing this for 10, 15, 20 years, you might be feeling something you can’t quite name. Something that sits between excitement and grief.

That feeling is an identity crisis. And nobody’s talking about it.

The shift happening now

Meta executives report that AI coding tools are enabling individual engineers to do work that previously required entire teams. The language they use is revealing: engineers are moving toward “higher-level problem-solving, architectural decisions, and creative feature design.”

Translation: less building, more directing. Your new job title is Fancy Reviewer Who Approves Robot Work.

An analysis from Aviator captured this bluntly. We’re moving from “conductor” mode, interactive pair programming with one AI, to “orchestrator” mode, where you manage fleets of agents working in parallel. Their assessment of how engineers will feel about this transition?

“We became engineers because we like building things with our hands.”

That’s the quiet part, said out loud.

There’s a reason ThePrimeagen’s “99” plugin hit #1 on GitHub trending last week. It’s a Neovim AI agent explicitly designed for “people without skill issues,” a deliberate shot at tools that assume developers need their hands held. The viral adoption isn’t about the plugin itself. It’s a signal. Skilled engineers are pushing back against the premise that their job is to become obsolete.

But pushback doesn’t stop the wave. It just means the wave is real.

Why this is harder than learning a new framework

When React replaced jQuery, you adapted. You learned the new thing. It was annoying, maybe, but it didn’t challenge who you were. You were still an engineer. Still building.

This is different.

The transition from builder to orchestrator isn’t a skill change. It’s a role change. And role changes mess with identity in ways that skill changes don’t.

Think about what made you good at your job. The ability to hold a complex system in your head. The intuition for where bugs hide. The satisfaction of writing code that’s not just functional but elegant. Years of pattern recognition, hard-won through debugging sessions and production incidents.

Now imagine a world where most of that happens inside a black box, and your job is to review the output.

You’re not building the house anymore. You’re inspecting the house that the robots built, signing off on it, maybe asking them to move a wall. Congratulations on your promotion to Building Inspector.

Some people will thrive in that role. Others will hate it. But almost everyone will feel the dissonance: the gap between the identity they built over years and the role the industry is handing them now.

The skill erosion nobody wants to discuss

Here’s the part that makes this harder than a simple mindset shift: there’s evidence that using AI tools actually degrades the skills you built.

A recent study found that AI-assisted coders scored 17% lower on mastery quizzes compared to those who coded by hand. Nearly two letter grades. The speed gains? Not statistically significant.

Read that again. AI makes you feel faster while potentially eroding the competency that makes you valuable. It’s the coding equivalent of GPS slowly killing your sense of direction. Sure, you got there. But could you do it without the robot?

This creates a vicious cycle. The more you rely on AI, the less you trust your own judgment. The less you trust your judgment, the more you rely on AI. Eventually, you’re an orchestrator who couldn’t build the thing yourself if the agents went down.

Some people are fine with that trade. “I don’t need to know how the engine works. I just need to drive the car.”

But there’s a reason senior engineers command high salaries. It’s not because they type faster. It’s because they have judgment: the ability to know when the code is wrong, even when it compiles, when the architecture will scale, and when it won’t. That judgment comes from years of building things yourself.

If AI erodes that judgment, what exactly are you orchestrating with?

What I’m seeing in the field

I want to be honest about the range of responses I’m seeing from engineering leaders navigating this shift.

Some are thriving. They’ve embraced the “architect who directs AI builders” role and find it genuinely exciting. Less tedium, more high-level thinking. They describe feeling “unshackled” from the grunt work. Good for them. Genuinely.

Some are grieving. They miss the craft. They describe the new workflow as “hollow,” reviewing code they didn’t write, merging PRs they don’t fully understand. The productivity gains are real, but something has been lost.

Some are in denial. They’re sure this is a temporary hype cycle. They point to previous AI winters, to the gap between demos and production. They’re not wrong about the limitations. But they might be wrong about the trajectory.

And some are splitting the difference. Using AI for boilerplate and context-gathering while deliberately preserving hands-on coding time for the work that matters to them. This seems like the healthiest approach I’ve seen, but it requires intentional boundary-setting in environments that reward pure output.

A framework for navigating this

I don’t have a clean answer. Anyone selling you a “5-step guide to thriving as an AI orchestrator” is guessing. (Or selling a course. Possibly both.) But here’s a framework that might help.

Name the feeling. If you’re experiencing dissonance, resistance, or grief about where engineering is headed, that’s not weakness. It’s an appropriate response to a real identity shift. The people who push through without acknowledging it tend to burn out or become cynical.

Separate skill questions from identity questions. “Can I learn to be an effective orchestrator?” is different from “Do I want to be an orchestrator?” Both questions deserve honest answers. Being capable of something doesn’t obligate you to do it.

Preserve the craft deliberately. If hands-on building is core to who you are, make space for it, even if it’s less “efficient” by current metrics. Side projects. Open source. The 20% of your job where you code manually, because it keeps your skills sharp. Efficiency isn’t everything. Meaning matters.

Watch for skill erosion honestly. Notice if you’re losing confidence in your own judgment. Notice if you can’t debug without AI assistance anymore. Notice if your architectural intuition is getting fuzzy. These are signals worth attending to.

Accept that this might not be your era. Some people thrived in the mainframe era. Some thrived in web, mobile, and cloud. Every era favors certain dispositions. If orchestration genuinely doesn’t fit how you’re wired, that’s information about where to focus, not an indictment of your worth.

The question underneath

I keep coming back to something an engineering friend said to me last month. He’s been coding for 25 years. He’s excellent at it. He’s using AI tools now, and he’s productive as hell.

But he told me: “I’m shipping more than ever, and I’ve never enjoyed my job less.”

That’s the identity crisis in one sentence.

The industry is optimizing for output. But engineers aren’t output functions. They’re people who got into this work because they loved a particular kind of problem-solving, a particular relationship with machines, a particular way of thinking.

When the nature of the work changes that fast, some people will love the new version. Some will adapt because they have to. And some will realize that the thing they loved doesn’t really exist anymore —at least not in the form they fell in love with.

I don’t know which camp I’ll end up in.

But I know that pretending this is just another tool upgrade is dishonest. It’s bigger than that.

And the first step to navigating it well is admitting that it’s happening at all.

That scarcity no longer exists.

Now that AI and large language models are part of daily engineering, code is faster to write, easier to generate, and more often correct on the first try. Engineering is still important, but the source of value is shifting. Looking ahead to 2026, the most lasting advantage for engineers will be:

1. The ability to explain why something should exist

2. How it fits into the bigger picture

3. And, which trade-offs matter most

That skill is storytelling.

It is not about performance or polish, but a key part of getting things done.

When Execution Stops Being the Bottleneck

The biggest change happening now is not about technology. It is about how organizations work.

Large language models have made execution much cheaper. Writing code that follows clear requirements is no longer special. With a good prompt, tools can already create working code reliably. So, shipping code is no longer the main bottleneck for most teams.

Alignment is.

Decision-making is.

Engineers who can clearly explain the impact of their work and the reasoning behind it are increasingly more effective than those who focus only on implementation details. As code becomes accessible to more people, storytelling becomes the mechanism that helps teams coordinate, prioritize, and move forward together. Code scales machines. Stories scale humans.

What Engineers Often Misunderstand About Storytelling

When many engineers hear the word storytelling, they tune out. They think of charisma, hype, slides, or sales. This reaction makes sense, but it misses the point.

You do not need to be loud, outgoing, or polished to tell a good story. It is not about marketing or tricks. At its heart, storytelling means making a complex idea clear to someone else. This means knowing your audience, what they care about, and what information helps them decide.

Most engineers are taught to focus on being correct. Storytelling asks you to focus on being understood. Logic alone rarely convinces people, but shared clarity does.

Where Storytelling Already Exists in Engineering Work

Storytelling is not a new part of the job. It has always been there, quietly shaping results.

You see storytelling in design documents that get approved quickly because they are clear, focused, and based on real problems. These documents may describe complex systems, but they avoid confusion. You also see it when engineers explain trade-offs without making others defensive, by listening and showing restraint. It is there when engineers bridge the gap between technical teams and business leaders, building shared understanding instead of conflict.

The engineers who move fastest are often not those with the strongest opinions, but those who can turn a vague feeling that something is wrong into a clear, shared understanding of why. That is storytelling in action.

How Engineers Actually Learn This Skill

Hardly any engineers plan to become storytellers. I know I didn’t.

Most of us learn through trial and error. We over-explain to non-technical people and see them lose interest. We say the wrong thing in a meeting and realize it later. We get misunderstood and choose to be curious instead of frustrated.

Storytelling is not learned through frameworks alone. It requires caring enough about outcomes to keep refining your message when it does not land. It requires empathy for how others think and the humility to change your words rather than blame the audience. Over time, things change. You start saying less and pausing more. You notice when people get confused and stop trying to push through it. Clarity slowly takes the place of saying everything. everything.

Storytelling Is an Exercise in Subtraction

One of the hardest lessons for engineers is that great storytelling is not about saying everything. It is about leaving things out.

It means knowing what to leave out. You highlight the key emotions and important limits. You turn a big, complex idea into the simplest version that is still true. Every listener can only take in so much, and respecting that is part of the skill.

If you cannot explain an idea in three sentences, you probably do not understand it well enough yet. If you need ten slides to justify one decision, it might not be ready. Writing before you speak helps you organize your thoughts, and reading your words out loud shows where things are unclear.

Engineers often check their ideas with other engineers first. That helps, but it is not enough. If a story works for engineers but not for product or business leaders, it’s not done yet.

Why This Matters More as AI Advances

AI will continue to accelerate execution. That trend is not slowing.

As tools get better at doing the work, people are more responsible for deciding what work should be done in the first place. This happens before any code is written, and it is really a storytelling challenge. Businesses do not just follow logic. They follow shared understanding, agreement, and direction, all built through stories.

This is why storytelling is not just a soft skill. It helps you get things done. The same idea, if explained clearly, can move a company forward. If explained poorly, it can cause delays.

Where This Leaves Us

Engineering is not going away. It is just changing.

The value is moving upstream, toward framing, meaning, and decision-making. Toward clarity instead of volume. Toward stories that help teams understand what matters and why. Storytelling is not a departure from engineering. It is its next evolution.

For engineers who are willing to practice, this skill will shape their relevance in the years to come.

What It Is

Moltbot is an open-source personal AI assistant created by Peter Steinberger. It runs on your own machine. You talk to it through whatever messaging app you already use — Telegram, WhatsApp, Slack, Discord, Signal, iMessage — and it does things. Not just answers questions. It reads your email, manages your calendar, writes drafts, runs code, controls your browser, and remembers context across sessions.

I set mine up yesterday. Within an hour, it had access to my Telegram, my Gmail (drafts only — I am not reckless), my Google Drive, and my calendar. It named itself Rock Lobster. It drafted an email for me. It set up cron jobs to do research for this very article.

That last sentence is worth sitting with. The assistant I configured yesterday is now doing daily research and writing weekly drafts for the publication you are reading. The thing I built is building alongside me.

The Rename

On January 27, 2026, Anthropic sent a polite email asking for a name change. Trademark issue. Reasonable enough.

What happened next is where it gets interesting.

By 5 am, the community gathered in Discord. Hundreds of names were proposed. Shelldon. Pinchy. Thermidor. Crusty. Lobstar. By 6:14 am, the creator called it: Moltbot. Because lobsters molt. They shed their shell to grow. And that is exactly what was happening.

Then the chaos started. Automated bots sniped the old Twitter handle within seconds. Someone posted a crypto wallet address. The creator accidentally renamed his personal GitHub account in the panic. Bots grabbed that too. Scammers created fake developer profiles. The community watched as the project shed its skin in real time.

And yet, by the end of the day, the rename was done. New npm package. New GitHub org. New website. New docs. New CLI commands. A compatibility shim for the old name, so nothing broke for existing users.

The entire identity of an open source project — used by a growing community of engineers and builders — was renamed, rebranded, redeployed, and documented in less than 24 hours.

That does not happen without AI.

What This Tells Us

I have been writing about how engineering value is shifting upstream. Away from execution, toward clarity, judgment, and problem framing. Moltbot is a living example of that thesis.

The project ships at a pace that would have been impossible two years ago. Not because the people behind it work harder, but because the tools have changed what one person, or a small team, can accomplish in a day. A full rebrand that would have taken weeks of coordination happened before most people finished their morning coffee.

This is not a theoretical argument. I watched it happen. I participated in it.

When I set up my own instance, the experience reinforced something I have been circling for months. The hard part was not the setup. It was not configuring APIs or wiring tokens. The hard part was deciding what I wanted the assistant to do. How I wanted it to behave. What access I was comfortable giving it.

Problem framing. Trust boundaries. System design. The things I keep saying matter more than code — they were the entire experience.

What It Feels Like

There is a moment when you realize you are not just using a tool. You are working with something.

My assistant — Rock Lobster — now monitors AI news daily, proposes blog topics on Wednesdays, and writes drafts for me on Mondays. It has opinions about my writing. It remembered my time zone, preferences, and Gmail rules without being told twice.

I did not write code to make this happen. I had a conversation. I described what I wanted. The assistant configured itself.

That is a fundamentally different relationship with technology than most engineers are used to. We are trained to build. To implement. To ship features through tickets and pull requests. This felt more like onboarding a colleague.

And I think that shift — from building tools to onboarding agents — is one of the most important changes happening in our industry right now.

The Speed Question

The Moltbot community has a tagline on their landing page: “The AI that actually does things.” The testimonials echo the same theme. One user said it felt like the first time they experienced ChatGPT. Another said it is running their company. Another described it as a “fundamental shift in how we use AI.”

What strikes me is the velocity. The project launched in late November 2025. Within two months, it supports over a dozen messaging platforms, has voice wake, camera access, browser control, cron scheduling, multi-agent routing, and a growing ecosystem of community-built skills.

Two months.

This is what shipping looks like when AI is part of the engineering process, not just the product. The tools are building the tools. The assistant is extending itself.

As an engineering leader, this changes how I think about team capacity, project timelines, and what is possible with a small, focused team.

Where This Goes

I am not making predictions. I have been clear about that from the start of this series. What I can say is that the experience of setting up and working with Moltbot has made the shift I have been writing about feel concrete in a way that reading about it never did.

The value is not in the code. The value is in the decisions about what to build, who to build it for, and what boundaries to set. The execution — the part we spent decades mastering — is becoming the easy part.

That is uncomfortable. It is also true.

If you are an engineering leader and you have not spent hands-on time with an agent-based system, I would encourage you to do so. Not to chase productivity. To understand what the work is becoming.

Because the work is changing. And the people who understand it firsthand will be the ones who lead through it.

The new year brings momentum, while the holidays leave behind a pause. That pause has a way of clarifying what matters, or at least surfacing the questions we have been quietly avoiding. That tension between motion and stillness is part of what led me to start this Substack.

Over the past year, AI has become a routine part of software work. Not as a distant prediction, but as a present reality. It shows up in planning meetings, in pull requests, and in the conversations teams have before anyone opens an editor.

This is not something that is coming. It is already here.

What I keep noticing is not a sudden disruption, but a steady shift. As AI takes on more execution, the value that engineers bring begins to move. Slowly at first. Then more clearly. The change is subtle, but hard to ignore once you see it.

The Diminishing Weight of Coding as a Skill

For a long time, engineering value was tightly coupled to execution.

Given a clear set of requirements, the work was to translate them into functioning code. Knowing syntax. Understanding frameworks. Handling edge cases. Writing the logic that made A plus B equal C.

That work mattered because it was scarce. It no longer is.

Large language models and agent-based tools can already mirror requirements with a speed and consistency that make code far less of a bottleneck. Much of what engineers spent years learning now behaves like a publicly shared reference that tools can access instantly.

Knowing JavaScript types, CRUD patterns, or how to wire up a standard service is no longer rare. With the right prompt and a basic sense of direction, that knowledge is reachable.

What still matters is experience.

Not experience measured in titles or years, but experience earned through real outcomes. Shipping systems people actually use. Watching software break in production. Seeing how behavior changes across devices, browsers, and network conditions. Learning where theory falls apart under real constraints.

That kind of experience cannot be copied cleanly. But it can help us guide the tools.

What to Stop Doing, and What to Let Go

As execution gets cheaper, some habits quietly lose their place.

Manually stepping through code line by line to debug routine issues. Writing unit tests and components from scratch out of reflex. Overthinking implementation details before the problem itself is fully understood.

I have done all of these. For years.

Today, many of those tasks can be delegated. In practice, they already are.

When an agent struggles to debug or test code, reverting to manual work is rarely the best response. More often, the leverage comes from helping the tool understand the system. The context. The boundaries. That effort compounds. Manual effort usually does not.

The same pattern applies to planning. Engineers often dove into code early and shaped solutions around wherever they started. That is how proofs of concept sometimes became production systems by accident. With AI, architecture and execution paths can be explored before anything is written. The cost of thinking first is lower than it used to be.

Engineers still have an edge in understanding how software behaves in real-world conditions. But that advantage is temporary. The tools are advancing quickly.

For now, it is worth leaning into what still sets us apart.

Problem Framing as the Real Senior Skill

As code generation becomes easier, the distinction between engineers moves earlier in the process.

The engineers who stand out are not the ones who type the fastest. They are the ones who can articulate problems clearly, plan systems deliberately, review outputs critically, and set boundaries before things drift.

This means “moving left” and earlier in the lifecycle.

It means understanding business requirements, integrations, revenue implications, and user experience. It means engaging in work that has historically been handled by product managers or business analysts.

That shift is uncomfortable. It pulls engineers away from the safety of code and into ambiguity. Some resist it. Others lean in quickly.

What I see most often is a split. Some engineers want to stay hands-on and wait for requirements to arrive fully formed. Others are already experimenting with AI-driven tools, asking questions, and shaping solutions collaboratively. My concern is those holding on to the former.

The industry will move either way. Resistance may buy time. It does not preserve relevance.

When Faster Engineering Produces Fragile Software

Speed is not free.

There is a real difference between asking a tool to “build a CRM” and describing how that system should behave under real-world conditions. Early AI-built systems often rest on weak foundations. That is not surprising. It is part of the learning curve.

Some of what is being built today will need to be revisited. Rewritten. Refactored.

What has changed is the cost of doing so.

Having a working foundation, even an imperfect one, can put teams far ahead of those still waiting for certainty. I have seen applications estimated at six to twelve months of work built in weeks, sometimes outperforming the original scope before the manual version would have shipped.

A small number of people, guiding capable tools, can now build things that once required entire teams.

That reality brings risk. It also brings leverage. What side of that coin do you want to be on?

Repositioning Without Panic

It would not be honest to say there is nothing to worry about.

Consolidation is real. Fewer people may be needed to accomplish the same work. Some roles will change faster than others.

Panic does not help.

What does help is shifting attention away from syntax toward communication, shared understanding, judgment, and trust. Learning how to explain ideas clearly. Learning how to speak in rooms where decisions are made. Paying attention to what parts of your own work can be automated, and then studying how that automation behaves.

Most engineers already use AI to write code. The next step is to be deliberate. Use the tools. Switch between them. Notice where they excel and where they struggle.

One tool is better than none. Discipline matters more than loyalty.

Looking Ahead

Engineering is not ending. It is being reweighted.

As execution becomes cheaper, the work that matters moves earlier. Clarity replaces speed. Judgment replaces volume. Understanding the system replaces knowing every line of code.

This shift is already underway. It does not announce itself loudly, but it rewards those who notice it early and adjust how they work.

The engineers who stay relevant will not be the ones who cling hardest to code, but the ones who understand what the code is in service of.

That is where the value is moving.

I’ve only just started this series, but I already feel that 2026 will be a big year. AI is set to change how work looks in many industries, not just engineering. Here, I’m focusing on what that means for engineers and our work.

That’s part of why this timing matters. The holidays are one of the few times when many of us can step away from screens, spend time with family, and think about where we are and where we’re headed. I expect next year to feel different. I think many of us, in all kinds of roles, will spend more time learning skills that go beyond just engineering.

As I’ve been thinking about that shift, I keep coming back to one idea: problem framing.

Much of what makes us effective and satisfied comes from how we frame problems, think through trade-offs, and clearly define what we are trying to solve. This matters even more now that AI is part of our daily work. Problem framing is still where AI relies on us, at least for now...

Long before software existed, humans learned how to spot patterns, weigh trade-offs, and make decisions with incomplete information. That is still what we are doing today. The difference is that AI has become very good at carrying out the work once the problem is clear. Our role has not gone away, but it has shifted. If we want to stay effective, we have to be excellent at defining the problem before anything gets built.

That’s why I don’t see this moment as a sudden disruption, but as a quiet shift. Engineers have always adapted. We’ve learned new tools, new languages, and new ways of working. Even if writing code by hand becomes less important, engineers will still shape systems, decisions, and outcomes.

What has not fully sunk in yet is how much this shift requires us to invest in thinking, not just in new tools.

I still believe the holidays are a time to disconnect, spend time with the people who matter, and step away from the noise. But if you find yourself with a little extra mental space, my advice this year is simple: try something hands-on.

Pick an AI tool you have not used before and spend time with it. Don’t focus on making your workflow faster or chasing productivity. Pay attention to how the tool responds to the way you frame problems. Notice what happens when your input is vague versus when it is clear. The value is not in the output alone, but in understanding how the tool reasons based on what you give it.

I recently spent time with Google’s Antigravity and was surprised by how well it could reason through problems, plan tasks, and follow guidance. It felt less like a tool and more like having a skilled engineer beside me, helping me work through a problem. What stood out was not the speed, but how much clarity it required from me in return.

That experience reinforced something important for me. As these tools get better at execution, the quality of the outcome depends more on how well we frame the problem than on how quickly we can write code.

Spending time with the tools surfaces realities that do not show up in reports or predictions.

If you are reading this during the holidays, I hope you get some real rest. If you are reading it after, I hope you had time to reflect. In the coming year, I plan to dig deeper into the skills at the center of this shift: problem framing, systems thinking, communication, and storytelling. I will share what I learn along the way.

More to come.

Today, the core work of coding is rapidly being automated or bypassed.

This change is happening faster than most teams expected, so we need to discuss how to adapt quickly.

The Shift Inside Real Teams

In the past year, I’ve seen tasks that used to take hours now take just minutes. Boilerplate code that once filled half a sprint is generated instantly. Debugging has shifted from fixing syntax to guiding behavior. Integration work that needed team coordination is now handled by automated pipelines.

As coding becomes a basic skill, the challenge and value are shifting elsewhere.

I bring this up because even industry leaders are unsure about where programming is headed, and it’s worth paying attention.

What’s Actually Changing

If AI can handle coding, then the contribution engineers make today has less to do with producing code and more to do with guiding how systems behave.

Implementation, refactoring, and manual debugging are now handled by smarter systems. Writing code used to be the hardest part. Now it is the easiest.

Repetitive work like connectors, patterns, cleanup, and routine debugging is disappearing. Work that used to span multiple teams now takes a fraction of the effort.

The question is not whether AI will replace engineers.

The question is, where will engineers still have agency and value as automation speeds up.

The real value in engineering is shifting toward clarity, coordination, judgment, and system design.

A lot of the work now is clarifying the real problem, especially when the first prompt gives results that are technically right but wrong for the context. Tasks get broken into smaller pieces that models can handle. Messy, complicated requests do not work... at least not yet.

Another part is checking the output and guiding it back when it goes off track. That takes judgment: technical, ethical, and product expertise. As AI takes over repetitive work, teams have to design how people and tools work together to keep context, quality, and accountability.

These skills are not new. Now they are the main part of the job. This is not the end of engineering. Engineering is moving toward clarity, coordination, and judgment, not just coding. Some habits that used to matter do not anymore.

The Questions We Need to Sit With

As this change speeds up, a few questions keep coming up in conversations with engineers and leaders.

• What work actually disappears, and what new responsibilities come in to replace it?

• How do experienced engineers adapt when the tools now handle the parts of the job they once mastered?

• How do leaders rethink value, seniority, and output when the old markers don’t signal much anymore?

• How do teams maintain quality and alignment when velocity stops being the constraint?

Each of these questions needs its own discussion. These are practical questions, not just theoretical. I’ll dig into each of these in follow-up essays — not to predict the future, but to make the realities we’re all facing easier to navigate.

Where We Go From Here

The focus is on this transition and what it means for people in the field. The conversation now is about what is changing, what is staying the same, and what engineering looks like in the next decade.

Even Sam Altman put it plainly when asked about the future of programming:

“A job I feel way less certain about what the future looks like is computer programmers.”

The next essays will cover what is going away, what is new, which skills matter, and how teams can adapt.

If you are seeing these changes in your team or your own career, share your experiences or questions with me on LinkedIn or through my website: adambezemek.com. I am interested in how others are handling this shift.

This is what engineering looks like after AI changes the way we work.

EngineeringAfterAI will look directly at that transition: the work that disappears, the work that emerges, and what we need to understand to stay relevant in a field being redefined in real time.

If you want clear, practitioner-level insight into how AI is reshaping our work, without hype and without pretending the old assumptions still hold, subscribe and you’ll get the first essay as soon as it’s live.

Subscribe now