Context: What is a Principal Engineer?
A Principal Engineer is a senior software engineer who is responsible for the design and implementation of the company’s software architecture. They are also responsible for the technical direction of the company, or the team(s) they work with and the development of the company’s (or team(s)) software engineers.
Context: What is the Agentic Era?
The Agentic Era is a new era of software development where software is built by agents. Agents are software that can learn, reason, and act (to a degree). They are able to perform tasks autonomously (theoretically) and are able to learn from their environment.
Where I Am
Over the course of the last few years, we have seen the rise of AI agents. These agents are able to perform tasks autonomously and are able to learn from their environment. They are able to perform tasks that are typically performed by humans, such as coding, design, and problem solving. This of course, has dramatically changed the way we build software already.
What I’ve written here so far is an observation of the reality we live in. I’m not trying to make a judgement call or say agentic tooling is good or bad, just merely setting the baseline of where we are. Whether you love AI Tooling or hate it or are indifferent to it, it’s here. No matter how much we discover it makes you stupid and lazy over time or other horrid things, the reality is that it is here and it is causing significant changes.
My Observations & Experience as a Principal Engineer
My experience so far, as a principal engineer – or one who does the work of a principal engineer – regardless of role. Is that I’ve started doing more debuging, troubleshooting, and problem solving than any actual coding. Not to say I am not coding, I’m doing a ton of that, but just as much I need to bring my experience and knowledge into play to ensure the debugging, troubleshooting, and problems solving gets answers in a timely way. However, I have agentic systems build things for me that previously I’d have hired junior or mid level engineers to do. But the core of what a princpal engineer does is almost the same as it was 5 or 10 years ago, it just involves agentic systems taking care of probably 50% of the code I’d have hired juniors or mid-level engineers to knock out, that work is gone.
What does this change mean overall? My personal experience lately comes down to two specific things.
- We are now able to build software faster and cheaper than the before era. Cheaper also meaning with less staff for longer stretches of time.
- We are now able to build software that is more complex and more intelligent at a rate we couldn’t before.
Does it just help with these? No. Agentic systems can help us in many other ways too, this is just the specific two things I’ve seen occur. Let me dig into this more deeply.
One Scenario
In one scenario I was in, working on some project work I found the team used the tooling to effectively identify, debug, and resolve issues at a dramatically faster pace than these issues could have been dealt with before. The solutions were also more robust because of the skill and knowledge of the developers using the AI tooling. If it had been less experienced developers this could have created a catastrophic development debt that wouldn’t be recoverable from.
Which leads presciently into the next scenario.
Another Scenario
In another scenario I found myself in, as an observer, it wasn’t the particular project I was working on. I watched as a team started to build a greenfield project. In most scenarios you would think, if familiar with agentic coding, that this is the perfect scenario for agentic coding. However this team lacked the experience with the stack and the domain. They then found themselves building out a prototype, trying to take that and continue with it as a deployed production system. Not an entirely odd or shocking scenario.
But with the use of the agentic systems, skipping over key learning moments and not knowing the system they had built put the team in an unprepared situation upon the first issues that came up. Within weeks of deployment they realized their lack of familiarity with what they built had effectively made them unable to troubleshoot problems effectively.
It was literally the opposite of the first scenario. This scenario quickly became catastrophic and the project got abandoned, somewhat unceremoniously, and the team didn’t particularly learn good lessons from the experience. Sadly, since it should have been obvious what the overall issue was, it seemed to be more blamed on the agentic tooling. The fact is, the team should have realized they need to spend substantial time ensuring they read the generated docs, the generated code, and understood what they’d built. Instead the assumption was the agentic system would be able to keep up with all those aspects.
In the end, it failed.
In Closing, Observations at This Point in Time
First observation among everything is that agentic tooling when used effectively is a massive game changer. A Principal Engineer, setting precedent and direction, with 1-2 teams can easily take on what 2-4 teams could do previously. But the key to it is effective use and more experienced engineers (i.e. Principal and a few seniors sprinkled in) that can ensure bugs don’t become roadblocks, and that the agentic tooling is being wielded properly.
The second bit observation is that if a team isn’t going to use agentic tooling effectively, it’s going to be a massive detriment to the team. It’s going to slow down the team, it’s going to create a lot of technical debt, and very likely it could derail the project to the point of failure.
For now, that’s just a few of my many observations. More to come and maybe some paired agentic code slinging! In the meantime, happy thrashing code.
