We have been defining engineering excellence for years
Photo by Jonathan Chng on Unsplash
I’ve spent years thinking about what makes a great software engineer, and how organizations can create the conditions for engineers to grow and succeed. Building engineering competency frameworks at companies such as TravelPerk, AltoVita and others was part of that journey. Different organizations, different stages of maturity, cultures and challenges, but the same question: what do we expect from our engineers, and how do we recognize and develop excellence?
In 2023, I revisited this topic, exploring different approaches to competency frameworks and how AI could help accelerate the process. Back then, AI was primarily a productivity tool. It could help us research, structure ideas, challenge assumptions and produce in hours what previously required days or weeks. But what we expected from engineers did not change.
Three years later, the conversation has changed. AI is no longer just helping engineers write code faster. We are seeing agents take responsibility for substantial parts of software delivery, from implementation and testing to reviewing and coordinating work. This is changing not only how we build software, but also how engineers contribute to the process.
And that raises a question: if the way we build software is changing this much, shouldn’t we also reconsider what engineering excellence looks like?
The nature of engineering work is changing
For decades, writing software has been one of the main constraints in turning ideas into working products. We developed methodologies, processes and organizational structures around coordinating the work of engineers, managing dependencies, reducing delivery time and ensuring quality. We invested in helping teams turn requirements into software faster, because implementation required substantial human effort.
AI is challenging that assumption. At Pensero, we’ve had weeks where agents produced most of our code delivery. While this is still far from being the norm across the industry, it illustrates how quickly the nature of engineering work can change when implementation becomes more accessible.
But making code easier to produce doesn’t mean engineering becomes easier. It can expose or amplify constraints that were previously less visible. When implementation accelerates, understanding the problem, making architectural decisions, reviewing changes, validating assumptions, managing dependencies and ensuring production reliability can become the limiting factors. More code is not more customer value, and faster execution can also accelerate mistakes.
Yet the responsibility for delivering outcomes hasn’t disappeared. Engineers are still accountable for understanding the problem, making good decisions and ensuring that what reaches customers works as intended. What is changing is how much of the execution they need to perform themselves, and how they organize, direct and verify the work of increasingly capable systems.
This is where our expectations of engineering excellence need to change.
What does engineering excellence look like now?
I don’t believe the fundamentals of great engineering have changed as much as we might think. The engineers I’ve admired throughout my career were rarely the ones who produced the most code. They were the ones who understood the problems they were solving, made thoughtful technical decisions, challenged assumptions, took responsibility for outcomes and helped others become more effective.
Those qualities remain as relevant as ever. In competency frameworks, we often translate these expectations into observable behaviors: what engineers do that demonstrates ownership, judgement, technical excellence or collaboration. This is where the transformation becomes visible. The competencies we value may remain largely the same, but the behaviors through which engineers demonstrate them are evolving.
Ownership beyond implementation
We’ve always encouraged engineers to take ownership rather than execute assigned tasks. But organizational boundaries, specialization and the cost of implementation have often limited how far that ownership could extend.
As agents take on more of the execution, engineers can engage with a broader part of the problem: understanding customer needs, exploring alternatives, coordinating implementation, validating results and learning from production. Success is not delivering a feature, but ensuring that the intended problem is solved. It doesn’t mean every engineer becomes a product manager or operations specialist, but we can expect greater responsibility for what happens before and after implementation.
Technical expertise and judgement
One of the paradoxes of AI-assisted engineering is that the less code we need to write ourselves, the more important it becomes to understand what good engineering looks like. An agent can propose several implementations, but someone still needs to evaluate the trade-offs. Does the solution fit the architecture? Is it unnecessarily complex? What happens when it fails? And should we build it at all?
These aren’t new questions. Experienced engineers have always asked them. But when alternatives can be explored and implemented much faster, those decisions carry greater consequences. Technical expertise remains essential, even if we apply more of it through problem decomposition, architecture, constraints and verification rather than direct implementation. Delegating execution doesn’t mean delegating responsibility for understanding the system.
Designing how engineering work gets done
One expectation stands out. For years, improving engineering productivity meant becoming more proficient with our tools, simplifying processes or helping teammates work more effectively. AI introduces another dimension: engineers can now design systems that perform substantial parts of their own work.
Instead of repeatedly executing the same workflow, an engineer can define the context, tools, boundaries and verification mechanisms that allow agents to perform it reliably. What begins as an individual improvement can become an automation that others reuse, or eventually part of how the organization operates. This changes how engineers can contribute, moving beyond executing work themselves to improving how work gets done.
However, automation is not an achievement in itself. A sophisticated agentic workflow that requires constant supervision or produces unreliable results may be worse than a simple manual process. Excellence also means understanding what is worth automating, at what level of autonomy, and under which conditions.
Quality and accountability
Writing tests, reviewing changes and monitoring production have always been part of good engineering. But as agents accelerate software production, relying primarily on individual inspection becomes difficult to sustain.
We need to design quality into the execution process itself, through clear acceptance criteria, automated verification, safeguards and feedback mechanisms. One behavior worth recognizing is moving beyond fixing a defect to improving the system so that the same category of defect is less likely to happen again.
We’ve experienced this at Pensero when working with coding agents. Adding a rule to an agent’s instructions is not always enough to prevent an unwanted behavior from recurring. We’ve had to complement those instructions with automated checks in CI, making the constraint enforceable rather than relying exclusively on the agent following it. It’s a small example, but it illustrates an important shift: the responsibility extends from validating individual outputs to improving the system that produces future work.
Learning, adaptability and helping others succeed
Great engineers have always been curious, willing to challenge established practices and invested in helping others improve. The speed of change in AI makes these qualities more important, but adaptability shouldn’t be confused with adopting every new tool or model. It means experimenting with purpose, understanding what improves outcomes and sharing those lessons.
Engineering also remains a collective activity. Mentoring colleagues, sharing knowledge and challenging decisions constructively are not becoming less relevant. Working with AI should also help engineers create more opportunities for learning, collaboration and collective improvement, rather than increasing individual output.
I don’t see these as entirely new competencies. I see familiar expectations being expressed through different behaviors. And if the way engineers demonstrate excellence is changing, we also need to reconsider how our organizations recognize and support it.
Our expectations need to evolve too
Photo by Jon Tyson on Unsplash
Recognizing these changing behaviors goes beyond updating competency frameworks or redefining career levels. It means reconsidering how we assess contributions, support professional growth and create an environment where engineers can succeed.
An engineer who designs a reliable workflow that improves how an entire team operates may create more value than someone who delivers a large volume of code individually. The same applies to engineers who identify important risks, prevent defects or challenge unnecessary work. These contributions have always mattered, but traditional measures of activity rarely capture their full impact. As engineering execution becomes more automated, distinguishing activity from meaningful contribution becomes more important.
This has implications for how we use engineering metrics. The volume of AI-generated code, agent activity or adoption rates may help us understand how work is changing, but they shouldn’t become measures of engineering excellence. We need evidence of outcomes, quality and sustained improvements, with metrics informing our judgement rather than replacing it.
Expectations also change with experience. Seniority has never been about producing more, but about the complexity of problems engineers can navigate, the responsibility they can assume and the impact they create beyond their own work. AI introduces new ways to demonstrate that impact, from directing agents to designing workflows and systems that others can rely on. The challenge is recognizing these contributions without confusing the sophistication of the automation with the engineering judgement behind it.
Competency frameworks also reflect what an organization needs at a particular stage. During rapid growth, we may encourage engineers to participate in hiring, onboarding and helping new colleagues become productive. During consolidation, we might emphasize knowledge sharing, reducing dependencies and improving operational consistency. These priorities don’t redefine engineering excellence, but they influence which behaviors we choose to encourage and recognize at a given moment.
I believe we’re facing a similar challenge with AI. Beyond learning to work with agents, we need engineers who help their organizations prepare for more autonomous ways of working. Strengthening testing and CI/CD, improving deployment and recovery practices, and designing workflows with appropriate safeguards can be as valuable as the software they deliver. Expecting greater autonomy without these foundations makes little sense. And the goal isn’t maximum automation, but developing the readiness to operate at the right level of autonomy for each kind of work. As organizations mature, the behaviors we emphasize will need to change again.
There’s another question I believe deserves attention: how do we develop the next generation of excellent engineers? Much of the judgement we value in experienced engineers comes from years of implementing solutions, making mistakes, debugging failures and learning through direct experience. As more execution is delegated to agents, we need to reconsider how less-experienced engineers develop that same depth of understanding. Access to powerful tools doesn’t automatically produce engineering expertise.
Having spent years building and revisiting engineering expectations, I’ve learned that no framework remains relevant without continuous adaptation. We are still discovering what effective agentic engineering looks like, and I don’t believe anyone has a mature, universal playbook today. Different organizations will find different answers, and some of our current assumptions will change as the technology and our understanding develop.
But I believe one thing is becoming clear: the fundamentals of engineering excellence aren’t disappearing. The behaviors through which we demonstrate them, and the impact we can reasonably expect, are changing. Our responsibility as engineering leaders is to recognize that shift, challenge our existing expectations and help engineers grow into what comes next.
If you are trying to understand engineering execution, technical risk, or team capability beyond static reports and interviews, this is the problem we are solving at Pensero.
And if this space resonates with you, we’re also hiring: pensero.ai/careers.