Skip header to navigation
Every few months, software engineering will be over in a few months again. It can’t be, but for reasons you might not expect.
When coming back to work in the beginning of 2026, organizations everywhere were going crazy. So many people, including lots of upper management, had used the winter break to build software with AI and felt that software engineering was over. They had experienced it first-hand. Everything had changed, because look at what they built! Why couldn’t work feel the same?
Their experiences were real, but they happened in isolation. Building software by yourself is orders of magnitude easier than building it in a team, or across multiple teams. The hard problem at work was never just about writing code. Their experiences didn’t reflect the challenges of the organization they worked in.
Organizations aren’t challenging simply because their structure is wrong and they need to fix it. Their structure might be wrong, but every structure is wrong for someone. If you were ever part of a reorg, you probably saw that some people thought it solved the problem, while others thought it made everything worse.
Still, organizations have to structure themselves somehow. Not everyone can know everything and work on everything. So they divide the work into domains, with a team for each domain. Over time, each team builds deep knowledge around its domain and develops a vision for where it should go.
This is good agile software development: people take ownership, plan, build, adjust, and learn from what happens. But those domains are never fully isolated. They overlap or depend on each other, and they keep changing as the product changes.
This ownership model that produces great results is also the main reason why organizational structures are so difficult. It’s hard to give teams a lot of autonomy to materialize their own vision, while also making sure that they don’t create issues for other teams and largely follow the grand vision of the company.
These are the two values autonomy and alignment. We need both values not simply because they are good values to have, but because each one solves a failure mode that the other one creates:
Pure autonomy without alignment results in teams that move fast in incompatible directions. You ship a lot, but it doesn’t add up to anything coherent. Eventually you accumulate so much inconsistency that the organization slows down anyway: integration nightmares, bad user experiences, duplicated work.
Pure alignment without autonomy results in an organization that knows exactly where to go but can barely move. Every decision needs sign-off, every team is blocked waiting for consensus. And after waiting for so long before shipping anything, you learn from your users that you shipped the wrong thing.
Autonomy and alignment are in tension, but this tension is important, even if it feels frustrating. It feels frustrating because the symptoms look like problems we need to fix: the meeting that should have been a Slack message, the RFC nobody reads, the three different date pickers that all don’t work for what you need. Some people ask for more process, trying to create alignment. Others want to strip process away, trying to restore autonomy.
The tension never goes away. It cannot go away. It just moves closer to one of the failure modes.
It’s tempting to use AI to skip the tension that we feel. Instead of talking to another team, we can describe their boundaries to an agent: what it can touch, what it should avoid, what vision it should work towards, and generally how it should behave around their domain.
But when the agent needs a change that crosses these boundaries, it will not negotiate. It doesn’t feel awkward about stepping into someone else’s area. It will work around the boundaries instead. It can easily copy some code from another team, paste it into the area without these boundaries, make the small change there, and move on.
For a senior engineer, that would feel wrong. The consequences are immediately obvious: now you have to maintain that new version, the two versions will diverge over time, and bug fixes will eventually be applied to one version but not the other. This feeling is worse than the discomfort of going through the tension with the other team. So you reach out and explain what you need. And somewhere in that conversation, your work shapes their domain, their context shapes your solution, and the organization becomes slightly more aligned than it was before.
The human feeling is important. It is what makes you stop before turning tension into a bad decision for the organization. It keeps autonomy and alignment in balance.
This matters even more now, because people who couldn’t write code will now want to use AI to contribute more directly. Designers can make adjustments by themselves, Support can replicate bugs and propose fixes. This is a good thing. The organization benefits from it. A lot of work exists because someone understands a problem, writes it down, throws it over a wall, and waits for an engineering team to look at it during a backlog refinement session. We can now lower that wall.
As that wall gets lower, more people will cross into domains they do not fully own. It will no longer only be engineers reaching out to you because they want to change something, but now non-engineers will reach out too. Not because they want you to change something, but because they want to change it themselves. They want autonomy, and by reaching out to you, they create alignment.
That is good. The surprising outcome is that when you give more people the power to act, you force more of these human conversations to happen. It keeps the tension in balance and prevents it from drifting toward one of the failure modes.
They cannot skip the conversation, because if they want autonomy, they need alignment. But your answer also cannot simply be: “you are not allowed to touch this.”
Your job as a software engineer will not disappear, and it will not drastically change because of AI. It will change in the same way that every software engineer’s career changes over time: you will become a better engineer.
Being a better engineer never meant writing more complex or smarter code.
As a good engineer, you know how to move through other teams’ domains without taking ownership away from them. You explain what you need, but you also listen to what the other team is protecting. You adjust your solution around the context you gather. You create alignment while still letting the other team own the decision.
And you bring that same mindset when someone reaches into your domain. You do not just block it, and you do not blindly approve it either. You guide that person through your boundary. You share context about what is safe, what is risky, and why. You listen to their needs and adapt your domain when it reduces future friction or makes contribution easier. And you aren’t nitpicky when a solution works, even if it’s not as elegant as the one you would’ve written.
This is where AI can help you, but not replace you.
Use AI as a tool inside the boundary you’re in. Let it explain code you do not fully understand yet, or a technology your team is adopting. Draft an architecture and let the AI point out risks, compare it to common design patterns, and surface flaws you haven’t seen yet. Use it to understand how the product is used, find answers in analytics data, recognize patterns in user feedback.
This is good use of AI because you’re not asking it to replace your ownership. You are using a tool to become more capable inside your area, so you can make decisions you can stand behind.
You hold yourself to that same standard when you’re crossing into someone else’s boundary. AI can help you prepare: turn a vague need into a clear problem statement, help you understand the tradeoffs, and find the right question to ask before sending that ineffective “I have a problem” DM.
And yes, use AI to be your coding partner whenever you need it. For me, I like to focus on the architecture and plan it out completely. I write the types and interfaces by hand, and let an agent finish the implementation details that are a chore for me: the repetitive plumbing and the stuff I already know how to write but don’t want to. This is what often works for me. I feel that I’m growing as an engineer by sharpening the skills that matter most to me.
This is like the human-in-the-loop pattern, but applied to a whole organization. People use an agent inside their ownership zone, then talk to other people, who use an agent to process that new information inside their ownership zone. The humans are still at the center, they’re just better equipped now.
Conversely, don’t use AI to take the humans out of the loop. Don’t use it to work around another team’s approval. Don’t use it to generate arguments you do not fully understand, just to tell another team why they are wrong about a domain they spent a much longer time becoming experts in. I wouldn’t one-shot a system I don’t fully understand. When someone asks me how the thing that I shipped last week works, I need to be able to answer that.
Ask yourself: after using AI, am I more prepared to own this decision? If the answer is yes, it helped you become a better engineer. If the answer is no, it probably helped you avoid the part of engineering that matters most.
Use AI to become a better software engineer. Just don’t forget why software engineering at work was hard in the first place.
The people who came back from their winter break, convinced that software engineering was over, had built something real. Their experience was real: creating and contributing code was now easier for them. It is genuinely easier to build the things that you wouldn’t have built before.
Their conclusion, though—that software engineering as we know it was over—was wrong.
They had discovered a tool that gives them more autonomy. More ability to turn an idea into something working, without waiting for someone else to translate it for them.
But autonomy was never the whole job.
AI can help us move faster inside the boundaries we own. It can help us understand the boundaries we cross. But it cannot remove the need for humans to feel tension, negotiate, adapt, and shape a vision. It cannot remove the need for software engineers to do the actual work of software engineering: helping people turn ideas into working systems, without letting those systems fall apart.
The tools around us will keep changing, as they always have. The boundaries of our domains will keep shifting, as they always have. The tensions in an organization will create discussions, as they always have. What remains is the elegant craft of listening, explaining, discussing, and adjusting so the system holds together a little better than it did yesterday.
If that’s what you care about, then software engineering was never going to be over for you anyway.
Every few months, software engineering will be over in a few months again. It can’t be, but for reasons you might not expect.
When coming back to work in the beginning of 2026, organizations everywhere were going crazy. So many people, including lots of upper management, had used the winter break to build software with AI and felt that software engineering was over. They had experienced it first-hand. Everything had changed, because look at what they built! Why couldn’t work feel the same?
Their experiences were real, but they happened in isolation. Building software by yourself is orders of magnitude easier than building it in a team, or across multiple teams. The hard problem at work was never just about writing code. Their experiences didn’t reflect the challenges of the organization they worked in.
Organizations aren’t challenging simply because their structure is wrong and they need to fix it. Their structure might be wrong, but every structure is wrong for someone. If you were ever part of a reorg, you probably saw that some people thought it solved the problem, while others thought it made everything worse.
Still, organizations have to structure themselves somehow. Not everyone can know everything and work on everything. So they divide the work into domains, with a team for each domain. Over time, each team builds deep knowledge around its domain and develops a vision for where it should go.
This is good agile software development: people take ownership, plan, build, adjust, and learn from what happens. But those domains are never fully isolated. They overlap or depend on each other, and they keep changing as the product changes.
This ownership model that produces great results is also the main reason why organizational structures are so difficult. It’s hard to give teams a lot of autonomy to materialize their own vision, while also making sure that they don’t create issues for other teams and largely follow the grand vision of the company.
These are the two values autonomy and alignment. We need both values not simply because they are good values to have, but because each one solves a failure mode that the other one creates:
Pure autonomy without alignment results in teams that move fast in incompatible directions. You ship a lot, but it doesn’t add up to anything coherent. Eventually you accumulate so much inconsistency that the organization slows down anyway: integration nightmares, bad user experiences, duplicated work.
Pure alignment without autonomy results in an organization that knows exactly where to go but can barely move. Every decision needs sign-off, every team is blocked waiting for consensus. And after waiting for so long before shipping anything, you learn from your users that you shipped the wrong thing.
Autonomy and alignment are in tension, but this tension is important, even if it feels frustrating. It feels frustrating because the symptoms look like problems we need to fix: the meeting that should have been a Slack message, the RFC nobody reads, the three different date pickers that all don’t work for what you need. Some people ask for more process, trying to create alignment. Others want to strip process away, trying to restore autonomy.
The tension never goes away. It cannot go away. It just moves closer to one of the failure modes.
It’s tempting to use AI to skip the tension that we feel. Instead of talking to another team, we can describe their boundaries to an agent: what it can touch, what it should avoid, what vision it should work towards, and generally how it should behave around their domain.
But when the agent needs a change that crosses these boundaries, it will not negotiate. It doesn’t feel awkward about stepping into someone else’s area. It will work around the boundaries instead. It can easily copy some code from another team, paste it into the area without these boundaries, make the small change there, and move on.
For a senior engineer, that would feel wrong. The consequences are immediately obvious: now you have to maintain that new version, the two versions will diverge over time, and bug fixes will eventually be applied to one version but not the other. This feeling is worse than the discomfort of going through the tension with the other team. So you reach out and explain what you need. And somewhere in that conversation, your work shapes their domain, their context shapes your solution, and the organization becomes slightly more aligned than it was before.
The human feeling is important. It is what makes you stop before turning tension into a bad decision for the organization. It keeps autonomy and alignment in balance.
This matters even more now, because people who couldn’t write code will now want to use AI to contribute more directly. Designers can make adjustments by themselves, Support can replicate bugs and propose fixes. This is a good thing. The organization benefits from it. A lot of work exists because someone understands a problem, writes it down, throws it over a wall, and waits for an engineering team to look at it during a backlog refinement session. We can now lower that wall.
As that wall gets lower, more people will cross into domains they do not fully own. It will no longer only be engineers reaching out to you because they want to change something, but now non-engineers will reach out too. Not because they want you to change something, but because they want to change it themselves. They want autonomy, and by reaching out to you, they create alignment.
That is good. The surprising outcome is that when you give more people the power to act, you force more of these human conversations to happen. It keeps the tension in balance and prevents it from drifting toward one of the failure modes.
They cannot skip the conversation, because if they want autonomy, they need alignment. But your answer also cannot simply be: “you are not allowed to touch this.”
Your job as a software engineer will not disappear, and it will not drastically change because of AI. It will change in the same way that every software engineer’s career changes over time: you will become a better engineer.
Being a better engineer never meant writing more complex or smarter code.
As a good engineer, you know how to move through other teams’ domains without taking ownership away from them. You explain what you need, but you also listen to what the other team is protecting. You adjust your solution around the context you gather. You create alignment while still letting the other team own the decision.
And you bring that same mindset when someone reaches into your domain. You do not just block it, and you do not blindly approve it either. You guide that person through your boundary. You share context about what is safe, what is risky, and why. You listen to their needs and adapt your domain when it reduces future friction or makes contribution easier. And you aren’t nitpicky when a solution works, even if it’s not as elegant as the one you would’ve written.
This is where AI can help you, but not replace you.
Use AI as a tool inside the boundary you’re in. Let it explain code you do not fully understand yet, or a technology your team is adopting. Draft an architecture and let the AI point out risks, compare it to common design patterns, and surface flaws you haven’t seen yet. Use it to understand how the product is used, find answers in analytics data, recognize patterns in user feedback.
This is good use of AI because you’re not asking it to replace your ownership. You are using a tool to become more capable inside your area, so you can make decisions you can stand behind.
You hold yourself to that same standard when you’re crossing into someone else’s boundary. AI can help you prepare: turn a vague need into a clear problem statement, help you understand the tradeoffs, and find the right question to ask before sending that ineffective “I have a problem” DM.
And yes, use AI to be your coding partner whenever you need it. For me, I like to focus on the architecture and plan it out completely. I write the types and interfaces by hand, and let an agent finish the implementation details that are a chore for me: the repetitive plumbing and the stuff I already know how to write but don’t want to. This is what often works for me. I feel that I’m growing as an engineer by sharpening the skills that matter most to me.
This is like the human-in-the-loop pattern, but applied to a whole organization. People use an agent inside their ownership zone, then talk to other people, who use an agent to process that new information inside their ownership zone. The humans are still at the center, they’re just better equipped now.
Conversely, don’t use AI to take the humans out of the loop. Don’t use it to work around another team’s approval. Don’t use it to generate arguments you do not fully understand, just to tell another team why they are wrong about a domain they spent a much longer time becoming experts in. I wouldn’t one-shot a system I don’t fully understand. When someone asks me how the thing that I shipped last week works, I need to be able to answer that.
Ask yourself: after using AI, am I more prepared to own this decision? If the answer is yes, it helped you become a better engineer. If the answer is no, it probably helped you avoid the part of engineering that matters most.
Use AI to become a better software engineer. Just don’t forget why software engineering at work was hard in the first place.
The people who came back from their winter break, convinced that software engineering was over, had built something real. Their experience was real: creating and contributing code was now easier for them. It is genuinely easier to build the things that you wouldn’t have built before.
Their conclusion, though—that software engineering as we know it was over—was wrong.
They had discovered a tool that gives them more autonomy. More ability to turn an idea into something working, without waiting for someone else to translate it for them.
But autonomy was never the whole job.
AI can help us move faster inside the boundaries we own. It can help us understand the boundaries we cross. But it cannot remove the need for humans to feel tension, negotiate, adapt, and shape a vision. It cannot remove the need for software engineers to do the actual work of software engineering: helping people turn ideas into working systems, without letting those systems fall apart.
The tools around us will keep changing, as they always have. The boundaries of our domains will keep shifting, as they always have. The tensions in an organization will create discussions, as they always have. What remains is the elegant craft of listening, explaining, discussing, and adjusting so the system holds together a little better than it did yesterday.
If that’s what you care about, then software engineering was never going to be over for you anyway.
