I’m genuinely loving the conversations happening almost daily around the evolution of software engineering and the impact AI will have on our craft. I have been in this profession for over 20 years, which means I have lived through enough industry turns to know that the interesting part is rarely the tool by itself. The interesting part is how the tool changes the way people work, learn, collaborate, and make decisions.
I came up through a mix of self-teaching, on-the-job training, and a tiny bit of formal computer science. I was writing HTML in the late 90s, in my late teens. There’s a funny story behind that where my mother thought I was “hacking the internet” because she didn’t understand what HTML was or how I figured it out. It took a few hours to convince her otherwise and educate her a bit about it.
I started writing code professionally in the early 2000s. That path shaped how I see the work. I learned software engineering as a lived practice first: by shipping, breaking things, asking questions, reading other people’s code, and slowly building enough judgment to know when the obvious answer was too simple. I worked with incredible people who taught me so much, but I also carried that quiet feeling that I had to work a little harder to “earn” my place and the title of software engineer. True or not, unique or not, that shaped me. It gave me a view of the work from a few different angles, and it made the people side of software feel just as real as the technical one.
The questions in front of us
When people ask “what will software engineering look like in x years?” or “how will the developer’s role change as AI and agentic workflows become more prevalent?”, I think those are good questions. I keep finding myself pulled toward a more immediate set of questions: “where are we now?”, “what does the current developer experience actually feel like?”, and “are we giving the human enough context, feedback, and support to be successful?”
That last question matters the most to me. If the humans are struggling to keep up within the systems and processes we already have, the agents we unleash into those same systems will inherit that confusion, scale it, and amplify it. I keep seeing peers circle around the same concern in some ways, usually between the lines: AI does not remove the need for a healthy engineering environment. It makes the health of that environment harder to ignore. The DORA folks call this out in the 2025 DORA State of AI-assisted Software Development report, describing AI’s primary role as an amplifier that magnifies an organization’s existing strengths and weaknesses.
I’ve been circling parts of this in my writeups on agent confidence, defensive patterns, and agentic context: confidence depends on context and evidence, defensive patterns reveal the pressures a codebase has learned to survive, and context helpers make some of that local reality legible to agents. But those are still pieces of a larger software ecology, not the entire story.
Good enough got us here
I want to be clear about something: I am excited about the potential. I am very excited about the changes to come. This is not a rejection of AI-assisted development or agentic workflows.
I am trying to highlight that many situations require a “good enough” approach to software engineering. Everyone has deadlines, resource constraints, and trade-offs to make so the job gets done. That mentality is necessary and healthy in many cases. Engineers can be perfectionists. We get lost in what is right, correct, and best for ourselves and our peers. We sometimes forget that the point of software engineering is to solve problems, create value, and keep learning.
Good enough is what lets us ship, learn from mistakes, and iterate. It helps us balance quality with speed, innovation with stability, and creativity with reliability. That matters because our business partners and customers do not benefit from the perfect thing we never deliver. If we are not putting useful software into their hands, even with known compromises, then we are not helping anyone yet.
But good enough also has a cost.
Sometimes the cost is small and temporary. Sometimes it becomes the shape of the system. The shortcut turns into the path. The missing context becomes normal. The manual validation becomes tradition. The tribal knowledge becomes the architecture. That is where AI starts to make me pause, because agents do not merely participate in that environment. They can multiply it.
A short aside… Everywhere I’ve worked, there is a recurring joke of “the most temporary thing is the most permanent thing”. It is a funny way to acknowledge how often we make compromises that outlive their original intent. I have seen that happen with code, architecture, processes, documentation, and even team structures. It is a reminder that we need to be intentional about the compromises we make and the technical debt we take on.
Software engineering at the tipping point
Recently, I stumbled upon a Google Developers video titled “Software engineering at the tipping point”. In the talk, Adam Bender frames modern software engineering as software ecology: the socio-technical ecosystem of people, culture, tools, incentives, and code that produces software. His core warning is that AI will amplify that ecosystem rather than magically fix it, so teams need to understand their current trade-offs, bottlenecks, validation, capacity, and human practices before agentic workflows multiply the pressure.
I absolutely recommend taking a few minutes to watch the talk.
This amplification framing is what I’ve been really “feeling”, yet failing to articulate. Both Adam and the DORA report highlight this amplifying effect as something that can absolutely get you more of the good stuff, if you have it in place already. But it can also significantly increase the negative effects of a team or organization’s existing weaknesses. And it is not a linear increase either.
That is the part I keep coming back to: human friction has been the hidden governor on a lot of weak systems. Agentic workflows can reduce that governor. Once that happens, the health of the system matters more than ever.
Human friction as the hidden governor
Today, human friction slows the software engineering process down. Some of that friction comes from physical and cognitive limits: typing speed, attention, context switching, fatigue, and the simple fact that humans cannot hold an entire system in their heads at once. Some of it comes from the systems around us: unclear requirements, missing documentation, fragmented ownership, weak feedback loops, and poor communication.
That friction is a bottleneck, and it is not a sustainable model for engineers. It can lead to burnout, stress, dissatisfaction, technical debt, bugs, and security vulnerabilities. At the same time, the slowdown often creates room for human judgment. A person pauses. A question gets asked. A reviewer notices that the ticket is wrong. Someone remembers the production incident from three years ago and says, “wait, this looks familiar.”
That is the distinction I care about. We need to reduce the unhealthy friction without accidentally removing the judgment that was hiding inside it. If our process depends on exhausted humans catching problems by sheer force of attention, the process is already fragile. AI does not fix that fragility. It exposes it.
Agentic friction is the new surface area
Agentic friction is the new layer of work introduced by AI-assisted development and agentic workflows. It shows up when we need to manage, constrain, validate, and collaborate with agents. It shows up when we need to understand what an agent knows, what it inferred, what it changed, what it skipped, and where its confidence came from.
That work is not abstract. It is the day-to-day engineering work of reviewing generated code, designing feedback loops, preserving institutional context, limiting blast radius, testing assumptions, and deciding where humans need to stay in the path. It is also the work of making sure agents are operating inside the actual ecology of the team, not inside a thin snapshot of a repository with none of the surrounding history.
Taking lessons from human friction, we can approach agentic friction with a mindset of learning, iteration, and improvement. We can start by acknowledging that the friction is real. We can invest in education and practice so engineers learn how to work effectively with agents. We can introduce context helpers that give agents better insight into the institution, project, codebase, and team. We can adapt our defensive patterns to account for the new risks and challenges introduced.
The next adventures
The next adventures in software engineering will be about navigating this new landscape of human and agentic friction. We need to keep the parts of human practice that create judgment, context, care, and accountability. We also need to reduce the exhausting, wasteful friction that burns people out and hides weak systems behind heroic effort.
AI gives us a chance to look at our software ecology with fresh eyes. Not because agents will save us from the hard parts, but because they make the hard parts harder to ignore. If we want agents to help us build better software, we need to build environments where humans and agents both have enough context, feedback, and validation to do good work.
That feels like the real adventure to me. Not replacing the craft, but expanding the conditions where the craft can actually thrive.