This newsletter is sponsored by G2i.

The bar for “good engineer” moved, your hiring process didn’t.

A year ago, using AI for coding meant using 1 AI agent at a time. Now it means orchestrating 3 or 5 at the same time, with the focus on the right code quality as well.

If your tech interview process still tests for pure syntax, you’re screening for a job that doesn’t exist anymore.

• Live session, judged by a real person in real time

• Scores RL, RAG, agentic development, and eval judgment

• Built from two years inside frontier AI lab work

• Vetted senior and staff-level engineers with 10+ years building production systems

See how G2i evaluates real engineering judgment:

Learn more

Thanks to G2i for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

Throughout this year, I had the pleasure of talking with many different people and teams about how everyone works and what makes them successful.

I’ve visited many companies in San Francisco and had countless conversations with engineers and engineering leaders from companies around the world.

In today’s article, I am sharing insights, particularly about what differentiates elite engineering teams from the average ones.

The insights shared in this article are from:

• Sulman Choudhry, Head of Engineering, ChatGPT, OpenAI

• Venkat Venkataramani, VP of Applied Infrastructure, OpenAI

• Katelyn Lesse, Head of Platform Engineering at Anthropic

• Jefferson Frazer, Director, AI Metadata and Delivery, Shutterstock

• Andrew Churchill, CTO, Weave

The question I asked them was: “What separates elite engineering teams from the average ones?” Their answers are shared in this article.

This is an article for paid subscribers, and here is the full index:

- Elite engineering teams focus on the “outer loop”
- Clarity on the north star and good metrics in place in order to measure success
🔒 At Anthropic, elite teams are more ambitious than average teams
🔒 Team tenure and committed work say a lot about how great the team is
🔒 Elite teams work within flatter orgs and have a good ratio of spending and delivering values
🔒 Last words

Let’s start!

Elite engineering teams focus on the “outer loop”

Sulman Choudhry, Head of Engineering, ChatGPT, OpenAI, described the difference between an average team and an elite team using the idea of the inner loop and the outer loop of software development.

The inner loop refers to shipping or writing code faster. But the problematic part is that more code is not always better. Many average teams are already good at this, they build quickly and produce a lot of code.

However, the real difference appears in the outer loop.

The outer loop is about getting real user feedback, learning from it, and quickly iterating to improve the product. Average teams often run into bottlenecks here.

Elite teams optimize both loops. They not only write code quickly but also build systems that help them test ideas, gather user signals, and iterate faster toward real outcomes.

And the example Sulman has shared:

Instead of writing code and manually testing it, elite teams use tools like Codex to test and iterate as part of the development workflow. This helps them get to the desired result much faster.

The ultimate version of the outer loop connects development directly to real user outcomes, such as product usage or user engagement.

So, to sum up the insights shared from Sulman:

• Average teams mainly optimize the inner loop, focusing on writing/generating code faster.

• Elite teams optimize the outer loop, learning faster and driving real impact.

What matters most is impact, not the amount of code written.

Clarity on the north star and good metrics in place in order to measure success

Venkat Venkataramani, VP of Applied Infrastructure, OpenAI, mentioned that for a shorter time period of the work of specific teams, it’s easier to see whether the team is doing well or not, because there are clear deliverables and well-defined metrics attached to it. It’s a lot harder to know if the project takes a long time to finish.

This is an important signal for infrastructure teams to break down projects into smaller, more manageable pieces, because that’s how you can show your progress a lot more clearly.

And the 2 specific high-signals of elite teams Venkat shared are:

• Does the team have clarity on what the north star looks like? (long-term goal of the team) And are they able to hit that goal as well?

• Another signal is if the team doesn’t have specific metrics in place that they track in order to know how well they are doing.

And then he also shared the following:

For every infra team, there’s always a time when there needs to be some “hill climbing”, which means that the team may be overwhelmed with the amount of work in a certain period of time because of how unpredictable infrastructure work can be.

Great teams are able to balance that short-term pressure well, without losing sight of the long-term goals.

Which means that they don’t just put “all hands on deck” when there is a certain pressure, but they stay composed, assign specific people to focus on the right areas, communicate clearly if there’s going to be any timeline changes on projects, and manage to juggle everything without dropping the ball.

At Anthropic, elite teams are more ambitious than average teams

Read more

This newsletter is sponsored by Unblocked.

[Webinar] How to stop babysitting your agents

Agents can generate code. Getting it right for your system, team conventions, and past decisions is the hard part. You end up wasting time and tokens in the correction loops.

More MCPs, rules, and bigger context windows give agents access to information, but not understanding. The teams pulling ahead have a context layer to give agents exactly what they need for the task at hand.

Join live on Sep 2 (FREE) to see:

• Where teams get stuck on the AI maturity curve and why common fixes fall short

• How a context layer solves for quality, efficiency, and cost

• Live demo: the same coding task with and without a context layer

If you want to maximize the value you get from AI agents, this one is worth your time.

Register now

Thanks to Unblocked for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

For a long time, moving up in engineering meant becoming less hands-on. You would spend less time building and more time leading, delegating, and enabling others. That is changing.

Engineering Managers, Tech Leads, Team Leads, and Architects are increasingly expected to be “player-coaches”. To be great leaders while also staying deeply involved in the technical work. It sounds great on paper. But here’s the problem:

We are adding more expectations to roles that were already difficult to do well.

AI was supposed to make the “player” part easier. In many ways, it’s doing the opposite, and in this article, I’ll share all about why that’s the case, and at the end, I’ll share my advice for both the leaders and player-coaches.

Let’s start!

What does being a “player-coach” actually mean?

We’ll start with this very important question because it’s crucial that we know and understand what it actually means and what the main responsibilities are.

A player-coach is someone who operates in 2 modes:

• They are a coach

They set direction, develop their people, give feedback, ensure everyone understands the goals, remove blockers for others, coordinate with other teams, while making sure that the team is also efficient.

• They are also a player

This might mean they are writing/generating code, reviewing/creating technical specifications, resolving production issues, building MVPs/prototypes, etc. Everything that a senior engineer would do.

The main associated roles of player-coaches are: Engineering Manager, Architect, Team Lead, Tech Lead.

Now, the main question you might have is: This sounds like 2 different jobs? How do you actually manage doing 2 jobs at the same time?

How do you actually do the work of a player-coach?

This has been an endless problem to figure out, especially for people who found themselves being in such position for the first time. The first-time tech leads, team leads, EMs, or architects.

You have a limited amount of time every day, you have a limited amount of mental energy every day, and you need to decide where to put your focus. There are endless things to do, but it’s crucial that you know what to work on and what not.

So, not only do you need to have both good people skills and tech skills, you need to be extremely good at managing your time and priorities.

And the biggest problem that I also had as a first-time lead was saying “no” to things that are not important, and trying to help everyone at the same time.

I found myself in so many different situations that “needed my help”, so that it became totally unmanageable. And it was either stop doing it or you’re going to burn out.

Learn how to manage your time in this article:

AI makes the player-coach role harder, not easier

The roles have been hard enough already, now, with AI, the role is harder than ever.

You might think that the “player” part is now easier, because you can just use AI to “do it for you”. In some cases, that is true, like creating a PR based on a clearly defined task is a lot easier.

But the problem is that there are 3x more PRs being created today than in 2024. And teams that use AI coding agents to develop their software create 6x more PRs than traditional teams.

And as we know, AI-assisted engineering is the standard way of developing software these days, so most teams are using AI coding agents, and if they are not already, they definitely should.

So, the reason why this is problematic is that the “player-coaches” are the ones who are most of the time responsible for the success of a certain project. And as I wrote in one of the past articles, code review is the new bottleneck for engineering teams.

With the speed of coding increasing, what happens is that a lot of reviewing falls onto these player-coaches to ensure that everything is on point.

And as you know, reviewing has always been a really draining part of software development, it’s much more satisfying when you are building than when you are reviewing other people’s code. That’s especially true for me.

So, based on my conversation with many engineering leaders across the industry, a lot of the work these days is actually reviewing other people’s code.

And what can be really problematic is when certain engineers don’t review their code correctly, and they just blindly submit “AI-generated slop”.

And that surprisingly happens quite often, especially with more junior engineers, where that engineer opens a PR full of AI-generated slop, and then it’s on the reviewers to find all the issues with it.

The unrealistic expectations of player-coaches

And then the real problematic part is that the “AI-generated slop” is actually incentivised across many companies these days, and a lot of leaders don’t actually understand that more code is not better.

We see people bragging that they are generating 50k lines of code per day, or even 100k, and many people think that this is “cool”. But here is the reality:

Less code and better code is much better, because less code means fewer problems and less maintenance we need to do.

With code that’s not needed, we are just creating future problems that we don’t need.

So, what happens is the following:

• Engineers are incentivized to create more

• Everyone is incentivized to create (you may have heard of a new important skill for non-tech people to “ship to production”)

• Company leaders don’t understand the bottleneck comes on to reviewing and ensuring the software is built with the right standards

• Company leaders think that you can do the “player role” with ease now that AI is here to do all the work and magic

This creates a ton of more work for these player-coaches, with no extra credit for them, because of the lack of understanding of what’s really important.

I’ll be sharing my advice for both company leaders and player-coaches next.

My advice for leaders who are managing player-coaches

Whether you are a Director, VP, CTO, or CEO, make sure not to fall into the story that “AI can just magically do everything for you”. It definitely helps in certain areas, but then creates a bottleneck in another area.

It’s your responsibility to figure out where that bottleneck is and provide the necessary support to the people who need it.

And that specific area is good judgment, which is a crucial skill that player-coaches must have in order to do well in their roles.

My advice is to really listen to the people who are at the root of these bottlenecks. The worst thing you can do is to just blindly “dismiss” it and keep on incentivising people to create more by using AI.

The people who are really important for the success of projects are going to be burning out because of the lack of understanding of how important their work is.

And at the same time, make sure to give credit where credit is due. Not just to people who “create more”, but to people who do the “glue work”, put so much effort into reviewing PRs, and proactively communicating with everyone to ensure that the project is still on track.

I know such work is often less visible, and that person must make that work visible. My advice is to keep your eyes on the lookout for people who are doing such work and ensure that they get the well-deserved credit.

My advice for player-coaches

Now, here comes the hard part, you are doing a lot of extra work, while people don’t really understand that your work is a lot harder, not easier.

The problematic part is that you can’t say that it’s the “leadership’s fault”, well in reality it is, because they might not understand how important your work is. But if you put the blame on others, there are no actionable things for YOU to do. And that’s the wrong mindset to have.

The best mindset to have is: “What can I do in order to ensure that people understand how important my work is?”.

The first thing is credibility and trust. You need to build both, because without them, your word doesn’t have weight, especially with the leadership.

The second thing is to actually have conversations with people about your work, and ensure that you communicate your impact correctly. You can “assume” that people know that already, but more often than not, they don’t.

Your manager sees about 40% of the work you do on a daily basis, it’s your responsibility to communicate the rest to them.

I wrote extensively about both how to build credibility and trust, and how to actively communicate your impact in these 2 articles:

I highly recommend you give them a read, they will help you a LOT with ensuring that you are viewed as a highly credible professional, and that everyone understands the impact of your work.

Last words

The “player-coach” role has never been easy, and with increasing expectations, it’s becoming even harder.

Let’s end the article with the following:

AI makes it easier to create more, but someone still needs to review, prioritize, make good decisions, and ensure everything fits together. And a lot of that responsibility falls on player-coaches.

If you are in such a role, remember, you can’t do everything. The key is knowing where your involvement creates the biggest impact, and saying “no” to everything else.

That’s what being a great player-coach is really about. You got this.

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

• Interested in sponsoring this newsletter? Check the sponsorship options here.

• Check out my book “The Multiplier Mindset” coming out later this year, here.

• Take a look at the cool swag in the Engineering Leadership Store here.

• Want to work with me? You can see all the options here.

Get in touch

You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.

If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

Check the benefits of the paid plan

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.

This newsletter is sponsored by Honeycomb.

Live Masterclass + Q&A: The Business Case for Observability

Observability is a significant engineering investment. On September 2, Honeycomb’s Liz Fong-Jones, co-author of Observability Engineering, will break down how engineering leaders can evaluate that investment, connect observability to meaningful outcomes, and build an evidence-based case for what comes next.

In this virtual masterclass session:

• Evaluate observability against engineering outcomes

• Identify gaps between monitoring and effective observability

• Build an evidence-based case for future investment

Register now and watch what you missed

Thanks to Honeycomb for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

I recently had the pleasure of speaking with Eric Sammer, Distinguished Engineer at Redis (formerly CEO Decodable).

We talked all about how Redis builds AI-native engineering teams, their process, culture, and also how they do hiring.

Interestingly, their engineering culture revolves heavily around performance. Not surprising, though, as performance plays a huge part in Redis’s products, and they work within pods of 3-4 engineers, each with a feature lead.

This is an article for paid subscribers, and here is the full index:

- What does AI-native mean at Redis?
- The size of Redis’s product&engineering org
- Redis’s AI-native teams structure
- Their meetings and process
🔒 How are they using AI to be more productive?
🔒 They are measuring token spend, but how effective the spend is is the hard part
🔒 Redis’s engineering culture
🔒 Hiring process for a new engineer
🔒 Last words

If you haven’t read the articles on how OpenAI, Anthropic, and Shutterstock build AI-native engineering teams, I highly recommend doing so:

Let’s start!

What does AI-native mean at Redis?

As with every article about AI-native teams, I always want to understand what AI-native really means for a particular company, and this is what Eric mentioned:

I think it’s similar to “cloud native”. It’s a term people use to mean almost everything and nothing.

To me, being AI native means treating AI as a default way of working, not as something you simply add on later.

The question I like to ask is: If we were building software engineering from scratch today, and AI already existed, what would it look like? How would we build teams, processes, tools, and technology differently?

That’s what AI native means to me. And I think cloud native is a good parallel.

Especially interesting is the parallel to being cloud native, which resonates, because when companies started to shift from on-prem to cloud, quite some time ago, that term got quite similarly sensationalized as AI-native is today.

The size of Redis’s product&engineering org

I was quite surprised to hear that Redis has about 350-400 people across the product and engineering org. They really came a long way from when Redis was just an open-source project started in 2009.

Engineering makes up the majority of that headcount, and around 20-25 people are in product. That’s about a 1:15 PM-to-engineer ratio. Very similar to what Shutterstock does. While Anthropic has a 1:8 ratio and OpenAI has 1:30.

One of the more interesting changes Eric has mentioned is that, looking from 2 years ago to today, there’s a lot less specialization of engineers, and a lot more engineers who are good generalists.

I wrote about this exact trend in this article: Become a Great Generalist or Extreme Specialist.

And he also mentioned that PMs don’t just work on creating PRDs or designing in Figma, but they actually build working prototypes in React and Claude Code.

Redis’s AI-native teams structure

They work within small pods of 3-4 engineers. Every team has a feature lead, which is basically a tech lead, leading the technical implementation of a certain project that the team is working on.

And these teams work with other teams, and people e.g. PMs, designers, customer support etc. when needed.

This is very similar to how OpenAI builds their AI-native teams, just the difference is that the feature lead is called the DRI (directly responsible individual), for both technical and product/business as well.

Eric also mentioned that the teams have support from higher-level engineers e.g. Staff, Principal and Distinguished engineers when needed.

These higher-level engineers are normally also called service leads, they lead specific larger functionalities and ensure that the teams who are building these related projects are aligned with the standards.

Their meetings and process

These teams can generally decide what the best way is to handle meetings and the overall process. Some of these teams work within 2-week sprints, and every team decides how many meetings they need.

Eric mentioned that this is something they are still figuring out and evaluating what the best way to go is, and he sees that alignment is more important than ever. This is what he mentioned:

I’ll be honest, I don’t think we’ve fully figured this out yet. It’s something we’re constantly evaluating to see if there’s a better way to work.

In the past, the biggest bottleneck was writing code, testing it, and getting it into production. Now, the bigger bottleneck is how quickly teams can align and make decisions. The more people you have, the harder that becomes.

That’s why I think frequent communication, like daily stand-ups, is more important than ever. They help teams spot when something is off, when people aren’t aligned, or when they don’t understand why we’re building something.

These stand-up meetings are also less about the technical details and more about timelines, priorities, and cross-team dependencies these days.

Planning also needs to move much faster. Some teams still use traditional 2-week sprints, but a lot can change within those 2 weeks.

Roadmap and prioritization decisions used to happen every couple of weeks. Now, they can happen every few hours. A team might finish something much faster than expected, and suddenly you need to figure out what they should work on next.

My feeling from talking with many different teams is that nobody really has it figured out, and everyone is learning as they go, even Anthropic and OpenAI, they are constantly evaluating and adjusting how they work.

How are they using AI to be more productive?

Read more

This newsletter is sponsored by Unblocked.

[Webinar] How to stop babysitting your agents

Agents can generate code. Getting it right for your system, team conventions, and past decisions is the hard part. You end up wasting time and tokens in the correction loops.

More MCPs, rules, and bigger context windows give agents access to information, but not understanding. The teams pulling ahead have a context layer to give agents exactly what they need for the task at hand.

Join live on Sep 2 (FREE) to see:

• Where teams get stuck on the AI maturity curve and why common fixes fall short

• How a context layer solves for quality, efficiency, and cost

• Live demo: the same coding task with and without a context layer

Register now

Thanks to Unblocked for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

This is something that has been on my mind for quite a while now. It seems like everything these days revolves around “AI”, “AI tools”, “AI productivity”.

• “You need to use this AI tool”

• “You need to be using this AI workflow”

• “Your engineers should be 2x, 5x, or even 10x more productive with AI”

And I get it. AI is changing how we build software, and I use AI tools myself every day as well.

But we’re focusing too much on AI tools alone and not enough on the environment in which the tools are being used. Because there’s something a LOT more important than AI tools, and that’s a great culture.

Throughout my 13+ year career in the engineering industry, I’ve seen both the negative effects of bad culture and the positive effects of a good one. I even felt it myself as an engineer and an engineering manager, when departments spent whole days blaming each other for problems.

So, I am a big believer that everything starts with a good culture, and I’ll tell you all about it in this article.

Let’s start!

"This is very easy to build now that we have AI, and we don't need as many people"

This is a sentence that breaks a good culture and makes people believe that their job is not important. Especially if it comes from an executive, e.g., a CEO, CPO, or even worse, a CTO.

The problem with it is that it totally decreases psychological safety, and everyone starts wondering whether they'll still be needed or not.

But here is an important thing that many people forget:

There is no better productivity hack than a great culture. No AI tools will provide bigger productivity gains.

I’ve unfortunately seen and heard this sentence quite a few times, either directly or from an engineer or engineering leader who has reported that to me.

I think things have gotten a bit better this year, but in 2025 and in early 2026, I heard this many times.

Let’s go more into why this is really problematic.

Without good culture, everything else won’t work well

Many executives believe that AI will just magically increase the productivity of everyone. But the reason that often doesn’t work is Conway’s law. It states:

Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

I mention this law quite a lot in different articles, because it’s just so important. And the reason why it’s particularly relevant in this case is that the overall productivity and the “end product” mimic the overall culture of the organization.

If the culture is bad, the end product will be bad as well, because people just don’t work together well and they don’t communicate properly. But if the culture is good, then often the end product will be good as well.

So, you should always think about good culture as a prerequisite for everything else. And I like to make an analogy to what health is to us, humans. Without health, we can’t do anything else well.

And the same is true for organizations with bad culture, everything else won’t be good as well.

“Other companies are 10x more productive by using this AI tool”

Now, here comes the problem that many people fall into, especially CEOs and other executives. They see either a competitor or some other company reporting 10x higher productivity using a certain AI tool.

They start to panic, they start feeling FOMO (fear of missing out), and they start blaming people around them: “Why don’t we have that same amount of productivity as well?”

A lot of the CEOs are unaware of what kind of problems this may bring. Especially to the culture of the organization. When you start actively “blaming”, it shows to everyone that they are not doing their job well, and that you don’t trust them to make good decisions.

And this especially falls hard on engineers and engineering leaders, as they are often viewed as people who should be initiating AI adoption.

What many CEOs don’t realize is that a lot of the “reporting” of AI increasing productivity by 10x is more or less selling a certain AI product, or a certain partnership where they are promoting the other product.

So, many of the CEOs fall for the trick and make their company culture a lot worse.

My recommendation: Always take a look at what the incentives are behind people saying something, that says a lot about whether it’s true or not.

AI makes good culture even more valuable

Here is another really important point, and many people seem to forget it. As we mentioned, good culture is a prerequisite for everything else. But when it comes to AI, it amplifies everything you already have.

So, both AI and good culture go hand in hand really well together. AI makes bad communication even worse, it also makes bad architecture even worse as well.

But if you have a good culture and good architecture, people will be more productive because they will help each other, and AI will also have a better blueprint of what good looks like because of good architecture.

Always keep this in mind. Just starting to use AI for everything just makes things worse if you don’t have good processes, architecture, and people don’t work together as a team.

Everyone just goes in the wrong direction faster.

This is my recommendation for building a good culture

If you’re wondering whether you have a great culture inside your team or organization, here are some useful questions to answer:

• Do people know what they are responsible for?

• Can they make decisions without unnecessary approvals?

• Do they feel safe challenging leadership?

• Do teams trust each other?

• Are priorities clear?

• Can people disagree constructively?

• Do we reward outcomes?

• Do people understand why they are building something?

• Do we learn from failures, or do we look for someone to blame?

If the answer to these is “Yes”, then you are on a good track to have a good culture. Additionally, here is my personal checklist that I look at when doing an assessment of a certain engineering culture:

Checklist for a great engineering organization

You can find my full checklist for assessing whether a certain engineering organization is great or not.

You can use the same checklist in your case as well. This checklist provides you with a guide on what you should focus on in order to create a great engineering organization where everyone can thrive.

It works for organizations with multiple teams or smaller organizations. You can also use this for a specific team that is part of the bigger organization as well.

Paid subscribers, you can get it here: 🎁 Products for paid subscribers.

Additionally, take a look at how I do a full engineering organization audit in this article:

Now, let’s go to a very important thing next. How to actually message AI adoption correctly, so that you keep a great culture and have everyone excited about using AI tools.

How to correctly message AI adoption

The best messaging I saw (and has worked well) is the following:

What great engineers and engineering leaders do is learn and utilize all different tools that help them do the work better. This hasn’t really changed.

AI is like any other tool that has come out over the years. Use it in your favor to help your team, organization, and the business. That’s what great engineers and engineering leaders do. And it hasn’t changed with AI.

Don’t ever mention something even close to “replacing” or something along the lines of “You are not important anymore, because we have AI”. Those are just going to completely diminish morale and break the entire culture.

When it comes to AI adoption, it only works bottom-up, it never works top-down, and the reason for that is that things are changing so fast, new AI tools are coming out every day, and there needs to be constant exchange of knowledge between everyone.

Always keep this in mind. Trying to “force” people will only result in bad outcomes.

Many people believe that AI adoption happens just by introducing a new tool, and people will just magically become 2-5x more productive. Well, it doesn’t work like that.

AI adoption is not a tooling problem, it’s a leadership problem.

And at the same time, if your goal is to just increase AI usage amongst everyone, you’re basically losing. The goal should always be business success and overall outcomes.

As we mentioned, AI is like any other tool, and we need to treat it that way.

Replacing engineers with AI is not the way to go

I wrote the article called: Companies should hire more engineers in the age of AI, back in July, 2025. And it’s now more true than ever.

I fully believe that the best companies hire more engineers, not fewer, and the reason is that with more people, you exponentially increase your productivity as well.

Of course, the prerequisite is that the company culture is on point. Without it, it won’t work.

Time to market (TTM) is a very important metric in the age of AI, and I strongly believe that the best companies in a specific industry are going to be the ones that are going to move the fastest, make adjustments based on market needs, and provide the best experience for the users.

This was true before the age of AI, and now it’s even more important as things are progressing faster than ever.

So, knowing this, why would you actually restrict yourself with less productivity and less talent?

It’s a huge competitive advantage to be more productive. And I believe being less productive (that you can be) is actually a huge liability, which would result in an overall decrease in market share percentage long-term, in my opinion.

If you believe that “replacing engineers with AI” is a good bet. You’re actually making your company a lot worse that way. That’s my opinion.

Last words

Let’s end this article with the following:

I DON’T think the biggest question for leaders should be: “How do we get everyone to use AI?” The biggest question is:

“How do we build an organization where great people can do their best work, and then use AI to multiply them?”

This is the real question that organizations should be asking and focusing on. Great culture is the biggest productivity hack.

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

• Interested in sponsoring this newsletter? Check the sponsorship options here.

• Check out my book “The Multiplier Mindset” coming out later this year, here.

• Take a look at the cool swag in the Engineering Leadership Store here.

• Want to work with me? You can see all the options here.

Get in touch

You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.

If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

Check the benefits of the paid plan

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.

This newsletter is sponsored by Sonar.

Cut AI coding token costs by up to 36% with Sonar Vortex

Sonar Vortex operates directly within your AI coding agent’s reasoning loop to supply architectural context before any code is written.

By verifying output in real time, it empowers you to build safer, higher-quality software while significantly reducing your LLM spend.

• Slash Token Costs: Testing showed reduced LLM token consumption by up to 36% on coding tasks.

• Reduce Bugs: Lowered software defects by 92%.

• Smarter AI Context: Equip your AI agents with deep architectural context before they generate code.

Make your agents more effective

Thanks to Sonar for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

I’ve been using Shutterstock’s platform for quite some time now. Whenever I needed a stock image, it was usually one of the first places I’d look.

But in recent years, Shutterstock has been adding a lot of new features and capabilities, especially around AI. It seems they went from focusing primarily on the stock content business to a company focusing a lot more on AI/ML.

A similar transformation I’ve seen with Canva as well (just in a different industry).

That was one of the reasons why I was excited to talk with them and learn how they think about building AI-native engineering teams.

I’ve recently had the pleasure of talking to Jefferson Frazer, Director, AI Metadata and Delivery, Shutterstock.

He shared a lot of interesting insights on how Shutterstock works and builds AI-native engineering teams, which I am sharing today in this article.

This is an article for paid subscribers, and here is the full index:

- What does AI-native mean at Shutterstock?
- How big is Shutterstock’s engineering org?
- The structure of their AI-native engineering teams
- The process of AI-native engineering teams
🔒 How are their engineers using AI?
🔒 Advice for writing good prompts
🔒 How do they track token spend?
🔒 What makes an elite versus average engineering team?
🔒 Shutterstock’s engineering culture
🔒 Being vocal and having an opinion is a very important trait
🔒 Hiring process for a new engineer
🔒 Last words

If you haven’t read the articles on how OpenAI and Anthropic build AI-native engineering teams, I highly recommend doing so:

Let’s start!

What does AI-native mean at Shutterstock?

This has now become a standard question that I ask different companies, and the reason is that “AI-native” means different things for everyone. Here is what it means for Jefferson and Shutterstock:

AI-native means that AI is integrated into everything that we do, all the way from coding and architecture to design, and also providing a good experience to our customers.

An interesting thought that he mentioned is that they want to provide the same kind of experience their people have internally using AI tools to Shutterstock’s customers as well. With AI workflows and experiences on their platform.

How big is Shutterstock’s engineering org?

Jefferson mentioned that they have been flattening a bit of their organization over the years, and they want to have an organization that is engineering-heavy.

They have about 350 engineers inside the org, across a lot of different time zones and countries. Their product org is kept purposely small, as they want their product managers to be working across different engineering teams.

And designers work more directly with product managers. The goal is to have the engineering teams autonomous as much as possible, and then bring in additional people when needed.

The structure of their AI-native engineering teams

Their AI-native engineering team structure is similar to Anthropic’s. They also work in a 2-pizza team setup with 5-8 engineers as part of the team and an engineering manager leading the team.

The big difference is that they have about 1 PM for every 2 teams, so the ratio is about 1 PM for 10-15 engineers. Also, product design is not a part of the cross-functional team, and it’s utilized when there’s a need for it in parts of the projects that the teams are working on.

Another big difference is that they have 1 dedicated Tech Lead inside the team, who is responsible for everything technical regarding the projects, but there can also be additional owners of certain projects inside the team, but primarily, one person is the main tech lead of the team.

Jefferson also mentioned that not every engineer is expected to be full-stack, the goal is to have all different skill sets covered in the team, so the team can be as independent as possible.

In practical terms, that means that some engineers may be a lot better in frontend, some better in backend, and then some better in DevOps, AI/ML, etc.

And one important thing as well is that they encourage their engineers to change teams if that’s their preference, in order to grow and develop various skill sets. To quote from Jefferson:

I can think of at least a dozen folks internally who have spread their wings and moved into different teams, picked up new languages, started working on front-end when they were back-end engineers, etc., and really developed their careers here.

The process of AI-native engineering teams

Their product teams work within 2-week sprints and use Scrum as their way of working, which is the same as traditional teams.

So, they have all the meetings like traditional teams: daily meetings, planning, retrospectives, etc. And there’s also a sprint demo meeting at the end of every sprint.

Additionally, at Shutterstock, they also have dedicated ML engineering teams, and they work a lot differently than product teams.

These teams work within 6-week “bet cycles”, where they focus on achieving a certain goal within the 6 weeks. No Scrum or Kanban.

The reason for quite a different workflow than with product teams is that ML work is a lot more unpredictable, and you can’t really promise certain outcomes in X amount of time. You see what may be possible based on the research that you do.

How are their engineers using AI?

Read more

This newsletter is sponsored by Atono.

AI is definitely making engineers ship faster than ever. But AI-generated specs keep coming back with questions. And the problem is the missing product context, understanding in detail, how the product should actually work.

In this recorded webinar from Product School’s AI Builder Week, Doug, CPO at Atono, shows how important giving AI real product context is.

In the webinar, you’ll learn:

• Why your AI keeps guessing and how product context fixes it

• How to ground AI in your actual product decisions and architecture

• When your spec is actually ready to hand off to engineering

Get the recording

Thanks to Atono for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

I like to say that good managers are hard to find, and once you have them, they should be appreciated. The reason is that managers have a big impact on you and can be the reason you are having a great time at work or not.

And I also like to say that: “Engineering is a lot more about people than just tech” (I also wear a T-shirt with that sign as well!). Conway’s law is very real, as it states:

The structure of a system is determined by the communication patterns of the people who design it.

We can translate this to the following: The greater the communication + culture of the organization, the better the end product is going to be.

Therefore, good managers play an extremely important role in the success of any engineering organization. But how do you actually determine whether you have a good manager or not?

Luckily, Ryan Murphy will share with us today his insights from his experience both as an engineer and engineering leader.

Let’s introduce our guest author and get started!

Introducing Ryan Murphy

Ryan Murphy has about 20 years of experience, both as an engineer and engineering leader, most recently leaving Yelp after 5 years as an Engineering Manager to be a founder of EM Accelerator (use code GREGOR for 25% off).

I know Ryan for quite some time now, and we chat on different occasions, he’s also a planned tech reviewier for my upcoming book The Multiplier Mindset. Therefore, I am happy to share his insights in today’s article.

Over to you, Ryan!

When your manager tells you, “You are a resource”

When I was a mid-level engineer, I got my first big job outside of my small hometown. My new job was working for a stockbroker in London.

Something I had dreamt of since I started coding at age 11, building my own games website so I could bypass the school internet filters and play games in computer lessons.

On my first day in that job, my manager took me into a meeting room for the usual “Hey, how are you? Welcome” induction. At the end of that meeting, he said to me, “Remember, you are a resource here”.

Thinking back, his body language and tone were as if he was trying to make a power move over an early-20s mid-level engineer who was just here because he loved to code.

I didn’t notice anything weird at that time, I didn’t immediately flag that as a red flag. I just shook my head and said, “Absolutely”. I was naive, because it was my first big job in a company that actually had any structure, any semblance of formal management, so I had no idea how this really went in the real world.

For me, as far as I knew, this was completely expected behavior from a manager. I was extremely vulnerable, and that was taken advantage of by someone who was looking to assert their dominance and make sure I knew they were the person higher up in the food chain.

We expect people to manage others’ careers but don’t train them

This manager, I later found out, was a newly promoted manager. This is the same manager who told me in a 1:1 that I had the green light for some external training course, and then later rescinded that, saying the exact words: “My promise is worth the paper it’s written on”.

Thinking back now, and typing that, that’s crazy. Absolutely bonkers. My guess is that as you are reading this, at least some of you are reminiscing about your own horror stories. Nearly everyone has stories of awful managers who shaped how they think and behave in today’s workplace.

We are putting people into positions where, let’s face it, they have a significant impact on people’s careers and lives (no matter how much you preach about work/life boundaries, if you are having a tough time at work, this does bleed into your personal life), and we are not training them?

It’s a significant bottleneck in our team topologies, and we need to stamp it out.

How many managers have you ever met that had training outside of HR mandated internal training? Which is effectively just there to make sure managers act in formal situations according to the HR playbook.

This isn’t just me being emotional or sprouting opinion, according to a study from the Chartered Management Institute (CMI) in partnership with YouGov, 82% of workers in the UK entering management positions have not had any formal management and leadership training.

If you are joining a team that has a new manager, there is an 82% chance that this person, who holds significant sway over your well-being and career during your time with them, is untrained.

When I write it out like that, I find it impossible to come up with a reasonable defense.

It’s the team that suffers

The new managers eventually learn. Given enough time and enough hard-fought moments to learn from, they learn that this role is about being an enabler.

The role is all about delivering business value, about letting go of what made you a good IC, about understanding that a happy team has a much higher chance of being a high-performing team, and, in interesting contrast, perhaps that making the tough decisions and failing early on initiatives and/or people is actually in the best interest of the team.

And also understanding that psychological safety isn’t just a fluffy word thrown about for points and so much more.

All that time, the people who are really bearing the brunt of the “on-the-job” learning is the team of engineers:

• Whose careers stall because the manager doesn’t know how to advocate for them.

• Who get left in limbo because the manager doesn’t know how to coach them on stakeholder communication.

• Who are stuck without leadership opportunities because their manager can’t let go of the critical path.

• Who don’t feel safe to speak up because wellbeing is seen as a secondary citizen.

• Who are stuck with the kind of manager who assumes that this role means they are an engineering leader now.

• Who are building bad habits and creating silos because their manager doesn’t know how to have difficult conversations.

These are just some purposefully obtuse examples to get a point across.

What are the signs your manager is actually good?

There are managers, even when trained, who are not good, who just can’t let go of that autocratic nature and give the excuse, “My standards are just so high, and people can’t handle that”.

There are managers, even when untrained, who are inspiring, who just seem to be really good at learning what good looks like, both when wearing their leadership hat and management hat.

In the paper titled The Value of Bosses, published in the Journal of Labor Economics, Lazear, Shaw, and Stanton measured that replacing a boss in the bottom 10% of quality with a boss in the top 10% of quality raises the team’s total output by more than adding a whole new worker to a team of 9 people.

An increase in output is greater than an 11% increase in headcount.

There are signs you can look out for to see which side of the fence your manager, or you, sit on. I’ll be sharing the top 3 examples that I believe define a good manager the most.

1. Treats you like an adult

Everyone has worked in a culture where it seems like you need permission to go to the toilet.

I once worked for an agency where we got a 30-minute lunch break, and I was once 6 minutes over the lunch break one day, and the lead developer was told to watch my timekeeping (I was 20 minutes early that day, and stayed an hour past when I was contracted).

I also worked for a company where a junior engineer asked to come in 2 hours late (he pointed out he would stay late) so he could attend a doctor’s appointment. The boss said no, and that he needed to do it outside of work time or take a day’s holiday.

When the junior went on to explain that it was to take his Mum to a breast cancer screening, the boss stood his ground. I left that company within 3 months.

That same boss said to me on my last day, “I think in hindsight you will see you are making a mistake”. The ego was unbelievable.

A boss who doesn’t treat you like an adult is a problem that is shared by many, and I can prove that by showing you my most viral post ever.

In 4 years of creating content, I have not had a post that resonated like this. ~80k likes, >4k reshares, and nearly 30 million impressions made it clear to me that I wasn’t alone here.

This is a universal problem, and it’s why it has to go at the top of the list on how to tell if your manager is actually good.

Do they understand that to achieve our best work, we need to work to outcomes, not hours at desk?

Do they understand that if having 2 hours away from your desk one day every now and then to attend a cancer screening with your Mum is such a productivity issue that’s actually a them problem, not a you problem?

Do they understand that people make mistakes and that we should always, as managers, assume good intentions rather than be suspicious?

2. They are not the atmosphere

Have you ever been in a team where the manager completely defines the mood? If they wake up in a bad mood, then your day is ruined. If they mismanage their priorities, then suddenly it’s your problem and sometimes made to be your fault.

If they are in a great mood one day, then that’s how they feel they always come to work, because their consciousness is biased to the moments they present themselves best.

This is another way to tell if your manager is actually good.

Don’t get me wrong, we all have emotions, and I am actually a strong believer that some of the best leaders are highly emotional. My argument isn’t against managers having emotions. It’s when that leads them to negatively affect others’ careers.

In this scenario, these managers one week turn up fully to your 1:1, and the next week, just when you need the help the most, they cancel the 1:1, or they are checking their Slack constantly in your meeting with them.

There is little chance of consistency. Constantly blaming the “nature of this work and the modern world” rather than taking ownership and looking to put systems in place to make sure people get an unbiased and fair representation of them every time they need them.

To illustrate this, when I worked in France, I had someone on the leadership team who would define the mood of the whole office. On good days, everyone got pastries and lunch, good talks, and future thinking workshops.

On bad days, when they were hungover, everyone just sat in complete silence, shut up, and tried not to be seen, as it was known that people could be fired on the spot on those days if it was severe enough.

3. They don’t just give feedback

One of the hardest parts of being a manager is having difficult conversations and giving feedback.

Every single new manager that has ever existed has tried to look for an excuse, any excuse, to delay some difficult conversations, and thought to themselves: “Let’s give it another 2 weeks and see”.

With enough practice, and enough lessons, you get better at it, and understand that, when you give feedback the right way, it’s actually an act of kindness more.

A common trap I see is that a lot of managers leave the conversation at the feedback and eventually the measurement of improvement. The conversation might go:

“I noticed in your weekly update to the senior leadership team that you gave too much unnecessary detail, and the feedback I have got is that it’s hard to tell at a glance the status of the project and any actions the recipients needed to take”.

A few more words might be exchanged, some guidelines perhaps, best practices shared over 5 minutes, and left there. The missing part of the conversation is:

“...I’m sorry for not sitting down with you earlier to go through this, let me book some time on our calendars whilst we are both in the room before the next update is due so we can have a live coaching session on how we might communicate to different stakeholders. We can have as many sessions over the coming weeks as you like.”

Notice the difference between the first one of just giving the feedback, and the second addition of a manager who actually wants to help them succeed and goes out of their way to try and make that happen.

I could go into more detail on feedback, such as the importance of giving it early, the SBI technique, etc., but the point I wanted to make here is that a way to tell if your manager is actually good is if they don’t just look to pass the buck and think that’s the job done, but actively help you grow.

They give feedback but also take that as an opportunity to coach. They take an active stake in your improvement.

Final thoughts

I knew the stats for untrained new managers were high, but when I was researching for this article and read that 82% of new managers are untrained and that a good manager can have more of an impact than just adding more headcount, it did surprise me.

Training for managers doesn’t automatically mean they will be a good manager. I know several untrained managers who I firmly believe are better natural leaders than I will ever be.

We must still be looking to give everyone a baseline of what is expected, and the raw materials to do the job so the team doesn’t bear the brunt of their “on-the-job” learning.

I think we can move past the norm I see in tech that the most training new managers ever get is internal training, which, let’s face it, is just HR’s way of making sure managers are accountable for ensuring certain formalities play out the way HR wants them to.

Last words

Special thanks to Ryan for sharing these insights with us! Make sure to check him out on LinkedIn, and check out EM Accelerator for more insights on engineering management.

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

• Interested in sponsoring this newsletter? Check the sponsorship options here.

• Check out my book “The Multiplier Mindset” coming out later this year, here.

• Take a look at the cool swag in the Engineering Leadership Store here.

• Want to work with me? You can see all the options here.

Get in touch

You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.

If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

Check the benefits of the paid plan

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.

Intro

The Forward Deployed Engineer (FDE) role has gained a lot of popularity in recent years, and OpenAI is a good example of fast scaling of their FDE organization.

Additionally, they recently built a separate entity called the OpenAI Deployment Company, focused on helping customers use OpenAI’s products.

I had the pleasure of talking with Colin Jarvis, Global Head of Forward Deployed Engineering at OpenAI.

We talked all about how their team works, what makes a great FDE, how they work with customers, and how engineers can prepare for the role.

This is an article for paid subscribers, and here is the full index:
- How OpenAI built its forward deployed engineering organization
- Forward deployed engineer role at OpenAI
- What does an FDE do on a daily basis?
- About 50% of their time is spent on the customer site
🔒 The hiring process for a new FDE
🔒 Onboarding process for a new FDE
🔒 What makes an FDE successful
🔒 Moving from a software engineer to FDE, how to prepare?
🔒 Last words

Let’s start!

How OpenAI built its forward deployed engineering organization

OpenAI started the forward deployed engineering organization last year, with a focus on gathering insights from customers, learning what the use cases are, and bringing the insights back to product and research.

They started with just 2 people and have now grown to around 140 people in the FDE org. The FDE org sits between the GTM (go-to-market) org and product and research, working with both of them, acting as a “link”.

After some time working with different customers, they have noticed repeatable problems that people and companies are dealing with, and that’s also the reason why they recently started OpenAI Deployment Company (which is a separate entity, but still part of OpenAI).

It has now grown to about 200 people, and I suspect it’s going to grow a lot more in the future. Its goal is entirely to help solve customer problems, which is at the core of what FDE is all about.

Colin mentioned that they intentionally want to keep the internal FDE org at OpenAI relatively small and focused on getting insights for the product and research, but they want to keep expanding the OpenAI Deployment Company in order to support the customers in need of integrating their products.

Now, let’s get more into the FDE role in general.

Forward deployed engineer role at OpenAI

When I asked Colin on how he’d define the FDE role at OpenAI, he mentioned the following:

A forward deployed engineer is focused on outcomes. Which means that their goal should be to work on problems where solving them has a much bigger impact than the work itself.

So, in practical terms, the value is not in writing code, instead, the focus is to solve the problem and, ideally, make themselves obsolete as well, so they are not needed anymore.

And if they are needed again (for the same problem), that usually means that the problem has not been solved entirely.

They want strong software engineers, but at the same time also good communicators, who can really dig into what the actual problem is and explain the solution in a way that resonates with everyone.

And (ideally), these engineers would also have some domain expertise in the field that the specific customer operates in.

For example, a software engineer who has worked in the fintech industry could be a great fit for an FDE helping out a customer who works in fintech, because they understand the domain.

However, an important thing that Colin mentioned is that they want to mix the domain experts and FDEs, who are not. And the reason is that a person who is not an expert in the specific industry, but has experience from another, is going to be much more likely to “challenge the status quo” and have unique ideas to solve certain problems.

What does an FDE do on a daily basis?

Colin shared an example of a project they are working on at the moment in Japan, specifically for “code modernization”. That specific customer has a lot of legacy applications, and migrating one of these systems can cost hundreds of millions of dollars.

They are helping that customer with the migration from older tech to the new tech using AI.

An FDE might spend the full day talking with the payments team to understand what specific things are important to them so that the migration would be successful.

And then the next day, start building tests based on the insights shared from the payments team in order to ensure that the migration is actually successful.

And then another day they might be writing actual migration code, or building the UI to show the progress of the migration, and/or specific steps of it.

So the role is really a mix of engineering and working directly with domain experts (and also having a good understanding of that field), going back and forth between the two.

There’s also a feedback loop with the product and research teams that’s important. And in this specific project, they found out that a specific model used for the migration kept making some simple mistakes.

And as Colin mentioned, they don’t just send the exact customer problem back to the research team. They try to be as specific as possible, for example: “The model struggles with these types of COBOL-to-Java tasks. We need more training data around these examples.”

They’ll do whatever is needed to make a certain customer successful, but the bigger goal is to make sure the model keeps getting better for every customer.

About 50% of their time is spent on the customer site

They generally tell new joiners to expect around 50% of their time on site.

But also, as Colin mentioned, it varies by project. For example, some of their people in the UAE are on site around 80% of the time. People based in Europe or the US might spend 2-3 weeks per month with customers. In Japan, people are also on site around 80% of the time.

But in general, they focus on trying to have the biggest impact possible when on-site, and they’d rather spend 2 or 3 impactful days instead of 4-5 less impactful.

And also, a lot of their customers are spread across different locations, so being on-site all the time isn’t practical. But, as a general guideline, around 50% of the time on-site is a good estimate.

The hiring process for a new FDE

Read more

This week’s newsletter is sponsored by Unblocked.

[Webinar] Can you prove AI is working?

AI is in your engineering workflow. While the token spend shows it, the throughput doesn’t. The human is very much still in the loop, and that’s a context problem.

Join live on Aug 19 (FREE) to learn:

• The 4 metrics to measure the gap where gains leak out before production.

• The 8 stages of context maturity, the specific walls capping your metrics, and a free tool to pinpoint where your team is.

• Why more MCPs and bigger context windows aren’t enough, and what it takes to get real value from your agents.

Register now

Thanks to Unblocked for sponsoring this newsletter. Let’s get back to this week’s thought!

Intro

What I’ve seen happen many times in my career:

A new startup builds their services with “modern” architecture, and of course, in the beginning, the costs are “free” due to the startup credits being given for a certain period of time.

But then, once the free credits are gone, they get surprised with a huge bill. Then, they try to ruthlessly optimize the costs, but often it’s too late. The architectural choices have been made, and switching becomes a lot harder.

It’s really important to keep in mind and have control of the cost of your tools and always try to optimize your spend-to-value ratio.

It’s especially important for all the startups that are just starting. The main focus should be on getting to product-market fit, not skyrocketing your bill for cloud costs.

In today’s article, we’ll go through a real-world case study of how John Gallagher, a seasoned engineering professional, optimized observability costs without losing value.

Let’s introduce our guest author and get started!

Introducing John Gallagher

John Gallagher is a principal engineer, consultant, and coach/mentor, focusing on helping engineering teams to improve production stability.

Today, John will share how to spot the potential red flags, reduce signal noise, and lower monthly cloud bill on observability tools.

Over to you, John!

The accidental discovery

I’ve always been interested in how much companies cost to run. I’d worked on introducing observability into our company and knew that observability tooling can be costly.

So one afternoon, out of curiosity, I pulled up our observability bill to see how things were trending. At first glance, everything seemed normal. Month over month, the increase was modest: maybe 8–10% each month.

But then I looked at a six-month view. Our costs had gone from around $1,000 per month to around $2,500 per month.

I thought about what had changed in that time:

• Our team had grown from 10 to 12 engineers.

• Our traffic had reduced.

• We’d only slightly increased usage of the tool.

Something didn’t add up. We weren’t getting 2.5x the value from our observability tool, yet we were paying 2.5x more for it.

This wasn’t a crisis. Nobody was breathing down my neck about costs. But I had a nagging feeling that we were slowly leaking money, so I started digging.

The granularity cliff

The $2,500 on our bill was broken down into traces, metrics, and logs. Beyond that, detail was hard to find.

Most observability tools give high-level billing reports. In the tool we used, I could get costs by service. That wasn’t enough, as I needed to answer more deeper questions:

• Which signals were consuming most of our budget?

• Within each signal, was there duplicate data?

• Which data was valuable and which was noise?

The billing report alone, didn’t give me this level of detail. I’d reached the edge of what I call the granularity cliff.

Many engineering leaders stop here. They don’t have time to dig into the details. Even when they do, they often lack the knowledge of the observability tool’s query language or the ability to group, filter, and analyze logs at scale.

Earlier in my career, I fell off this cliff constantly. I’d see the $2,500, feel a bit uncomfortable, and not know what to do next. So I’d just ignore it and work on other tasks. There was always something more urgent to work on.

But this time I wanted to take a different approach. I resolved to tackle the cost issue head on. I went through 6 steps.

Step 1: Understand the cost model

Before I could lower our costs, I needed to understand how our observability vendor charged us. Different vendors have different pricing models:

• Per-event pricing

You pay based on the number of log events ingested. Each signal costs you money, regardless of how much data is in it.

• Per-data-volume pricing

You pay based on the total size of data ingested. A 10KB log costs you more than a 1KB log.

• A hybrid model

You pay based on some combination of events and volume, or you pay tiered pricing based on retention.

We were on per-event pricing with our tool. This meant that the number of log lines mattered much more than the size of each log. A 1KB log and a 10KB log cost us exactly the same.

This directed my optimization strategy.

If we would have been on per-data-volume pricing, I would be focusing on reducing log size. But since we were on per-event pricing, I needed to reduce the number of logs.

Understanding which pricing model is being applied before optimizing is crucial! A strategy that work for one model can be completely wrong for another.

Step 2: Choose the signal to optimize

Observability tools can include multiple signals, such as logs, metrics, traces, synthetics, user monitoring, profiling, etc.

Each signal has its specific cost structure and there’s a different strategy to optimize each. I chose to focus on logs for 3 reasons:

1. Most control

We wrote the code that generated the logs. I could change them directly.

2. Good familiarity

I understood logging deeply. I’d written most of our logging myself.

3. Optimized elsewhere

We’d already reduced our tracing sampling to 15% (the minimum we could responsibly manage with head sampling). Metrics had been cleaned up after an earlier incident where high-cardinality dimensions exploded our costs.

But I didn’t try to optimize everything at once. I picked the signal where I had the most leverage and went deep on that first.

Step 3: Group the data to identify potential waste

I needed a simple way of figuring out which logs had the most volume. I started off grouping by the log message. Grouping by message meant that I could see a broad picture of where we were spending the most.

We had structured logs, so I could have started with any other attribute, but message is the one field that all logs tend to have, so it gave me a good overview.

However, there’s a big problem with grouping by message. Messages were often unique because they contained variable data:

User 12345 logged in from 192.168.1.1
User 67890 logged in from 10.0.0.5
User 11111 logged in from 172.16.0.1

These are 3 different messages, but they are probably coming from the same source, because they have the same pattern: “User X logged in from Y.”

Some observability tools can detect these message patterns by figuring out whether certain parts of the message are variable, such as user IDs, IP addresses, and timestamps. Our observability tool supported this, and it was invaluable. Instead of the 3 log messages above, I’d see a pattern of:

User /d+ logged in from /d+\./d+\./d+\./d+

I sorted by the number of logs in these patterns, which allowed me to see the highest-volume patterns.

I then categorized each message pattern from wasteful to valuable. Agonizing over “not sure” message patterns became a distraction and time sink, so if the value wasn’t immediately apparent, I categorized it as “unknown.”

As I went through the top 50 highest-volume message patterns, I found that:

• ~40% were valuable (e.g., request logs, error logs, critical business events).

• ~50% were unknown.

• ~10% were waste (health checks, statistics, debug logs from third parties).

It became clear then that the sky-high costs weren’t caused by one or two wasteful log patterns. They were from 10–15 lower-volume patterns that had accumulated over time.

Each wasteful log seemed insignificant. But added together, they were costing us $1,500 per month, or $18,000 per year. This was death by a thousand paper cuts.

Step 4: Check the value of the data

I needed to be sure that no other team members were using the logs that seemed obviously useless to me. For every log I classified as waste, I checked:

• Dashboards: Is this log field used in any dashboard?

• Alerts: Is this log pattern referenced in any alerting rules?

• Querying: Is this log used regularly to answer questions?

For dashboards and alerts, our observability tool let me trace a log backward to see where it was used.

For tools without that capability, I’d suggest taking the dashboards and alerts that are most used by the team and manually listing out all the logs they use.

I also looked at our incident postmortems and debugging sessions to see which log queries engineers were actually running when there was an outage.

If I wasn’t sure, I erred on the side of caution and kept the log. At this point, I had two lists: log patterns to remove and log patterns to keep.

Step 5: Remove instrumentation generating noise

For each log pattern to remove, I made a separate code change. I wanted to be able to deploy each change independently, monitoring the impact of each change in isolation. That way I could easily roll back if something went wrong.

So I followed 3 steps.

Step 5.1. Change the code to stop logging

I discovered 3 sources of wasteful logging:

• Codebase

• Library

• Third-party vendors

Source 1: Codebase

The easiest logs to remove were in our code. I searched our app codebase for the wasteful log message pattern.

• If I could identify the logging code, the change was easy: Delete the code, update any tests, and deploy.

• If the logging wasn’t coming from our code, I moved on to the next source.

Source 2: Library

Next, I searched for the log pattern within the libraries our app depended on.

Instrumentation in libraries is more difficult to remove. We didn’t have control over these codebases directly. If I wanted to remove all logging from the library, I would often disable logging using configuration the library exposed.

But in other cases, I needed to make more fine-grained adjustments, or the library wouldn’t expose the relevant configuration. In these cases, I resorted to configuring our logger instead of the library.

In one example I’ll go into later, I needed to filter out the log message “OK.” Instead of configuring the offending library, which proved impossible, I configured our logger to block that exact message.

Source 3: Third-party vendors

If the log didn’t come from our code or a library, it was likely coming from a third-party vendor. Vendors such as AWS, Google, Heroku, Segment, Stripe, and Cloudflare allow their logs to be sent to an external observability tool.

I found some instances where this logging integration had been set up years ago and then forgotten.

There are some obvious clues to look out for in these cases. Often the log to remove would have an attribute such as “app,” “service,” or “source” to indicate that the log was coming from an external vendor.

Other times I needed to do deeper detective work. I would look at all the dashboards of our third-party vendors and check for event webhooks or other related settings. This allowed me to see integrations that I could either switch off or tweak to reduce log volumes.

Last resort: Blocking at ingest

Even in our modestly sized codebase, there were times when I couldn’t figure out exactly where a log was coming from.

In those cases, I blocked the logs at the observability tool. This solution is entirely specific to the observability tool, so it’s my least favourite option and a last resort.

Double-check that these blocked signals won’t count toward your cost. Some tools allow you to block, but the data ingest is still billed, which isn’t that useful to cost savings.

Step 5.2. Deploy it to production

Once I updated the code, I deployed it to production through a PR that other team members could review. I generally tagged one other team member who I knew could respond quickly.

Step 5.3. Watch whether the log volume dropped

I searched for the log pattern I’d removed in our observability tool. When the code was deployed, I was looking for the volume to drop to zero.

Previously I’d created log events for when our app was deployed, so I could see the connection between my code being deployed and the logs disappearing.

If the wasteful log patterns didn’t go to zero, it implied I’d made a mistake. In those cases, I’d adjust the code and try again.

In some cases, I kept an additional eye on other dashboards and alerts to make sure everything was still working.

Step 6: Monitor Usage

Cost optimization isn’t a “one and done.” Keeping costs in check requires ongoing attention.

Once the large volume of wasteful log patterns had been removed, I regularly queried for log message patterns once a month. When I saw suspicious patterns with high volumes, I investigated further and kept on top of costs.

Many of the biggest sources of waste arose from my ignorance, so checking the logs every month allowed me to keep an eye on what was being logged and nip any other cost problems in the bud.

Examples of common waste

I was surprised at some of the low-hanging fruit that was wasting our precious operational budget. If you audit your observability costs, you might be surprised, too.

I uncovered 3 eye-opening examples of waste.

1. The “OK” log message

When going through the top 10 log patterns, one pattern stuck out, appearing over 100 million times per month:

OK.

What?! Clearly this was a useless message.

Investigating further, I discovered that this message was from a third-party library we’d added a few months ago. Buried deep in the library was a health check that ran every few seconds. When the health check passed, it logged a single word: “OK.”

This health check was completely invisible to us. It was built into the library, and we’d never noticed that it was costing us hundreds of dollars per month.

2. The statistics spam

When I looked at the next pattern with highest volume, I saw logs containing IP addresses and some additional numbers:

Stats: 192.168.1.45, requests: 1247, latency: 123ms, errors: 2
Stats: 10.0.0.12, requests: 891, latency: 145ms, errors: 0

This time, the library was logging performance statistics in plain text. We were paying hundreds of dollars a month to store statistics that we couldn’t analyze and never used.

3. The metrics mistake

Before I even started this logging optimization, I had had an expensive lesson with metrics. I’d added a metric to track the p95 response time for each endpoint in our Ruby on Rails app. I had tagged the metric with the controller and action of the request.

What I didn’t realize was that we had more than 200 unique combinations of controller and action. Each combination created a separate time series. And in our observability tool, we paid per time series.

This one metric was on track to costing us $800 within three weeks.

I’d fundamentally misunderstood how metric costs work. The larger the number of unique tags for a metric, the more it costs, and it scales linearly.

Thankfully, my manager caught it early and notified me by Slack message.

The solution? Derive this metric from our logs on demand. We didn’t need to store it as a metric at all. We removed the metric immediately.

My lesson: High-cardinality dimensions on metrics can destroy a budget.

The Results

From this purely self-directed project that I worked on during slack time, I discovered that we were wasting precious operational budget on observability because we were too busy shipping features to review our costs.

I had invested just two days of engineering time, spread over 2–3 weeks and interspersed with regular project work, to find those savings.

Removing the logs caused zero production incidents, and we didn’t need any rollbacks. In fact, the team didn’t even notice the changes.

Observability cost optimization is all about optimizing value versus cost. The key is asking: “Are we getting value proportional to what we’re spending?”

Last words

Many thanks to John for sharing these insights with us! Learn more about him on his Linktr.ee page. Additionally, you can also go through John’s observability spend assessment to gain a better understanding of how you can lower your costs.

We are not over yet!

Why Engineers Must Become Multipliers in the AI Era (6 Important Trends)

The recording of my recent talk at the TechLead conference in Amsterdam in June 2026 is now available. I’ve talked about how the role of engineers is evolving in the AI era.

As development tools become more powerful and accessible, the expectations for engineers are shifting from simply writing code to creating meaningful impact across teams and organizations.

The 6 important trends in software engineers points exactly in this direction.

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

• Interested in sponsoring this newsletter? Check the sponsorship options here.

• Check out my book “The Multiplier Mindset” coming out later this year, here.

• Take a look at the cool swag in the Engineering Leadership Store here.

• Want to work with me? You can see all the options here.

Get in touch

You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.

If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

Check the benefits of the paid plan

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.

Intro

Back in December, 2022, based on your feedback, I wrote an article that has been very useful: How to have great 1:1 meetings. Also, the template included has been the most downloaded out of all.

And because the article has been helpful, I decided to do a 2026 extended version of it. So, in today’s article, I am sharing how to have great 1:1 meetings in 2026 and beyond.

This article is written from the perspective of a manager who is organizing and having 1:1 meetings with their direct reports.

It’s also important to mention that in many companies in 2026, a team lead or a tech lead may have 1:1 meetings with their team members, but they are not directly reporting to them. It works from this perspective as well.

This is an article for paid subscribers, and here is the full index:
- What has changed for 1:1 meetings in 2026?
- Make sure to schedule all your 1:1 meetings in advance
- Be on time
- Get your own 1:1 Notion template that I use
🔒 Meeting agenda
🔒 Focus on objectives, goals, and career development
🔒 Meeting notes
🔒 Last words

Let’s start!

Ready, Spec, Ship Hackathon with Kiro

I am happy to share that I will be a judge at the Ready, Spec, Ship Hackathon with Kiro.

There is a $9,600 prize pool available for the top 3 submissions. You can enter solo or form a team of up to three people. Build something ambitious, creative, useful, or completely unexpected with Kiro.

Excited to see all the great stuff being built alongside my fellow judges John Crickett and Angie Jones. Check out the details and enter here:

Check the details

Looking forward to seeing what you’ll build!

What has changed for 1:1 meetings in 2026?

Well, interestingly, not that much. I still use the same template for all the 1:1 meetings I have, and that’s also what I recommend. I’ve been a big fan of Notion for a while now (dating back to 2020), so I’ve been using the same Notion template for more than 6 years now.

Additionally, what I would say has changed the most is that while I keep all the 1:1 meetings very personal and human, I’d occasionally use AI to help me generate ideas for discussion points, brainstorm action items, and help frame certain feedback better.

While I find this helpful, I wouldn’t say AI has been remotely close to an important part of the 1:1 preparation. My goal with every 1:1 meeting is that I build a better working relationship, and that we can openly talk about things. Not try to AI-generate feedback, and sound like a robot.

Additionally, an important shift I notice in comparison to having 1:1 meetings today versus in 2022 is that it’s really important to acknowledge the shift that is happening in the industry with AI.

And it’s even more important to be a good manager and a leader at this time. That’s also one of the biggest differences about how people feel at work these days, in my opinion. The team they are a part of, and the manager they have.

So, with a lot more uncertainty about the future, it’s important to really be there for your team, have great 1:1 meetings, acknowledge the uncertainties, and do your best to support everyone.

Now that we understand some of the differences, let’s start with the basics.

Make sure to schedule all your 1:1 meetings in advance

So, that’s the first thing you should do, it’s important that you have a regular cadence of 1:1 meetings, and that you don’t just schedule them sporadically.

The reason is that if a meeting just shows up in the middle of the week, your report might feel like something bad would happen in a meeting, and they would be unnecessarily worried about it, which can cause a lot of stress.

As a full-time CTO, I heavily stuck to separating my time into manager time and maker time, with the manager time used for meetings, alignments, and slack/emails, while the maker time was for head-down time for deep work.

I organized all my 1:1 meetings on the same day, one after another, with a bit of a break in between. I usually prepared the day before for the 1:1 meetings the next day. A 30-minute meeting is also a standard for a 1:1 meeting.

You can read a full overview of how I organized my time as a full-time CTO in this article:

Checking in with your reports to see if that specific time works for them is also my suggestion, so it doesn’t feel like the time is forced. And in general, this meeting is for your report, not for you, so finding the right time that works for them is important.

Be on time

I’ve had a lot of 1:1s with the managers, who just showed up late to the 1:1 meeting. Sometimes, they would send a message that they’d be late, another time, they would just show up late, with just 15 minutes left in the meeting.

Experiencing that, I focus a lot on being on time as much as I can. Of course I am not always perfect, and it happened to me as well. But at least if I’m late, I send a message. But I do my very best to be on time for the meeting.

Everyone’s time is important, not only yours. And if you treat people like their time is not important, it’s not a good look, and it’s an awful way of building a good professional relationship.

Don’t try to justify that you are a “manager” and that you’re very busy. How you treat your people on a daily basis tells me everything about what kind of manager you are.

Always keep this in mind.

Get your own 1:1 Notion template that I use

This is the exact template that I have been using for the past 6 years, and it works great!

If you want to always be prepared for your 1:1 meetings and need a system to organize all of your notes, make sure to use this template.

Paid subscribers, you can get it here: 🎁 Premium products for paid subscribers.

Meeting agenda

Read more

This week’s newsletter is sponsored by Unblocked.

[Webinar] Can you prove AI is working?

AI is in your engineering workflow. While the token spend shows it, the throughput doesn’t. The human is very much still in the loop, and that’s a context problem.

Join live on Aug 19 (FREE) to learn:

• The 4 metrics to measure the gap where gains leak out before production.

• The 8 stages of context maturity, the specific walls capping your metrics, and a free tool to pinpoint where your team is.

• Why more MCPs and bigger context windows aren’t enough, and what it takes to get real value from your agents.

Register now

Thanks to Unblocked for sponsoring this newsletter. Let’s get back to this week’s thought!

Intro

AI has definitely changed what it means to be a great engineer. Some time ago, you could be considered a great engineer just by being good at a certain programming language and/or specific framework.

Today, a lot of the expected work of software engineers is actually more aligned with being a Tech Lead and a multiplier for others (making everyone around you better). You can read all about this specific shift in this article:

In today’s article, we’re focusing on how you can utilize AI to be more efficient and productive in your day-to-day work, while providing more impact and making everyone around you more effective.

This is an article for paid subscribers, and here is the full index:
- What is an engineering multiplier?
- How to be an effective engineering multiplier?
- There are 3 camps of engineers and engineering leaders when it comes to using AI
- Engineering multipliers use AI to help them be successful, but they don’t delegate their judgment
🔒 This is how you can utilize AI to be a multiplier
🔒 Learn faster using AI
🔒 Think through difficult problems
🔒 Write better code
🔒 Communicate more effectively
🔒 Find relevant information quickly
🔒 Coaching and leading your team
🔒 Make better decisions overall (especially data-driven)
🔒 Automate repetitive work
🔒 Last words

Let’s start!

My Upcoming Book “The Multiplier Mindset” Published by O’Reilly

This article is an adapted version of one of the chapters of my upcoming book called “The Multiplier Mindset”, published by O’Reilly. The book will be published later this year!

Learn more about the book

What is an engineering multiplier?

As tools for development got better, the desired skills for engineers have moved from just pure knowing programming languages and frameworks (expected) to problem-solving abilities and people skills.

It's less about the tasks, but how big an impact you can create. And engineers who can create the biggest impact have the multiplier mindset.

It's the mindset where you focus less on just your pure individual tasks, but you focus on how you can make things better for your whole team, organization, and, of course, the customers (users).

I like the term “Engineering Multiplier” because it’s a mix of “Engineering” and “Force Multiplier”, which fundamentally connects the two together.

Being an engineering multiplier means being someone who amplifies the productivity and effectiveness of the engineers around them, not just focusing on their own output, but elevating the entire team.

An engineering multiplier doesn’t just ask, “What can I build?”, they ask, “How can I make everyone around me more effective?”.

How to be an effective engineering multiplier?

As you can see from the picture above, the 2 main focus areas that are important in the AI era to become an engineering multiplier are:

• Human-related skills and

• Problem-solving abilities

And here is the visual of the most important areas:

In this article, we’ll particularly focus on how to utilize AI to help you in all of these specific skills. Before we get into the details, it’s important to have the proper mindset for utilizing AI.

There are 3 camps of engineers and engineering leaders when it comes to using AI

1. The first camp → everyone who avoids using AI in their day-to-day work

Those are normally more experienced people who have been in the engineering industry for a while and have also seen a lot of shifts in the industry. They are more reluctant to change, and rather stick to what they know and what they are good at.

The problematic part is that the mindset of “It has worked well for me for 15 years, why would I change?” can be really harmful for learning new things and improving your craft.

2. The second camp → everyone who overuses AI in their day-to-day work

Those are normally less experienced engineers, either coming to the industry or they’ve been in the industry for a short while.

Such people normally have a good grasp of AI tools and what’s available out there, but they overly rely on them, resulting in the work being mediocre or, even worse, they don’t even check if the output from the AI tools is aligned with the standards.

Such work can be quite a problem for teams, as it puts a lot of work on reviewers to find out all the problems, which can end up taking a lot more time than it would take if they just do it right from the start.

3. The third camp → everyone who takes a balanced approach with curiosity

This is where you want to be. You don’t just blindly trust the “fancy new tool”, and at the same time, you are very curious to find out how you can improve your own and your team’s workflow with new tools.

You are keen on trying new things out, and at the same time you understand how important good engineering fundamentals and understanding of good engineering practices are.

You like to learn new things all the time, and you look at software development as one of the most fun things to do, because there’s always something new to learn.

Engineering multipliers use AI to help them be successful, but they don’t delegate their judgment

Using different tools that are available to make your day-to-day easier and more productive is what great engineers and engineering leaders do.

This hasn’t changed with AI, it has always been like that. We’ve always looked to automate aspects of our work. AI is a tool like any other, just the difference is that it’s a lot more ambiguous to use.

You get a tool that has so many capabilities, but no real manual on how to use it for your specific case. You need to figure out what works best for you and your work specifically.

At the same time, you shouldn’t just blindly trust these tools, you should verify and ensure they actually make you more productive.

This is how you can utilize AI to be a multiplier

Read more

Read more

This week’s newsletter is sponsored by Unblocked.

[Webinar] Can you prove AI is working?

AI is in your engineering workflow. While the token spend shows it, the throughput doesn’t. The human is very much still in the loop, and that’s a context problem.

Join live on Aug 19 (FREE) to learn:

• The 4 metrics to measure the gap where gains leak out before production.

• The 8 stages of context maturity, the specific walls capping your metrics, and a free tool to pinpoint where your team is.

• Why more MCPs and bigger context windows aren’t enough, and what it takes to get real value from your agents.

Register now

Thanks to Unblocked for sponsoring this newsletter. Let’s get back to this week’s thought!

Intro

Earlier this year, I was in San Francisco talking with different companies, and one of them was Larridin. Funnily, I came right in the middle of their team meeting (sorry guys).

They are building a platform for what many companies are wondering these days → how to measure AI adoption and AI fluency.

Things that especially stood out from our conversations:

• They are a true definition of an AI-native team, with AI being at the core of everything they do.

• They are big advocates of spec-driven development. The spec needs to be almost perfect before they start with the implementation.

• Every engineer owns the feature end-to-end → from creating the spec to implementing it, to ensuring it’s working correctly.

• Ameya Kanitkar, CTO, Larridin, mentioned they also like to work with more junior-level engineers, but they need to leave and breathe AI and always look to improve and get better in this area.

• A great analogy about using AI → You have a fast-driving car right in front of you, why not use it?

I’ve talked with the devs, and also with Ameya, whose insights I am sharing today. In today’s article, we’ll dive into how they are doing spec-driven development at Larridin.

Let’s start!

What is spec-driven development?

There are many different definitions out there, but here is what it means for me:

Spec-driven development is a way of building software where you focus on building a good specification first, and then use AI to implement the project.

There are many ways you can write the spec, for example, Michael Bolin, Codex Tech Lead, uses Notion to create a spec and then asks all the other engineers on the team to take a look and provide comments.

This helps spot any issues beforehand and improves the overall implementation done by the LLMs. To learn Michael’s full process for AI-assisted engineering, read this article:

The popularity behind spec-driven development is increasing

I am seeing spec-driven development as the way to build software used by more and more companies, and it definitely makes sense.

Especially with the cost of tokens just keep increasing, you don’t have the luxury of just infinitely prompting in order to get the desired output (unless you work with unlimited tokens).

With a great spec, you can usually use a lower-tier model and get a very similar output, the reason for that is that the instructions in a great spec are very clear.

So, this is also the workflow that I see many companies use:

• Write a spec (with the help of higher-tier LLMs)

• Build the spec (with the lower-tier LLMs)

Now, let’s get into more details on how Larridin does spec-driven development!

1. Start with a spike first

Ameya mentioned that before they start writing the spec, they prove that the “risky” things work.

In software development, there are a lot of unknowns when you are building things, and it’s impossible to write a complete spec if you are dealing with unknowns.

So, what they do is, they create a spike task to resolve these unknowns of a specific project first.

The goal is not to build a full MVP, it can be a small, ugly, throwaway-quality work. Just enough to answer the question “does this actually work”?

The purpose is not to extend it afterward, as you would normally do with the MVP, but the goal is to remove any technical uncertainty, which, alternatively, would just contaminate the spec with various different options.

Some examples:

• If the API that you’re going to build has 3 edge cases, spike those.

• If your whole system depends on how fast your API is, spike the hot path and measure it.

• If you’re building a new view that has a lot of records in it, prove that the API can return the results fast enough.

And another example that Ameya shared from their work:

We wanted to create a model to measure “AI Fluency”. So we wrote a spike to ensure our core logic works. Once we were happy with the results, the rest of the design followed (queue, monitoring, database, etc.). Spec was simply for ensuring core logic works and is token efficient.

The goal is to stop when you have an answer, not when the code is pretty. If you’re worried about naming variables, functions, and file structure, stop, that’s a sign you’re putting too much thought into implementation details.

2. Promote the spike to reference implementation

Once the spike works, don’t throw it away. It’s now your reference implementation.

This is now a reference that you can point the LLM to and say “I know this pattern works, because here it’s working!”

Ameya believes that this is one of the most underrated things when you’re doing spec-driven development. A working example is worth a lot more than a full page in the spec. That’s how the model stops hallucinating and stops “guessing” the behavior as well.

The reason is that the model can now check the reference and see the approach that has been taken to implement that specific part.

The reference implementation belongs in the repo in a known location. All of the references are in a location: spec/spikes/reference/referenceName.

And also another tip here is to comment on the specific parts that prove the approach, and also add comments to the parts where things are hardcoded, maybe the error handling is missing, or the implementation is not on point.

The more info you give in the codebase, the more accurate the overall implementation by the LLM is going to be.

Ameya believes that a spike without comments can be similarly dangerous as not doing it at all, because the model can just reproduce the wrong parts alongside the right ones.

3. Write the spec

Now that you have the reference implementation with comments, it’s time to write the spec! The spec should be detailed enough to hand to a junior engineer or a small model.

You can and should, of course, use AI to help you write the spec. When you use AI to write the spec, Ameya suggests forcing the model to restate what needs to be done, list any assumptions, and also flag any kind of ambiguity.

So, in case there are any non-handled assumptions and ambiguity left, you can either create a new spike or update the existing one.

Here is also a desired spec structure that they use at Larridin:

• Problem statement at the top

What you’re solving and for whom. One paragraph.

• Non-goals

What this system explicitly will not do. This is where you head off half the overengineering before it starts.

• Assumptions

The details that you have already decided, so the model doesn’t “silently” pick them. Cursor or offset pagination? Lazy loading of components? You need to write all of these down.

• Reference implementation

Link to the spike. Call out (if not already in the comments) which parts are shortcuts, and which parts prove the implementation.

• Architecture

Data model, module boundaries, interfaces, error handling, etc.

• Test plan

What unit, integration, and/or e2e tests are needed and how they need to be done. More on this in the next phase.

Example of a good spec shared by Ameya: Full example of the spec.

And a recommendation he shared:

My recommendation is to write the smallest spec that unambiguously specifies the system. If a section feels like fluff, cut it. If a decision feels obvious, write it down anyway. “Obvious to you” is not the same as “obvious to the model”.

4. Write/adjust the test plan before the implementation plan

Read more

Intro

If you go on any social media these days, you can quite quickly spot AI-generated posts or comments, and it’s really becoming frustrating. As soon as I see that, I immediately go to something else, and I lose a bit of credibility for that person.

And it’s the same with AI-generated emails, messages, articles, or even ADRs and tech specs. While there is certainly a time and place where AI-generated writing makes sense, the problem comes when people expect to read human, thoughtful writing, but instead they get AI-generated text, with no substance.

Imagine asking a question to your colleague, and they just copy & paste an AI-generated response, without even taking the time to edit it. It’s very similar to just submitting a PR full of AI code slop, without taking the time to edit, and putting all the work on reviewers to try finding the issues.

In today’s article, we’ll go through why AI-generated writing is problematic, its use cases + how you can write clearly, develop your own style, and communicate in a way that gets the response you’re looking for.

This is an article for paid subscribers, and here is the full index:
- Why is AI-generated writing problematic?
- Another example, the problem with AI-generated code
- AI is not the issue, the issue is doing “half-done” work
- AI-generated writing is fine if the expectation is aligned with that
- Brevity is more important than ever
🔒 How to write clearly?
🔒 Develop your style of writing
🔒 Know your audience
🔒 Different tips and tools that can help you
🔒 Last words

Let’s start!

Why is AI-generated writing problematic?

As mentioned a bit in the intro, it’s not that AI-generated text is problematic by default, the problematic part is the misalignment between expectations.

Here is a good example:

You go to the cinema to watch a new movie that has been advertised as the “next must-see movie”, and you have high expectations of it. Great story, thoughtful scripts, great cast, etc. You are excited.

But then the movie starts, and things go sideways quickly. Generic story, generic graphics, generic cast, etc. The movie was actually AI-generated. What are your thoughts?

You are not happy about it because your expectations were different.

And it’s very similar with AI-generated emails, messages, blog posts, etc. You get a bad taste in your mouth if you expected to read thoughtful writing, while in reality you read AI-generated writing.

Let’s go to another example that I regularly see being problematic, especially for engineers who are reviewing code.

Another example, the problem with AI-generated code

What I am seeing and also hearing happening regularly, especially with less experienced engineers, is the following:

They are assigned a task, and they use a certain AI coding tool, use their agent mode to finish the task, and then they don’t go the extra mile to actually understand what has been changed and ensure the changes are made within the guidelines of the codebase.

They open the PR, and because they didn’t actually take the time to read and edit the code, this puts a lot of pressure on reviewers to find all the mistakes and completely shifts the work on them.

There may be a lot of comments on PRs, and it takes a lot of time to review correctly. And even in some cases, engineers give up and just approve the PR, which makes things a lot worse in the long run.

For me, personally, if I see a PR opened full of AI-generated slop, that particular engineer would lose a lot of credibility in my eyes. Or even worse, if they mention that the mistake is there “because of AI”.

Every good engineer should know and realize that overall accountability is on them to ensure that good-quality code is delivered and not look to shift the accountability elsewhere.

Of course, I get it, we all make mistakes, but at the end of the day, submitting a full PR of AI-generated slop or blaming AI for a mistake is not a good look.

AI is not the issue, the issue is doing “half-done” work

This is the core message that I want to get across in this article.

As soon as you send a message or open a PR where you just copy & paste the first AI-generated output and didn’t actually take the time to ensure it’s done to the correct quality, you lose credibility.

Even if you don’t receive the feedback directly, you are going to be perceived differently, and if you do this for a longer amount of time, you’ll end up having a bad reputation, which can be quite problematic, especially these days with a lot of layoffs happening across the industry.

So, always ask yourself, am I doing the work that is perceived to be good quality? Or am I just doing the minimal effort work?

If you’re doing the second, it’s time to really reconsider your priorities. Your reputation is one of the most important things, and how people perceive you really goes a long way.

Now, let’s get to an important point, where AI generated writing is totally fine.

AI-generated writing is fine if the expectation is aligned with that

There are definitely use cases where AI-generated text is fine, like, for example, if everyone is aligned that the tech spec or ADR will be fully AI-generated, and you keep improving it with prompts.

Additionally, if there is a clear PR template prepared, where everyone generates the description with AI, that’s totally fine as well.

But the problem comes when you’re trying to share AI-generated writing masked as your own. Like responding to PR review comments with AI, or responding to Slack messages with purely AI-generated text.

Or even writing full blog posts, articles with AI, that’s fully unacceptable from my perspective. Maybe some people would read it, but me, I won’t.

That’s also the reason why all the articles on this newsletter are going to be written in my style, which I developed in close to 4 years of writing online.

Now that we understand where AI-generated text is fine versus not, let’s go through the importance of clear writing and brevity.

Brevity is more important than ever

What brevity means is to use the right amount of words (no fluff) to communicate an idea clearly. It’s being concise and clear with your written communication.

It means that you can put yourself in the shoes of your reader(s) and write it in a way that resonates with them.

Brevity is a sign of respect for the reader’s time.

This is the post that I posted on LinkedIn earlier this week, which shares an example of brevity (from 2014):

In this situation, it worked. Niraj got the response from Evan, which resulted in a positive one.

What’s important to mention here is that I wouldn’t bet on sending a cold email like that in 2026 and expect to get a similar response.

A lot of people, especially recruiters or hiring managers, have already seen this before (as it’s been quite a popular picture shared across social media in recent years). And it’s a bit of a cliché.

But what’s important is that it worked for Niraj back in 2014. And that’s how you need to think about writing.

Ask yourself: How can I write in a way that would get me the desired response?

This is the art of brevity. Knowing who your audience is and how to frame it in a way that would resonate with them the most.

Let me share some examples and tips for clear written communication next.

How to write clearly?

Read more

Read more

Intro

Over the course of my 13+ year career, both as an engineer and engineering leader, I had the pleasure of being a mentor/coach for many different people.

It started already when I was a Software Engineer, onboarding new engineers, and then it became a standard for me when I became a manager.

I always viewed a part of my role as a manager to be a coach for everyone who was directly reporting to me, and I always enjoyed seeing my people grow.

Interestingly, this was also one of the reasons why I started writing online, a bit less than 4 years ago.

In today’s article, I’ll be going through some of the most important lessons I learned from coaching over 300 engineers and engineering leaders both in my full-time roles, group coaching, or individual coaching.

This is an article for paid subscribers, and here is the full index:
- My experience with coaching
- What’s interesting about coaching is the following
- Those are the reasons why I highly recommend that everyone become a mentor/coach
- Lesson #1: A lot of people already know what they need to do
🔒 Lesson #2: Believing they are not ready or that they don’t deserve it
🔒 Lesson #3: Accountability is crucial
🔒 Putting it all together
🔒 Last words

Let’s start!

My experience with coaching

As mentioned at the beginning of the article, I consider being a coach for everyone who has ever directly reported to me. I’m not counting indirect reports, where I was a skip-level manager, I am counting everyone with whom I had 1:1s with.

The reason for this is that I always looked at 1:1s very similarly to doing a 30-minute coaching session.

Additionally, I did 8 cohorts of the live course called Senior Engineer to Lead: Grow and thrive in the role, where I taught close to 250 engineers and engineering leaders.

And I also had the pleasure of having a lot of individual coaching sessions with many different great individuals throughout my career.

What’s interesting about coaching is the following

You learn a lot as a coach, not only does the person who is receiving coaching.

The biggest benefits of being a coach are:

• If you can teach it, you understand it

It forces you to clarify your thoughts on certain topics, as if you don’t understand a certain topic clearly, you won’t be able to teach it to someone else.

It also shows where you might have blindspots and which particular parts you don’t understand that well.

• You get exposure to a number of different problems people are dealing with

Which helps you to do future coaching a lot better, especially if you see repeating patterns from 1 person to another. Or maybe you come across a similar issue, just disguised a bit differently, and you spot that pattern and re-use a similar solution.

Additionally, you are able to solve various different problems better, as the more problems you are exposed to and solve them, the easier future problems can be solved.

• Communication skills, active listening, asking good questions, and not just handing the “solution”.

This is crucial, and if you want to grow in your career, it’s more important than ever to improve in these skills, as there is a limited amount of impact you can have just with your own contribution.

Being a multiplier for others is how you can have so much bigger impact, especially in the AI era, where pure building has become much more accessible.

That’s also the reason why I am putting a LOT of effort into writing the book The Multiplier Mindset, which will be published later this year. So, everyone develops the right mindset that’s crucial to be successful in current times, both as an engineer and an engineering leader.

Those are the reasons why I highly recommend that everyone become a mentor/coach

As mentioned, you don’t only help the other person, but YOU learn and grow this way as well. It has tremendously helped me throughout my career, and I couldn’t recommend it more.

Try to find opportunities where you can help others grow, even if you are not a manager. Being a mentor is very valuable, and you’ll quickly find out what specific things you know and where you need to improve.

Now that we better understand how important coaching is, let me share my top 3 lessons from coaching many different people throughout my career.

Lesson #1: A lot of people already know what they need to do

I see this all the time, and I’ve seen it in many individuals in tech. Very similar to eating healthy food and exercising to get in shape. Many people know exactly what they need to do, but the problem is starting to do it, being consistent, and sticking with it.

The same is for growing in their careers as engineers/engineering leaders. A lot of people know they need to be more visible, share their work better, be more vocal in meetings, share their opinions, ask their manager for the next step, follow up on the ask, etc.

But the problem comes when you need to actively put this into practice and stick with it. Being more visible means you need to actively find opportunities internally and/or externally to share your knowledge, either via learning sessions, blog posts, speaking at meetups/events/conferences, etc.

Having an opinion in a meeting starts with doing research on the topic before the meeting starts, asking the manager for the next step starts with preparing the full script on what you’re going to say + rehearse it, and before that, doing a good amount of research on what next step you actually want to take.

The problem is mostly the need to put in the work every day consistently, and that’s where a lot of the things stop. Especially if they don’t have a person holding them accountable. I’ll talk a lot more about accountability in the 3rd lesson!

Now, let’s go to the second one, which is closely connected with the first one.

Lesson #2: Believing they are not ready or that they don’t deserve it

Read more

Proud to announce my book “The Multiplier Mindset” published by O’Reilly!

The main premise of the book:

In today’s AI era, being a great engineer is no longer defined by individual contribution alone.

Being a great engineer is defined by the ability to make others around you better, to deliver projects successfully, and to create impact that moves the whole organization forward.

And engineers with the biggest impact have the multiplier mindset.

In the book, I cover:

• Exact mindset you need to thrive today and in years to come, both as an engineer and engineering leader

• Important traits and skills to develop

• 8 case studies from successful multipliers from companies like Pinterest, Adobe, Microsoft, to name a few

I already shared 2 case studies (adapted for the newsletter) as articles, and you can read them here:

The book will be published later this year! 2 chapters left to be written, and the tech review process finalized.

Early release of the book available here: Early release of the book.

Get also a 1-month free access to all the O’Reilly books: Free access to O’Reilly platform.

Wish you a great rest of the week!

Gregor

Read more

Intro

I recently had the pleasure of visiting OpenAI’s offices in San Francisco. Had a great time there, and it was a pleasure getting to know and talk to different engineers and engineering leaders.

Here is also the article, based on my conversation with Michael Bolin, Tech Lead for the Codex open-source repo. We talked all about how he does AI-assisted engineering:

In today’s article, I am sharing the insights from my conversation with Venkat Venkataramani, VP of Applied Infrastructure, OpenAI, and Emma Tang, who is leading Data Infrastructure at OpenAI.

We talked all about how infrastructure teams work.

This is an article for paid subscribers, and here is the full index:
- 5 Core Pillars of Infrastructure at OpenAI
- Infrastructure teams are critical to the success at OpenAI
- The amount of AI-generated code is lower than with product teams
- How they prioritize work?
- Unblocking teams is a crucial part of prioritization
🔒 Their primary challenge with infrastructure at OpenAI has always been the pace of growth
🔒 Another challenge is the unpredictability
🔒 AI-generated PRs have also shown to be another infrastructure challenge
🔒 What makes a great engineer for an infrastructure team?
🔒 How they measure the success of the infrastructure teams?
🔒 Last words

Let’s start!

5 Core Pillars of Infrastructure at OpenAI

At OpenAI, they organize their infrastructure around 5 main pillars, each focusing on a specific part.

1. Developer Productivity

Focusing on improving the software development process + research, giving everyone the tools and capabilities to do the best work possible.

Think of it as everything that helps teams build, test, deploy, and move faster, so that everyone can move as fast as they can.

2. Compute Infrastructure

This is the specific hardware and/or software needed for all the computing behind OpenAI’s products. This includes the infrastructure powering: ChatGPT, API, Codex, and any future products.

Venkat also mentions that this specific pillar could be referred to as Fleet Infra, as it’s specifically focusing on GPU infrastructure.

3. Networking and Storage

With this infrastructure, AI workloads can communicate while storing data generated by models and apps.

This pillar goes hand-in-hand with the compute infrastructure, as their work is closely related.

4. Observability

Monitoring, telemetry, metrics needed to keep the systems reliable. That’s the focus of this specific pillar. The goal is to detect issues quickly, understand what’s happening across the infrastructure, and ensure that the services are reliable.

5. Data Infrastructure

The last but definitely not least. Venkat describes it as one of the most important infrastructure organizations because basically every application continuously generates data.

This is the infrastructure that enables OpenAI’s feedback loop, helping improve future models and products.

Emma shared a great example of their work, which is an in-house data agent. They created an internal-only tool where everyone inside OpenAI can ask data-related questions and get the insights needed in order to make data-driven decisions.

No need to go to data engineers to “generate another dashboard”, they can simply ask the data agent to get the desired insights they are looking for.

Infrastructure teams are critical to the success at OpenAI

Everyone’s productivity is determined by how well the infrastructure enables them.

With bad infrastructure, you are limiting how fast people can move and make things happen. You want to enable everyone instead to do the best work possible.

It’s crucial to enable both:

• teams and people internally at OpenAI, and

• the customers/users

to be able to do what they want to do.

A good example is the following: Good infra plays a huge role in user experience, like how fast ChatGPT responds to the questions being asked, and also how reliable it is.

And there’s another important factor as well, which is cost, and balancing cost with speed and reliability. How to find the right balance between them, so that they don’t burn the full budget just on compute.

And then also specifically for data infrastructure, it’s important to have a good infrastructure in place so that every team inside OpenAI is able to make data-driven decisions.

It’s important to view infrastructure as the backbone of many other essential functions a business can’t operate without.

The amount of AI-generated code is lower than with product teams

This is a very important insight, mentioned by Emma, as many people may believe that you can just use AI and generate thousands of lines of code without consequences. That’s completely not the case when you are building infrastructure.

The infrastructure work is a lot more critical to the business, and with one simple mistake, there can be huge consequences. You can block other teams from being able to progress with their work, and even worse, the users might not be able to achieve what they want to do using their products.

They focus a lot more on understanding every single line of code and making sure that everything works correctly. Therefore, they don’t see as much higher productivity boost using LLMs than some other more product-facing teams.

How they prioritize work?

As you may know, working in any kind of platform/infrastrucure team, there’s always a big issue with how to effectively prioritize the work, as there are often many competing priorities. I’ve asked Venkat about how they think about prioritization.

The really important message and how they think about infrastructure is the following.

They think about infrastructure as a product.

So, the main thing they keep in mind is that any kind of infrastructure you are building, e.g., CI/CD pipelines, data infrastructure, analytics, cloud infra for compute, etc., think of that as a product that you are building.

And everyone using your infrastructure (product) is the customer. Very similar to having an actual product and offering it to real customers.

And an example that Venkat mentioned:

If you are a startup, and you have a lot of competing customers, and you want to say “yes” to all of them, you find a way to make it work.

That’s very similar to what they try to do at the infrastructure organization as well. They try to say “yes” as much as they can, but oftentimes there has to be a certain negotiation.

They might not be able to do everything that a certain team asks for, but maybe they can do 4 out of 5 things, and that can be delivered in the following week.

Unblocking teams is a crucial part of prioritization

And the second important thing regarding prioritization is that if a certain ask is far away from their focus, they’ll ask how they can unblock that specific team as quickly as possible, so that at least they can move forward.

And they’ll focus on building a quick solution (even if that might not be the best possible solution), just to unblock that specific team. What’s important here is that the solution is built in a way that can be easily replaced with the proper solution down the line.

And what they’ll do after is launch a project where they would find the best solution to that specific ask, and build it in the next 1-3 months.

Think of it as building an MVP → unblocking the team with it → building an actual long-term solution and replacing the MVP.

Their primary challenge with infrastructure at OpenAI has always been the pace of growth

Venkat mentioned that building infrastructure that scales to these heights is a hard but not impossible task.

Read more

Read more

Intro

With AI-assisted engineering being the standard way of building software these days, every company is trying to answer the same question:

What does an AI-native engineering team actually look like?

To help us with this, I recently had the pleasure of talking with Katelyn Lesse, Head of Platform Engineering at Anthropic.

We talked about a LOT of different topics regarding Anthropic’s engineering culture, how they work, and how they build their products. She shared a lot of interesting insights, some of which will be shared today, and some in future articles.

In today’s article, I’ll share, based on our conversation, how Anthropic builds AI-native engineering teams.

This is an article for paid subscribers, and here is the full index:
- What does AI-native actually mean at Anthropic?
- The structure of AI-native teams
- Similar structure with an important difference
- With many projects happening simultaneously in the team, there’s a bigger need for PMs
- They are even looking for more PMs in a cross-functional team?
- No dedicated QAs, automated testing + AI Evals are more important than ever
- All of their code is AI-generated
- Defining the desired outcome is key when working with AI
🔒 Additional use cases for using AI in their work
🔒 Responsibility + accountability should always be on engineers, never on AI
🔒 AI-native engineers are becoming tech-agnostic
🔒 How has the onboarding of new engineers changed from 1-2 years ago?
🔒 Working with AI agents should be the new normal for all companies
🔒 Last words

Additionally, earlier this year, I talked with Thibault Sottiaux, Head of Codex at OpenAI, on how OpenAI is building AI-native engineering teams. If you haven’t read the article, I highly recommend doing so here:

Let’s start!

What does AI-native actually mean at Anthropic?

As mentioned in the article AI-Native Engineering Leadership, there are many definitions of being “AI-native” across different companies. I’ve asked Katelyn about what it means at Anthropic. She mentioned the following.

Being truly AI-native means that AI is built into the workflow so that it doesn’t feel like an extra tool.

Whether you’re writing code with AI in collaboration or running autonomous AI systems in the background, AI should become a part of the process rather than something separate.

When it works seamlessly and feels natural, that’s when you are AI-native.

The structure of AI-native teams

Throughout our conversation with Katelyn, one point she mentioned many times is the following:

Many aspects of software development haven’t changed, and likely don’t need to change, even as AI becomes deeply integrated into engineering teams.

Therefore, that’s exactly the case in the Anthropics team structure. They still use the traditional 2-pizza cross-functional team structure, with 5-8 engineers in the team, an engineering manager leading the team, a PM, and a designer as part of the team.

The reasoning for it is the following:

Teams still need enough people to build, operate, and maintain systems over time. Ownership, reliability, and shared knowledge are crucial, regardless of how much AI is involved. The difference is just that AI gives everyone significantly more leverage.

Similar structure with an important difference

In a traditional team, you had 1 tech lead, who would lead the project from the tech perspective and coordinate with other teams, while other engineers on the team focused more on implementing features and completing tasks.

Today, almost every engineer is expected to take on a tech lead role if needed. The reason are AI tools, which can enable individuals to accomplish a lot more than before.

As a result, the team size is unchanged, but the work changes.

A team of 8 engineers that previously focused on 1 or 2 projects at a time can now potentially run 4 or 5 projects in parallel.

The team still owns and maintains the same systems, but AI enables everyone to execute far more work in parallel.

With many projects happening simultaneously in the team, there’s a bigger need for PMs

Interestingly, Katelyn mentioned that AI has not reduced the need for PMs, especially TPMs, product managers who really understand the underlying tech as well. She sees the role as even more important.

That’s pretty different from what some other companies are doing, where they actually have fewer PMs. Like OpenAI with a 30:1 engineers per PM ratio, and companies like Telnyx or Portkey, where they work with 0 or a few PMs.

This is her reasoning: With engineers being able to build and ship software much faster with AI, the bottleneck shifts from implementation to decision-making. And the challenge is no longer whether a team can build something, but whether it is building the right thing. So, that’s where PMs come in.

Additionally, Anthropic has a specific role inside their company called Prod Ops (product operations), with the role of making systems, processes, and tools more effective so PMs and teams can make better decisions more quickly and achieve better results.

She sees that in an AI-native environment, strong product management becomes even more valuable because it ensures that increased engineering capacity is focused on the highest-impact problems.

They are even looking for more PMs in a cross-functional team?

Traditional teams had 1 product manager supporting a team of engineers. They have the same setup → 1 PM per team, but she believes this will change soon in their teams.

There are simply more decisions to make, more customer needs to understand, and more projects to coordinate. Because of this, her team is finding that they need more PMs than before.

She believes every team needs someone who deeply understands what customers need, what the team is trying to achieve, and what should be built next.

No dedicated QAs, automated testing + AI Evals are more important than ever

They don’t have a dedicated QA engineer inside the team. Testing is a shared responsibility across the team.

They also rely heavily on automated testing. And because AI allows engineers to generate code much faster, they have to be careful about how tests are written.

They value the traditional quality pyramid:

• Most unit tests

• Lesser integration test

• Even fewer e2e tests

And specifically, they focus on creating quality unit tests and a smaller number of slower end-to-end tests. This helps keep development moving quickly and prevents the CI pipeline from becoming a bottleneck (long time for tests to pass).

Another important part of testing is evaluating their AI models and products (AI Evals). They invest a lot of time in building and maintaining evaluation systems that help them measure quality and ensure new models, products, and platform updates perform as expected before reaching customers.

This work is not owned by a single team. Engineers spend a lot of time on testing and evals, and PMs are also heavily involved as well. Everyone contributes to making sure products meet a high standard before they are released.

She also mentioned that roles inside the team have become a lot more flexible and that there is no clear separation of responsibilities.

Like everyone these days, they are also learning as they go, they don’t believe they have found a perfect formula, they are adjusting based on what they see works for them and what doesn’t.

All of their code is AI-generated

I asked Katelyn if her teams have a similar sentiment to what Boris Cherny (Head of Claude Code) has mentioned, which is that all of his code is AI-generated these days.

And she mentioned that it’s what their teams do as well. However, the important thing that she added is that this doesn’t mean AI is building software on its own.

She mentioned that engineers play the most important role in designing systems and making architectural decisions. AI is an excellent collaborator during this process, but engineers are responsible for deciding how large and complex systems should be built.

Once the design is clear, the implementation is largely handled by AI agents. Rather than switching back and forth between AI agents generating code and manually writing code, it’s better to guide the agents until they produce the desired result.

This is also a very important thing she mentioned:

The effective use of AI is not about asking an LLM to generate code and accepting the first answer. You should continuously steer the agent, provide feedback, and let it test and improve its own work until it meets the required standard.

Because of this, she believes reviewing AI-generated work has become one of the most valuable engineering skills.

Defining the desired outcome is key when working with AI

Additionally, her top tip for working with agents is to define the desired outcome instead of simply assigning a task.

Rather than saying, “Build me a dashboard,” you should clearly describe what the finished dashboard should accomplish, what success looks like, and any important requirements or examples.

To support this workflow, her team built a feature called Outcomes in Claude Managed Agents.

You provide a simple description of the desired result, and a second AI agent evaluates whether the generated solution meets those expectations. If it doesn’t, the coding agent automatically iterates and tries again before presenting the final result.

The clearer you define the outcome, the better the AI performs.

Good prompts are less about telling the AI what to do step by step and more about clearly describing what success looks like.

Additional use cases for using AI in their work

Read more