Updated speaker lineup for the Engineering Leadership Live event in San Francisco, that I am hosting together with my friends from Augment Code.

- Gregor Ojstersek, CTO & Author Engineering Leadership newsletter
Talk: AI-Native Engineering Leadership

- Vinay Perneti, VP of Engineering, Augment Code
Talk: We Thought AI Transformation Was About Adopting Agents. We Were Wrong.

- Andrew Churchill, CTO, Weave
Talk: What Actually Works: AI Coding Patterns from the Top 1% of Teams

- Anwar Haneef, GM & Head of Ecosystem, Canva
Talk: Your Product’s Next User Might Be an AI Agent. What Engineering Leaders Need to Know.

Join the event (limited spots available):

Secure your spot at the event

Looking forward to seeing you there tomorrow!

Gregor

This week’s newsletter is sponsored by Larridin, an AI-native developer intelligence platform.

Measure AI’s impact on engineering.

Claude writes code 10x faster than a human. So why is engineering productivity up 20%, not 200%?

Engineers spend only 30-40% of their time actually coding. The rest goes to deployments, sprint planning, admin overhead, support questions, design reviews, incident response, and everything in between.

Until now, we’ve had no way to map and measure where that invisible work actually goes. Larridin changes that. Mapping how engineering work flows across your org, surfacing the blockers and friction that drag on productivity, and showing you exactly what to fix.

Larridin delivers complete 360° developer intelligence for AI-native engineering teams. From traditional developer productivity metrics to AI-era measures like Agent Effectiveness scores.

Unlock AI-native engineering potential

Thanks to Larridin for sponsoring this newsletter, let’s get back to this week’s thought!

Intro

I like to say that finishing projects in software engineering is more like an art than a clear blueprint. Every team and project is different and what works for one may not for the other.

There are many ways to approach engineering projects. Today, we’ll go through a case study on what worked well for Karol Wójciszko, Senior Engineering Manager, Webinterpret.

It’s a bit of an unconventional approach, and that’s exactly what makes it valuable and interesting to read.

Let’s introduce our guest author and get started!

Introducing Karol Wójciszko

is a senior engineering manager for Webinterpret, running multiple engineering teams. He also writes about engineering leadership topics in his newsletter called Engineering Leader’s Playbook.

Today, Karol will share a case study from a project he ran with an adapted version of critical chain project management. It’s a method from Eliyahu Goldratt’s Critical Chain, originally designed for manufacturing and construction.

Let’s start!

1. What Critical Chain Is and Why It Works So Well in IT

The core mechanic in critical chain project management is almost provocatively simple. You take your team’s estimates, cut them all by 50%, and call these new numbers “aggressive but achievable.”

The time you removed from each task doesn’t disappear. It becomes your project buffer: a shared pool of time that the entire team draws from.

Let’s say an engineer estimated a task to take four days; they now have two days to finish it. If they do it in two days, you just put two days into the project buffer. If they finish in three days, there’s a day in the buffer.

And if they do it in five? They’ve used three days from the buffer, which is also fine. Nobody gets punished. You’re tracking how much total buffer the project is consuming versus how much actual progress has been made.

Why does this work? Because of Parkinson’s Law.

You’ve probably heard of it: Work expands to fill the time available. If you give someone four days for a task that they could realistically finish in less than two, they will almost always use the full four days.

Not because they’re lazy or wasting time; it’s just how human brains work. We fill the available time. We polish things that don’t need polishing. We revisit decisions. We context-switch because “there’s still time.”

The result is a painful asymmetry in every project: Early finishes get absorbed silently, but delays are loud and visible.

Think about it. When was the last time an engineer finished a task a day early and that extra day actually benefited the project timeline? It almost never happens. The saved time evaporates into a longer code review, an extra refactor, a coffee break.

But when a task takes one extra day? That shows up immediately in your burndown chart. Everyone notices.

Critical chain flips this dynamic. By setting aggressive targets, you create conditions in which early finishes are actually captured. Some tasks will run over the aggressive estimate. That’s to be expected. It’s what the buffer is for.

But the tasks that come in early now benefit the whole project instead of disappearing.

The two rules that make critical chain work

There are two rules that are nonnegotiable for this method to work.

• Rule 1: Absolutely do not give penalties for going over the aggressive estimate

I mean “penalties” both formally and informally: no performance notes, no disappointed looks, no passive-aggressive “so, task 7 took a bit longer, huh?” in a standup. The engineer did their best.

The aggressive estimate was designed to be missed sometimes. If you create any kind of penalty, even subtle social pressure, you’ll destroy the entire method. People will start padding estimates again, and you’ll be back to square one.

This is harder than it sounds. As a manager, you need to genuinely not react when someone takes five days on a task estimated at two and a half. Your body language matters. Your tone matters. The team is watching.

• Rule 2: Track the buffer, not individual tasks

The question is never “Did Sarah finish task 7 on time?” The question is always “How much total buffer has the project consumed versus how much total progress have we made?” This is a team-level metric.

Individual task overruns don’t matter as long as the overall project buffer is healthy.

This also builds team spirit. Now it’s not about individual performance. It’s about the collective mission. Some tasks will finish early, and some will finish late. The team wins together.

Adapting it for story points (yes, I know)

I need to address the elephant in the room: story points.

Classic critical chain uses time estimates. But most software teams estimate in story points (SPs), which is a measure of complexity rather than time. Purists will tell you that you can’t convert story points to time. And technically they’re right.

But you can calculate how long your team historically takes to finish tasks of each size. That’s not a theoretical conversion; it’s empirical data. And it’s good enough for critical chain to work.

Here’s what I do: I pull all completed tasks from the previous quarter and calculate the median completion time for each SP value. Whether a task had 2 SPs or 5 or 8 or any other amount, I still take the median completion time, which scales with the points.

Why median and not average? Because the median filters out outliers. That one task that took 14 days because an engineer went on vacation mid-project? The median ignores it; the average doesn’t. The median gives you a naturally tighter, more aggressive baseline, which is exactly what we want.

A critical point: This entire calculation happens outside of the team. I pull the data, I compute the medians, I set up the buffer. Engineers don’t need to think about any of this. They just do their normal work. This is homework for the manager, not an extra burden on the team.

Once you have the median times, you cut them by 50%. That’s your aggressive estimate for each task. The sum of everything you cut becomes your project buffer.

I use 50% in this case study, but you can start gentler, such as 30% or even 20%. The principle is the same. You can adjust the aggressiveness as you and the team get comfortable with the method.

2. Case Study: From Red Zone to Early Finish in 4 Weeks

Let me walk you through an actual project week by week, so you can see how this plays out in practice.

Our starting conditions:

• 17 tasks, estimated at 70 SPs total

• A team of three: two senior engineers, one midlevel

• A clearly defined scope (fixed epic)

• Buffer after 50% cut: 35 SPs

The math behind buffer tracking

In the case study below, I track two numbers week by week:

• buffer consumption and

• project progress.

Here’s how I calculate each one.

Buffer consumption is based on the difference between the aggressive estimate and the actual cycle time for each completed task.

When a task is closed, I know how long it actually took. I compare that against the aggressive estimate I assigned during planning. The difference tells me how much buffer that task consumed or saved.

A quick example: If the aggressive estimate for a task was 2 days, but the task actually took 3 days to complete, that task consumed 1 day of buffer. If it took only 1.5 days, it saved half a day of buffer.

At the end of each week, I add up the total buffer consumed across all completed tasks and express it as a percentage of the total project buffer. So if used 2 days out of a buffer of 10 days, we used 20% of the buffer.

Project progress is simpler. It’s the percentage of delivered story points relative to the total scope. If the project has 70 story points in total and the team delivered 7 this week, progress is 10%.

Are we on track? I compare the two numbers. If buffer consumption is 26% but project progress is only 16%, we’re 10 percentage points, or 62.5%, behind.

The project is consuming buffer faster than it’s producing results. If progress is ahead of buffer consumption, we’re in good shape.

One thing I want to call out here: I deliberately keep the math simple.

You might notice there’s no weighted scoring, no statistical modeling, no confidence intervals. That’s intentional. The foundation of this entire method is a median for cycle time, which is already an approximation.

We’re working with uncertainty from the start. There’s no point in building sophisticated calculations on top of an uncertain baseline. That’s just stacking assumptions on assumptions.

I treat these numbers as a guideline, not a guarantee, and the method works precisely because it embraces that simplicity instead of pretending to be more precise than it is.

Week 1: Red alert

Buffer consumed: 26% | Progress: 16%

Buffer consumption was 10 percentage points ahead of project progress (26%-16%). The gauge chart went straight to red.

Here’s the interesting part: By traditional velocity/throughput metrics, this was a completely normal first week. If I’d been running this project with a standard burndown chart, nobody would have raised an eyebrow. The team was delivering at a typical pace for Week 1.

But the critical chain gauge doesn’t care about typical. It cares about the ratio of buffer consumed to progress made. And that ratio was bad. We were burning through the buffer faster than we were completing work.

So I called a quick retro, just a 30-minute conversation about what was slowing us down. The answer was clear: Several key tasks lacked clarity. Requirements were ambiguous, a few diagrams were missing, and engineers were spending time figuring out what to build instead of building it.

We spent an afternoon with the project manager clarifying requirements, updating diagrams, and resolving open questions. This wasn’t anything dramatic; it was the kind of thing that happens in every project. The difference is that we caught it in Week 1, not Week 3.

And here’s what’s worth emphasizing: No other methodology would have raised an alarm at this point.

By velocity/throughput standards, we were on track. This looked like a perfectly normal first week. No burndown chart would have flagged anything. We would have cruised along for another two to three weeks before realizing that unclear scope was silently eating our time.

Before the retro, nobody on the team thought scope clarity was the bottleneck. It wasn’t obvious. But when we sat down and asked ourselves what was constraining us the most right then, that was the answer.

And because the critical chain gauge is so sensitive to the buffer-to-progress ratio, we got that signal in Week 1. We fixed it at the earliest possible moment.

Without this early alarm, we would have learned about the problem much later, when the damage was already done and much harder to recover from.

Week 2: Recovery

Buffer consumed: 46% | Progress: 41%

The gap narrowed to 5 percentage points, buffer consumption at 46%, progress at 41%. The clarity fix from Week 1 was paying off.

The gauge chart was sitting around the yellow-red boundary - still not great, but the trend was clearly moving in the right direction. We were slowly clawing our way back.

At this point, my job was simple: observe, don’t interfere. The team was doing their thing, the fixes were working, and adding more management overhead would only slow them down.

This is one of the things I like about the method: It tells you when to act and when to leave the team alone. Yellow zone? Watch. Green zone? Forget about it. Red zone? Intervene. There’s no ambiguity about it.

Week 3: First win

Buffer consumed: 63% | Progress: 70%

For the first time, progress was ahead of buffer consumption, by 7 percentage points. We were ahead of the historical median.

This was a milestone worth celebrating!

I shared the numbers with the team and we acknowledged the progress. Not every task had been finished within the aggressive estimate. Several went over. But that was fine. The overall project was ahead because enough tasks came in early to more than compensate.

This is the moment the team starts to really get the method. They see that individual task overruns don’t matter. What matters is the collective result. It shifts the mindset from “I need to finish my task on time” to “we need to finish the project on time.”

Week 4: Done early

Buffer consumed: 83% | Progress: 100%

Project completed. We used 83% of the buffer to deliver 100% of the scope. That 17 percentage point gap was pure time savings.

I don’t have a parallel universe in which we ran this same project with a different methodology, so I can’t tell you definitively that we would have been 17% slower without critical chain.

But looking at the data, one thing is clear: The Week 1 red alert alone probably saved us at least a week of delay. And the overall pace of work was noticeably tighter than what I typically see from the same team on standard projects.

3. Track Project Progress in 10 Minutes a Week

You saw the gauge chart in action during the case study: red in Week 1, yellow–red in Week 2, green in Week 3, and yellow in Week 4.

Here’s how I actually define those zones and what I do with them.

Defining the zones

The thresholds are based on two reference points you already have: your aggressive estimates (median cut by 50%) and the raw historical median. The gauge tracks the difference between buffer consumption and project progress, measured in percentage points.

• 🟢 Green = Progress is ahead of buffer consumption, tracking at or below the aggressive estimates. You’re on track to finish early. Close the spreadsheet, go do something else.

• 🟡 Yellow = Buffer consumption is roughly in line with progress, somewhere between your aggressive estimates and the historical median. You’ll probably finish on time, but not early. Keep an eye on the trend - is it improving or worsening?

• 🔴 Red = buffer consumption exceeds progress by more than 5 percentage points above the historical median. At this pace, you’ll blow through the buffer before completing the scope. Time to act - call a retro, find the constraint, fix it..

You can adjust these thresholds to your own risk tolerance. Mine are calibrated to my teams. The exact numbers aren’t sacred. What matters is having clear, visual triggers that remove ambiguity about when to intervene.

The weekly ritual

My entire engagement with this method during a project looked like this:

1. Refresh the data (I pulled the completed tasks from Jira into the spreadsheet).

2. Look at the gauge chart:

   1. Green: I’m done for the week.

   2. Yellow: I note the trend, and then I’m done for the week.

   3. Red: I schedule a 30-minute retro.

That’s it. No daily tracking, no manual data entry, no complex dashboards. One chart, one look once a week for about 10 minutes total.

When this method doesn’t work

I don’t apply the critical chain to every project. Here are some team compositions where it consistently fails:

• Junior-heavy teams

I’ve tried this, and it backfired. Juniors take the aggressive estimates personally. Even when I explicitly say “no penalties,” even when I demonstrate it with my behavior, they stress about missing the target.

It creates anxiety instead of motivation. The method requires a certain level of professional maturity to work. People need to understand, both emotionally and intellectually, that missing the aggressive estimate is fine.

• Burned-out teams

If your team is already stretched, adding aggressive estimates, even with a buffer, even with no penalties, will feel like more pressure. Read the room. If people are exhausted, this isn’t the time for productivity experiments.

• Very senior teams on familiar codebases

I’ve also struggled with teams where everyone is senior and has been working on the same domain for years. Their estimates are already tight.

There’s not enough slack in their estimates for the method to create leverage. They’re already working close to their actual pace, so cutting estimates doesn’t produce meaningful buffer.

• Undefined or shifting scope

This is the fundamental prerequisite. You need to know the full list of tasks upfront to calculate the buffer. If you’re dealing with an epic where new tasks keep getting added mid-sprint or where the PM is still figuring out requirements as you go, stop.

Fix the scope first, then consider critical chain. It works for defined-scope projects, like epics, milestones, and clearly scoped features. It doesn’t work for ongoing maintenance or discovery work.

I run this method maybe once a quarter, sometimes once every six months. I pick projects for which the deadline matters and the scope is locked. It’s a precision tool, not a daily driver.

The compound effect

There’s a bonus that becomes visible over time.

If you apply this method periodically, say, once a quarter, you’ll notice something interesting: Your team’s median completion times actually shrink. The feedback loop tightens.

Engineers internalize the habit of working with focus instead of letting tasks naturally expand. Not because you’re pushing them but because they’ve experienced what it feels like to finish tasks faster, and they liked it.

After about six months of periodic use, you’ll probably need to recalculate your medians. Your historical data will show shorter completion times, which means your aggressive estimates become even more aggressive. And the cycle continues.

That’s the real win. Not finishing one project early, but building a team that habitually works with intensity and focus without the stress.

One more thing: I know the orthodox critical chain community might push back on my adaptations of using story points instead of pure time estimates, using medians instead of single-point estimates, and modifying the buffer thresholds. I get it.

But these modifications are what make the method practical for modern software teams. The original theory is brilliant. Implementation must meet your team where they are.

It took me several iterations across multiple projects to get this setup right. I needed to figure out which Jira automations would work, how to structure the spreadsheet so it wouldn’t need manual input, and how to make the gauge chart update itself.

Below, I walk through the exact configuration step by step: how to compute your median completion times, set up automatic due dates in Jira (with the automation code), and connect a self-updating spreadsheet for buffer tracking.

I’m also including a ready-to-use template with all formulas from the case study above. If you’re planning to try this on your next project, it’ll save you a few hours of trial and error.

4. How to Configure Everything So It Calculates Itself

The whole philosophy behind my setup is the team does nothing extra. No additional tracking, no spreadsheets to fill, no status updates beyond the normal board workflow.

Engineers just move tickets across the board as they normally would. Everything I need calculates itself.

Here’s how.

Step 1: Calculate your median completion times

Export completed tasks from the last quarter (or or last four months) from Jira. You want tasks that are fully done, status “Done” or equivalent.

Group the tasks in the spreadsheet by SP value: Put all 1-point tasks together, all 2-point tasks, all 3-point tasks, all 5-point tasks, and so on.

One of the reasons I like Fibonacci sizing is because you end up with a manageable number of buckets to analyze.

For each group, calculate the median time from when the task moved to “In Progress” to when it was resolved. Remember: not average, median. The average gets skewed by that one task that took 14 days because of a dependency blocker or a vacation. The median gives you a clean, representative number.

You have a few options for doing this practically:

• Spreadsheet export

Export your Jira tasks to a CSV or connect Google Sheets to Jira. Then a pivot table will calculate medians in about 10 minutes. Seriously. This sounds like it should take hours, but if you know your way around a pivot table, it’s fast.

• Jira plugins

There are plugins like Time in Status (free tier available) that can show you these distributions directly. When I started, I used one of these. Now I find the spreadsheet approach faster for my workflow.

• Monte Carlo simulation

Some teams already use Monte Carlo diagrams for forecasting. These show similar distributions that you can use as a baseline for your aggressive estimates.

• A custom tool

We’re in 2026. You can build a simple script using the Atlassian API to pull this data and calculate medians automatically. I have several custom tools like this for team management, written with just a few prompts in Claude Code. (Maybe I’ll show how I build these in a future article.)

Whatever method you choose, by the end of this step you’ll have a table like:

• 1 SP → median completion time: X days

• 2 SP → median completion time: Y days

• 3 SP → median completion time: Z days

• 5 SP → median completion time: W days

Cut these by 50% (or 30%, or 20%, your choice). Those are your aggressive estimates. The sum of everything you cut is your project buffer.

Step 2: Set up automatic due dates in Jira

This is the key automation that makes the method low maintenance.

Create a Jira automation rule so that when a task moves to “In Progress,” Jira automatically sets the due date based on its story point value. The due dates are your aggressive estimates.

For example, with a 50% cut:

• 1 SP → due date = today + 1 day

• 2 SP → due date = today + 2 days

• 3 SP → due date = today + 2.5 days

• 5 SP → due date = today + 4 days

Here’s how to set this up in Jira Automation (Project Settings → Automation → Create Rule):

TRIGGER: Field value changed → Status → to “In Progress”

Then add a series of if/else conditions branching on the Story Points field, each setting the due date accordingly. The rule logic looks like this:

TRIGGER: When status changes to “In Progress”

IF Story Points = 1

  → Set Due Date to {{now.plusBusinessDays(1)}}

ELSE IF Story Points = 2

  → Set Due Date to {{now.plusBusinessDays(2)}}

ELSE IF Story Points = 3

  → Set Due Date to {{now.plusBusinessDays(3)}}

ELSE IF Story Points = 5

  → Set Due Date to {{now.plusBusinessDays(4)}}

ELSE IF Story Points = 8

  → Set Due Date to {{now.plusBusinessDays(6)}}

Note: Jira updates its automation UI frequently. It might look a bit different by the time you’re reading this.

A few more notes on the setup:

• Use plusBusinessDays instead of plusDays so weekends don’t count against the engineer. Nobody wants a due date landing on Saturday.

• Adjust the day values to match your own medians cut by your chosen percentage. The numbers above are examples from my case study.

• You can also handle this with a single Lookup table action if your Jira plan supports it. You’ll map story point values to day offsets in one place, making it easier to maintain.

You hardcode these values once. Update them roughly every six months if your team’s speed improves, which it likely will.

The due date must be visible on the board. This is important.

When an engineer picks up a task, they should immediately see the aggressive target. Not as pressure, as information. You want their mindset to be “This is how long it would take if everything goes perfectly. Let’s see how close I can get.”

And you’ll see something interesting: Many engineers actually enjoy the challenge. There’s genuine satisfaction in hitting an ambitious target. I’ve seen real joy on people’s faces when they finish a task within the aggressive estimate. It’s like a personal best.

But if they don’t hit it? Nothing happens. No consequences. No comments. That’s the deal, and you have to honor it every single time.

Step 3: Connect a spreadsheet for buffer tracking

I connect Google Sheets to Jira using a JQL connector. My query pulls only tasks with status “Done” from the specific epic I’m tracking.

The JQL looks something like:

project = [YOUR_PROJECT] AND status = Done AND “Epic Link” = [YOUR_EPIC]

Once the tasks are imported into the spreadsheet, I calculate:

• Cycle time for each task: The difference between the resolved date and the date it moved to “In Progress”

• Buffer consumed: The sum of time overruns beyond the aggressive estimates

• Progress: Percentage of total scope completed

• Gauge chart zone: Green, yellow, or red based on the buffer-to-progress ratio

Once a week, I refresh the JQL import. The new completed tasks flow in, all calculations update automatically, and the gauge chart tells me whether I need to do anything.

Total weekly time: about 10 minutes. Refresh, look, decide.

It contains all the calculations from the case study, buffer tracking, gauge chart zones, cycle time formulas, everything. You can duplicate it and plug in your own data.

🎁 Spreadsheet template with all the formulas

You can download my spreadsheet template. It contains all the calculations from the case study: buffer tracking, gauge chart zones, cycle time formulas, and so on. Duplicate it and plug in your own data.

Conclusion

Critical chain project management is one of the most underused tools in engineering management. Adapted properly, it gives you three things that are hard to get from any other methodology:

• Early warning

The buffer-to-progress ratio catches problems in Week 1 that burndown charts won’t surface until Week 3. That’s the difference between a fixable issue and a project delay.

• Captured time savings

By setting aggressive estimates, you neutralize Parkinson’s Law. Tasks that would have quietly expanded to fill their allotted time now generate actual savings for the project.

• Low overhead

Once set up, the method runs on 10 minutes of your time per week. The team does nothing extra. No additional tracking, no extra ceremonies, no new tools to learn.

The setup does take some upfront work. You’ll need to calculate medians, configure automations, and build the spreadsheet. But after that? You’re just looking at a gauge chart once a week and deciding whether to act or not.

Pick one defined-scope project. Set it up. Run it for four weeks, and see how it goes. The bar doesn’t have to be “not late.”

Last words

Special thanks to Karol for sharing his insights with us! Make sure to sign up to his newsletter Engineering Leader’s Playbook. To learn more about Karol, check him out on LinkedIn.

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

• Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.

• Interested in sponsoring this newsletter? Check the sponsorship options 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.

Full speaker lineup for the Engineering Leadership Live event in San Francisco, that I am hosting together with my friends from Augment Code.

- Gregor Ojstersek, CTO & Author Engineering Leadership newsletter
Talk: AI-Native Engineering Leadership

- Vinay Perneti, VP of Engineering, Augment Code
Talk: We Thought AI Transformation Was About Adopting Agents. We Were Wrong.

- Andrew Churchill, CTO, Weave
Talk: What Actually Works: AI Coding Patterns from the Top 1% of Teams

Join the event (limited spots available):

Secure your spot at the event

Looking forward to seeing you there!

Gregor

I’ll be giving a talk at the Engineering Leadership Live event in San Francisco

The talk is titled: AI-Native Engineering Leadership, and I’ll be sharing:

• What does it mean to be an AI-native engineering leader

• What has changed from 1-2 years ago

• Important trends and skills to learn to thrive in the role

Join the event live in SF on May 26.

Secure your spot at the event

Looking forward to seeing you there if you’re joining! Let’s get back to this week’s thought.

Intro

“My work speaks for itself”.

This is unfortunately what many engineers and engineering leaders believe, but the sad truth is that it rarely does.

The problem is not that your work is not high-quality enough. And the problem is also not that people are unfair (well, in some cases, that might be true), but mostly the problem is related to attention, and the organization being full of noise.

Especially leaders and decision-makers in the company, they sit in back-to-back meetings, and they get SO much information on a daily basis, it’s impossible for them to be on top of everything.

In such an environment, no matter how exceptional your work is, it can quickly become invisible. This is where narrative matters.

In today’s article, we’ll go through all about how to build a story around your work and how important it is to do that.

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

- The highest-impact engineers and engineering leaders are not only strong operators
- You need to build a narrative about your work in a similar way, just on a smaller scale
🔒 How to build a narrative around your work
🔒 1. You should start building a narrative even before the work begins
🔒 2. Find ways to repeat this message many times
🔒 3. Connect the work to business outcomes
🔒 4. Bonus: Make sure to communicate progress consistently and explain trade-offs
🔒 Being good at building a narrative is one of the highest-leverage leadership skills
🔒 Last words

Let’s start!

The highest-impact engineers and engineering leaders are not only strong operators

As we see the shift in our industry due to AI, strong builders and operators are being praised for their work a lot more than 2-3 years ago. But it’s really important to understand that they don’t just do great work alone, they are also skilled narrators.

Let me share a concrete example next.

Andrej Karpathy is someone that a lot of us know for the great work that he is doing around AI. But, imagine if Andrej were just to stay in the “research mode”, and only focus on doing great work, while not sharing his work online. He wouldn’t be perceived as the way he is today.

He recently announced that he is joining Anthropic as part of the pre-training team, and it was one of the biggest news stories in the tech space that received over 25M views on X.

I have to also give a shoutout to my friends and for the fun comments on the announcement post :)

The reality is that I am sure that Andrej got the job without the interview process. No leetcode, no system design interview, and no behavioral interview as well. And that’s all because of the credibility he built through his work and the narrative.

He is very smart about what he says, how he says it, and when he says it as well. He coined the term “vibe coding”, appears on podcasts to create narratives about what’s happening with AI and shares predictions, and also regularly shares his thoughts on X (almost daily).

He is building a narrative about his work every day, which is why we perceive him as a very credible individual.

The other 2 very good examples are:

• Boris Cherny (the creator of Claude Code), and

• Thibault Scottiaux (Head of Codex).

Thibault was also a guest on one of my most popular articles called: How to Build AI-Native Engineering Teams (highly recommend a read).

They both are great operators and builders, but at the same time, they are both active on X and appear on different events and podcasts. They both have cemented themselves as the go-to people for two of the most popular AI coding tools today: Claude Code and Codex (well, I’d put Cursor in between as well).

But you get the point, both would have an unlimited amount of opportunities if they’d want to work elsewhere or do something on their own. And that’s all because of the narrative they are building every day.

Now, all of these examples are quite extreme, but they paint a good picture about how powerful building a narrative is, and what it can do for you and how your work is perceived.

Let’s go to more realistic examples next.

You need to build a narrative about your work in a similar way, just on a smaller scale

It’s important to mention that there’s no need to appear on podcasts or post on X daily or LinkedIn daily in order to build a narrative about your work (of course, this helps, but it’s not required).

What I mean by building a narrative around your work is all about helping people understand:

• Why your work matters

• What problems it’s solving

• Why are these problems important now

• What tradeoffs were considered

• What changed because of your work

• What outcomes were created

• What future opportunities exist because of your work

Narrative provides context into the “why”, “what”, and “what were the outcomes”. Which is crucial. And goes well with what I like to regularly say:

You can do the best work in the world, but if it’s not aligned with the expectations, it won’t be perceived that way.

Look how big a change it is when you say.

1. My team has created product X, and customers seem quite happy about it.

2. My team has created product X that has increased the Daily Active Users (DAU) by 50%, and Average Revenue Per User (ARPU) by 25%, while also increasing the Net Promoter Score (NPS) by 20%.

The sad reality is that if you say the first version, the work won’t get the same praise and recognition, but if you say the second version, it doesn’t matter if you do the same work. The story behind the work in many situations matters more than the work itself.

The narrative in the second version is a lot better, and it’s all about the details and the context that you share, connected with what outcomes your work creates.

Especially important to understand as an engineering lead, if you don’t create a great narrative, your team will also not get the desired recognition, no matter how hard everyone works. So, it’s not only about you.

Now, let me share the detailed steps on how to build a narrative around your work.

How to build a narrative around your work

Read more

This week’s newsletter is sponsored by Larridin, an AI-native developer intelligence platform.

Measure AI’s impact on engineering.

Claude writes code 10x faster than a human. So why is engineering productivity up 20%, not 200%?

Engineers spend only 30-40% of their time actually coding. The rest goes to deployments, sprint planning, admin overhead, support questions, design reviews, incident response, and everything in between.

Until now, we’ve had no way to map and measure where that invisible work actually goes. Larridin changes that. Mapping how engineering work flows across your org, surfacing the blockers and friction that drag on productivity, and showing you exactly what to fix.

Larridin delivers complete 360° developer intelligence for AI-native engineering teams. From traditional developer productivity metrics to AI-era measures like Agent Effectiveness scores.

Unlock AI-native engineering potential

Thanks to Larridin for sponsoring this newsletter, let’s get back to this week’s thought!

Intro

In a previous article, I mentioned that code review is the new bottleneck for engineering teams. The reason is that these days, we are able to generate code faster than ever with AI.

But the problem is that we can’t review the code fast enough, so the review process is the new bottleneck. And for that reason, a lot of teams are trying to find the right balance between these 2 options:

1. Block the progress by doing great human code reviews and ensuring that the quality remains high

2. Rely just on AI code reviews and/or doing shallow human code reviews

The issue here is that there’s no industry-wide agreement on how to scale the code reviews in a way that would support the speed of generation of the newly created code, without generating bad code, e.g. “AI code slop”.

Lucky for us, Ankit Jain, CEO, Aviator, is our guest author for today’s article. He will be sharing his recommended solution.

Let’s introduce our guest author and get started.

Introducing Ankit Jain

Ankit is a cofounder and CEO of Aviator. Previously, he led engineering teams at Sunshine, Homejoy, and Shippo, and was also an engineer at Google and Adobe.

He also leads The Hangar, a community of senior DevOps and senior software engineers focused on developer experience. Today, he is sharing with us his take on how to avoid bad AI-generated code output, e.g., “AI code slop”.

Over to you, Ankit!

Code review process is not made for the AI-era

This article is a follow-up to How to Kill the Code Review, which argued that traditional code review is no longer a viable quality gate in an AI-accelerated software development life cycle.

The natural next question is, if not code review, then what? What should be the alternative?

This article is the practical answer.

Velocity charts look great. PRs are merging faster. If you only look at the code written, the numbers tell a story of AI accelerating output. But behind those metrics, engineering teams are accumulating a new kind of technical debt.

Those PRs are either sitting unreviewed for days or are being rubber-stamped because no engineer has time to carefully review 500-line diffs.

I am not saying engineering teams should go from reviewing every line of code to nothing. I’m advocating for moving the approval gates upstream to prevent what I call the “AI slop” code. Code that compiles, passes basic checks, and looks plausible but is subtly wrong.

Now, let me share in more detail where AI-generated code goes wrong, even without “looking wrong”.

6 ways AI code goes wrong without looking wrong

1. Plausible but incorrect logic

The most dangerous variety. The code reads right and has correct syntax, but the logic is wrong. These bugs are difficult to catch in review because they require understanding what the code was supposed to do, not just what it does.

2. Over-engineering

AI models are trained on vast bodies of code that include enterprise patterns, framework abstractions, and production-hardened architectures.

Asked to solve a problem that genuinely needs 15 lines, a model may produce a 200-line abstraction layer that anticipates a generality nobody asked for.

3. Convention blindness

Models generate good generic code, not code that fits your system. Your repo has conventions around naming, error handling, logging patterns, and module boundaries.

AI frequently ignores them, not because it can’t learn them, but because it hasn’t been told about them in the prompt.

4. Hallucinated APIs and deprecated usage

Models confidently invoke methods that don’t exist, reference config options that were removed two versions ago, or call internal APIs that aren’t accessible in the current service context.

These errors are sometimes caught immediately, and sometimes only in production.

5. Defensive overreach

Excessive try-catch blocks, silent error absorption, redundant logging. The code handles failure gracefully in the sense that it swallows it silently, making debugging substantially harder.

6. Cargo-cult patterns

Copies patterns without understanding why, like retry logic in a context where retries make no sense. Circuit breakers for calls that are always synchronous. Error handling that looks thorough but doesn’t map to actual failure modes. The pattern is there; the reasoning behind it is not.

The common thread is that slop passes the eye test. It looks like real code. That’s precisely what makes it dangerous at scale.

Why existing processes are not enough

Code review was designed for a different world.

AI-generated PRs are different in kind, not just in scale. When a human writes code, intent travels with the author through the review process.

They can explain the tradeoffs they considered, the alternatives they rejected, and the constraints they worked within. Even unwritten, that context is accessible.

When AI writes code, intent may exist in a prompt that was never saved, a ticket that doesn’t capture the decision-making, or only in the engineer’s head. The implementation is preserved; the reasoning behind it is not.

Tests catch less than we assume. Automated testing is necessary but not sufficient. Tests verify behavior within the scope of what the test author thought to test.

AI-generated code introduces failure modes that are, by definition, unanticipated because if the engineer had anticipated them, they would have specified them in the prompt.

You cannot write tests against requirements you didn’t know to articulate.

The missing ingredient: Intent

The concept of formalizing intent before implementation isn’t new. Behavior-Driven Development, Test-Driven Development, and Design by Contract all attempt to define behavior in a structured, human-readable form before any code is written.

These approaches were often perceived as overhead. Under delivery pressure, they got skipped. AI makes them practical in a way they were never before.

AI can help generate structured acceptance criteria, specs, and contract-like descriptions from a brief. It can also verify output against them. The overhead objection disappears when the spec itself is AI-assisted.

We tested intent-driven verification on a real feature

At Aviator, we recently ran an experiment to test the intent-driven verification approach. With the main question we wanted to answer:

What if the review happens before the code is written?

The team implemented a medium-scoped, full-stack feature. A hierarchical, per-repository configuration system, with zero manually written application code.

Everything was guided by a spec reviewed and agreed upon by the team before a single line was generated.

It spanned the full stack, including a database model and migration for config history, a schema/validation layer, a resolution engine that merges repo and global configs, a GraphQL API (types + mutation) for reading and updating configs, integration of the resolved config into all runtime subsystems (sandbox provisioning, CI handling, code generation, chat processing, persona selection), and a frontend settings page with a config editor, change history view, and source indicators showing where each setting originates.

The kind of feature that, done conventionally, would generate dozens of review comments across multiple PRs.

Writing the spec

The spec was generated collaboratively: a scaffolding PRD was fed to Claude Code, which was instructed to ask clarifying questions that were answered synchronously by the team.

The resulting spec was reviewed at two levels.

1. The first was implementation details

Specific UI component choices, input validation requirements, performance strategies like Redis caching for config lookups.

These are the kinds of concerns that normally surface during code review, not spec review.

2. The second was scope and completeness

The team caught a missing UX requirement, questioned whether a persona’s feature was well-defined enough to include, and flagged places where the spec text was out of sync with the actual design (e.g., referencing a table that didn’t exist).

These are decisions that, if deferred to post-implementation review, would require rework. The spec review took about 10 hours of engineering work across multiple engineers.

It produced 14 acceptance criteria with 65 checkable items. It also produced a document that could serve as a document against which the code could be verified.

Implementation and verification

We used Claude Code to implement the spec. The agent decided to split the implementation into four phases:

1. Foundation,

2. Backend core,

3. Integration, and

4. Frontend.

The whole implementation consisted of around 6k lines of code, with 40% app code, 40% tests, and 20% GraphQL auto-generated files.

It’s worth noting that no explicit instruction to write tests was given in the specification, which suggests the agent’s strategy for meeting the acceptance criteria was to write tests.

A second agent then verified the 65 acceptance criteria against the resulting PRs.

This took six minutes and produced a structured report with file references and explanations for each item:

• 60 passed,

• 4 failed, and

• 1 partial.

A human doing the same verification thoroughly would have needed hours.

What the code review caught

Human reviewers left an average of 10 comments per PR. Few bugs were found, with the major one being a stale editor state. Code review caught convention-level issues such as import placement, enum duplication, and naming patterns.

This was an expected outcome. Spec review catches design-level issues like missing requirements, underspecified features, and scope questions.

Code review catches convention-level issues, the things that require familiarity with your specific codebase. Both layers are necessary because they catch different things.

Five guardrails engineering teams can start using now

We’re still learning how to write specs that are precise enough for agents to implement reliably but flexible enough that the team doesn’t spend more time specifying than they would have spent coding.

Engineers tend to stress too much about what a spec should be and the overhead of writing it.

If we think about writing a spec simply as writing a JIRA ticket, that stress can go away. For a simple issue, a single-line intent or what you’d write in a ticket could be a sufficient spec detail, and acceptance criteria can be generated by AI.

Our experiment worked well enough to change how we think about verifying AI code and preventing code slop.

The following practices are not a complete methodology. They’re a set of concrete interventions that teams can adopt incrementally, starting where they have the most pain.

1. Scope AI tasks tightly

Large, open-ended prompts produce the most slop. ‘Build this feature’ hands the AI too much latitude.

Well-scoped tasks with clear boundaries: a specific function, a defined API surface, or a constrained refactor, produce way better output and are significantly easier to verify.

This is counterintuitive for teams that see AI’s value in handling large tasks. The value is there, but it works better when large tasks are decomposed into smaller, well-specified subtasks with explicit checkpoints between them.

It’s no different from how we humans work better.

2. Make intent a first-class artifact

Before any code is generated, the intent should be written down in a form that can be reviewed and approved. This doesn’t require a formal methodology. It requires the habit of documenting the what before generating the how.

Acceptance criteria can also be written by AI. Intent is really hidden in the prompt conversation that the user is having with AI (the decision tree) or the details a user may be adding in the ticket.

At the more rigorous end, it means BDD-style specs or contract-like descriptions that can be used to verify output.

The exact format matters less than the discipline of capturing intent explicitly. Again, I’m not trying to add overhead and invent new documents to write. We already do a pretty good job of expressing intent when prompting LLMs.

In practice, that would most probably look like a lightweight spec template for AI-assisted work.

Two to three sentences on scope, a list of acceptance criteria, and a note on what’s explicitly out of scope. Make it a PR requirement. That, again, can be generated by AI.

3. Review intent before implementation

For any AI-assisted task above a certain complexity threshold, require spec approval before code generation begins.

The most expensive review is the one that happens after the code exists.

When a design decision is caught in a spec review, fixing it is a sentence change. When it’s caught in code review, it may require significant rework.

Teams that shift review earlier, approving specs before generating code, front-load the high-value decisions and leave code review to do what it’s actually good at: catching implementation-level issues.

4. Automate what you can

Tests, linting, and type checks catch surface-level slop, and you should absolutely not skip those. As I said in my piece, trust is layered when it comes to AI code. We stack imperfect filters until nothing comes through.

5. Build and maintain a team slop register

Every codebase has patterns that AI consistently gets wrong. Maybe it’s a specific error-handling convention, a naming pattern, a module boundary that gets violated, or a library the AI prefers that you’ve deprecated. These are knowable and preventable.

A slop register serves two purposes: feeding these patterns back into prompts (to prevent them from occurring) and informing CI checks (to catch them when they do).

You don’t need the full workflow to see results

The most common pushback against spec-first workflows is that they’re slower.

Writing specs takes time. Getting them reviewed and approved takes time. And engineers who are already productive with AI tooling don’t want to slow down.

It may seem that this intent-driven verification adds process, but we are just changing the ways of working that we’re used to. The tools aren’t ready. The organizational structures aren’t ready. We are in transition.

If your team is early in this process, the most valuable first step is usually the simplest one: require capturing the intent from prompts for any AI-assisted task above a defined complexity threshold.

The format doesn’t have to be perfect and rigidly defined at first. A few sentences on scope, a short list of acceptance criteria, and a note on what’s out of scope.

From there, introduce a spec review as a step before code generation. Add the slop register. Build toward automated verification against acceptance criteria.

The full workflow takes time to establish. But each step in that direction improves the signal-to-noise ratio of what ends up in the codebase, and makes the AI investment return what it’s supposed to return.

Last words

Special thanks to Ankit for sharing his insights on this important topic with us! Make sure to check out Aviator, they are building a lot of cool stuff there, highly relevant for building engineering teams in the AI era.

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

• Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.

• Interested in sponsoring this newsletter? Check the sponsorship options 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.

Engineering Leadership Live Event in San Francisco

Together with my friends from Augment Code, we are hosting a live event in San Francisco on May 26!

Engineering leaders are holding excitement and dread about AI at the same time. The job description is changing faster than anyone can rewrite it.

Engineering Leadership Live is an evening for that conversation.

Three speakers, a room full of peers, networking, and snacks after.

It’s a free-to-join event, but there is a limited number of spots available, so make sure to register for the event below while the spots are still available.

Secure your spot at the event

Looking forward to seeing you there! Let’s get back to this week’s thought.

Intro

As mentioned already in the article Become a Great Engineering Leader in 2026, the entry-level engineering leadership roles (Staff Engineer, Tech Lead, Team Lead, EM, Architect) are just getting closer together as time goes on.

And especially a common scenario that I am hearing frequently is a Tech Lead or a Senior+ Engineer also taking on managerial responsibilities of the team.

Today’s article is especially for these people. People who have recently taken the managerial responsibilities of the team, regardless of their title.

I am sharing all of my knowledge and experience on how to manage your time as a first-time lead. This was also one of the modules in the Senior Engineer to Lead: Grow and thrive in the role course, and now adapted as an article in this newsletter.

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

- Managing my time was one of the biggest struggles I had as a first-time team lead
- Prioritize ruthlessly
- Make sure to block focus time in your calendar
- Use a Pomodoro timer to avoid distractions
- Improve communication to save time for everyone
- Remove pointless meetings
🔒 Separate “maker time” and “manager time”
🔒 Group similar work together
🔒 Say “no” more often
🔒 Take time off
🔒 Bonus: Biggest lessons I learned
🔒 Last words

Let’s start!

Managing my time was one of the biggest struggles I had as a first-time team lead

When you grow to a lead role, everyone wants your help, advice, or your involvement as well. I found myself saying yes to everything (which is NOT the way to go!). I’ve helped solve problems, joined discussions, supported everyone, and gotten involved in a lot of different initiatives.

The result was 10–12+ hour workdays, working as a manager during the week, and working as an engineer during weekends. It wasn’t sustainable.

It’s really important to understand that if you don’t manage your time correctly, your team will struggle, important work won’t get done, and you will eventually burn out.

A big learning for me was the following:

The more senior you become, the more you succeed through others, not through your own output.

As a lead, don’t try to take on all the hardest tasks yourself. That turns you into a bottleneck. It’s much better to delegate, trust your team, and focus on enabling others to succeed.

Now, let me share some of the most important things you need to do in order to manage your time effectively.

Prioritize ruthlessly

You need clarity on what to work on, what to schedule, what to delegate, and what to ignore.

A useful framework is dividing tasks into four categories:

• Do first: Important and urgent tasks.

• Schedule: Important but not urgent tasks.

• Delegate: Urgent but less important tasks.

• Don’t do: Not urgent and not important tasks.

One of the worst things you can do is keep everything in your head, and even worse if you can’t decide on priority.

Indecision often creates so many more problems, in some cases, a lot more problems than making a wrong decision. Because then you know that the decision was wrong, and you can pivot to the right one.

So, make sure to make decisions quickly. Either do it, schedule it, delegate it, or remove it.

Make sure to block focus time in your calendar

Everyone needs time dedicated just to focusing, without being distracted. If you don’t protect focused work time, your calendar gets consumed by meetings and “someone else’s priorities”.

And you might think that you are productive, but at the end of the day, nothing really gets done, therefore, I highly recommend putting dedicated focus blocks into your calendar.

Examples:

• 2–3 hours daily,

• half-days,

• a full day once a week,

• or several long blocks during the week.

Make sure that during the focus time, you disable any notifications, no meetings, no emails, no Slack messages, and other distractions.

Try to keep focused on what you are doing. This was one of the most impactful changes I made as a first-time lead, which has really helped me be able to do good work long-term.

A very important and underrated part is that it also creates healthy boundaries because people see you’re unavailable during those blocks.

Use a Pomodoro timer to avoid distractions

Additionally, if you have problems with focusing, the Pomodoro timer is the way to go. It always puts me in a state of focus because I intentionally avoid distractions, while the clock is telling me to focus.

I typically go for 25 minutes of focused work and a 5-minute break. Sometimes I go for 50 minutes of focused work, and a 10-minute break. Depending on how focused I feel and the overall motivation. I put the timer on full screen on one monitor, and then do the work on a bigger screen.

This helps me to stay in the zone and reminds me that I need to focus. Whenever I feel like my mind wants to do something else, the timer reminds me it’s time to focus.

During the focus time, I don’t check Slack, I don’t check my phone, I don’t look at social media, etc. The focus should only be on one task, and to finish it. Pomodoro helps force you into deep work mode.

Improve communication to save time for everyone

A lot of wasted time comes from poor communication. I like to say that overcommunication is better than undercommunication.

I intentionally overcommunicate specific topics in order to ensure that things are really clear, especially in a remote environment, working with people from all over the world, across different time zones.

It’s a lot better to say things multiple times and ensure they are understood than to assume they are, and you assume wrong. Overcommunication is usually the right amount of communication.

Key habits that will help you with this are:

• explain the “why” behind decisions,

• set clear expectations,

• avoid misunderstandings,

• proactively communicate,

• ask for feedback regularly.

And additionally, if you have something important for the whole team to focus on, say it in a meeting, and then also write it in the team’s Slack channel as well.

Remove pointless meetings

There’s nothing wrong with removing a meeting that is no longer useful. Not every meeting should exist.

The problem actually comes if there’s a meeting that is scheduled in a weekly cadence, and nobody feels comfortable removing it. While there’s no actual outcome from the meeting.

Always keep asking yourself:

Does this meeting help make a decision? Is this meeting necessary? Could this be async instead?

Separate “maker time” and “manager time”

Read more

This week’s newsletter is sponsored by Depot.

CI was designed for a different era. Depot CI is fast by design.

AI has shifted the bottleneck from writing code to integrating it. Agents can produce code in seconds. But if your CI pipeline takes 15 minutes to respond, you haven’t gained velocity. You’ve just moved the waiting.

Depot CI is a new, programmable CI engine built for the speed agents demand:

• Migrate your existing GitHub Actions workflows in minutes

• Targeted job reruns means no waiting on unrelated steps

• Instant starts, no queue time, billed by the second with no minimums

• Full API access so agents can trigger, monitor, and retrieve results programmatically

See how engineering teams close the gap

Thanks to Depot for sponsoring this newsletter, let’s get back to this week’s thought!

Intro

Talking with different engineers and engineering leaders, some of the main use cases, where AI is helpful, that come up the most are (apart from coding):

• Debugging issues

• Finding the root cause of an incident

• And also understanding the codebase and onboarding to it.

If you want to learn how 15 engineers and engineering leaders use AI in their day-to-day work, you can read this article:

Today, we are focusing a lot more on onboarding, and we’ll be going through all about how you can use AI to onboard into a codebase faster.

To help us with this, Jeff Morhous, Senior Software Engineer, CoverMyMeds, will be our guest author for today’s article.

Let’s introduce our guest author and get started.

Introducing Jeffrey Morhous

Jeffrey Morhous is a Senior Software Engineer, working in the healthcare industry. I have known Jeff for quite some time now, as we chat on different occasions and exchange our views on AI and all things engineering related.

He is also writing a newsletter called The AI-Augmented Engineer, where he regularly shares his insights on different AI-related topics. In today’s article, he’s sharing all about how AI is helping him onboard to a new codebase faster.

This is our second collab, and you can read the first one here:

Over to you, Jeff!

From “Where do I start?” to a structured plan

With Claude Code, (and most modern AI coding tools), you can compress “where do I start?” into a structured map of architecture, entry points, key flows, boundaries, test strategy, and runnable setup.

This is explicitly reinforced in the official Claude Code’s best practices guide. It describes onboarding workflows that improve ramp-up time.

Personally, it’s where I see AI to be useful the most.

If I already understand the codebase and need to make a small change, it’s often faster for me to type the change myself than to guide an LLM through it.

But if I’m not familiar with a codebase, and I need to make a change, it’s always faster for me to use AI to understand the new codebase first. I fully believe that if you’re opening a codebase for the first time and not using AI to help you get started, you’re losing hours of time.

In this article, I’ll show you my tool-agnostic framework for quickly getting up to speed in a new codebase, and I am also including my personally created prompts that you can use immediately.

Why rapid onboarding is one of the best uses of AI

For software engineers, onboarding to a new codebase can happen pretty often. If you work at a big enough company, you might work on apps you don’t have familiarity with, on a monthly or even weekly basis.

So onboarding into a new codebase is not just something you do when you get a new job, but happens regularly in an existing role as well.

Anthropic’s Claude Code best practices explicitly list onboarding as a top use case and even showcase the canonical onboarding prompt: “I’m new to this codebase. Can you explain it to me?” with an example of high-level codebase structure output.

Additionally, in their case study: How Anthropic teams use Claude Code, onboarding appears as a main Claude Code use case in multiple teams’ workflows.

Now, let me share how I get started with onboarding to a new codebase with 4 core onboarding tasks.

Core onboarding tasks

A good onboarding to a new codebase gives you a compact mental model you can keep in your head. The tasks below represent the set of mental models before I’m confident making safe, testable changes:

• Initial app understanding

The end result I aim for: A documentation file like a README, CLAUDE.md, or AGENTS.md.

• Mapping architecture

My goal in this step is to create a repo-local onboarding doc. A diagram of how components work together, and some sample traces of a request from entry to execution.

• Identify tests

In this step, I look for what tests exist, how they map to layers, and the fastest “confidence loop”.

• Identify how to run locally

I aim to get a minimal local run (or devcontainer run) with a smoke test that exercises a key flow.

The goal in going through these steps is to help me understand how to close the feedback loop from making a change to validating it, and to understand the path of a request into the app.

I’ll show how I use each of these with Claude Code, but the process is generally applicable to other popular AI-coding tools, including Cursor and Codex.

I wrote it as a step-by-step guide, so you can follow along if you want!

Onboarding with Claude Code

To run Claude Code in a new repo, install the tool and just run claude in the root of the repo.

1. Initial app understanding by using /init

If there is already a CLAUDE.md file or AGENTS.md file, read through them. If not, use Claude Code’s init command by running /init. The init command will skim through the codebase and create an understanding of the most important things, then document them in CLAUDE.md.

Use an Opus model when you run /init, even though it will cost you more tokens. Tokens spent on reasoning up-front are tokens well-spent.

When I use Plan Mode with a cheaper model like Sonnet, I find the plan is more likely to have overlooked critical architecture or contain consequential mistakes in the plan.

Opus or similar, more reasoning-heavy models have a lower rate of that and are likely to come up with things you wouldn’t have thought of on your own.

Cursor has a similar feature, you just have to ask Cursor’s agent in “Ask Mode” to explore and explain the codebase.

2. Mapping architecture

It’s great if you can produce a map of the repository early on. Understanding major components, responsibility boundaries, and dependencies can give you a huge boost when it’s time to actually make changes.

Here’s a prompt to help you do this:

You are onboarding me to this repository.

Tasks:
- Identify the top-level architecture (apps/services/libraries), and what each does.
- Produce a directory map: top 10 directories with responsibilities.
- Identify key runtime boundaries: API layer, domain layer, persistence, async jobs, config.
- Show a dependency diagram (Mermaid) using the repo’s actual module/package boundaries.
- Cite exact files for each claim (paths + brief evidence).

Constraints:
- Do not edit files.
- Prefer reading docs first (README, AGENTS.md, CLAUDE.md, docs/, CONTRIBUTING, ADRs) and then code.
- If the repo is a monorepo, explain the workspace/tooling setup.

Diagram:
Create a mermaid diagram with your findings

Claude Code will do just fine at finding information, and will present directories as boundaries in a nice table format.

But it won’t do a diagram. Alternatively, Cursor responds very well to this prompt and is happy to give you a really useful diagram. If you do this in Cursor, use Ask Mode, which will give you a really well-designed diagram, as you can see below.

3. Identifying tests

Every app handles tests differently, so sometimes it’s hard to figure out what tests your change should require. If you want to understand the test pyramid in your app and build a quick confidence loop, you should identify the patterns for the app right away.

Here’s a prompt I love for this:

Identify the testing strategy in this repo.

Output:
- Where tests live and how they’re organized (unit/integration/e2e).
- The fastest local confidence loop: which commands to run before a PR.
- How fixtures/mocks/testcontainers are handled.
- Common failure modes in this repo’s tests (if visible from config/docs).

If there is no testing strategy, propose a plan for one that follows the testing pyramid (lots of unit tests, less e2e tests).

My side projects don’t usually have tests (I know, I know), so this prompt is a nice way for me to get started with a good testing plan.

Claude happily suggested one, and it’s easy to turn this into a real “plan” and have Claude execute on it. With this level of detail, you can usually get away with a cheaper model (Sonnet).

I’m surprised by the level of detail Opus 4.6 gives when providing test plans. It shows a much greater “understanding” of the codebase and intended features than even recent versions of Opus.

Test commands can be fragile across environments, so ensure you confirm dependencies and env vars before trusting “works on my machine”.

In all my working sessions with AI tools, I’ve noticed that setup issues or deficiencies are the source of nearly all my issues. If you’re having quality problems, be sure to address anything that might stop your agents from validating their own output.

Be sure an agent has the ability (and instruction) to run the app with dependencies and run tests against its own code.

4. Running the app

If you don’t already have it by now, you’ll want instructions on setting up the app and running it.

Ask for setup steps strictly grounded in repo evidence:

Produce a repo-specific local setup checklist with commands.

Rules:
- Only include steps you can justify from files in the repo (README, Makefile, package/build files, scripts, devcontainer config).
- Include: required runtimes, dependency install, env vars, database setup, migrations/seeds, and “run server / run worker / run UI”.
- End with a smoke test of one key flow.

This should give you a single “happy path” setup that ends with a running service + a verification step. Claude Code gave me a great result when I ran this with Opus 4.6, and I didn’t even have to use a higher effort setting.

Bonus: Build a change plan before touching code

Once you understand the rough shape of the codebase, resist the urge to immediately ask your agent to make the change.

This is where a lot of AI-assisted work goes sideways.

You open a new repo, ask for a feature, and the agent happily starts editing files before you understand the blast radius.

Sometimes that works, but it can also change the wrong abstraction, skip the important test, or implement the feature in a way that technically works but doesn’t fit the codebase.

A better pattern is to ask for a plan first.

Before writing code, make the agent explain what it thinks needs to change, why those files are involved, what tests should be updated, and what could go wrong. This gives you a chance to catch bad assumptions while the cost is still low.

Here’s a prompt I like (it’s important to use plan mode):

I need to make this change: [describe the change].

Before writing code, create an implementation plan.

Include:
- The files likely involved.
- The smallest safe change.
- The existing patterns this should follow.
- Risks or hidden side effects.
- Tests to add or update.
- Manual verification steps.
- Questions I should answer before implementation.

Rules:
- Do not edit files yet.
- Cite exact file paths for every claim.
- Separate confirmed facts from assumptions.
- Prefer the smallest change that fits the existing architecture.

This is one of the highest-leverage habits you can build when using coding agents. Don’t let the agent jump straight from “I found the code” to “I changed the code.”

Make it show its work first.

For example, if you need to add a new field to a checkout flow, the plan should tell you whether that field touches the database, the API response, the form object, the frontend state, background jobs, analytics, tests, or docs.

In a codebase you already know, you might be able to hold all of that in your head. In a codebase you just opened 45 minutes ago, you probably can’t.

This also gives you a much better review loop. You can look at the plan and say, “No, that’s not the right service object,” or “This should use the existing policy class,” or “You missed the serializer.”

That feedback is much cheaper before the agent has scattered changes across 8 files.

What else will you do with AI?

So you’re looking at a new codebase, and you want to understand it quickly? Lean on your tools. Use AI to help you understand your code. Don’t just use AI to produce code.

Using AI this way will give you compounding productivity gains over time. I don’t think clicking through the UI of the app and trying to understand how previous engineers were thinking and where they put stuff is fun, and it certainly isn’t a good use of your time anymore.

To recap, here’s the playbook for getting up to speed in a new codebase quickly.

1. Initialize your onboarding context with /init

Read and understand the results. Take some time to validate them against what you see in the codebase. This should take 10-30 minutes.

2. Map the architecture

Get an understanding of the components and ideally, a diagram of how they work together. You should certainly understand how a request is handled and where to start if you want to make a change. This should take 20-40 minutes.

3. Get on top of tests

You should know what sorts of tests you’ll need to add for a change and how to run them. This should take around 15 minutes.

4. Get the app running

And understand how to do so consistently. The time it takes to do this will really depend on the specific app and its complexity.

If you do these things, you could hit the ground running in a brand new codebase in just a few hours.

Even if the changes you need to make will be largely agent-driven, the time invested here will pay dividends when you start to hit edge cases or unexpected complexity.

Last words

Special thanks to Jeff for sharing his insights with us! Make sure to check out his newsletter The AI-Augmented Engineer to get more insights on how to use AI effectively.

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

• Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.

• Interested in sponsoring this newsletter? Check the sponsorship options 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.

Engineering Leadership LIVE Event in San Francisco

Together with my friends from Augment Code, we are hosting a live event in San Francisco on May 26th!

Engineering leaders are holding excitement and dread about AI at the same time. The job description is changing faster than anyone can rewrite it.

Engineering Leadership LIVE is an evening for that conversation.

Three speakers, a room full of peers, networking, and snacks after. I’ll be sharing more about the speakers in future newsletters!

It’s a free-to-join event, but there is a limited number of spots available, so make sure to register for the event below while the spots are still available.

Secure your spot at the event

Looking forward to seeing you there! Let’s get back to this week’s thought.

Intro

Many companies these days are removing AI completely from tech interviews, not allowing the use of any of the AI tools to solve a coding task.

But that’s wrong.

Not allowing the use of AI is like removing a tool that engineers use daily. Similar to Google, Stack Overflow, or using an IDE. Are you going to remove that as well, and just check how well a candidate memorizes specific functions of a programming language?

Modern engineering is: having good judgment + using AI to move faster. Judgment is the important skill you should be checking.

So, why remove something that engineers use and are expected to use every day?

Especially, it doesn’t make sense when a company is even pushing for more AI adoption.

In today’s article, I am sharing in detail about which parts of the hiring process I recommend allowing the use of AI and which not.

I am also sharing 3 concrete options on how to structure a tech interview, so you allow the use of AI, and get all the info that you need to do a proper assessment of the candidate.

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

- AI-assisted engineering is the best way to build software these days
- Leetcode-style of a tech interview has been a standard for years
- I’d be surprised if, by the end of 2026, companies still use such a type of interview
🔒 This is my recommendation for a tech interview in 2026
🔒 This is how to structure a tech interview
🔒 Option 1
🔒 Option 2
🔒 Option 3
🔒 Putting it all together, the full process for hiring a new engineer
🔒 Last words

Let’s start!

AI-assisted engineering is the best way to build software these days

It has become a standard for the way we build. Most of the engineers these days are using AI in at least some part of the development process, which may be generating code, researching, or something else.

Learn how 15 engineers and engineering leaders use AI in their day-to-day work in this article:

To quote from the recent survey conducted by JetBrains:

The biggest question is not whether developers use AI at work. The answer to that is already obvious: They do. In January 2026, 90% of developers regularly used at least one AI tool at work for coding and development tasks, a clear sign of high AI usage in software development.

We are currently in May, which means that the % of engineers using at least one AI tool has just increased.

So, if using AI as part of the development process is a standard these days, why would companies want to remove AI from the assessment of new candidates?

The goal with the tech interview should be to get as close as possible to the actual work that an engineer is doing on a daily basis, right? That’s how you can assess whether it’s a fit or not.

Well, that’s been a problem for years now as well, even before AI became so popular. Let’s get to that next.

Leetcode-style of a tech interview has been a standard for years

LeetCode (the platform) was founded in 2015, and quite quickly after that, it became the go-to style for tech interviews in many companies. It has become a standard for “objectively” assessing the technical skills of a certain candidate.

Well, I was never a fan of it, and I’ll tell you why.

When I was a Software Engineer, preparing for interviews, I solved 200+ leetcode style type challenges, and while solving them, I kept looking for specific patterns that could be reused across different challenges.

I made sure to create templates, which I could reuse for any problem that I’d be asked to solve in an interview. So, doing that, I was well prepared for interviews, and I also nailed the interview and got the job.

Well, that felt good, that I was able to “grind” leetcode challenges for weeks, and I got the job, but then none of it really helped me in my day-to-day work.

The work that I was doing was completely different than what I had been grinding for weeks.

So, basically, with the leetcode-style type of interview, you don’t really assess the actual skills that a specific engineer needs to be able to do the job well. You assess whether the person has been practicing such types of challenges or not.

I’d be surprised if, by the end of 2026, companies still use such a type of interview

Especially these days, with AI, you can solve any of the leetcode-style challenges in a matter of seconds.

And if the standard in our industry is AI-assisted engineering, then it really makes no sense to “check the tech skills” with problems, which can be easily solved with a prompt.

I’ve talked to many engineers and engineering leaders about this, and many share a similar sentiment, so I’ll be really surprised if, by the end of 2026, we’ll still see such interviews done by any of the companies.

As mentioned, a leetcode-style interview just checks whether the person has been practising solving such problems or not. But these problems are not even close to what an engineer does on a daily basis.

Now, let me share what my recommendation is.

This is my recommendation for a tech interview in 2026

Read more

Together with my friends from Augment Code, we are hosting a live event in San Francisco on May 26th!

Engineering leaders are holding excitement and dread about AI at the same time. The job description is changing faster than anyone can rewrite it.

Engineering Leadership LIVE is an evening for that conversation.

Three speakers, a room full of peers, networking, and snacks after. I’ll be sharing more about the speakers in future newsletters!

It’s a free-to-join event, but there is a limited number of spots available, so make sure to register for the event below while the spots are still available.

Secure your spot at the event

Looking forward to seeing you there!

Gregor

This week’s newsletter is sponsored by Codacy.

The average codebase relies on 10 AI models and 2 coding assistants. Most leaders can’t list what’s in theirs.

For most engineering leaders, mapping their own team's AI usage takes weeks of manual surveys, and the results are obsolete before completion. Meanwhile, compliance gaps keep widening.

With Codacy’s AI Inventory, engineering managers can oversee:

• Every AI model, SDK, API key, and MCP server in the codebase, down to the file and line.

• Which AI coding assistants their engineers are using and in which repos.

• A real-time AI inventory built from source code alone: the foundation for EU AI Act, ISO 42001, and DORA ICT compliance work.

Control the AI in your repos

Thanks to Codacy for sponsoring this newsletter, let’s get back to this week’s thought!

Intro

I am currently writing a book, The Multiplier Mindset: How to Move from Senior Engineer to Tech Leader in the AI Era (check out the early release on the O’Reilly website).

The book will feature 8 case studies of successful multipliers (tech leads, engineering managers, staff engineers, and architects), looking at:

• How they multiply others

• What makes them successful

• How they use AI

• Their advice to engineers and engineering leaders to thrive in the AI era

Today, I am sharing the case study of Anton Zaides, engineering manager at HoneyBook, which will be included in the book.

Let’s introduce our guest author and get started.

Introducing Anton Zaides

Anton Zaides is an engineering manager at HoneyBook, managing a team of software engineers. Previously, he grew from being a software engineer to director of engineering at Taranis, an agri-tech startup.

Anton also writes a weekly newsletter for engineering managers, Manager.dev, sharing what nobody tells you about engineering managers.

Today, Anton is sharing with us the five areas of responsibility every engineering manager has and how he juggles them. Over to you, Anton!

The 5 areas of responsibility

As an engineering manager (EM) at Honeybook, I manage a team of seven software engineers, from mid-level to senior staff. I started this role around six months ago, taking over an existing team.

In today’s article, I’d like to share some behind-the-scenes stories from my career that I believe helped me succeed and provide my take on thriving as an EM in the AI era. Let’s start with the basics.

As an EM, I have responsibilities across five main areas:

• Product building

My team and I build the company’s product. This is the main thing that we are evaluated on and is what often takes about 80% of an EM’s focus.

• Team support

I have 1:1s with my team members, making sure they have clear career paths, are being challenged in their work, and are being paid fairly.

• Customer support

I ensure we provide good service for our customers and other teams that depend on us. This often clashes with product building and team support. Customer support can slow down delivery, and engineers don’t usually enjoy the work.

• Technical direction

This is about how we build things: the processes, the tools, and the tech debt we leave behind.

• The team’s future

Where do we want to be in six months? What areas are we responsible for? This includes hiring and pushing for strtegic positioning for the team (e.g., getting important projects).

Focusing on things that the team needs most

I’ve now had three EM roles and each time, I prioritized my responsibilities differently.

A huge part of being a successful EM is adapting yourself to what your team needs, not what you enjoy or what comes naturally to you.

In my most previous EM role, my work was much more technical. I was the main coder and was very involved in the initial stages, building the technical foundation.

There was not a lot of senior talent in the company, so I stayed involved in most technical decisions throughout my tenure, even when I was the director of engineering.

My current EM role is very different.

My team consists of very strong engineers, and the codebase is in Ruby on Rails, which I wasn’t familiar with before starting the job. My comfort zone is to dive deeper and become more technically involved, but in this situation my added value would be negligible.

My time is better spent focusing on two other areas:

• The engineers themselves

Even senior engineers benefit from management. Most of the team hadn’t had 1:1s in months before I arrived. There had been no engineering manager for almost a year, and because they were considered strong, they were left to fend for themselves.

My first goal was to talk with each of them individually: understand where they stood, who wanted to get promoted, who felt underpaid, and who wasn’t challenged.

• Customer support

My company is B2C-ish, with many customers, and I felt the process of handling support tickets could be improved. Tickets would be open for weeks or months. Some would fall through the cracks.. They really weren’t anyone’s priority, and it’s an area engineers often don’t like dealing with.

So I took on the most annoying and became knowledgeable there. The return on my time was high: I improved response time, communication with support, and overall understanding of the issues we were seeing.

I also focus on my team’s vision, but I’m barely involved in the delivery and technical direction parts! You can’t really focus on all five areas in the time you have, and I feel this ability to understand what’s needed more right now is crucial.

I’ve only been in this role for six months. In time, I’ll be able to become more involved in those areas, but for now they are in good hands. I’m learning slowly by fixing customer tickets.

How to be a truly product-minded EM

Every amazing EM has at least a bit of a product manager (PM) inside them, and this is doubly important now. With LLM, code is no longer the bottleneck; engineers are now waiting for PMs.

With many organizations expecting engineers to take more ownership and make product decisions, there is no way to succeed in our jobs without some PM skills.

I divide being product minded into three parts.

1. Product involvement

I like product management. I listen to Lenny’s Podcast, and I’ve read Marty Cagan’s books. When we understand how PMs work, we can better influence their decisions and better support them.

The very basics of product involvement is understanding your customers’ pains. It can be done by diving deeper into the analytics, watching session recordings, or, ideally, actually talking to customers.

Most organizations are just not built in a way that encourages this, however. There are several layers between engineers and customers, and breaking through them takes some effort.

To get access to customers:

• Observe existing meetings. Ask to silently join customer discovery calls run by PMs, sales, or customer service (CS). Promise not to interrupt, just listen and learn. If you have a question, send your contact a private message during the meeting.

• Reach out via support. Find a user who has recently complained or a customer ticket that you fixed, and reach out to them. You’ll be surprised how receptive customers can be.

• Work with CS to identify a power user. Send a short, respectful email, like: “‘I’m an engineer on the team that built X. I’d love 15 minutes to learn how we can make it better for you.” CS teams are often delighted when engineers take this initiative, because the usual mindset from engineers is “don’t waste my time with useless meetings.”

At my previous company, it took me three years to actually go visit a customer. My company flew drones over agricultural fields, analyzed the images with AI, and provided our farmer customers with insights into the problems in their fields.

Our customers were in the United States, requiring me to fly from Israel to see them in person. I was willing to do that, but the farmers were also super busy and didn’t really want to talk to engineers.

Then our CS team got me in touch with one of our customers by identifying a power user. They connected me with a customer who was really enthusiastic about one of our latest releases.

They mentioned that an in-person meeting would be more effective, as on Zoom our customer would turn his camera off and wouldn’t have a lot of patience. So I drove 10 hours from our office in Indiana to that customer in Iowa for just a 1-hour meeting. Let me tell you: It was so worth it!

• I saw how he used our app in real life on an iPad. It turns out that in one of the critical flows, this customer jumps from our app to another app on his iPad to get some data and then returns to ours. That’s not something we knew. I asked about it, and he mentioned that it’s very annoying but he has gotten used to it.

• There was a question I asked that he couldn’t answer, so he just called an intern into our office. It turned out that the intern is a super-enthusiastic user, who of course is never invited to Zoom calls because he is not senior enough. I got a lot of great product feedback from him.

I believe that this single meeting helped my product orientation more than a year of session recordings could.

2. Business understanding

Most EMs skip understanding how the company makes money and how their team is connected to it.

My previous team had been writing all the software for the drone pilots, who were internal users. They were a critical part of getting the images needed for our product to work, but my team didn’t directly impact revenue most of the time.

The company’s gross margin was less than 50%. This means that for every dollar our customers paid us, we got less than 50 cents. That was largely because we need to pay the drone pilots to actually go fly the drones and take images. We had a goal of increasing the margin to 60%, which my team was heavily involved in.

Of course, we didn’t want to pay the drone pilots less; they’d leave otherwise. What if we could help them fly more fields per day and we split the gains? For example, if they usually flew over 10 fields a day, we’d improve the software so that they could do 15 instead. We’d pay a bit less for each field, but they’d still make more money overall.

We built a super-small feature that helped the pilots plan their routes better, and it improved the pilots’ outcomes by 11%!

Once we released the feature and I saw how excited everyone was about the gross margin part, I started to mention it in conversations and immediately saw an impact.

For example, I had wanted for a while to improve our app’s stability, but it was never a top priority (as often happens with internal apps).

But mentioning how we’d be able to hire fewer support engineers the following year (who scaled linearly with the business) and increase our gross margin, I got a much better reception.

Once you get used to thinking in business terms, there is no way back. You start to question every part of your work, which is a great thing.

3. Extreme dogfooding

The final part of being product minded is to truly understand your product from the inside.

Two years ago, I read From Worst to First, a book about Continental Airline’s CEO, Gordon Bethune, who transformed the airline from the worst to the best. One idea stuck with me: Bethune got a commercial pilot’s license so that he could speak the same language as his pilots and understand them better.

I decided to experience firsthand how our apps were used. I got a commercial drone pilot license from the US FAA. During the preparation, I spent some time with our operations team (my main customers), and it was a great opportunity to bond. Then I worked a full day in the field as a drone pilot, doing real flights for our customers.

This really helped me understand better how our app was being used and the difficulties with it. I even discovered small things, like needing battery power for the laptops and having a hard time seeing things on the screen because of the sun.

Go extreme with dogfooding! Uber’s CPO spends a day each month driving an Uber! If he can find the time, so can you.

Build a team that doesn’t depend on you

As an engineering manager, you don’t want to be a tunnel that everything must pass through. I want my engineers to talk directly with product managers and designers. Just conversations shouldn’t be constrained by my schedule.

I want my engineers to be able to decide things on their own. They should consult me when needed but not depend on me for every decision.

For every new project, I assign an engineer as the responsible owner. I’m on the sidelines; they communicate, they share the successes, they get the recognition. That’s how you build a team that is more autonomous and less dependent on you.

Another part of building an autonomous team is giving team members exposure to the day-to-day. When engineers deal with real problems and real requests, they build context. Over time, they make better decisions and move faster because the knowledge isn’t centralized in one person.

On a previous team, too many things passed through me. So we introduced a team representative who would be responsible for day-to-day operations. Support talked to the rep, the PM talked to them, and all requests went through them.

It reduced dependency on one person, built more context across the team, and helped people make better decisions over time.

There’s also advocacy.

As a manager, you need to fight for your people for promotions, raises, and recognition. You have to advocate in smaller ways too.

Telling someone they did a great job on a project, that you appreciate how they handled a challenge is underrated. People are often surprised by that recognition, but it goes a long way.

My approach to AI adoption

AI adoption is a tricky balance. On one hand, you need to let people explore on their own and not force AI on them. On the other, you need to nudge them into trying it and give them the time and space to do so.

If people focus only on their day-to-day work, they won’t explore, and they’ll become less relevant over time.

The best ideas will come from the engineers themselves. There’s no need to force AI exploration. Just create the conditions for it and nudge them once in a while.

A good example of this is the AI hotfixer one of my engineers built. As soon as a support ticket opens, an LLM-based process scans commits and tickets from the past few months, suggests the likely cause, and surfaces similar tickets with their resolution steps.

This turned out to be super helpful. A hotfixer shift lasts a week, and you don’t always know what happened the week before. Many issues are recurring, but because each engineer is dealing with them once, the pattern is invisible.

Instead of debugging a complex issue from scratch, you can see that it also happened last week and the exact steps someone took to resolve it, sometimes saving hours.

More importantly, it changed how we handle recurring problems. When you can easily see similar issues across time, you can spot patterns and you’re much more likely to solve the root cause.

Our production load decreased by 30–40% as we worked through those root causes one by one.

This is what “give space to explore” looks like in practice. There was no mandate to improve our processes with AI. An engineer just did it because they had the time and the trust to try something.

Another critical point is that most conversation about AI in engineering focuses on the tools themselves, but I think the bigger challenge is what changes around them.

The first that changes is that development becomes cheaper, so decisions matter much more. When code is cheap to produce, the cost of building the wrong thing goes up, because you can ship bad decisions faster.

This means managers must be deeply involved in what gets built, not just how (another point for product orientation!).

The second is that implementation becomes very easy, meaning you need more rigorous planning, not less. The discipline to stop, think, and plan before touching code is harder to maintain when the friction of starting nearly disappears.

Using AI personally

I work about 90% of the time in Claude Code. The most significant change in how I work isn’t that I write code faster; it’s that I’m managing context across a complex, multiperson project.

I’m currently working on a greenfield project involving more than 10 people, who are running in parallel across different streams. One of the engineers set up a Git repository that holds all the context for the project. I was skeptical at first, but it works remarkably well.

Meeting transcripts automatically sync into the repo. The repo connects to Slack and can summarize discussions. There are markdown files organized by topic that automatically sync to Notion as we work on them. The repo becomes a living, queryable record of the project, not just our decisions but our thinking.

When I want to get up to speed on a specific part of the project, I just talk to Claude. I can ask what specific people think about a given decision, and I’ll get an accurate answer grounded in the Slack threads and meeting transcripts.

Instead of scheduling 10 conversations to understand where 10 people stand, I can ask one tool to figure it out for me in minutes.

Final advice for engineering leaders

All of this distills down to three things you need to do to be a successful EM:

• Stay a part-time engineer

Even if it’s only a small part of your workweek, you need to stay active. Our whole career is changing, and to fully understand what your engineers are experiencing, you have to be part of it.

• Become product oriented

You and your team must become product oriented, if you’re not already so. Understand the PM world, talk with customers, and get closer to the business.

• Get to know the people you work with

Human connections matter more than ever. Create opportunities to get to know your team and your customers.

Last words

Many thanks to Anton for sharing his experience as an EM with us! Sign up for the Manager.dev newsletter to get one practical idea every week on how to be a better EM.

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

• Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.

• Interested in sponsoring this newsletter? Check the sponsorship options 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

I’ve been interested in writing about the FDE role for a while, as I’ve seen the big increase in popularity in recent years.

And especially after attending the Salesforce TDX in SF and speaking with Nick Johnston, SVP, Global Consulting Partnerships & Partner Sales at Salesforce, it became clear that the role’s popularity is just increasing.

We talked for 30+ minutes just about FDEs and what they do! Here is also the picture:

Today, I am sharing my thoughts on whether I think you should become an FDE or not, what FDEs really do, and who the role is best suited for.

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

- What is a forward deployed engineer?
- Why the role exists
- What a forward deployed engineer at Salesforce does
- What a forward deployed engineer at OpenAI does
- What a forward deployed engineer at Palantir does
🔒 Should you become a forward deployed engineer?
🔒 The pros
🔒 The cons
🔒 Who thrives in this role?
🔒 Is it a good career move?
🔒 Last words

Let’s start!

What is a forward deployed engineer?

Forward deployed engineer (FDE) has gained a lot of popularity in recent years, especially among tech companies that work directly with businesses (B2B).

What my feeling is, talking with different engineers and engineering leaders about the role is that a lot of people have some sort of idea about what FDEs do, but in reality, the roles are quite different from one company to another.

The role varies based on the requirements of a specific company. Which means the skills needed (especially on the tech side) are different, but one thing is clear. Customer empathy is really important, and it’s highly unlikely to be a great FDE without being able to put yourself in the shoes of the customers.

I like to personally view this role as an intersection between software engineering, customer success, and product/business. The reason is that FDE’s primary role is to help customers use their products.

Therefore, they need to be technically savvy and, at the same time, be able to communicate well with the customers and have a good understanding of the product and the overall business, so they can find the right solutions.

Think of the role as a consultant who is also a main developer, integrating the solution directly. In many ways, you’re not just building software, you’re solving business problems in real time.

If you’re considering this path, it’s worth understanding what the job really involves, who it’s best suited for, and the trade-offs you’ll face. Let me share, next, why the role really exists in the first place.

Why the role exists

Especially companies that offer more complex products to their customers, can face issues between what their product can do and what customers actually need. FDE is the person helping to fill this gap.

They help:

• Increasing adoption of the product

• Customize implementations for specific customers (if needed)

• Gather feedback from customers to improve the product itself

Let’s go through, next, what FDEs at Salesforce, OpenAI, and Palantir do.

What a forward deployed engineer at Salesforce does

Nick mentioned that there is no single recipe for the role, and it may vary a lot from customer to customer, but the core responsibility is clear:

Help customers get value from technology faster.

An FDE typically starts by understanding the customer’s needs, pain points, and, of course, their current environment:

• What systems are already in place

• Where customer data lives

• How that data flows across systems

Once that is a lot clearer, they focus on defining use cases that would help the customer.

Example use cases:

• Adjusting the data flow

Not just within Salesforce, but also in external systems in order for the customer to be able to integrate with Salesforce successfully.

• Setting up AI agents in order to automate a certain business process

This is another use case (which seems to be a popular use case, based on my impression from the Salesforce TDX conference).

As we mentioned in the article, 3 Key AI Trends, EGI (Enterprise General Intelligence) is something that should be a clear focus for all enterprise companies. And EGI means using AI, its tools, and systems to perform business-specific tasks with high capability and consistency.

• Implementing the right guardrails for the customer

And a third use case that Nick has mentioned is implementing the guardrails, which may be security, governance, compliance, or something else. Especially important for bigger companies, which need to ensure compliance with specific standards.

These are just examples of use cases that FDEs deal with. To sum up, the core focus of FDEs is to ensure they understand the customer’s needs very clearly and find the optimal solutions to help them get the best results.

There are 2 types of FDEs at Salesforce, internal and partner

1. Salesforce FDEs (internal)

These engineers are closely connected to the product organization. Customer work is secondary unless a client explicitly requests Salesforce involvement. Their main goal is to:

• Gather feedback on product features

• Test new features in live environments

• Help improve the product

2. Partner FDEs

Those are FDEs from companies like Accenture and Deloitte, who work directly with the customers:

• To deliver specific implementations for a customer

• Provide direction or solution design

• Have support from Salesforce FDEs

This partner model helps Salesforce to scale without building a massive internal services organization.

What a forward deployed engineer at OpenAI does

I’ve checked all the different openings of a forward deployed engineer position at OpenAI, and here is what I found out.

FDEs are expected to:

• Design, architect, and develop full-stack solutions

• Build production AI systems and integrations

• Deploy advanced AI models on customer infrastructure

This is a combination of being a solutions architect, software engineer, and AI engineer.

They provide a hybrid work model of 3 days in the office per week, and travel up to 50% is required. Which means that FDEs are consistently traveling to customers and working directly on-site.

A lot of the FDE roles are general, defined as Model Deployment for Business, which means that they can contain any kind of work related to OpenAI. From creating custom GPTs for the customer to helping integrate OpenAI into the logic of the customer’s applications, or something else.

There are also some more specific focused FDE roles like “FDE, Financial Services”, which means that FDE works mostly with Fintech companies.

What a forward deployed engineer at Palantir does

Palantir is the company that first invented the role, and from doing research, the reason was that their software was too complex for customers to just “plug it in”, therefore a dedicated person was needed to get a specific customer up-to-speed.

Here is the definition of an FDE from their official blog:

FDE is a software engineer who embeds directly with our customers to configure Palantir’s existing software platforms to solve their toughest problems.

While a traditional software engineer focuses on creating a single capability that can be used for many customers, FDEs focus on enabling many capabilities for a single customer.

Additionally, they mention that FDEs need to be iterating closely with customers across various industries and require a unique and broad skillset, ranging from software development to data engineering to customer engagement and creative problem-solving.

FDEs need to address questions like:

• What products are we deploying for this use case?

• Why are we deploying them?

• How will we spin up workflows that utilize these products to address the customer’s specific needs?

FDEs need to be able to answer these questions, and at the same time, also implement these solutions.

Now that we better understand the role and what it looks like based on different companies, let me share whether you should actually become an FDE yourself.

Should you become a forward deployed engineer?

Read more

This week's newsletter is sponsored by Postman.

The ROI of AI-Native Engineering

Most engineering teams have adopted AI, but the gap between using tools and getting measurable ROI is wider than most leaders realize.

Postman’s latest cost savings analysis benchmarks six core API workflows to show exactly how much time is lost when AI is bolted on externally versus built directly into the development platform.

Download the report to learn:

• Native vs. External: Why integrated AI reduces cognitive load.

• Workflow Benchmarks: Data-driven time savings for engineering teams.

• The ROI Gap: Closing the distance between adoption and results.

Get the report

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

Intro

Last week, I was in San Francisco, and I also attended the Salesforce TDX conference. It’s been interesting to get to know what Salesforce is focusing on these days, and yes, no surprise here. It’s all about AI.

But what I didn’t expect was the shift that they are now doing, which is, in my opinion, a huge shift in a whole different direction than what they have been focusing on for the last 25 years.

At the event, I also spoke with different product and engineering leaders from Salesforce: Gary Lerhaupt, Itai Asseo, Dan Fernandez, Nick Johnston.

And, a lot of other engineers and engineering leaders, attending the conference as well. Today, I am sharing my thoughts and insights from the conference.

In this article, we’ll go through:

1. Salesforce Bets on AI Agents: Their announcements on the event, my thoughts on them, and why this might affect how you look at AI strategy at your company.

2. 3 Key AI Trends from Salesforce AI Research Team: EGI is something that all enterprise companies should focus on.

3. How Salesforce Engineers Use AI to Build Their Products: Prototyping, planning, code quality, and observability are some of the most important use cases for them (alongside coding).

1. Salesforce Bets on AI Agents

The majority of the talks and workshops have been AI-related. This was my first impression coming to the conference, and in general, with San Francisco as well.

Everything revolves around AI. The conversation everywhere is all about AI agents, MCP, vibe coding, AI adoption, etc. And that’s been exactly the case with Salesforce TDX. I’d say around 80-90% of all the talks and workshops have been AI-related.

Based on all the talks, workshops, and new announcements, one thing is clear to me. Salesforce is essentially betting on this premise:

Future enterprise software will be run largely by AI agents, not humans clicking through user interfaces.

Interestingly, Salesforce has always been known for an interface-heavy experience, but now it is completely changing the script. Less UI, less clicking, more automation.

Here are some of the new things they have announced at the conference, exactly pointing out the change of direction.

Headless 360

The subtitle on the announcement page says it all:

Everything on Salesforce is now an API, MCP tool, or CLI command, and agents can use all of it.

With the question presented: “Why should you ever log into Salesforce again?”. Which points exactly in this direction, as we mentioned above.

The user interface is becoming less and less important for them, and automation is what is becoming the moat for them.

This quote represents what they want to do with Headless 360:

For 25 years, using Salesforce meant working inside Salesforce. A customer service rep opened a console, clicked into a case, and manually updated its status. A human, navigating a platform, to get work done.

But in the Agentic Enterprise, humans aren’t the only ones doing the navigating. Agents are too, and they don’t go to a browser or click through UIs. They call APIs, invoke MCP tools, and run CLI commands directly.

This is definitely something to think about for the AI strategy for your company. Ultimately, it’s in line with the trends these days, but the main question is: “Is it worth investing in UI, or focus a lot more on automation?”

Clearly, for Salesforce, automation is where their big bet is.

Agentforce Vibes

At the event, they introduced the new version (2.0) of the Agentforce Vibes. If you haven’t heard about it before, think of it like a GitHub Copilot, as the 2 main ways to use it are as a VS Code extension or directly in the browser.

You can write prompts directly inside the IDE, and you can use either the plan mode or the agent mode. The first one will just share the plan, and the second one will do what you ask.

Interestingly, I tried it out in 2 workshops. In the first one, I needed to build an app based on certain requirements. And if done correctly, you get a prize, and in the second one, I needed to use it in order to debug a LWC component correctly.

From my experience, I’d say it’s good if you are developing things on Salesforce, as that’s what it’s ultimately built and optimized for. But I’ll stick with Cursor or Claude Code for building at this time.

What’s missing from my experience is a Desktop-native app for Mac/Linux/Windows of the IDE. Because that’s how most of the developers build software these days, using a browser, not as much.

Agentforce

If you haven’t heard about Agentforce, it’s Salesforce’s platform for building AI Agents. At the TDX conference, they particularly announced 3 new things:

• open-sourcing Agent Script

This was interesting for me, as I know Salesforce is known for building its own things, instead of reusing existing ones. Similar to what they did with LWC components and APEX programming language.

They have now open-sourced Agent Script, which is a language for defining how AI agents work, their reasoning, and responsibilities.

• ADLC (Agent Development Lifecycle)

They announced a set of skills for Claude Code for building, deploying, testing, and monitoring Agentforce agents.

• Agentforce Labs

They also created Agentforce Labs, where you can start building on the site directly or see some example use cases.

2. 3 Key AI Trends From Salesforce AI Research Team

It was interesting to get to know how they think about AI in general and where they see the future of it. The insights shared next are based on my discussion with Itai Asseo, VP, Salesforce AI Research.

He particularly mentioned that while AGI (Artificial General Intelligence) is something aspirational at the moment, EGI (Enterprise General Intelligence) is something that should be a clear focus for all enterprise companies.

EGI means using AI, its tools, and systems to perform business-specific tasks with high capability and consistency.

And that’s exactly what Salesforce is focusing on at the moment, as we mentioned above in the first section, their biggest bet is on AI Agents and less on User Interfaces.

Now, let’s go to the 3 trends they see as the most important at this time.

Simulation environments

This is the first trend mentioned by Itai, and he shared an interesting analogy:

Athletes train in safe, controlled places before real games. AI agents need the same thing.

AI Agents need to learn and improve in these environments before being used in real situations. This lets companies test them without taking risks.

A big part of this is synthetic data.

Companies shouldn’t always use real data because it might be private or sensitive. So instead, they should create fake data that looks real but is safe to use. Similar to how Formula 1 drivers practice in simulators before driving actual race cars.

Simulations are also useful for testing how well AI works. Companies can try different scenarios, like text or voice, and see where the AI struggles. Then they can fix those issues and make it more reliable before using it for real.

Itai also recommended that for companies just starting with AI, simulation is one of the easiest and most useful ways to begin. It gives them a safe space to try things, learn, and improve step by step.

This is where AI Evals come in, and I highly recommend reading these articles, if you want to jump further on how to properly test your AI features and simulate data:

Ambient Intelligence

This is the second trend, and it means that AI can always be there, working in the background. It understands what’s going on and helps without you needing to ask.

Itai mentioned an interesting analogy on this, which is the movie Her, where you have some kind of omnipresent agent, who is available to respond at any time, and at the same time, it’s proactive.

Itai mentioned that they recently shared an early beta version of PISA (Proactive In-Meeting Support Agent), a prototype for sales conversations. PISA can listen in the background, identify topics in real time, and push relevant talking points to the sales rep without being prompted.

He also mentions another use case, which is: A customer service agent could be supported with instant recommendations tailored to the specific customer and situation, while on the call.

The main benefit of ambient intelligence is that it fits smoothly into the work that a certain person is already doing. You don’t have to stop and ask for help, it just happens proactively. This saves time, makes work easier, and helps people do their jobs better.

For me, personally, I am always happy when I get recommendations that fit exactly what I need, without me even asking for them. So, I definitely think this is a field where companies can benefit a lot.

Agent-to-agent communication

This is the third trend that Itai mentioned, and it means the following. As companies use more AI agents, these agents need to work together.

Right now, most AI agents are built to talk to humans, not to each other. This causes issues when multiple agents try to work together, things can get messy or unclear. Sometimes it may look like they’re working together, but they’re not really doing it well.

To fix this, agents need a shared way to communicate. Think of it like a common language or system they all understand. This helps them stay on the same page, share information, and work toward the same goal.

This will become more important as companies move from using one AI agent to using many connected agents. If those agents can’t work well together, the whole system won’t work well.

Itai also shared that they recently did a study based on data from Moltbook, an AI-agent-only social platform, where they checked 800k posts, 3.5m comments, and 78k agent profiles.

Quoting from the study:

Our findings reveal agents produce diverse, well-formed text that creates the surface appearance of active discussion, but the substance is largely absent.

Which means, that Agent-to-agent communication is not at the level it needs to be at this time, and needs improvement.

3. How Salesforce Engineers Use AI to Build Their Products

These insights are from my conversation with Dan Fernandez, VP of Product for Developer Services, Salesforce. Interestingly, as we were talking, he was showing me how they use AI at Salesforce straight from his IDE.

Let’s get to the first example.

Prototyping and building MVPs is an important use of AI for them

Dan mentioned that the way they build products has changed a lot. They rarely go straight into building a full product right away, instead, they build quick prototypes and MVPs, and check if the idea is worth it.

Usually, they form a small group of cross-functional people, and they figure out what they want to build, create simple versions, and show them to the relevant people.

Dan shared an example from the past: We might build a dashboard for executives, with lots of features, and show it on a big screen. But then, they learn something important, executives mostly use their phones, not big screens.

So the idea needs to change. With building prototypes and MVPs, they avoid building the wrong thing. This saves time and helps everyone to focus on the right things.

Planning is where they use AI a lot

They have a CLI command in their developer tools called “deep planning.” This helps them think through a feature or an app before building it.

It asks simple questions, like:

• What do you want to build?

• How should it work?

• What are the requirements?

It works like a back-and-forth conversation. You answer questions, and the tool helps shape a clear plan. The goal is not to write code right away. The goal is to create a solid plan first.

An example that Dan mentioned: If you want to build an asset tracker app, the tool will ask what kind of items you want to track and what the app should do. Then it helps define things like data, structure, and how everything fits together.

It also checks if something already exists that they can reuse. Instead of building everything from scratch, they try to reuse existing tools, APIs, or parts of code. This saves time and avoids unnecessary work.

The main idea is simple:

Plan first, reuse what you can, and only build what’s really needed.

Code quality and creating tests

They have a tool called Code Analyzer. It checks code quality using a large set of rules, around 700 now.

It’s built by them, but it also uses other tools. For example, it uses ESLint and an open-source tool for checking Apex code. They also built their own logic that checks how parts of the code connect to API calls, to catch deeper issues.

So it doesn’t just look at code line by line. It also checks how everything works together.

They run this tool at different stages:

• while writing code (they can check the quality and review the code)

• when the PR is opened, it will run automatically

• In the CI process, when the PR is merged and when it is deployed to production

This helps catch problems early.

If you’ve been developing on Salesforce for a while, then you know that they require 80% of test code coverage before code can be deployed on the Salesforce platform.

With AI, it has now become easier to create tests, and the 80% of the test code coverage needed has become easier to achieve.

Observability is an important use case for AI

They have a tool called Scale Center.

It helps them understand how their work is performing while it’s running in production. It shows real-time insights, like what’s working well and what’s slowing things down.

Inside it, there’s another tool called ApexGuru. It looks at how the code behaves in reality and points out what needs fixing.

What’s useful is that they can see the insights directly in their developer tools. So instead of guessing, they get clear feedback on what to improve.

The system can also warn them early. For example, if they are running out of limits, if performance is dropping, if errors (like 500 errors) start happening.

It can also help fix issues (with AI):

• find the root cause

• explain what went wrong

• suggest a fix

• create a PR with changes

So instead of digging through logs and tools, they can get fast answers with it.

Every engineer can use AI tools that work for them

Even though Agentforce Vibes is the Salesforce version of GitHub Copilot, engineers are free to use what works best for them, which can be Claude Code, Cursor, or anything else.

What Dan has mentioned is that it’s very similar to a “vim vs emacs” debate, where neither one is the right choice, it’s the preference. Whatever works best for the specific engineer.

An important thing to mention as well is that they are doing more and more things through Slack. Slackbot has become a popular feature of Slack, which is an AI bot that can do things for you.

And what Dan has said is that a lot of collaboration happens directly through Slack, like for example working on different requirements together, making decisions, discussing things, and you can use Slackbot to help with all of that.

Last Words

I’ll also be sharing more about how their forward-deployed engineers work in one of the future articles. Stay tuned for that.

It’ll be interesting to see how things play out for them. It’s definitely a big shift, and for people who use their products as well.

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

• Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.

• Interested in sponsoring this newsletter? Check the sponsorship options 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

My recent trip to San Francisco and meeting with different people and companies got me thinking a lot about the differences between EU and US tech companies.

Especially the conversation we had with the Larridin team, about different markets and how US vs EU tech companies operate. Here are also some pictures from the visit:

I’ll be sharing more about how they work in a future article.

In today’s article, I am sharing my thoughts about the differences between US and EU tech companies, the mindset behind them, and the pros and cons of each.

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

- I’ve worked with a number of EU and US companies over the course of my career
- US companies tend to innovate a lot more than EU companies
- EU companies are a lot less prone to taking risks
🔒 I see a lot less self-confidence in EU companies in comparison to US companies
🔒 Work-life balance is a lot better in EU companies
🔒 US companies tend to let go of people faster
🔒 Sales-oriented & crushing the competition mindset is prominent in US companies
🔒 EU companies are dealing with a lot more regulation
🔒 US companies raise a lot more capital a lot more quickly
🔒 Last Words

Community chat

Before we start with today’s article, a reminder. As a paid subscriber, you are able to ask any questions related to engineering/engineering leadership and get an opinion from like-minded people.

• Share ideas, challenges, or get an opinion on the approach (you can start a new thread)

• Connect with everyone

• Special opportunities

We are just discussing the biggest challenges in our roles. Make sure to share yours as well!

Join the community chat

Let’s start with today’s article!

I’ve worked with a number of EU and US companies over the course of my career

In my full-time roles, I worked for both EU and US companies as a (senior) software engineer, at the same time also as a manager (Team Lead, Engineering Manager, Head of Engineering, Interim CTO).

I was also a VP of Engineering and a CTO for a company based in Singapore, but we had the team in the majority in the EU.

Alongside doing full-time roles, I was also doing freelance projects. I like to say that freelance work has been my secret to the growth of my career. I finished over 100 projects for both the EU and US clients, while most of the clients were from the EU.

At the same time, I did (and still do) advising and consulting for both US and EU companies, and I also do coaching and mentoring, having the pleasure to work with different people across the world.

And of course, I also had the pleasure to attend many different events, speak at conferences, both in the US and the EU, and meet many different people, both in person and online. I also regularly talk with engineers and engineering leaders across the world.

So, my perspective on how tech companies operate comes from a lot of different angles, and I’ll share my view on what I see.

Let’s start with the first difference and the one that I felt the most, especially during my latest visit.

US companies tend to innovate a lot more than EU companies

From my experience and what I am seeing across companies in the US, especially in San Francisco, is that they are all constantly evolving and trying new things. While in the EU, there’s a lot more fear of change, therefore, less innovation.

US companies tend to try new things faster, learning as they go, making mistakes. Change is something they actively look for. There’s a bias to take action, even when no one knows exactly how it’ll turn out.

A good example of that mindset is the company that I recently had the pleasure of getting to know, the company called Weave, and I wrote about how they work in this article.

In the EU, the mindset is often different. There’s a lot more focus on stability, predictability, and getting things “right” before moving forward. While this can be the right move for some companies, it slows down innovation.

There are definitely exceptions on both sides, and SF does not represent the whole US, but that’s the difference I see in the majority of the companies.

Neither approach is inherently wrong. One optimizes for speed and innovation, the other for precision and reliability.

But in a world that’s moving faster than ever (especially because of AI), I think speed and innovation are what’ll make a big difference in the upcoming years.

Let’s go to the next one.

EU companies are a lot less prone to taking risks

From what I’ve seen working with and observing companies across Europe, there’s generally a much stronger urge to minimize risk. Decisions are made more carefully, plans are more detailed, and there’s often a clear desire to avoid unnecessary uncertainty.

Risk-averse is the right phrasing for many of the companies in the EU, and change is something that many people tend to avoid. And from my experience, change is something that a lot of people in the EU are not looking forward to, and it takes a decent amount of time for the change to be accepted.

While in the US, my feeling is that changes get accepted a lot quicker, where it feels like decisions get made overnight.

In the EU, before launching a new product, entering a new market, or making a big strategic decision, there’s usually a lot of validation, alignment, and internal consensus needed. Things need to make sense not just in theory, but also in terms of long-term sustainability.

While working with US companies, I felt many times that some of the decisions were rushed, but people have been comfortable taking them, even though the results have not been guaranteed.

“Go big or go home” mindset is something that I’ve seen in many companies in the US. Especially in SF.

Some of the examples that I saw in US companies, that I haven’t seen in the EU:

• Completely changing the direction overnight through an email, without explanation

• Letting go of half of the engineering department and shutting down access completely

• Setting extremely aggressive, a lot of times unrealistic targets (revenue, growth, product timelines) and committing to them publicly

Of course, there are exceptions in both US and EU companies, and it depends a lot on the industry as well.

Now, the next one is related to both of the points I’ve mentioned before, but it’s extremely important to understand why I believe that is the case.

I see a lot less self-confidence in EU companies in comparison to US companies

Read more

Read more

Intro

This is a pattern I keep seeing after talking with many different engineers and engineering leaders across companies.

The most in-demand engineers at this time tend to fall into two groups:

• Great generalists who can build and ship end-to-end

• Extreme specialists with rare, hard-to-replace expertise in a specific technology or domain

In this article, I’ll explain why, and help you figure out where you fit (if you don’t know yet).

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

- Companies in San Francisco are Mostly Looking for 2 Types of Engineers
- The Role of Engineers is Changing
- In Bigger Companies, the Change is Much Slower
🔒 Should You Become a Great Generalist or Extreme Specialist?
🔒 Skills that Make a Great Generalist or Extreme Specialist
🔒 With Specialists, the Focus is a lot More on a Deep Understanding of a Relevant Topic
🔒 My Recommendation on Which Path to Take
🔒 Last Words

Let’s start!

Companies in San Francisco are Mostly Looking for 2 Types of Engineers

I am in SF till the end of this week, talking with different companies and people, while also attending the Salesforce TDX conference. I’ll be here until Friday, but I’ll be back in May as well.

Will be sharing more insights on some of the conversations I am having in future articles. If you’re a company that wants to chat in May, let me know, and we’ll set up some time then.

Interestingly, everywhere I go here in SF, the conversation seems to revolve around AI, agents, MCP, vibe coding, AI adoption, etc. AI is the main theme here, you can see it on the streets, in cafes, on screens, etc.

And also one of the core topics is how engineering is changing overall, and what are the most important skills for engineers to thrive in the AI era.

What I am hearing a lot is product-minded engineers becoming the norm and their role expanding to own features end-to-end, while also expected to be talking with the users. Such engineers can be labeled as really great generalists.

At the same time, there’s a need for a special kind of engineers (extreme specialists), who are really good at a certain topic, that may be AI-related, specific tech, or just pure experience and battle scars within a certain field.

Those are the exact two “sides of the barbell” that we are talking about in today’s article. Becoming a great generalist or extreme specialist, that’s what companies are looking for.

Let’s get more into that next.

The Role of Engineers is Changing

Especially in smaller companies (startups) and mid-size companies, that’s where the biggest change is.

I see the ratio between PMs and Engineers continuing to increase. There is no surprise if there are even 0 PMs in the company, like for example, I recently talked to Vrushank Vyas, GTM at PortKey, and he mentioned that in the company (PortKey), there are around 24 engineers, with 0 product managers.

At the same time, I am seeing many companies constantly looking for engineers, so it definitely feels like there has been an increase in engineering roles available. Just not any engineers, it’s a majority of great generalists, and a minority of extreme specialists. Those are two of the most desired types.

That’s exactly what Sulman Choudhry, Head of Engineering, ChatGPT, OpenAI, has mentioned, in our recent conversation, as a strong hiring criteria for them.

On one side, they hire extreme generalists. These are engineers who can work across many areas: mobile, frontend, backend, and more. They might not specialize in just one domain, but they can do enough across all of them to build and ship products.

On the other side, they hire extreme specialists. These are people with very deep expertise in a specific domain and often many years of experience.

For example, one of their specialists in real-time communication is the person who wrote the WebRTC standard, while many of the engineers around him are extreme generalists.

This mix works really well for them. The specialists bring deep expertise, while the generalists move quickly across problems, and together they create a strong culture of mentorship and learning.

In Bigger Companies, the Change is Much Slower

The way I see it in bigger companies, it takes a lot more time to really make a change, but eventually, my prediction is that all the engineering roles in all the companies will go in this direction: great generalists and extreme specialists.

People in between will have much less opportunities, because that doesn’t provide as much value, since the value you can contribute is limited. You don’t have “superpowers” to either take on a broad spectrum of challenges, or you don’t have a specific, deep understanding of a particular topic.

Now that we understand what I am seeing happening across different companies, let me share my recommendation on whether you should become a great generalist or an extreme specialist.

And yes, you should make a decision and go in a certain direction! If not, you’ll be stuck in the middle, and that’s where you’ll get the least amount of opportunities today and even less in the future.

But important to note as well is that you can also adjust your focus from one to another, it’s totally up to you, but let me share my recommendation for which might fit you best, next!

Should You Become a Great Generalist or Extreme Specialist?

Read more

Read more

Before we start with today’s article, a reminder.

As a paid subscriber, you are now able to ask any questions related to engineering/engineering leadership and get an opinion from like-minded people.

• Share ideas, challenges, or get an opinion on the approach (you can start a new thread)

• Connect with everyone

• Special opportunities

This chat is available to 1700+ engineering leaders, who are paid subscribers from companies such as Meta, Google, OpenAI, and 500+ others.

Think of it as StackOverflow for Engineering Leadership, except no toxic behavior :)

I’ll also use this chat to provide special updates regarding the newsletter, new products, videos, early releases, and also provide special opportunities.

We started with introductions recently. And there’s also a special update on how you can get a free 1-month subscription to the O’Reilly platform.

Introduce yourself in the chat here:

Let’s get back to this week’s thought!

Intro

Over the past year, AI adoption inside tech companies has gone from experimentation to AI being an active part of the day-to-day of tech professionals.

At Meta, they’ve gone the next step. They created an internal leaderboard ranking employees based on how many AI tokens they use.

The problem with such a leaderboard is that if token usage becomes the metric, then token usage becomes the goal. And that’s where things can go sideways quickly.

And then the question that comes up as a side effect is: Are we actually becoming more productive with AI or just better at looking productive?

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

- A leaderboard called “Claudeonomics”
- This seems to be a part of the broader trend in Silicon Valley
- Using token consumption as a benchmark for productivity. The side effects
🔒 Is judging people based on token consumption the right way to go?
🔒 This is a trend that I am seeing all the way from early 2025
🔒 The same incentive is behind the trend of “tokenmaxxing”
🔒 Judging people based on token consumption
🔒 I rather look at these 4 specific things
🔒 Should you do something similar in your company?
🔒 Last words

Let’s start!

A leaderboard called “Claudeonomics”

This is the name of the leaderboard at Meta, and it tracks AI token usage of over 85k employees. Interestingly, this has been a bottom-up initiative, built by engineers and shared on the company’s intranet.

Some unofficial data I have seen based on my research:

• In the past 30 days, the total usage exceeded 60 trillion tokens

• Estimated cost $900 million based on public pricing for the Claude Opus 4.6 model

• The top individual user consumed 281 billion tokens

So, based on how much your token consumption is, the higher you are in the leaderboard.

There are also different badges, from bronze, silver, gold, platinum, to emerald, awarded to people, and the top 250 people in the leaderboard are considered “power users” and can get additional badges like “Session Immortal” and “Token Legend”.

So, it’s like a game of who is using the most tokens. But the actual question is:

Is the use of tokens actually going in the right direction? Solving actual business problems?

This seems to be a part of the broader trend in Silicon Valley

The trend seems to be called “tokenmaxxing”, where token consumption is treated as a benchmark for productivity and a competitive metric to determine if an employee is “AI-native”.

Here are some more examples (according to Forbes):

1. Nvidia CEO Jensen Huang

Stated that he would be “very concerned” if an engineer earning $500,000 annually spent less than $250,000 on AI tokens each year.

2. Ali Ghodsi, CEO of Databricks

Delivered a keynote to the company’s engineering team, where he highlighted a particular engineer who had used over $7,000 worth of AI tokens within just two weeks in January.

Rather than criticizing the high spending, Ghodsi used it as a positive example. And mentioned: “We actually had the whole engineering team applaud him and recognize his efforts. My goal is to encourage everyone to start using these tools.”

3. Andrew Bosworth, Meta CTO

Said at a tech conference in February that a top engineer who spent an amount equivalent to their salary on AI tokens saw a productivity increase of up to 10 times. And mentioned: “It’s a no-brainer, keep doing it, there is no upper limit.”

4. Andrej Karpathy, a former AI scientist at Tesla and OpenAI, now heading an AI education startup

Said on a podcast: “The name of the game is tokens. How can you maximize your token throughput and not be in the loop”.

Using token consumption as a benchmark for productivity. The side effects

I am also hearing the following: Some employees at Meta, in order to climb the leaderboard, they let AI agents run continuously for hours to perform research tasks, maximizing token consumption.

There seems to be a lot of other companies doing something similar as well, it’s not just Meta.

One engineer mentioned the following:

My company has been doing something like this as well, and it’s as stupid and easily gamed as you would expect. Right up there with measuring lines of code or using story points to gauge productivity.

The best way to rack up tokens seems to be keeping a chat context going for a long time, telling it to read tons of code (multiple repos for extra points), and pasting as much code or text into the chat as you can.

Another mentioned:

It’s official in the company I work for, but in our case, if you don’t reach an AI usage threshold each week, you are fired.

And there have been more similar cases like these. Some other engineers I talked to have also mentioned that they either are judged based on token usage in their company or they know someone who is.

Based on the company names, the majority of such companies are based in Silicon Valley. I believe the trend of “tokenmaxxing” is less common in companies outside of that bubble.

Now that we know what’s happening, let me share my take on whether this is the right thing to do and if your company should be doing something similar.

Is judging people based on token consumption the right way to go?

Read more

Read more

Before we start with today’s article, there’s a special announcement.

🎁 Engineering Leadership Community Chat

As a paid subscriber, you are now able to ask any questions related to engineering/engineering leadership and get an opinion from like-minded people.

• Share ideas, challenges, or get an opinion on the approach (you can start a new thread)

• Connect with everyone

• Special opportunities

This chat is available to 1700+ engineering leaders, who are paid subscribers from companies such as Meta, Google, OpenAI, and 500+ others.

Think of it as StackOverflow for Engineering Leadership, except no toxic behavior :)

I’ll also use this chat to provide special updates regarding the newsletter, new products, videos, early releases, and also provide special opportunities.

For example:

• I’ll be looking for tech reviewers for my new book, which I am working on with O’Reilly, The Multiplier Mindset, and paid subscribers will have a bit of an edge :) (credibility always comes first, though). I’ll also announce when the book will be ready for the tech review in the chat as well.

• In the book, I am also sharing 8 case studies of successful multipliers, and I am currently looking for 2 Tech Leads, 1 Staff+ Engineer, and 1 Architect to share their case studies in the book. I have just shared that in the chat:

• Companies also regularly reach out to me if I know someone for a specific role, or they share special discounts / free tickets to events or conferences. I’ll be sharing such opportunities in the chat as well.

You can access the chat here:

Let’s get back to this week’s thought!

Intro

With the rise of AI-assisted engineering, changing team structures, and increasing expectations on leaders, many people are asking themselves this question:

Is becoming an engineering manager still worth it in 2026?

In today’s article, I am sharing my thoughts on this, and I’ll go back in time to 2020 when I first became a manager and compare it to today’s time -> If I were a senior software engineer looking to take the next step.

This is an article for paid subscribers, and here is the full index:
- I Became a Manager in 2020
- The Difference Between Then and Now
- Middle Management Was Always Hard, But It Became Even Harder These Days
🔒If I Were a Senior Software Engineer Looking to Progress to the Next Step in 2026, Would I Still Go the Manager Route?
🔒The reason I had a hunch that the management path was the right path for me
🔒Those were the exact traits that made me a good manager
🔒🎁 Notion template: Decide your career path
🔒 Last Words

Let’s start!

I Became a Manager in 2020

I started my career as an engineer in 2013 and in 2020, I was a Senior Software Engineer for some time and felt a bit stuck, as I didn’t know exactly what the next step would be for me.

“Should I go into management, become an architect, or grow in the IC track?” That question was always on my mind, and I couldn’t make a decision on which direction I should pursue.

And because I didn’t know which direction to pursue, I wasn’t convincing my manager in 1:1 meetings that a certain “next step” would fit me best. So, when I eventually got offered a Team Lead position, the manager was actually surprised that I was for it, as they thought that I wouldn’t be.

It’s really important that you at least have some idea of what the next step would be, as then people will automatically know that when a certain role opens: “I know Gregor would be a good fit, as they are already working toward progressing to that role”.

So, after I became a Team Lead, I started managing a cross-functional team, and I’ve made many mistakes -> what made me a good engineer didn’t make me a good manager. You can read about my mistakes in this article.

Over the course of a few months, I persevered and started to get the hang of the new role. Things have started to look better.

After about six months in the role, my manager left the company. Following a discussion with my skip-level manager, I became the new engineering manager and started leading three teams.

That was also the time when I started to realize that the management path was the right choice for me, as my set of skills and overall personality have been a good fit for it.

Things have progressed very fast after that.

After about a year, I became a Head of Engineering at a different company, then Interim CTO at that company, and later VP of Engineering at a different company and was shortly promoted to the CTO role.

You can read my full career progression here: How I Grew From Engineer to CTO.

Now, let’s go through the difference between becoming a manager in 2020 and today, in 2026.

The Difference Between Then and Now

There has been quite a big shift in the industry, and roles have changed quite a bit. The IC path became a lot more standardized and also normalized, which is really great.

In 2020, there were some Staff/Principal/Distinguished level roles, but not a lot of companies had them. The overall mindset was “You need to become a manager in order to grow in your career”, but shortly after that, the IC path gained a lot more popularity.

Still, to a certain extent, if you wish to grow to a CTO role someday, you need management experience. That hasn’t changed.

Maybe you can get away with not having a lot of experience with management if you are a startup CTO, but for sure, if you are a CTO for a scale-up or a mid+ sized company, that’s when you need to become a good manager.

And that’s something that it’s a lot harder to learn in the IC track, as there it’s all about leadership and influence without having direct authority.

Another key difference is that salaries have become quite similar regarding the IC track versus the management track, so just pure salary is less of a motivating factor today, as it was in the past, when the only way to make more was to become a manager.

Today, we can even see that some of the IC roles are even paid more; for example, Meta has recently been offering huge salaries to people who are extremely good in the ML space.

There are also 2 big shifts that have started happening recently:

1. Amazon’s increase in the manager-to-IC ratio

After Amazon raised the manager-to-IC ratio by at least 15%, a lot of other companies did a similar thing.

2. Architect, EM, and Staff Engineer roles became a lot closer

A lot of the people reported taking on additional responsibilities as part of their current responsibilities. I’ve seen Tech Leads taking the manager role as well, while also potentially being architects, and the same goes for EMs and architects, expecting to take on the 2 other roles if needed.

A similar shift has happened in engineering and PM roles, where the product engineer role has become increasingly popular. Companies like OpenAI, Anthropic, Lovable, etc., are all looking for engineers who can also wear a product hat and own their projects end-to-end.

So, overall, roles have come a lot closer together, and I fully believe that these days (and in the future) it’s less about the title and more about what impact a certain individual can bring to the organization. That’s what is most important for the companies.

And I’ve also seen this repeating trend in different companies now, which I first got introduced to by speaking with Sulman Choudhry, Head of Engineering, ChatGPT. They like to hire engineers at two extremes.

Let me also share an important difference between then and now, next!

Middle Management Was Always Hard, But It Became Even Harder These Days

I like to say that one of the toughest roles in tech is being a middle manager, as you need to be really good at managing up (leadership, stakeholders, your manager), sideways (peers), and also downwards (your team(s)).

You need to be great at understanding both tech and the business, as you act as a translator for both parts, and good communication is crucial. You need to be a really great generalist in order to do well in the role.

And especially in current times, there tends to be a lot more unrealistic expectations from the leadership team and other stakeholders, which is caused by FOMO (fear of missing out) thinking that a certain AI tool should provide an immense impact to the business.

That’s why the role has become even harder, as there are a lot more managing such expectations, and it can be really problematic for less experienced EMs, who haven’t yet built good credibility inside and/or outside of the company.

Even experienced EMs can struggle with this. I’ve seen cases where EMs just gave up on really pushing back.

Another reason is that, as you are less involved in the fine details of building, you may miss out on using the latest tools, but the plus side is that building has become even more accessible for managers, as with AI tools and good overall engineering understanding, you can ramp up on a certain codebase and become productive a lot quicker.

Now that we understand the differences in detail, let me share my answer if I would still go for the management route in 2026, next!

If I Were a Senior Software Engineer Looking to Progress to the Next Step in 2026, Would I Still Go the Manager Route?

Read more

This week’s newsletter is sponsored by Stigg.

Most engineering teams discover the gap between billing and usage enforcement the hard way. AI features ship. Adoption grows. Then one day an enterprise customer asks why a request got blocked while an identical one went through, and nobody has a clean answer.

The problem isn’t billing. Billing is working exactly as designed. The problem is that billing records what happened after execution. It was never built to decide what’s allowed while the system is running. And it’s just one layer in a monetization stack that most teams only realize is incomplete once AI hits production.

Shai Betito, VP of Engineering at Stigg, breaks down why this distinction matters more than most teams realize until it’s already painful:

• Why limits stop being simple counters under concurrency and become a consistency problem at scale.

• How a single request can touch multiple organizational dimensions simultaneously, and why resolving that correctly in milliseconds is a fundamentally different challenge than monthly reconciliation.

• Why identity-based access control breaks under AI workloads. Automated pipelines don’t have seats, and the control model has to change accordingly.

A technical breakdown of a class of infrastructure problems that appears after AI reaches production, written by engineers who’ve had to solve it.

Find out what's missing from your AI product's infrastructure:

Read the article

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

Intro

Based on recent reports, we can see that AI adoption in companies is increasing. As AI becomes more common in the workplace, the hiring process must reflect its presence.

From my conversations with engineering leaders from companies like OpenAI, Meta, and others, I’ve learned that there is an increased expectation in AI fluency, especially for engineering and product roles.

Companies are starting to understand that AI is becoming an important part of the day-to-day work that tech professionals are doing.

The question we want to answer today is how can we actually check for AI fluency in technical interviews? To help us with this, Hamid Moosavian, director of engineering at Xe, our guest author, will share practical insights on how to evaluate candidates.

Let’s introduce our guest author and get started.

Introducing Hamid Moosavian

Hamid Moosavian writes First 90 Days for Engineering Managers, a biweekly newsletter of practical management tips, and is the creator of the free First 90 Days Kit, a collection of copy-ready templates for new engineering managers. Hamid is also director of software engineering, Americas, for Xe.

Your engineers are already using AI in their work. Your engineering candidates probably are, too. But how do you know whether candidates are using AI well if you’re not interviewing for it? Hamid walks us through the importance of including AI in your interviews and how to do it.

Over to you, Hamid!

Your Tech Interview Process Shouldn’t Be AI Resistant

When Copilot and similar AI pair-programmers emerged, most teams made their hiring processes AI resistant. The logic was simple: If candidates used AI during assessments, their real skills couldn’t be evaluated.

That approach is outdated.

By the end of 2025, over half of professional developers were using AI daily. Some surveys put the number at 97% when including those planning to adopt it. AI assistants have become standard tools for productivity.

At the same time, senior engineers and tech leads started sharing examples of poorly reviewed AI code. The pattern is clear: Some developers use AI as a thinking partner and ship better code, while others blindly accept suggestions and generate unmaintainable systems.

The tool isn’t the problem. How people use it is.

The comparison to Google and Stack Overflow is obvious. No one expects developers to avoid documentation or search engines. But we do expect them to use these resources well.

This situation changes what good hiring looks like. The goal is no longer to prevent AI use. It is to evaluate how candidates use AI and whether they produce clear, maintainable code even when the tool misleads them.

Companies like Meta and Canva have already made this shift. More are following.

Here’s what to understand about AI fluency and how to update your process.

What AI Fluency Actually Means

Let’s first be more specific about AI fluency. I suggest the following framework, though you can adjust categories to fit your context.

Level 0 AI Avoidant: Is skeptical of AI tools and refuses to use them. Relies on memorization or traditional resources. Sees AI as cheating and won’t trust AI-generated code. Struggles with productivity when peers use AI assistance.

Level 1 AI Dependent: Uses AI-generated code without understanding or verification. Accepts the first suggestion, can’t explain what the code does, and gets stuck when AI gives wrong answers. Can’t debug AI output.

Level 2 AI Competent: Uses AI for boilerplate, refactoring, unit tests, and repetitive tasks but reviews output critically. Catches obvious errors, tests generated code, and explains what AI suggested and why they accepted or rejected it.

Level 3 AI Advanced: Knows when not to use AI. Combines AI with deep technical knowledge to explore edge cases and verify assumptions. Treats AI as a thought partner, not a decision-maker. Works effectively with or without AI.

What do these levels look like in practice? Let’s break down the patterns that separate competent and advanced users from the rest.

Level 2 and 3 engineers share these habits:

• Context-rich prompting: Provide relevant code snippets, file paths, and project constraints rather than vague or broad requests.

• Incremental integration: Generate code in small chunks, test after each step, and commit frequently.

• Critical review: Read all generated code line by line, check for edge cases and architectural fit, and validate against project standards.

• Security awareness: Verify package names (up to 20% of AI suggestions reference nonexistent packages), check for hardcoded secrets, and validate input sanitization.

• Appropriate skepticism: Treat AI as a pair programmer, not autopilot. Can proceed when AI is wrong or unavailable.

AI fluency shows up differently across engineering tasks. In debugging, it means using AI to generate test cases or explain error messages. In code review, it means catching issues you might miss manually. In architecture discussions, it means exploring design patterns without letting AI make final decisions.

Here’s what this looks like in practice:

A Level 1 engineer might prompt like this:

Create a POST endpoint for user registration.

A Level 2 or 3 engineer provides context and constraints:

Using Express.js with TypeScript, generate the boilerplate for a POST endpoint at /api/users that:

- Accepts JSON payload with email and name
- Includes Joi validation
- Uses async/await error handling
- Returns 201 on success, 400 on validation errors

I’ll add the business logic afterward.

You want engineers who can code without AI but also use AI fluently to improve their productivity.

Remember, though, AI is not a magic wand. It’s just a very powerful tool. Think of it like a power saw: It can cut through work 10 times faster than a hand saw, but without proper technique and safety measures, you can lose a finger. You still need to know carpentry; the tool just amplifies the skill.

Why Companies Are Making This Shift (and Why You Should Consider It Too)

The traditional approach to technical interviews is changing. Companies are realizing that if AI tools are standard in daily work, they should be part of the hiring process too.

Why? Because you want to see how candidates actually work, not how they perform under artificial constraints. The closer your test mirrors reality, the more reliable the results. Interviews should predict job performance, and job performance now includes AI.

Who’s already making the shift

Companies like Meta, Canva, and Intuit are testing a new approach. They’re not just allowing candidates to use AI tools like Copilot but observing how they use them.

Goldman Sachs has given its engineers access to GitHub Copilot and Gemini Code Assist and is even holding competitions to promote creative AI use among developers.

At Meta, candidates work with an IDE and AI chat window for writing code, debugging, and creating unit tests. Evaluation focuses on how effectively candidates use AI as a tool, integrating it into their process for daily engineering work.

The evaluation format is moving away from pure data structures and algorithms (DSAs) toward project-based tasks that mimic real engineering challenges. Interviewers assess problem-solving, code quality, verification, and communication, specifically how candidates prompt, debug, and justify AI suggestions.

Candidates must demonstrate control. Doing so shows that they’re the primary engineer, not a passive AI user. They should be catching subtle errors in AI-generated code and iterating on solutions. They should be articulating their prompts, reasoning, and trade-offs. They should be asking targeted questions to get efficient, accurate results.

Many Fortune 500 companies still share Amazon’s stance against AI interviews. But a growing number are embracing this shift, wanting to hire engineers who leverage new tools to enhance their skills.

Addressing the skeptics

Companies that don’t allow AI in technical assessments have a valid concern. They argue that allowing AI means everyone gets the same AI-generated solution, candidates don’t show their true skills, and AI covers for their weaknesses. Allowing AI does require redesigning the technical evaluation. Without it, you won’t collect meaningful signals.

However, that’s exactly what you want to test: how candidates differentiate when everyone has access to the same tools. Judgment becomes more critical than ever.

The evaluation shifts from “Does it work?” to “How was it built?” Discussions focus on key decisions, major choices, and code structure. Qualities like thoroughness become crucial: writing detailed prompts, refining them when needed, reading responses attentively, and reviewing proposed solutions carefully.

These habits separate engineers who think about tech debt and maintainability from those who just want working code.

Why This Matters for Your Company

Properly evaluating AI fluency leads to better hires in several ways.

Cost implications: When you evaluate candidates using the tools they’ll use on the job, you get a clearer signal faster. Instead of watching them struggle with boilerplate syntax, you see how they think about architecture, edge cases, and trade-offs, things that actually matter in the role.

Quality of hire: Here’s an example drawn from life. Let’s say you hire an intermediate front-end developer who writes good CSS and understands the front end well enough for the level. You give them Copilot access. Suddenly they move fast but create unmaintainable code. They’re using Copilot for the first time or using it irresponsibly. Your hire failed because you didn’t test what they’d actually do on the job.

Karat recently argued that interviews should mirror the job. Its blog states that preventing AI use hampers hiring engineers who can adapt to new tech. Its data suggests that watching how candidates interact with a large language model provides a stronger signal of seniority than traditional whiteboarding. If you’re not collecting this signal, you’re missing valuable input.

Competitive risk: Your competitors are already evaluating candidates’ AI fluency, and you’re losing AI-fluent candidates to them. You don’t need to pivot immediately, but start making your assessment more comprehensive.

Future-proofing: The skill gap is widening. For most product engineering roles, candidates who aren’t AI fluent today will struggle within six months. AI fluency signals that candidates are good learners who stay current and adapt to new tools. This is a strong indicator of future development potential.

These benefits stem from one principle: When interviews mirror how engineers actually work, you get a clearer signal and fewer post-hire surprises. Test the real workflow, and you’ll hire for the real job.

We’re at the beginning of this shift. My projection is that any company hiring product engineers at scale will eventually include an AI-fluency component, whether hands-on testing or interview questions. Since AI is becoming integral to developers’ work, it must be addressed during hiring. Otherwise, you risk unpleasant surprises.

How to Evaluate AI Fluency in Your Interviews

Read more