The term ‘agentic engineer’ has certainly been used before, but it hasn’t really gained momentum until this past week. There’s a simple reason why: AI has been gotten to a point where it removes most of the blockers inhibiting engineers from building. This has made being an agentic engineer more important than ever.
An agentic engineer is an engineer who just does things. They’re able to identify high-impact work that needs to be done and take care of it without being told what to do or how to do it.
You might think that sounds like what every senior engineer should be able to, but there’s a difference. The key to being a senior engineer is the capability to take a system from requirements through the design and build stages on their own. An agentic engineer takes this a step forward.
An agentic engineer starts earlier in the pipeline. They identify the requirements on their own by understanding problems, recognizing needs, defining scope, and taking initiative entirely on their own. While senior engineers make progress, an agentic engineers drive outcomes.
Now you might be thinking: “Oh, I’m familiar with this. You’re talking about a 10x engineer.” I want to clarify that I’m not. In fact, articulating why I’m not talking about The 10x Engineer will put into perspective why an agentic engineer is becoming so important.
To me, a 10x engineer has always been a legend due to their in-depth understanding of technical concepts and their intuition that allows them to pick up new concepts quickly. Previously, this knowledge and intuition was the key to obtain 10x output and their ability to build systems faster than their colleagues. However, this is no longer the case.
As AI progresses, it breaks down the barrier that separated a 10x engineer from the rest of the pack. Technical concepts and fast coding are becoming more accessible to everyone. The defining factor in the age of AI is taking action. This is what defines an agentic engineer and what puts them ahead of their peers: Their ability to know what actions to take and the drive to execute them.
What you’ll see all over social media is everyone telling you to be an agentic engineer. What you don’t see anyone telling you is how. Why is this? Being an agentic engineer is difficult and is rooted outside of technical ability.
It’s something I’ve struggled with and I think about a lot, so in this article I’ll simplify the three things that set an agentic engineer apart from the rest and how you can become one.
If you missed last week’s article, I wrote about why right now is the best time to be a software engineer (contrary to everyone’s opinion). You can check it out here:
1. Understand Business Objectives
The first step that turns someone into an agentic engineer is understanding business objectives. Regardless of the size of company you work for, the problems that need to be solved align with business objectives. If you want to identify the most important problems and tackle them, you must take the time to understand the business objectives they aim to solve.
When I first started working as a software engineer, I naively thought my job was just to build software. I’ve always been confident in my knowledge of technical concepts but I quickly realized I had no experience in applying that knowledge.
This is something many engineers, researchers, and PMs in tech struggle with because it’s a learned skilled that isn’t taught in school. It also isn’t a skill that just clicks and you have it—it’s a skill highly dependent on the technology you’re working on, the company you’re working for, and the role you play in building the systems you work on. Understanding business objectives is an ongoing, frequently changing task.
The good news is that it gets easier with practice—and practicing it should always be readily accessible. Take note of the emphasis on ‘should’ here because it’s something we’ll get back to.
At most companies, leadership frequently goes through planning cycles with their team where they identify what they want to accomplish and the work needed to do so (objectives). They also identify concrete metrics that define whether or not those objectives were met (these are KPIs, which stands for ‘key performance indicators’).
The results of this planning cycle are shared throughout the organization with all roles so they can understand the most important problems to tackle and align on projects to do so.
The easiest way to know the most important problems you (as an individual) can solve to make an impact is to internalize the objectives and KPIs from these planning cycles. Coincidentally, this is also the best way to manage up and understand the work the leadership that controls your career progress wants completed. Every agentic engineer I know understands current business objectives and KPIs and solves problems accordingly.
Let me bring it back to the emphasis I put on should some paragraphs earlier. All the information I mentioned above should be made widely available to the entire organization. Some companies have well-defined processes for doing so.
One of the biggest and less-talked-about advantages of working for companies like Google, Meta, Microsoft, or other large tech companies early in a developer’s career is that these companies have these processes in place and this make it easy for junior developers to gain the skills they need to understand business objectives—a skill that pays dividends throughout their career.
Some companies don’t have these processes and it makes it much more difficult to practice this skill. If the company you work for doesn’t have these processes, you have two options:
Find a way to communicate up your management chain to understand business objectives. This will require frequent communication with your leadership and good communication from them.
Find a company that does. I know this isn’t an excellent solution, but it’s reality.
2. Be Curious
In my first software engineering job out of college, I lucked out with an incredible manager. He’s now a Partner at Microsoft1 and gave me some of the best early career advice I’ve ever received.
He simply told me to be more curious. He reminded me that one of the best things about software engineering is you can figure out how anything works as long as you have access to the source code (with the exception of machine learning systems, of course, but even then it’s helpful).
It had never crossed my mind that I could just look into anything I had access to just because I was curious about it and learn how it works simply because I can. It was such a simple concept that was absolutely mind-blowing for naive, new-grad Logan.
With so many companies using monorepos or large repositories to group microservices, this advice is even more beneficial. At Google we use one giant monorepo for all our code called google3. This means I have access to the source code for all Google products with the exception of intellectual property. I can literally dig into how any Google product works just because I want to.
Curiosity is important to be an agentic engineer because you can’t solve the problems you identify by understanding business objectives using the tips above if you don’t understanding the code currently solving those objectives. Or, more simply put, you can’t improve systems if you don’t understand how they already works.
So I’ll echo my first manager’s advice to anyone I meet: The best software engineers stay curious.
3. Just Start Building
A common phrase in the software community that I love is “you can just do things.” I’ll take this one step more and say “you can just build things.”
Too often we forget this. At large tech companies, there are processes put in place to align individuals on working within the same problem space. Usually these processes are meant to identify key stakeholders, refine plans, deduplicate work, and coordinate execution. Really that’s just a bunch of business speak for letting people know what’s going on and getting feedback.
One of these processes used at both Google and Microsoft (the two places I’ve worked) is document-driven design. This means writing a plan in a document, tagging reviews and approvers, and going through a feedback cycle and making changes as needed. It’s a great process for getting more eyes on a plan and informing others of the work you’re doing. It can also be great at delaying execution of the project by weeks or even months.
If every project requires a document and every document requires multiple reviewers, you can imagine that a considerable amount of engineering time is spent reviewing docs and giving feedback. Combining that with multiple iterations of document reviews and projects (especially those with more ambiguity) can end up in a sort of document purgatory where progress is stunted as stakeholders try to find alignment.
Sometimes this can go on for so long that you could have built the system multiple times in the amount of time the project takes to gain approval. This is especially humorous because part of the reason for document-driven design is to ensure time is well-spent and man hours aren’t wasted (i.e. the work is important enough to warrant time spent on it).
Having been stuck in this situation, I asked a more senior engineer how to avoid it and he told me to “just build the thing.” There are many times where he’s been getting approval for a project while actively prototyping it on the side and making adjustments in real-time based on feedback. In fact, every Googler has an “experimental” directory in google3 specifically for prototyping away from production code.
I bring this up because a major difference between an agentic and non-agentic engineer is agentic engineers aren’t stopped by processes. This doesn’t mean they don’t participate in them—they just don’t let the processes stop them from building.
It’s really easy to get caught up in these processes because they’re a huge part of an engineer’s job. It’s fundamental for company success to encourage employee agency by making it easy for them to build software whenever they want to. Any company that inhibits their engineers’ abilities to build software is not a company you want to work for.
These are just a few things I’ve learned over the course of my time as a software engineer. Let me know what’s helpful and what isn’t, and let me know what you think is fundamental for someone to be an ‘agentic engineer’ by leaving a comment.
I end my articles with a few resources to help you become a better engineer and some other interesting things you should know about. If you’re interested in getting these in your inbox each week don’t forget to subscribe.
If you’ve found Society’s Backend beneficial, you can also become a paid subscriber for just $3/mo to support me and get even more articles and resources.
Enjoy the resources!
To help you become a better engineer
A Survey of AI Agent Protocols: A survey centered around how AI agents communicate with tools and data sources. A great read on a space I feel has been dominated by MCP without much thought for other options.
Getting things "done" in large tech companies: Another commentary on what it takes and (more importantly) what it means to get things done at large tech companies.
Quantization by Hugging Face: Quantization represents data with fewer bits, making it a useful technique for reducing memory-usage and accelerating inference especially when it comes to large language models (LLMs). This is a guide on quantizing a model to 4-bits and training it with LoRA.
Other interesting things
A post by Elon to essentially crowdsource difficult questions for Grok. As anyone working with machine learning knows, data cleanliness is incredibly important for proper model performance. I’m not sure how xAI intends to use this info, but I could see low-quality data be a major issue with this approach.
A different, more useful approach to using difficult questions with LLMs. This is something I’ve done before as well but I imagine Francois Chollet’s difficult questions are probably more difficult than mine.
Klarna has backed off from their “only hiring AI” approach very quickly. I said this was a bad idea when they announced this approach so I can’t say I was surprised to see they had reverted their decision so soon.
An interesting Note from right here on Substack. Learn about CPU architecture by playing a game! Who wouldn’t think this is awesome?
I’m glad to see more interesting technology and AI content on the Notes feed. It’s got huge potential but it’s too dominated by writing content and meaningless platitudes.
That’s all for this week! I’ll send a roundup at the end of the month with a more comprehensive overview of AI for the May. Make sure to subscribe so you don’t miss it!
Thanks for reading!
Always be (machine) learning,
Logan
Partner at any large tech company is VERY difficult to get to. Usually they have a limited number of employees that are allowed to be Partner at any given time so someone actually has to leave for someone else to be promoted.
