It is seriously interesting times to be a software engineer. On the one hand, phenomenal cosmic powers. On the other hand, software 3.0, “the end of coding as we know it”, and the very real fear of years — decades — of hard-won experience going out the window.

Let’s assume you are paid to deliver products. Or paid to manage teams trying to do that. What do you do in 2026? How do you respond when your CEO asks you when a competitor will be able to build your product via an LLM? How do you think about your priorities, your teams’ priorities, as they try to balance existing, likely infinite list of tasks, with the transformation that is coming?

Nobody knows for sure — especially not people who are trying to sell you something. I certainly don’t. But what I believe is that soon¹, most² software development will be within the capabilities of coding agents.

Estimate when your existing product, code, or interface will no longer be a moat

Even if — especially if — you’re building on a glorious 20-year history of incredible innovation and industry leading brilliance, stop assuming that answer is “forever” and start putting a real date on when a smart competitor working without your legacy, debt, and foolish decision from 2002 will be able to lap you using a smart team and a commitment to agentic coders.

I believe that by 2027, software engineers will be talking about code the same way they talk about assembly today. In specific cases, engineers will dive into the weeds and the particulars. Coding and software engineering will operate around goals, objectives, algorithms, and experiences.

Sure, it is plausible that your particular math, language, or platform is so bespoke, artisanal, or complex that no LLM will be able to reproduce or accelerate duplication of it, but I would be very careful about that assumption. I asked an OpenAI engineer how long it would be before they just pointed Codex at their “build a web browser”-strategy in October. They chuckled and suggested that was still a ways away. Simon Willison predicted 3 years two weeks ago. It just happened.

Get yourself, your team, and your org to agentic coding table stakes

For the vast majority of software engineering, infra engineering, and product development, it’s likely the following will be positive ROI:

• Code review on all checkins
• Ongoing review, maintenance, and improvements to testing
• Ongoing review, maintenance, and improvements to documentation
• New team member onboarding
• Co-design and co-creation with team members
• Production feature development with both real-time and asynchronous coding agents. Boris might be an extreme example, but not that extreme.

Doing this will ensure you and your team are aware of the current capabilities, have navigated the particulars for your org, and likely surfaced a host of very real challenges around using coding agents in your particular environment.

If you can’t really prove this is ROI positive to your CEO and CFO, use the uncertainty to guide where you have opportunities to improve metrics, o11y, how you measure customer improvement, etc.

Dedicate resources to getting your code in proper shape for agentic development

If you aren’t doing this, know your competitors are. Build systems to create, monitor, and maintain…

• Test coverage. Agents will go off the rails, misunderstand instructions, and cheat. Real, solid testing is your first line of defense here. The good thing is that agents don’t get tired or bored writing test code, so take advantage of that!

• O11y. Seriously. Everything that matters in your system, every user interaction, every service, API call, etc etc etc needs to be getting logged in a way that forces you to describe your system via Service Level Objectives, shift you from watching dashboards to effective alerting, and create a second line of defense for agentic coding. SLOs not only create more context for your agents, they create another acceptance check on regressions.

• Conformance suites. English language descriptions of what a component, system, API, or product are supposed to do. Conformance suites are your third line of defense, create a way to double check tests and SLOs are accurate, have kept up with customer and product changes, and are properly prioritized. Conformance suites also create a path for new engineer — and new agent — onboarding.

• Whatever version of “I test in prod” is right for you and your products. Agentic development means your capacity to transform the experience, meet customer needs, but also seriously disrupt expectations is about to grow beyond either your wildest hopes or fears (depending on whether you have ops in your title). For obvious reasons, just letting all those changes — and the interplay between them — stack up for weeks or months before delivering them on users is both dangerous and deprives you of valuable learning time. So, what is the fastest path to get the most change as close to end users as you can?

Build the moonshot

The good news is that everything in the prior sections should also help existing work. If you’re lucky enough to be a high-growth company, nothing is going to help your 2026 more than improved onboarding that gets new hires fully operational more quickly. If you already have customers and revenue, better test coverage and o11y will improve your ability to prioritize and deliver on their needs. Sure, you’ll send some money to Open.AI, Anthropic, and Google, but a team more comfortable with AI is going to pay dividends.

What’s going to hurt is spinning up the moonshot team. In this context, the moonshot is your best guess at what a competitor is trying to do using AI, LLMs, and agents, with the benefits — and downsides — of all your inside-baseball knowledge, existing customer relationships, and strategic priorities.

How much should you invest? That’s the $64,000 question. More than 5%, less than 20% of your product, infra, product, and design resources? Big enough to feel like a real team, small enough not to cripple your existing work — unless you can already see the competition coming and it’s time to burn the boats.

Key aspects of building a moonshot.

• It can’t become an active retirement community. Don’t just staff it with your most tenured, most senior people. Make it your most dynamic team.
• Enable it to challenge sacred cows, but don’t lose track of your market and key customers. You are specifically trying to disrupt yourself, not build into a open space.
• Have real OKRs. Even for a moonshot that might need 3-6 months to see progress, use OKRs to keep it from being a science project.
• Timed rotation of team members. The Shiny New Thing (tm) is always more fun. Moonshots will seem like science projects no matter how real they are, no matter how many demos. The best antidote is to move people around, to make the moonshot team something team members shift onto for a quarter, half, or year.
• Be willing to have more than one. Moonshots, like risks, fail. Portfolios give you a way to mitigate that risk. Improvements to the status quo give you one alternate path, but if you have the resources, consider multiple red team efforts.

Fear is the mind killer

Even the table stakes aren’t easy for existing orgs. The world of software development is hitting new heights of fear, uncertainty, and doubt. Large changes and risks — especially those that intersect with our identity and livelihood — are incredibly challenging. How do invent the future while also handling all the other pressure and demands on our time, teams, and companies.

Priorities start with goals. As leaders, as CTOs, as companies, none of this will happen if we don’t make optimizing our use of AI a priority. Necessary but not sufficient.

Navigating the identity portion, the “but I’m an engineer and I write code”-part is going to take something else. To me, it’s about mission, what it means to be part of an organization, about what I’m paid to do. I was trying to find the right way to express this and realized it had already happened, spectacularly, in my favorite podcast of 2025: John Cena’s conversation with Bill Simmons.

Cena’s interview starts at the 1:42 mark — it’s a long podcast — and what jumps out again and again is so how singularly focused John Cena is on organizational success, on being a team player. How open he is to be part of something larger, to learning how he fits in.

Of how he was always willing to do the work to succeed in WWE.

The cool thing was I, I essentially failed fast. You know, and I, I was held accountable for my failures. “Kid, obviously this isn’t working.” … I went from wearing boots and tights and carrying my laptop to playing Roller Coaster Tycoon to like, you’re the rap guy. Fine. I’m the rap guy. I’m going to buy my gear in the hood. I’m going to get faded up at the barber shop. I’m going to tell everybody I’m throwing this jersey out tonight. I’m going to wear diamonds and then switch the diamond for a steel chain. I’m going to wear um, five-fingered rings. I’m going to wrestle in sneakers. I’m going to wrestle in jorts. I’m going to wrestle in yellow corduroy and blue sheepskin suits. I’m not gonna look like everybody else. I’m going to make my own music. I’m going to freestyle everyone in the parking lot so they know it’s not rigged and no one’s writing my stuff. I’m going to come out with my own album. We’re going to make music videos. I’m going to do concerts. I’m going to work clubs in between SmackDown and Raw and pay-per-views.

Nothing nothing truly happens until it does. You know, there’s a lot of stuff that can happen between the bell ringing and the bell ringing again, that can change outcomes or whatever. And these are moments, hopefully anyone who’s involved in WWE is, you know, thought about their entire life. And when they happen, it it there probably is a wave of surrealism that comes over them, you know?

I could easily excerpt the whole thing, it’s great. Despite Bill repeatedly trying to get John to take credit for specific decisions, strategy, etc, John every time came back to WWE, his just being part of the business, and his job trying to do the best within the priorities of WWE.

With the exception of a true solo founder or solo maintainer, software engineering is a team sport. And it’s a team sport where the tools have always been changing around us. When I was a baby software engineer, the best computer for solving complex control system questions was an analog one. Digital started taking over in 1990, but it was still often easier to plug in patch cords. The mobile transition at Facebook was — as much as anything — a command line to IDE transition. Pivotal built a whole business on pair programming. Deep learning came along and demolished every prior approach to recognition, classification, and ranking.

LLMs and agentic coding assistants are transforming what it means to create software, what it means to “write code.” It doesn’t change why we are building products or technology.

We’re doing it to solve problems, answer questions, build businesses, and delight our users. I, for one, welcome technology that lets us do that better.