This week's newsletter is sponsored by Unblocked.

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

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

Join a FREE webinar on April 23 to see:

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

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

• Live demo: the same coding task with and without an organizational context engine

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

Register now

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

Intro

There is a lot of hype regarding AI and how big a productivity increase it brings. But there’s a lot less talk about the side effects of it.

And the side effect is that teams are drowning in PRs and are not able to review them fast enough. So, it’s important that the code review process evolve as well.

Of course, this really depends on the size of the codebase and the overall complexity of it. The more complex the codebase is, the less productivity increase AI brings.

In today’s article, we’ll go through why PR reviews have become a new bottleneck for engineering teams, and what to do to ensure that they become less.

Let’s start!

Fast PR Reviews Have Always Been a Signal of High-Performing Teams For Me

PR Cycle Time (time from creating the PR to merging it) has always been a metric I liked checking for the teams that I have led over the course of my career.

I am not saying it has been 100% the case, but faster PR Cycle Time has, in many cases, shown to be a case for high-performing teams.

The reason is that the more time we let the PRs stay unreviewed, the more context we need to keep holding in our heads, and the harder it is to move to other things.

Let’s say an engineer creates 1 PR, waits for the review. In the meantime, they start working on another one and later also open a PR. That engineer now has 2 PRs opened and needs to keep the context of both in their head.

And then what if his 2 PRs haven’t been reviewed yet, and they start working on the 3rd one? Then suddenly, the context gets blurred, and especially “why” something has been done the way it has been done gets forgotten. That’s where issues arise, edge cases get forgotten, and bugs get deployed to production.

Now, let’s go through the problematic part of doing code reviews.

The Problem with Code Reviews

For me, personally, I always enjoyed building more and doing code reviews less. And I think the majority of the engineers/engineering leaders would agree with that.

The reason for that is the following.

With building:

• You are solving problems, and you get satisfaction when you solve a certain problem → the code you write or remove results in a change of behavior.

• You are making visible progress, which increases dopamine.

• Finishing a task, closing it, and seeing the change you made directly in production motivates you to keep going and keep building.

Doing code reviews:

• You need to get the full context of the changes and understand them if you want to really review the PR the right way, which takes a lot of mental energy, especially if you review a lot of different PRs. While understanding and getting the context, you may need to ask questions or get additional information from different sources.

• You are directly or indirectly responsible, depending on whether you are an assignee or a reviewer for the PR.

• You are expected to correct or find issues. And giving feedback might be hard, depending on a specific person, especially if a certain discussion results in disagreements between the author and the reviewer.

So, those are the reasons why building is a more enjoyable part of software engineering. However, it’s important to note that the more you grow in your career, the more you need to accept reviewing as an important part of your day-to-day.

That may be reviewing PRs, documentations, specifications, decisions, etc. Especially as a Staff+ Engineer, Architect, or EM+.

This is Also the Reason Why Many Teams Have Issues With PR Cycle Time

Ever since I started working in teams as an engineer and we had mandatory PR reviews + QA engineers testing the PRs, it has always taken some time until the PR got merged.

And especially if the PRs included a bit more change than usual, or the things that we have been building were more complex, part of the legacy codebase, or the changes may have been a bit more ambiguous.

And every engineer has their own things they need to do and focus on, their own problems and initiatives, and doing code reviews is not their primary focus point.

Additionaly, most companies do not look at code reviews as a direct KPI of the performance of a particular engineer. And they shouldn’t as well.

Now, let’s go through an important point about why PR reviews have really become a bottleneck at this time.

Increase in Speed of Writing Code Results in More PRs Created Than Ever

With tools for development becoming better and AI-assisted engineering becoming a standard in our industry, the speed of writing code has increased exponentially. That also automatically means more PRs created.

Especially the 2 main reasons for more PRs created are:

1. Agentic AI PRs

With tools like Devin, OpenClaw, or similar, you can create a dedicated GitHub account for them, and then you assign them work which results in the PR being opened by them directly. The problem with it is that you lack the contextual information of the change, and you need to go over the full code changes when the PR is opened. This results in a lot of mental energy needed.

2. AI-assisted engineering

Using tools like Cursor, Claude Code, or similar, that’s where you use AI to help you generate the code needed in order to finish a certain task. It’s a much more common and preferred approach. In my opinion, it’s the best way to build software these days. You have the full context of the changes, and the PR is opened on your behalf.

Both of these 2 approaches drastically increase the velocity of new PRs created. Now, this sounds great and all, but let’s talk about the problematic part.

With More PRs Created, Code Review has Become a Bottleneck

So, now that we have more PRs created, code reviews have become the real problem in many engineering teams. I’ll be sharing some of the ideas on how to remove the bottleneck and think about code reviews in the latter part of the article.

The recent report from LinearB, called: 2026 Software Engineering Benchmarks Report, supports this. In the report, they checked 8.1M PRs from 4,800 engineering teams across 42 countries.

Especially the data of the difference between Agentic PRs, AI-Assisted PRs, and Unassisted PRs in regards to code review speed, makes a lot of sense.

• Agentic AI PRs have a PR Pickup Time 5.3x longer than Unassisted ones

• AI-assisted PRs have a PR Pickup Time 2.47x longer than Unassisted ones

The data provides a new finding, which is:

Engineers dread reviewing AI-generated code and often procrastinate when it comes to reviewing such PRs.

So, with more PRs created than ever and with the PR pickup time increasing, PR reviews have become a clear bottleneck.

An Important Note on Codebase Size and Complexity

The more complex a certain codebase is and the more architectural changes you need to make, the less productivity gains you get from AI in general. That has been reported by many of the engineers I talked to. So, usually, the longer the software exists, the smaller the increase in PRs there is.

The biggest increase is in greenfield projects, where you have an opportunity to set up things in a way that LLMs can provide a lot more accurate solutions.

That’s also the reason why frameworks such as Ruby on Rails and Angular have recently gained popularity. It’s because they are very opinionated, and best practices are clearly defined. This results in AI being able to generate much more accurate solutions.

Now, let’s go through my thoughts on how you can approach making PR reviews less of a bottleneck.

This is How you Can Approach Making PR Reviews Less of a Bottleneck

There are a number of different approaches you can take here, and it’s really important to ask yourself: “How can I make the work of reviewers easier?” or “What kind of PR would I like to review?” and do exactly that.

Here are my tips on how to do that:

1. Create test cases of your newly added code

With proper test cases, you automatically improve the confidence in your code, doing exactly what it is supposed to do. This also helps reviewers to have a lot more confidence in your code changes.

This is a great skill you can use to help you generate proper test cases based on the changes that you have made. There are many more skills created by Addy Osmani in this repo that would help you, and I definitely recommend to check it out: Agent Skills.

2. Use AI to review your code even before you open a PR

To make the job of reviewers a lot easier, it’s great if you do a pre-check of your code before opening a PR. Always keep in mind that you want to avoid any unnecessary back-and-forth regarding issues, because that usually takes a lot of your and the reviewer’s time before the PR gets merged.

There are many different AI code reviewing tools available, and you can use them, or you can also use a simple prompt or a skill from Addy’s Agent Skills repo.

3. When you open a PR, I recommend making comments on the parts that may be harder to understand

If you can predict where a certain part of the change may not be that clear to reviewers, make sure to add a comment on the PR in that particular change, even before you assign the PR to reviewers. It will help remove the back-and-forth and get your PRs merged faster.

4. Use an AI code reviewer to automatically review your PRs when you open them

Similar to reviewing PRs before you open a PR, you can use an AI to review your code when the PR is opened. That step is part of the CI, and you can use any of the AI code review tools that already exist, or you can also set up a prompt yourself.

I think that is one of the biggest improvements, and it should be a no-brainer in my opinion, as it makes it so much easier for reviewers to start reviewing when there is already an AI code review check being done, so you don’t start completely from scratch.

This change alone should drastically improve the PR Pickup Time metric. Now, let’s talk about the balance between AI and human reviews.

Balance Between AI Code Reviews and Human Code Reviews

As human code reviews are becoming more and more a bottleneck, I am hearing from many different people that they are relying more on AI code reviews.

For example, I recently talked to Andrew Churchill, CTO, Weave, and he mentioned that they use 4 different AI code review tools.

What they do is: they onboard a new engineer and do really great (human) PR reviews, but after some time, that engineer gets the context of the codebase, and PR reviews are reviewed mostly by AI reviewers.

He mentioned that this provides a lot of productivity gains, and they can move really fast because of it.

Also, Raphaël Hoogvliets, Principal Engineer, Eneco, mentioned that he configured a coding agent with a prompt: “You are a staff engineer. Review this PR. If it meets production standards, approve it. If it doesn’t, request changes with specific reasoning.”

He also based the agent’s skill config on the CV of an actual, really good staff engineer. This has worked well in his case, and he saw a lot of benefits in doing that. He now sees how big a bottleneck human PR reviews are.

I also believe that this is going to be the future of where we are heading as an industry. It’s going to be impossible to keep up with the pace of how fast we can generate code versus how fast we can review code.

Setting up great guardrails and increasing trust in AI code reviews is where you can get enormous productivity gains. Think about decreasing the PR Cycle Time from 2 days to 20 minutes. That kind of productivity improvement can make a huge difference.

A concern regarding AI code reviews I am seeing is for the companies that need to be SOC2 compliant. In order to do that, for every PR review, you need to have at least 1 human engineer confirming (outside of the author) the PR.

And also, an additional concern is with more complex systems. As mentioned above, the more complex your codebase is, the less useful AI is, and the smaller the productivity gains are.

It’s also every company’s individual choice whether to focus more on speed or quality. My take is that for startups, the speed is where they benefit more, while for more established companies, the quality should be the bigger focus.

Of course, every industry is different, and it really depends on what kind of users you are building for.

Last Words

As the speed of generating code increases, it’s important that we also ensure that the code review process evolves as well.

If not, code reviews ultimately slow down everyone and become the bottleneck. That’s also how we won’t be able to get all the productivity benefits that AI brings.

My recommendation is to start simple and make one improvement at a time, like adding AI code reviews when opening a PR.

That alone brings a lot of benefits imo, and is the best way to start.

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.

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

This week's newsletter is sponsored by Anyshift.

Context is what separates a 30-second root cause from a 2-hour investigation

Anyshift maps every service, deploy, config change, and dependency into a versioned graph.

When an incident fires, it traces the root cause to the exact commit that caused it. No jumping between consoles. No guessing. Up to 85% MTTR reduction.

• Zero agents, read-only access, connects your stack in 30 minutes

• One graph that stays in sync across AWS, GCP, Kubernetes, GitHub, Datadog

• Start with one service, scale when you're ready

Used by engineering teams at Citrix, MotherDuck and more.

Check the ROI

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

Intro

Over the past few years, tools like ChatGPT, Claude, Copilot, and Gemini have made a big impact on the way we work. Especially in our industry, the focus has moved from pure writing code toward solving problems more effectively.

Now, we’re moving into a phase where AI doesn’t just respond to prompts, but actually takes action and gets work done for you.

That’s where OpenClaw comes in.

OpenClaw isn’t just another chatbot. It’s more like having an assistant that can break down tasks, spin up sub-agents, connect with the tools, and deliver real outcomes instead of just ideas.

There are still common downsides, though, where your overall judgment becomes more important than ever, and we’ll get to that later in the article!

In today’s article, we’ll go through what OpenClaw is, why it’s getting so much attention, and, most importantly, how you, as an engineering leader, can use it to save time, help your team, and build things.

Let’s start!

What is OpenClaw?

If you haven’t heard of OpenClaw before, it’s an open-source personal AI assistant that you can install on your own device, and chat with it through your preferred choice of messaging software. That can be WhatsApp, Slack, Discord, Telegram, and others.

If we make a comparison with ChatGPT, it’s less of a chatbot, but more of an autonomous assistant who executes tasks on your behalf. It can also connect to the tools that you use, and it understands the context of your work.

It can also spin up sub-agents and assign tasks to them to finish a specific (bigger) project. Think of it as: assigning a big project and implementing it as well.

It can dissect a project into multiple smaller tasks and assign them to other agents who would implement them in parallel.

The project was first published in November 2025 as ClawdBot and renamed to Moltbot on January 27, due to trademark complaints by Anthropic.

That’s the time it also gained a lot of momentum, and now (as OpenClaw) has already close to 350k stars on GitHub.

In February, OpenClaw was also bought by OpenAI.

Why Has It Gained So Much Popularity So Fast?

I’ve set it up myself in order to understand where the appeal is coming from, and I can clearly see why. There are many possibilities with it, and there are endless use cases that you can use it for.

It’s up to you for what particular things you want to use it for, and if it makes sense in terms of making you more productive. There are also more than 46k skills published in Clawhub, which you can use for your case.

And if you do something that’s not done yet, you can also publish the skill yourself, which is great!

We’re also going to go through the use cases that I believe are the most useful for engineering leaders later in the article.

A thing that I really like is that if you want to do a certain optimization, let’s say use fewer tokens per request, you can just ask openclaw, and it’ll share the available options that you can do, which you can just easily pick and choose the one that makes sense.

Even though setting it up can be a bit of a pain, especially for a less technical person, with enough perseverance, I believe anyone could set it up and start using it.

We’ll go through a step-by-step process on setting it up, and I’ll share my reasoning for what makes the most sense, what I found out works, and what doesn’t.

Choosing Where to Install It

You can install it on your own computer, a separate computer, a virtual machine, or on a dedicated server.

I don’t recommend installing it on your own computer, where you have all the important files that you work with daily. The reason is that you are giving OpenClaw access to your full computer to do things.

Unless you are really diligent with permissions, and you really know what you’re doing, I wouldn’t recommend it.

The quickest starting point and also a relatively cheap one would be to buy a virtual machine, a.k.a droplet, on a hosted service like DigitalOcean or similar. Here is also the guide if you want to do that.

They already have an OpenClaw image prepared that you can just install on the droplet.

The downside is that the OpenClaw version is most probably not going to be the latest, but I think you can update it manually yourself later on. So, if you just want to quickly try it and see how it goes, you can go that route.

But in our case, we are going to use our own hardware and install OpenClaw on a separate Mac mini. That also gives us complete control of all the data and resources as well.

If you want to follow along and install it on your own, feel free to do so; if not, you can read through the steps, and you’ll get insights on how to install OpenClaw and also ideas on how to use it.

Let’s start.

Let’s Prepare Our Mac Mini

Starting from scratch is the best way to go, so completely wiping out our Mac mini is the first step. You can do that by going to System Settings > General > Transfer or Reset > Erase All Content and Settings.

The second thing we want to do is to prepare all the necessary accounts and API keys. I highly recommend setting up a separate Gmail account for OpenClaw, which we are also going to use for creating a new Apple ID.

Also, having a password manager like LastPass or 1Password is really great. I personally use LastPass and then share only the necessary passwords to the Gmail account I use for the Mac mini, so I can just copy&paste them when I need them.

Regarding API keys, I first started by adding Anthropic’s API key to OpenClaw. But after trying out a harder task, where there was much more work, I quickly stumbled upon rate limits. So, my recommendation here is to set up at least another one, such as OpenAI’s API key or Gemini API key.

In the best case scenario, you would have all 3 (or even additional, like Grok, MiniMax, Deepseek, etc. and then OpenClaw can route different requests to different APIs if the rate limit has been hit. But for starters, you can start with creating 1 API key, and then if you hit rate limits, you can set up additional ones.

So, now that we have everything ready, let’s install MacOS on the Mac mini and create the Apple ID with the Gmail we created for this purpose. We’ll want to use Apple’s App Store to install the Amphetamine app, so we can keep our Mac mini on at all times.

If you want to go through a very detailed guide on the installation, check out this guide.

Installing OpenClaw

Once we have the MacOS installed, it’s time to start installing everything that we need for OpenClaw. We first need Xcode Command Line Tools. We can get it by simply copying this into the terminal:

xcode-select --install

Of course, having Homebrew is great, and you can get it by copying this into the terminal:

/bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”

Next, you’ll want to have Node.js.

brew install node@24

After that, it’s time to start installing OpenClaw. Paste this into the terminal:

curl -fsSL https://openclaw.ai/install.sh | bash

And once you have it installed, you can start with onboarding:

openclaw onboard --install-daemon

We won’t go through this step in detail, but I highly recommend checking out the details on different options when onboarding here.

A cool thing after we go through onboarding is that we can check out the gateway dashboard on http://127.0.0.1:18789 or http://localhost:18789.

That’s where we can check logs, and a lot of other interesting info on what’s happening regarding openclaw.

Connecting Your Messaging Software

Once we have OpenClaw installed and onboarded on our system, that’s when it’s important to connect your messaging software of choice.

I personally use Telegram, as that’s what has been recommended as easiest, as you can quickly set up a bot there and connect it to OpenClaw.

There are a lot more options, like Slack, WhatsApp, Discord, etc. Check the options here.

In order to connect to Telegram, all we need to do is open Telegram, search for @BotFather, and start creating our own bot.

I won’t go into detail on how to do that, as this guide gives you a good walkthrough. Once we have our bot configured in Telegram, it’s important to connect it to OpenClaw.

On the chat with our bot, type /start, and it will return the pairing code. Then all we need to do is add the pairing code to OpenClaw. We can do it like this:

openclaw pairing list telegram
openclaw pairing approve telegram <code>

Now, once we have that all running, congrats, we have a working OpenClaw bot, which we can talk with!

If you want to go through the setup in detail and configure a lot more other things, this guide will help you with that.

Fun fact: I’ve named my bot GOclaw, but you can name it anything you wish!

First Thing I’ve Built

Now, once I had that, I started testing what’s possible and what’s not. The first thing that came to my mind was to ask GOclaw to call me and wish me a great day.

So, I asked, what is needed to achieve that. GOclaw responded with the plan to get a number on the Twilio dashboard (which I did) and then proposed to write a script that calls Twilio’s API and makes the call.

We basically did this in a couple of minutes, and it worked well! We then also played around with it to make a few tweaks and so on. It felt like working together on a problem, similar to how I would work with another engineer.

Another thing that’s important to keep in mind is that I was using Claude Sonnet 4.6 at the beginning as the main model of choice, but it became really expensive pretty fast, so I switched to using Haiku, and it was much cheaper and produced similar results.

The Second Thing: Technical Specification of a Project

After that, the next goal was to create a technical specification of a certain project. I specified the functionalities needed, provided examples (links to working functionalities) of what needs to be done, and included some of the links to where more information about what’s needed can be found.

So, in this case, if you have been using Cursor or Claude Code, instead of adding the context in the prompt or as a .md file in the project, you can just add context as a message, and OpenClaw will automatically use that to do what’s needed.

The first version was already pretty good, the second a lot better, and the third one, even better, which I was pretty happy with.

The Third Thing: Build the Project

Now that we have a technical specification, with a good plan of implementation, we can implement the project.

That’s when I saw issues with rate limits, as there’s a need for many different things to be implemented in order to finish the project, which took a lot of tokens, and Anthropic’s API just couldn’t support using so much in the short amount of time.

So, that’s when it’s really important to connect additional API keys, so that if the rate limit happens, OpenClaw can then call other APIs.

In the end, I was pretty happy with the result, as it implemented the project based on the technical specification. I also created a separate GitHub account (that is connected with GOclaw’s email) and created the repo there. The newly generated code was then also pushed to that GitHub repo.

My Thoughts After the Test Projects

So, these were my test projects in order to see what’s possible and how we can use OpenClaw. And I am impressed by the flexibility and the overall experience.

There are, of course, some things that are not so great, as the onboarding process can be quite tedious, as there are many things to think about, especially regarding security and ensuring that you really take care of permissions and restrict access.

And of course, as with all LLMs, hallucinations are the problem, and you need to have good judgment and overall technical experience to know if a certain approach is actually the right approach to take or not. You can’t get away with bad fundamentals and a poor understanding of engineering.

So, think of using OpenClaw as Claude Code or OpenAI Codex, just with a different interface (as you are talking via messages) and a bit more flexibility and options, as you have the whole Mac mini available to store things and create context.

I really like the overall user experience with that, as I find it much easier to do things, then just prompting via terminal or using a separate UI. And the reason is that we are already using messaging software a lot daily, so it feels a lot more natural.

Now, let me share some of the concrete examples that I believe you can use OpenClaw as an engineering leader.

How to Use OpenClaw as an Engineering Leader

After the test projects, here are my thoughts on projects that could be great to use OpenClaw as an engineering leader:

1. Use OpenClaw for side projects/internal tools

I think this is a great use case, especially if you are building projects where you are fine with just “throwing away code”.

• You can build a website that would help organize learning sessions for your teams, send reminders, and automatically generate transcripts + create documentation pages based on the session.

• You can build throwaway proof of concepts of certain new features and see the complexity behind them before handing them over to the teams.

• Build something that just helps you in your day-to-day life, maybe a quick daily reminder to go for a walk, or do exercise. Openclaw is really great at creating cron jobs and executing a certain task at a certain time.

2. Working on an already existing project

Now, here it’s really important to be a lot more careful. You can use OpenClaw the same way as you are giving access to human engineers. You can create a GitHub account and give access to specific repositories, and then ask to finish a certain task and open a PR.

You then review the PR, add comments, and then tell OpenClaw to make adjustments based on the comments and commit them.

Important: You should never give direct write permissions here, as that may cause a lot of issues. As I mentioned, hallucinations are a problem, and you can’t rely on the results being on point.

This is a trial-and-error approach, where you need to work on giving the best possible context and requirements, and good feedback. OpenClaw will store your feedback as context and ensure that the next time it will be considered.

3. Meeting checker and reminder

Ask OpenClaw to check your calendar and give you insights for every meeting 5 minutes before it starts. Who’s attending, some additional info about them, what’s the purpose of the meeting, and what are the key expected takeaways.

You can then also grab the transcription and summary of the meeting from the note taker and share that with OpenClaw, which can analyze if the meeting was needed or if it could be just an email.

4. Get the info about existing projects

As mentioned, OpenClaw is really great with cron jobs, and you can connect Jira/Linear with it and then ask to give you the latest summary on projects and tasks.

Are we still on track, or are there some potential issues that a certain timeline may not be reached? You can go into as much detail as you need.

5. Check for stale PRs

As we all know, some of the biggest blockers in engineering team productivity are slow code reviews. In my experience, slow code reviews have always been a sign of a poorly performing team.

What you can do is ask OpenClaw to create a cron job every morning and give you the list of all the PRs that have been open for more than 2 days.

Then you can make a habit in the morning and go through them and see if there’s a certain repeating pattern happening.

6. Turn Slack discussions into documentation/reports

This can be an interesting project, especially if you are doing incident management communication via Slack. Let’s say that there was an incident, and you were in charge of comms with other departments to ensure everyone was on the same page.

You’ve created a new Slack thread where you reported the findings and what’s happening at the moment.

After the incident is finished and the problem is gone, you can ask OpenClaw to analyze the thread and create an incident retrospective document based on the thread.

Then you can make a few adjustments needed, and you’re good to host an incident retrospective and ensure everyone is aware of the root cause and action items that need to be taken.

Last Words

These are just a few examples of how you can use OpenClaw to help you be more productive and get things done.

Over to you, what are you building with OpenClaw? I would love to know! Make sure to share your experience in the comments.

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.

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

Understanding AI fluency is one thing. Evaluating it in a 60-minute interview is another. You don’t need to redesign everything, though. Just adjust what you look for and how you interpret what you see.

What changes in your interview setup

The mechanics are simple. Explicitly allow candidates to use AI tools like Copilot, Cursor, Claude, whatever they prefer. Provide access within the interview environment if they don’t have it. This levels the playing field.

Not all candidates have access to premium AI tools, so providing them ensures you’re testing fluency, not financial access. Make it clear that using AI is encouraged, not forbidden, and that you care about how they work with it.

If a candidate hasn’t used AI tools before, that’s a valuable signal. For senior roles where AI fluency is critical, inability or unwillingness to engage with AI is a red flag. For junior roles, you’re evaluating potential: Can they learn it quickly when given the chance? Watch how they respond when you offer to show them how the tools work.

The bigger shift is in what you ask. Move away from isolated algorithm problems to realistic scenarios. Instead of “reverse a binary tree,” try “build an authentication endpoint” or “debug this performance issue.” These problems work better with AI because they mirror real work, and they reveal how candidates integrate tools into their thinking.

The signal framework

Focus on process, not just output. Strong AI fluency looks like this:

• Provides context before prompting AI (”I’m building a REST API for user authentication...”)

• Iterates on AI suggestions (”That’s close, but let me modify the error handling.”)

• Catches AI mistakes in real time (”Wait, this function signature is wrong.”)

• Explains reasoning independent of AI (”I chose this approach because …; let me verify with AI.”)

While weak AI fluency looks like this:

• Accepts first suggestion without reading it

• Can’t proceed when AI gives wrong answer

• Doesn’t verify AI output against requirements

• Treats AI as a source of truth that can’t be wrong

The difference between Level 1 and Level 3 shows up in these moments. A Level 1 engineer copies and hopes it works. A Level 3 engineer uses AI to accelerate their own thinking.

How AI fluency shows up across interview types

Evaluation looks different by format. Let’s look at some examples.

Live coding: Watch how they prompt, review output, and catch bugs. Do they read what AI generated or blindly accept it? When AI makes a mistake, can they debug it or do they get stuck?

Code review: Give them buggy code and let them use AI to find issues. Strong candidates validate AI’s findings against their own understanding. Weak candidates trust whatever AI suggests.

Take-home assignments: Assume AI was used extensively, which is fine since it mirrors real work. During the debrief, ask candidates to walk through their approach: “How did you use AI? Where did it help? Where did you override it?” You’re evaluating their process and judgment, not whether they wrote every line by hand.

Technical assessment platforms: Most screening tools, such as Codility, HackerRank, and LeetCode, now allow you to enable an AI assist feature for candidates. You can review their prompts along with their solution and assess how they used AI.

Architecture discussion: Ask candidates to use AI to explore design patterns or validate assumptions. Strong candidates treat AI as a thought partner, asking questions, challenging suggestions, and synthesizing insights. Weak candidates let AI make decisions for them.

System design: AI fluency shows in how candidates research patterns and verify ideas, not in how they memorize solutions. Can they use AI to stress-test their thinking? Do they know when AI’s generic suggestions don’t apply to their specific constraints?

Integrating AI Fluency into Your Rubric

AI fluency matters, but it’s not the only thing that matters. Weight it 10–40% based on seniority and how critical AI fluency is to the role. The more senior the role, the higher the weight. They’ll be role models for junior developers’ AI usage.

In practice, add an AI fluency row to your scorecard:

1 = Avoids or misuses AI

2 = Writes basic prompts, accepts suggestions uncritically

3 = Uses AI effectively, with verification

4 = Uses AI strategically, knows when not to use AI

Core competencies: system design, communication, debugging, architectural thinking, still dominate. AI doesn’t replace these skills. Instead, it amplifies them. You’re looking for engineers who are strong without AI but are even stronger when they use it well.

If you allow AI in interviews, adjust problem difficulty accordingly. With AI available, candidates should tackle more complex problems, handle more edge cases, or work under tighter time constraints. Don’t compare AI-enabled interviews directly to traditional ones; you’re testing different skills.

The key is treating AI fluency as one signal among many. You’re not replacing technical evaluation; you’re just making it more realistic.

Conclusion

The shift is already happening, and companies allowing AI in interviews are getting better signals about real job performance.

Start simple: Allow AI in one interview format, watch for the patterns outlined in “How to Evaluate AI Fluency in Your Interviews,” and learn and adjust quickly.

The goal is making technical evaluation mirror actual work. When you do that, you’ll hire engineers who are productive from day one.

AI fluency is here to stay. The question isn’t whether to evaluate it. It’s when you’ll start and how you do it.

Last Words

Thanks very much to Hamid for helping us learn to interview better in regards to AI fluency! Learn more about Hamid on LinkedIn, and be sure to grab your free copy of the First 90 Days Kit.

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

For a long time, being a great engineer meant having strong technical expertise.

The more you understood systems, algorithms, and the underlying technologies, the more valuable you were.

And that made sense, because building was a lot more difficult. Access was limited, and creating anything required deep knowledge and experience.

But that world is changing.

Today, code is easier to produce than ever. The gap in producing code has decreased, and what used to take days to implement can today be done much faster.

So naturally, the question becomes: If everyone can build, what actually differentiates great engineers?

The answer is no longer just pure implementation. Judgement is becoming an important skill for engineers.

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

- As Access Increases, Judgment Matters More
- From Pure Implementation to Decision-Making
- An Important Note on the Size of the Organization
- What Actually Good Judgment Means In the Engineering Context?
- The Cost of Poor Judgement
🔒 How To Develop Better Judgement
🔒 Experience
🔒 Actually reflecting on your mistakes and mistakes from others
🔒 Seek feedback
🔒 Understand the “Why”
🔒 Understand that every decision has trade-offs
🔒 Last Words

Let’s start with an analogy first!

As Access Increases, Judgment Matters More

Before the Printing Press Revolution in the 15th century, books were rare and expensive. Only a small group of scholars had access to knowledge, and learning itself was the main challenge.

Then, after Johannes Gutenberg invented the mechanical movable-type printing press, books became cheaper and widely available.

With books becoming more accessible, a new problem appeared. There were now too many books, more books than a person could read. So, the question changed from “Can you access the knowledge?” to “Which books are actually worth your attention?”.

A similar situation is happening today with the flood of AI-generated content online. And it’s no longer about how to find specific information, but which information is actually worth your attention. That’s where good judgment helps a lot.

And a similar case today is with developing software. With generating code being a lot more accessible, judgment becomes a lot more crucial.

From Pure Implementation to Decision-Making

As we see the shift happening across the industry, where more and more code is being generated instead of just typed out, the speed of pure implementation has increased tremendously.

With this shift, building the right things has become more important than ever. And that’s where good judgment comes into play.

Good judgment helps you answer questions like:

• Should we build this feature at all?

• Is this solution over-engineered?

• What are the long-term consequences of this shortcut?

• When should we prioritize speed over perfection?

And especially, if you can make these decisions correctly with speed, that’s where you can provide a lot of value in a very short amount of time.

Now, it’s really important to also mention that the importance of judgment heavily depends on the overall organization’s size. Let’s get to this next.

An Important Note on the Size of the Organization

Good judgment will especially shine where you are able to have a good amount of ownership, responsibility, and empowerment. That’s usually in smaller to mid-size companies.

A good example are teams at OpenAI, where they have a very bottom-up culture, and engineers often own projects straight from the idea phase and all the way to where the project is being released to the users.

If you are a part of a similar culture, judgment is more important than ever for you. If you are a part of a larger organization, it is much less, but the importance is growing.

In larger companies, there are more defined roles and a smaller scope that a specific engineer can have, which limits the overall impact you can have as an engineer. So, it’s definitely understandable that the overall judgement is much less effective.

But, I can see where the trend is heading: Smaller teams, more ownership, less typing, and more empowered decision-making. That’s where organizations want to go, but for larger companies with more rigid processes, that will definitely take some more time.

Now that we understand the importance of judgment, and the importance of it based on the size of the organization, let’s focus more on judgment in general.

What Actually Good Judgment Means In the Engineering Context?

Good Judgement is hard to define, as it contains many aspects, but personally, I like to view it as a combination of pragmatism and taste.

Pragmatism means that you find the best solution possible within the constraints of the real world, not the ideal world. Those constraints can be a specific budget, knowledge, expertise from the team, hardware constraints, people-related factors, or something else.

And taste from the engineering perspective is about making decisions that lead to systems that are simple and easy to evolve. Often, it’s hard to define what a certain “tasteful” solution is, but in many situations, you just know it when you see it. Think about what simple code looks like and how you would define it. You can’t, but your experience tells you it’s simple.

Often, both pragmatism and taste are heavily connected with experience and your overall understanding of your craft. The better you understand a specific domain or technology and the more experience you have solving similar problems, the better your judgment will be.

It’s the reason why experience, good understanding of fundamentals, and overall domain knowledge are more important than ever. It’s impossible to have good judgment without them.

The Cost of Poor Judgement

Good versus poor judgment can really make a huge difference.

Here is an example of poor judgment: Building a microservice architecture, with 2 engineers, while having 0 paying customers.

And an example of a good judgement: Building a monolith with the most important features of the product, so we can get paying customers as soon as possible.

Of course, there can be specific cases where building a microservice architecture would make sense, but you get the point.

Without the business, there is no engineering. So, the cost of making poor judgment in this case would be that the company would eventually need to be disbanded, as there would be no paying customers for a long time.

That would be the worst-case scenario, but in many other cases, poor judgment can also show up as an increase in technical debt, a slow system in general, reliability, or security issues as well.

How To Develop Better Judgement

Read more

This week’s newsletter is sponsored by Warp.

Introducing Oz: the orchestration platform for cloud agents

Engineers are shipping faster than ever, but agents stuck on local machines don’t scale. Without cloud agent orchestration, there’s no reliable way to scale across your infrastructure, measure impact, or enforce security standards.

Download the report to learn:

• Why 75% of companies fail at building their own agentic systems

• How teams save hours per engineer per day by using agent automations

• What makes 60%+ of PRs agent-generated actually achievable

Download free report

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

Intro

In this special edition of the Engineering Leadership newsletter, engineers and engineering leaders share how they are doing AI-assisted engineering.

They come from a variety of backgrounds and a range of company sizes, from startups to mid-sized and large organizations.

Our contributors to this article are:

• Brian Jenney, Senior Software Engineer, Coupa

• Sam Williams, Head of Product Engineering, Pronetx

• Owain Lewis, Founder, Gradientwork

• Florijan Klezin, Data Engineer, Samotics

• Vlad Khambir, Senior Software Engineer, Principal Associate, Capital One

• Mauro Accorinti, Software Engineer, Qurable

• Lucian Lature, Solutions Architect, Wiley

• Tamás Csizmadia, Senior Java Software Engineer, Precognox Kft

• Matthew Kyawmyint, Founding Engineer, Humanist Venture Studios

• Hans Vertriest, Full-Stack Engineer, Bizzy

• Uladzimir Yancharuk, Engineering Team Lead and Senior Full-Stack Engineer, Siena AI

• Frances Coronel, Senior Software Engineer, Slack

• Gilad Naor, Founder, Naor Tech

• Anyell Cano, Staff Engineering Manager, GitHub

• John Crickett, Founder and CTO, Coding Challenges

If you are looking to improve your AI-assisted engineering workflow, this is a must-read article for you.

Let’s start!

1. Coordinating AI-Assisted Engineering Across Multi-Repo Workflows, Side Projects, and Code Reviews

Shared by Brian Jenney, Senior Software Engineer, Coupa

Most of the work I’ve been doing spans multiple repos, so I first describe what I want to accomplish, such as “Create an IAM policy and relevant Terraform for repo A to do x, y, and z.”

I then explain the dependencies between the current repo and others that need to be updated, such as “Repo B needs an update to allow repo C to create the resources for repo A,” and provide good examples and files to illustrate what we are attempting to do. Lastly, I ask if the instructions are clear before proceeding.

For side projects, I create larger features in a smaller codebase and lean on AI more heavily to write code after creating a solid set of expectations and feature requirements. For example:

Create an endpoint at [fileName.ts] that does x, y, and z. Here’s an example endpoint doing something similar for reference. A UI component should be created here [someComponent.ts] that can call the API similar to this component [referenceComponent.ts]. Is this clear?

For code reviews at work, we have AI-assisted review in addition to human review. Human reviews tend to catch errors outside code syntax, like unexpected downstream effects or tribal knowledge.

We might get feedback like “This naming convention for that service won’t work because our script depends on this particular text to be present” or “That pattern is outdated and you can now use it this way to do this thing with a new library that we’re using.”

As far as I’m aware, we don’t use any AI tools for deployments that need a human review and final acceptance.

Our organization gives us access to both Claude and Cursor. I mostly use Claude, using Cursor rarely.

2. Building a Full AI Workflow on Top of Claude Code and Custom Skills

Shared by Sam Williams, Head of Product Engineering, Pronetx

Ideation

When generating ideas, we use Claude Cowork with a few skills. We have the option to use the BMAD (Build More Architect Dreams) Method, CCPM (Claude Code Project Manager), or our custom skill, all of which attempt to feed into our standardized requirements format.

These options get us better requirements and allow us to add our specific questions, which would normally cause a follow-up call.

Building

For building, we use Claude Code and a series of custom skills and Model Context Protocols (MCPs) tailored to our stack and architecture. We start by having AI convert the requirements document into a development plan.

We then review the plan and make any modifications. We catch quite a few things at this stage, such as requirements issues or needed improvements in the planning skill. Tests are written as you write the code.

We also have Claude run a second agent to review any tests written to make sure they aren’t just testing that a mock is a mock.

Review

We have a separate instance of Claude Code running on every pull request (PR), whether it’s human or AI generated. Quality assurance (QA) is still pretty manual right now, but we’re looking to have more automated end-to-end (E2E) tests.

3. Spending Half the Project on Design so AI Can Build the Rest

Shared by Owain Lewis, Founder, Gradientwork

I use AI across the entire engineering lifecycle. My primary model is Claude Opus 4.6 via Claude Code (the CLI tool) for all interactive work, layered with OpenAI Codex for automated background analysis.

The biggest productivity gain isn’t faster coding; it’s spending more time on design, because implementation is no longer the bottleneck.

Ideation and design

This is where I spend the most time using AI, up to half of the project time. I feed raw requirements to Claude and get back an initial architecture: data model, API design, tech stack, and deployment strategy (design first).

Then I challenge every decision aggressively: “Do we need this table? What happens when this fails? Is this overspecified?” I go through multiple design versions before writing any code.

On a recent project, I did more than 10 design iterations on a simple project. AI can build code fast, but it can’t fix bad architecture.

Building

I delegate nearly all coding to AI. I write detailed specs first to ensure we build the right thing and use Linear MCP to capture tasks for agents to work on.

Although I’ve been writing code for more than 20 years, AI is generally better at it than any engineer I’ve worked with. But it does make mistakes and you must use your judgment to find them.

The design document becomes the implementation brief. I review and iterate every output, often multiple times. The first thing AI produces is a draft, not a deliverable.

For larger tasks, I run multiple Claude Code agents in parallel on different parts of the codebase.

Reviewing

AI might be better at writing code, but I’m better at knowing whether the code should exist at all. I review every file, then ask the AI to review its own output (”Review this like a senior engineer”).

This consistently catches issues the generation pass missed. I also use multiple agents to review from different angles: security, performance, correctness, simplicity, and so on.

On one project, an AI review pass found nine concrete issues before implementation. Five minutes of review saved hours of rework. Never trust the first output.

Merging and CI/CD

AI opens PRs with structured summaries and test plans and writes tickets with detailed descriptions. This is a huge time-saver and the quality is consistently better than human-written descriptions.

Claude Code also generates commits with clear messages and runs as an automated reviewer on every PR. OpenAI Codex runs nightly against my repos, scanning the full codebase, identifying bugs, and auto-opening tickets and PRs with fixes. It catches things I miss during the day.

I use AI heavily for operations work and debugging production issues.

Tools

I don’t use multiple AI tools because one is insufficient. I use them because they play different roles. For example, Claude is my interactive engineering partner, while Codex is my automated background quality gate.

• Claude Code (CLI) with Opus 4.6: Primary tool for all engineering.

• Claude Code agent teams: Multiple parallel agents for large tasks and multiperspective review.

• OpenAI Codex: Automated nightly codebase analysis, which runs unattended, finding bugs and auto-opening tickets and PRs; I run different models to find errors in code.

• GitHub Actions and Claude Code: AI-powered code review as a CI step on every PR.

• Langfuse: Large language model (LLM) observability for AI-powered features in production.

• uv (Python)/Bun (JS/TS): Fast package managers that keep the iteration loop tight.

Key lessons

• AI doesn’t reduce iterations, it increases them.

Each one is faster, so you can afford more. Projects go wrong when someone accepts the first output and ships it.

• The skill shift is from writing to reviewing.

Spotting subtle bugs, unnecessary abstractions, and confident-but-wrong AI claims requires deep experience.

• Design documents are the most important artifact.

When AI generates code from them, their quality directly determines output quality.

• You still need to know your craft.

AI makes experienced engineers dramatically more productive. It doesn’t make inexperienced engineers into experienced ones.

The formula: rigorous design + AI implementation + aggressive review + multiple iterations = high-quality output at speed.

The trap: no review + first-output acceptance = fast production of technical debt. The difference is discipline, not tooling.

4. Using Cursor as a Thinking Partner, Not Just an Autocomplete Tool

Shared by Florijan Klezin, Data Engineer, Samotics

I use Cursor as part of my daily engineering workflow because the repository indexing is strong, the pricing is reasonable, and I really like the overall IDE experience.

I can easily switch between models depending on the task, and the feature set is rich enough to support everything from large refactors to deeper architectural reasoning.

As a data engineer, I rely on AI for tasks like cross-file refactoring in data pipelines, generating integration tests, analyzing query plans, and running quick ad hoc analyses or plots to validate assumptions during investigations.

It’s more of a thinking partner than simple autocomplete, with output quality largely depending on how well I structure the problem up front.

5. Creating Reusable Workflows Rather Than Ad Hoc Prompts

Shared by Vlad Khambir, Senior Software Engineer, Principal Associate, Capital One

My approach to AI-assisted engineering centers on structured workflows rather than ad hoc prompting. Real productivity comes from applying AI to repeatable engineering patterns, not just isolated questions.

I’ve moved beyond using AI as a conversational assistant. Instead, I build reusable Windsurf Workflows that handle specific, recurring tasks, such as:

• Pre-PR code review

• PR preparation with consistent structure

• Implementation planning from ticket requirements

• Review of feedback processing

Each workflow is a structured prompt with defined inputs, expectations, and output formats. This eliminates the cognitive overhead of reexplaining context every time.

The biggest lesson I’ve learned is that AI doesn’t reduce work, it intensifies it. Poor context management leads to slower responses, degraded reasoning, and inconsistent results.

I apply the Agent Skills pattern (inspired by Claude’s approach) to separate three concerns:

• Instructions: Markdown documents defining goals, constraints, and expected output

• Resources: Static files, like style guides, templates, and internal docs

• Scripts: Executable logic for external integrations (Git, Jira, etc.)

The Agent Skills keep the AI focused on reasoning instead of drowning in integration details.

Tools and stack

• Windsurf: Primary AI coding environment with workflow support

• Claude (via Xcode 26.3): For agentic coding with AGENTS.md, skills, and MCPs

• Voice input: About twice as fast as typing, reducing the friction between thought and code

• Custom linting and validation: Because AI generates tech debt faster if your process is messy

Balancing speed, structure, and human judgment

I don’t aim for full automation. Instead, workflows provide:

• Structured feedback for code changes

• Consistent PR descriptions

• Implementation plans that respect architectural patterns

• Categorized review feedback

The goal is to reduce friction and standardize routine work while keeping engineers in control.

From my experience building iOS apps with AI tools:

• Tech debt accumulates faster. AI doesn’t replace a good process; it just amplifies your current process.

• Hidden dependencies hurt more. That makes early dependency checks and clear agent rules essential.

• Context limits are real. Be sure to separate the MCP responsibilities (data fetching) from reasoning tasks.

• Speed isn’t free. If you want to ship faster, you need to debug faster.

AI tools intensify rather than reduce cognitive load. It’s like watching YouTube at double speed: You’re processing the information faster, but the mental demand increases with it.

The solution isn’t more AI; it’s better structure and clearer constraints. And it means accepting that you’re trading speed for a different kind of complexity.

This approach has helped me ship faster while maintaining quality, but only because I invested up front in workflow design and context discipline. I had to accept that AI is a force multiplier, not a replacement for engineering judgment.

6. AI-Assisted Engineering: Figma, Parallel Agents, and Learning New Tech on the Fly

Shared by Mauro Accorinti, Software Engineer, Qurable

Apart from how I am doing AI-assisted engineering, I’ll include how I’ve seen others use AI as well, since I believe that’s just as valuable.

Ideating

I’ve seen tech leads use AI to help write clear requirements in Jira tickets. The AI is given a definition of ready document, which it uses to divide the tasks into smaller chunks that the teams can take on.

AI is excellent for creating pretty clear tickets with descriptions, test cases, boundaries, and expected results.

With clearer tickets, it becomes easier to read and bring up edge cases to consider during our planning. It can be a massive time save for the tech lead, because AI can understand the tasks and create clear requirements.

Then they can just double-check the output and correct it on the spot.

Building

I’ve been building using AI agents for the last few months. Honestly, it’s changed a lot of how I work. Here are several examples.

Working with Figma MCP with IDE agents

With front-end work, my productivity has sped up a ton by using MCPs. Once set up, AI can view my Figma files and implement a design with 85–90% accuracy while integrating it to an existing Next.js project.

Things like text size or padding/margin spacing tend to be off, but the general positioning is there and I can correct the code to my liking.

I’ve found that the less accurate you are with the prompt, the worse the code is (e.g., adding font sizing to every p element instead of adding it once to the parent div element), but you learn to work with it as time goes on.

And you don’t always need to use MCP. I’ve found decent success using simple screenshots of the design.

Working with new frameworks/languages

AI has become a big help whenever I start working in repos with tech I’m not familiar with. I can now work faster and be more productive in these sorts of environments, thanks to AI helping me understand the repo better.

I describe my task to the agent, have it generate code, and then work with a separate AI to understand why the code does what it does. I can learn about the framework alongside doing my tasks in a way I couldn’t before.

I can ask questions about anything I might be worried about, like security, tests, requirements, and alternative ways to execute the same task, using common sense throughout.

This approach has cut down on the time I needed to learn about new tech before being able to work with it effectively. I run into fewer syntax and beginner errors with AI assisting me.

Doing tasks in parallel

I’m currently working on two projects. Sometimes I’m working on a big task in one project when a small task in the other project pops up.

If I have to, for example, disable a particular button while the form is submitting, I can give the task to the AI agent while I continue working in the other project.

After the AI agent’s work is done, I can quickly switch back to review the work and then create the PR, the code for which was being created while I worked on another task. This still seems crazy to me.

Helping create test cases

AI is honestly spectacular in creating unit tests for different features in a codebase. Once you create your feature, if you know what has to be tested, you can ask the agent to create the test suites needed. You can then check what was created and modify it to your specifications.

AI agents have become excellent at generating tests that don’t fail. They are now smart enough to run the test suite, detect any errors, and autocorrect until there aren’t any more before telling you the code is done.

Reviewing

In one of our projects, we use GitLab integrated with an AI that reviews all PRs and analyzes the code. This review is added as a comment to every PR.

This process does a few things. It compliments what’s good about the code and critiques elements that are missing, could be improved, or shouldn’t be included.

For example, it brings up warnings whenever you accidentally committed .envs, if the PR title doesn’t include the ticket, if test cases weren’t created or don’t consider a specific case, or if the code seems different from the rest of the specifications currently in the repo.

It’s a great first look while you wait for other devs to take a look at it.

7. Separating Generation from Verification Across the Pipeline

Shared by Lucian Lature, Solutions Architect, Wiley

When I’m doing AI-assisted engineering, I think of the AI as a high-speed collaborator throughout the entire pipeline, but I keep it on the rails with two rules: I separate generation from verification, and I separate conflicting goals into separate “modes,” or specialist agents, so security paranoia doesn’t undermine shipping and shipping pressure doesn’t undermine risk.

Building the right thing begins with ruthless problem framing

I start by writing down the problem statement, the target user, the outcome, the metric, and the non-goals. Then I use the AI to attack them, so that I get the assumptions that I must make true, the fastest way to kill those assumptions, and what I should not build.

If it’s a problem in multiple domains, I don’t use one general agent. I delegate to multiple modes, one to think about the product, one to think about the architecture, one to think about security, so that I get to the smallest testable slice with the clearest success criteria.

Design is interface-centric, tradeoff explicit

Before I write code, I have the AI to give me two plausible designs, and I force myself to make a decision by weighing cost, complexity, usability, failure cases, and so on. I define contracts early, so I know the API shape, the events, the error cases, and the data ownership.

This is where I’m likely to want to use the stronger “reasoning” model, since shallow suggestions are expensive to fix later. I also ground everything in the existing context, so that I don’t accidentally redebate old decisions or drift in style. I pull in existing decisions, conventions, and constraints so that I don’t relitigate old problems.

Implementation is where AI gives you the biggest speedup, but only with tight feedback loops

I use AI very heavily for scaffolding, repetitive glue code, mapping between different levels (schemas to types to handlers), and exploring different alternatives quickly. However, I do not use “big bang” AI commits. The cycle is generate, run, see how it goes, fix.

If I’m getting into very specialized domains, I use the appropriate expert: TypeScript-type system problems use a TypeScript-focused expert, React architecture uses a React-focused expert, infra or CI/CD uses a DevOps/SRE expert.

However, they all have one thing in common: They have smaller toolsets and domains that make them more accurate and cheaper than one monolithic expert.

Testing is intentionally adversarial and separate from code generation

I do not use the same expert that wrote the code to test it. I switch experts and ask for edge cases and negative cases and ask how this could break in production. Then I take actual bugs and turn them into regression tests immediately.

For critical paths, I’m biased toward integration tests over a forest of brittle unit tests. AI is helpful for this by coming up with cases and producing a first draft of tests. However, tests must always be deterministic, readable, and tied to a failure mode.

Code review is not one pass; it is a series of passes

I do code review in several passes: correctness and maintainability concerns first, then security concerns, and then design and performance risks. Each reviewer outputs a list of concerns with severity and location.

To do this efficiently, I use context reuse between review passes. The expensive structural understanding of the codebase is cached so that the second and third reviewers do not need to reparse everything and rediscover the same things.

Merging is about accountability, not automation

I use AI to write out the PR description, risk checklist, and test plan so that I have all clarity quickly.

However, I personally review the top-level risks just before merge because there is a risk of a “rubber stamp” problem as velocity increases and understanding decreases with AI adoption. I use it to reduce the review surface area to a minimum.

Monitoring and continuous improvement closes the loop

I define a small set of signals for each change: error rates, latency, saturation, and a single business signal if applicable.

I also use lightweight live evaluation for AI-heavy processes by sampling: cheap checks at high rates and expensive judging at lower rates. This is always done asynchronously so it does not add user-visible latency.

The tools I use to implement all of this are a cheap routing step to decide whether to use a large model, specialists for conflicting domains, hybrid retrieval so that the agent is connected to the world via real-world context, workflow primitives for repeatable patterns such as review and synthesis, and reliability primitives such as timeouts and retries so that a single stuck call does not block the entire system.

8. Using an In-House Tool to Help with Spec-Driven Development with AI

Shared by Tamás Csizmadia, Senior Java Software Engineer, Precognox Kft

We use an in-house tool called Precognox AI-Aided Development (PAID), which enhances spec-driven development with AI capabilities.

Our typical workflow begins with specifications created by our business analyst team in collaboration with developers. We use PAID to review, assess, and finalize these specs before converting them into user stories.

During refinement, we use PAID to groom stories and break them down into actionable tasks. The tool also helps us generate wireframe diagrams, user journey maps, and demo videos. Project managers and team leads can quickly create presentations for sprint demos.

As the maintainer of this internal tool I like to think of PAID as a context engineering assistant.

What makes PAID powerful is its extensibility through templates and features (something like a plugin). Any team member can contribute improvements to the tool itself.

For example, one developer recently added Figma integration via Figma MCP, and another one packaged his agentic skills as reusable components, making them available to all developers across our projects.

Currently we are preparing the MCP server feature of PAID and involve non-devs in the development process more and more.

9. Teaching AI to Catch Its Own Mistakes over Time

Shared by Matthew Kyawmyint, Founding Engineer, Humanist Venture Studios

Inspired by Every and the StrongDM Software Factory, I rely heavily on AI to ideate, research, spec, build, validate, deploy, monitor, and more.

I’m in a solo dev phase of our company, and AI (especially Claude Code) has helped me implement best practices in code and in infra/tooling that bring in more pro-level scans, testing, and monitoring setups.

If I find issues, I investigate it postmortem style: Would it be possible for AI to catch and fix these issues in the future? Can I add to AI’s senses, that is, augment what validation tools or abilities it has, so that I don’t have to be the intermediary for every little check?

After I do the postmortems enough times and add the learnings to our repos, AI gets better at addressing the types of problems we’ve already solved together. That allows me to move on to new tasks: new ideas, refactors, consolidations and refreshes, audits, and so on.

I’ve found that the more I address tech debt proactively (keeping a close eye and adding more tools to have AI watch bloat), the faster AI can move, because it doesn’t need to deal with janky AI slop of assumptions and antipatterns all over the place.

One of the difficult parts is that I heavily rely on my own instincts from working in big tech and startups large and small. When I revisit code threads and PRs, I try to understand whether, in broad strokes, we’re going in the right direction or I need to have AI deeply investigate aspects of the PR and problem, solution, and domain.

I dig into the PR code when I’m curious about things, want to learn more details on how it works, or notice something that smells off.

For PRs, I use CodeRabbit and Bito for AI-assisted reviews, as well as other CI steps that run CodeQL, in addition to other validation patterns. This helps me a lot, like having a second pair of eyes.

I use new worktrees for each new issue or thread (unless I want to double up on a thread for some reason). I have a custom script that copies over MCPs and other useful tools, in addition to setting up fresh worktrees.

I regularly use OpenAI Codex for a second opinion on those threads, but that’s a newer workflow I’m still smoothing out.

10. Using a Custom Planning Skill Optimized for Exploring the Best Solution

Shared by Hans Vertriest, Full-Stack Engineer, Bizzy

With Claude Code, I use a custom planning skill optimized for exploring the best solution for the problem, where the AI asks critical implementation questions and we go back and forth until I agree with it.

When execution is done, I review the changes by adding comments with a Visual Studio (VS) Code extension, which saves the comments to a notes.json file. I still use VS Code so that I can directly make smaller changes and fixes myself.

After review, I call a custom implement-notes skill, which reads out the note.json file. This loop keeps going until I get a clean, readable result.

All GitHub PRs are automatically reviewed by Copilot.

11. Spec-Driven Development at Scale

Shared by Uladzimir Yancharuk, Engineering Team Lead and Senior Full-Stack Engineer, Siena AI

Process and tools

I’ve been implementing code as a full-stack engineer for almost 20 years, most actively for the past 6. I tried Cursor, Claude Code, and Codex about 10 months ago. I settled on Claude Code (Max 5 subscription) as my primary tool within a month, but I’ve recently started experimenting with Codex again.

Where I use AI

At Siena, provider of AI agents for customer support automation, I mainly work across two repos: a JavaScript/TypeScript back end (over 230,000 lines of code) and a React front end (over 200,000 lines of code).

On the side, I’m cofounder of language learning app Menura (2,000 ratings worldwide) for which I fully reworked the onboarding flow and built an AI voice tutor with Claude Code (over 50,000 lines of code on the back end and over 60,000 lines of code on the front end).

The language-level assessment with AI tutor is handled entirely from the client device using ChatGPT’s gpt-realtime model.

My process for spec-driven development

1. Setting up the project

I keep CLAUDE.md under 100 lines, including only project-specific rules, such as error handling patterns and import constraints. I added architecture docs in /docs/ as high-level component maps (docs/SystemComponents.md and others), using them to prime context at the start of every session.

Task specs live in /specs/, while big modules have their own README.md in their folders. All of these markdown files exist primarily for AI coding agents, not humans.

2. Priming the context

Every session starts with a prime_context command that reads the project tree and key architecture docs, so Claude Code has the right mental model before touching anything.

3. Planning before coding

As well, every session starts in planning mode, with a back-and-forth with Claude. I continuously monitor context usage with a customized status bar and keep it to no more than 40% before moving to implementation.

For big, important features, I ask it to produce a structured spec (specs/feature-implementation-plan.md) that’s broken into high-level objective, method changes, type changes, and test changes.

This is the most important step, because it prevents Claude from going off-track and gives me a chance to catch design mistakes before any code is written.

I often use links to already implemented PRs as a starting point for planning, such as building a new feature based on the patterns and approach from a past implementation. Smaller tasks don’t need a formal spec; the planning conversation is enough.

4. Implementing from spec

Once the spec looks right, I tell Claude to implement it. Because the plan is explicit and scoped, the output is better than if I just said “Build X.”

5. PR reviews

I also actively use Claude Code for PR reviews with custom requirements for quick issue and inconsistency detection. These reviews catch things I’d miss on a manual pass, especially across large PRs.

How my approach helps productivity

The spec-driven approach means the specs, which are essentially detailed prompts, also serve as artifacts. They can be reused by AI agents as examples for future implementations, with each feature you build accelerating the next one.

Although I’m primarily a back-end engineer, Claude Code has helped me to fully handle front-end code implementation as well. Sometimes I use Google’s Stitch to improve existing pages or extend the user interface without needing to involve a designer.

For Menura, I shipped a complete AI voice tutoring feature, which includes real-time conversations, speech-to-text, text-to-speech, lesson flow, essentially solo, which otherwise would have taken a small team to complete.

At Siena, AI lets me move quickly across a large codebase while maintaining quality. I’m now using Codex for smaller, well-scoped async tasks like refactors or test generation where I don’t need the interactive back-and-forth.

At the end of 2024, I wrote a Medium article on using LLMs for code generation from a public GitHub repo that was the starting point of me experimenting and testing the abilities of LLMs to generate code, and the workflow has evolved significantly since then.

12. Using Claude Code as a Primary Engineering Companion

Shared by Frances Coronel, Senior Software Engineer, Slack

I’m a senior software engineer at Slack, where I focus on building new features for the sidebar and notifications system, and I use Claude Code as my primary AI engineering companion.

Here’s my process across the development lifecycle.

Codifying my standards with CLAUDE.md

The most impactful thing I’ve done is invest heavily in CLAUDE.md files: persistent instruction files Claude reads in every session. I maintain both a global one (personal standards) and a project-level one (codebase-specific patterns).

I encode branch naming, commit workflow, PR templates, code quality checks, file length guidelines, and even Slack update formatting.

Instead of repeating myself every session, Claude follows my playbook automatically. For example:

Always create PRs as drafts with auto-merge enabled, run TypeScript + Prettier + ESLint before every commit, and commit/push after each completed change.

Once codified, Claude just executes the full pipeline.

Ideation and planning

For nontrivial features, such as net-new components and huge refactors, I use plan mode. Claude explores the codebase, reads relevant files, and proposes an approach before writing code. I review and approve before implementation.

I also enforce a strict rule: Never propose changes to code you haven’t read. This ensures it respects existing patterns and avoids hallucinating solutions.

Building

When I’m building, I describe what I need, such as features, flag cleanups, and bug fixes. Claude reads the relevant files first, implements changes following existing patterns, and then runs the full quality pipeline: type check, format, lint, commit, and push. Each commit is atomic and focused.

I also use shared internal plugins for repetitive tasks, such as:

• Toggle cleanup for removing concluded feature flags (I created this one!)

• A CI plugin to auto-diagnose and -fix CI failures

• Playwright test generation from natural language flows

• Front-end copy internationalization checks

These remove a huge amount of boilerplate work.

MCP integrations

Claude connects to internal tools via MCP servers. I’ve integrated Slack (searching threads, drafting messages, providing context from conversations), our feature flag platform, analytics/data warehouse (SQL queries), and Figma (design screenshots).

This lets Claude look up rollout percentages, search Slack for bug context, or query analytics without me switching tools. I recently used a few of these MCPs to merge in a fix for a SEV2 incident in 27 minutes from start to finish.

Hooks and notifications

I use macOS notification hooks so Claude alerts me when it finishes a task or needs input. Different sounds signal different states. This lets me delegate work asynchronously instead of watching it run.

Code review and PR creation

Claude generates structured PR descriptions using my template: why, testing checklist, before and after demos, risk assessment, revert plan, preview links, and cross-references to Jira and Slack threads.

Every PR is created as a draft with auto-merge enabled and opened automatically so that I can add reviewers while CI runs.

Monitoring and debugging

Our Claude plugin diagnoses and fixes CI failures automatically. Slack MCP helps me gather context on incidents without leaving my terminal.

Tool summary

• Claude Code (CLI) running Claude Opus via AWS Bedrock

• CLAUDE.md files (global and per-project workflow standards)

• MCP servers (Slack, feature flags, analytics, Figma)

• Plugins (CI auto-fix, toggle cleanup, codebase search)

• macOS hooks for async notifications

• GitHub CLI (gh) for draft PR creation and auto-merge

• Warp for terminal

• Claude Code status line (custom one at Slack we use from DevXP AI team)

The real ROI of AI-assisted engineering isn’t the model, it’s codifying your standards and making sure the developer experience from end to end is top notch.

Every time I repeat an instruction, I encode it. The AI improves because my expectations get clearer. Clear standards produce consistent results.

13. Using AI to Interview Myself Extensively for Each Product Idea

Shared by Gilad Naor, Founder, Naor Tech

I use AI to interview myself extensively for each product idea. Instead of writing a spec, I have the AI push and prod me, challenge my assumptions, and dig for more details. This usually takes 30–60 minutes, and the end result is the detailed spec that I use with Claude Code.

On the coding side, I break the work into small slices. I ask Claude in planning mode to create an Elephant Carpaccio style plan.

I now have a bias for languages and tools with strong guarantees, such as Rust. I invest most of my effort at the start, building the quality harness. After that I try very hard never to look at the code. I focus on the quality of the integration tests and on manual E2E QA.

14. Embedding AI Across the Workflow, but Always with Humans Making the Key Decisions

Shared by Anyell Cano, Staff Engineering Manager, GitHub

My organization at GitHub owns infrastructure and platform systems where scalability and performance requirements are beyond what’s needed in most systems out there.

That context shapes how I think about risk, automation, and where AI fits in the process. The words below are mine and don’t represent GitHub as a company

This is how I work

My product partner owns the business roadmap, translating business needs into clear requirements. My role as an engineering manager is to build the technology roadmap.

Together, we define the priorities for the organization: the what and the why. From there, I assign engineers to each project. Every project has one directly responsible individual (DRI) who owns the overall outcome.

I encourage collective ownership and an inclusive culture, but I believe every project needs a clear point of contact.

The DRI is responsible for analyzing requirements and proposing a solution. I am a strong believer in written documentation: architecture decision records for medium-sized and large projects and well-documented issues for smaller features.

For medium-sized and large projects, the broader team vets the design. This is the phase I get most personally involved in. Design is my favorite part of building software. Once the design is approved and no major concerns are raised, implementation begins.

Delivery is something I care deeply about. I believe in shipping small, iterative features, avoiding premature optimization, and keeping a laser focus on the goal. Ship to learn. Stay close to the customer.

Where AI fits in this process

AI is embedded across our workflow but always with humans making the key decisions:

• Documentation

Engineers use AI to draft and improve written artifacts throughout the process.

• Code generation

Each engineer uses the tools that work best for them. I trust my engineers to pick the right tool for the job or the tool they are more comfortable with. This applies to agents or IDE.

• PR reviews

AI assists with code review, but a human always makes the final call.

• Merging

Always a human decision. This feels natural and right to us.

• Monitoring

This is an area of active growth. AI is proving very useful for early detection, gap analysis, anomaly detection, and surfacing insights from historical data. Observability tooling in this space is evolving fast, and we are paying close attention.

• Deployment

This is fully automated with classic CI/CD. Given the criticality of the systems I oversee, this is the last area where I will consider deeper AI integration. That said, I do see significant potential in AI-driven proactive recommendations during rollouts, especially when paired with the observability capabilities above.

Beyond the engineering workflow, we also use AI heavily for collaboration: transcribing meetings so no one has to take notes, summarizing long threads, and surfacing action items from conversations.

I find it genuinely exciting to work alongside engineers who are finding creative, practical ways to weave AI into their daily work. Seeing it in action, not just in theory, is what builds conviction.

15. AI-Assisted Engineering in Phases

Shared by John Crickett, Founder and CTO, Coding Challenges

My workflow relies on leveraging the coding agent for multiple steps in the software development lifecycle.

That means everything from creating a high-level project specification through the development and review of more detailed requirements, the creation of a design and a breakdown of the tasks required to implement the design and deliver software to meet the requirements.

Setting Up The Project

My workflow assumes some structure exists in the project:

project/
├── AGENTS.md
├── CLAUDE.md
├── design/
├── memory/
├── plan/
└── spec/
    └── project.md

These are used as follows:

• AGENTS.md - This is the agents file, built on the AGENTS.md specification, it should contain the least amount of detail to required to guide the agent through the project. Covering: Commands, Project Structure, and Process.

• design - Any design documents created will be stored here.

• CLAUDE.md - This is directs Claude Code to read the AGENTS/md file.

• memory - A record of what has been learned during the development of the project. It provides a basic “memory” for the LLM between context windows.

• plan - Any plans created will be stored here.

• spec - Any specifications and requirements created will be stored here. The starting point for a project is a project.md that should provide the high level overview of the project and requirements.

All of these can be generated using tools/init.sh, which will create this structure in the current working directory.

Specifications

Creating the high level specification

After creating the AGENTS.md and spec/project.md with the tools, they should be edited. All sections in curly braces (i.e., {PROJECT TITLE}) should be replaced with the relevant details.

For example, for a Rust project, the AGENTS.md would go from the template to:

## Commands
- Build: `cargo build` (compiles Rust, outputs to target/)
- Test: `cargo test` (runs the tests, must pass before a task is consider complete)
- Lint: `cargo clippy` (check for possible issues)

## Project Structure
- `src/` – Application source code

## Process
 - Always write tests before implemeting functionality.
 - Always ask before adding dependencies.
 - Always ask before modifying existing tests.
 - Never change a test to make it pass.

Update the process to reflect your own development processes.

The spec/project.md should be similarly updated. Again all sections in curly braces (i.e.: {PROJECT TITLE}) should be replaced with the relevant details.

For example for a simple Redis Like Server it might become:

# Project Spec: Redis Like Server

## Objective
- Build a Redis like server in Rust. It should support multiple concurrent clients, connected via TCP using the RESP2 protocol. The server should support the commands: SET, GET, EXISTS, DEL.

## Tech Stack
- Rust 2024 edition

Creating detailed requirements

Having created the high level detail, use the agent to create a requirements document. I do this using the prompt:

Read specs/project.md and ask me questions to help refine a set of requirements for this project.

Use the The Easy Approach to Requirements Syntax for the requirements, write them to ./specs/requirements.md

The Easy Approach to Requirements Syntax (EARS) is a mechanism to gently constrain textual requirements. The EARS patterns provide structured guidance that enable authors to write high quality textual requirements.

Generic EARS syntax: 

The clauses of a requirement written in EARS always appear in the same order. The basic structure of an EARS requirement is:

While <optional pre-condition>, when <optional trigger>, the <system name> shall <system response>

The EARS ruleset states that a requirement must have: Zero or many preconditions; Zero or one trigger; One system name; One or many system responses.

I then answer the questions the agent asks, and when it produces it, review the resulting spec/requirements.md.

If it’s relatively close, I might edit it myself; if it’s far off, then I clear the agent’s context window, refine the psec/project.md, and repeat the process to get another spec/requirements.md, until I am satisfied that it reflects my current understanding of the project.

Planning

Ask the agent to review the requirements and create a plan alongside a set of requirements for each step.

Review the updated set of requirements and create a plan that details the tasks needed to implement the requirements.

Output the plan to plans/plan.md add one line per task. Create one specification file per task in the specs folder.

Example plan file:

# Implementation Plan

| Task | Description | Spec | Requirements |
|------|-------------|------|--------------|
| [ ] 01 | Setup project | [task-01-project-setup.md](../specs/task-01-project-setup.md) | REQ-03 |
| [ ] 02 | Create Table | [task-02-create-tables.md](../specs/task-02-create-tables.md) | REQ-02, REQ-11 |

We're done with planning, so clear the context and switch to building.

Building

Prompt the agent to build the first (or next) item:

Read specs/prd.md for an overview of the project.
Read plans/plan.md, pick the next most important task and read the relevant specification from the specs directory.
If it exists, read memory/learnings.md.

After reading the specification create a set of tests to verify the implementation behaves correctly. Then create the code required to meet the specification. Very the functionality is correct using the tests.

Before marking the task as done in plans/plan.md ensure the code lints without issue.

If you learn anything that will be needed for future tasks, record it in memory/learnings.md.

Stop after completing one task.

Once the agent claims the task is complete, test it.

If it does not work, provide errors and detailed feedback to the agent. Until it does.

When it works, commit the changes. Clear the context and then repeat the build step until the full plan is implemented.

Code review and fix

Ask the agent to code review the project.

Review the code in this project. Look for possible logic errors and failures to write idiomatic code.

## Instructions
1. Read all the code in the repository.
2. Run the tests against the code and ensure they pass.
3. Run the appropriate linter and formatter for the programming language.
4. Check the code against best practices for the programming language of the file.
5. Check the code is clear, easy to read and simple.
6. Check the code is consistent with the majority of the code in the project.
7. Suggest any refactoring opportunities.

Report any issues in a file codereview.md

Ask the agent to create a plan to address the issues:

Create a plan to fix these issues, save it to plans/fix-codereview.md detail the fixes required in specs/coderevew-{ITEM}.md replaceing {ITEM} with a name for the item that relates to the step in the plan

Once a plan has been created, prompt the agent to fix the next item:

Read specs/prd.md for an overview of the project.
Read plans/fix-codereview.md, pick the next most important task and read the relevant specification from the specs directory.
If it exists, read memory/learnings.md.

After reading the specification create any new tests required to verify the implementation behaves correctly. Then create the code required to meet the specification. Very the functionality is correct using the tests.

Before marking the task as done in plans/fix-codereview.md ensure the code lints without issue.

If you learn anything that will be needed for future tasks, record it in memory/learnings.md.

Important

If, during the workflow, you notice requirements are missing, have the agent update the requirements and the plan. Then review it. Clear the context before returning to building.

Last Words

Special thanks to all the engineers and engineering leaders who shared their insights and experience on how to do AI-assisted engineering.

I hope you enjoyed this special edition newsletter, where I brought together tech professionals who shared their insights!

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

“What will others think if I do this?”

I fully believe that this question is the #1 reason why many people are holding off on the next new thing that they want to pursue. Me included.

We often think too much of “what will they think if I do this”, and the funny thing is that it’s all in our heads. People are way too busy with their own lives to constantly look at what we’re doing. And they have their own problems to worry about.

And even if we make a mistake, they might think about it for a second, but then they will go straight back to worrying about their own problems.

That was a quick introduction to the spotlight effect, and in today’s article, I’ll be going through all about what a “spotlight effect” is, why it’s holding you back, and I’ll also share my personal examples throughout my career as well, how it held me back, and how I overcame it in specific cases.

If you have career aspirations (and you definitely should) as an engineer/engineering leader, it’s definitely a must-read article!

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

- What exactly is the Spotlight Effect?
- Practical Example From the Experiment Conducted by Thomas Gilovich in the Early 2000s
- As a Self-Taught Engineer, I Believed People Thought I Wasn’t Qualified Enough
- Similarly, I Thought People Regularly Think I Wasn’t Qualified Enough to Be a Senior Software Engineer
🔒 When I First Became a Manager, I Believed Everyone was Thinking I was too Young to Be a Manager
🔒 “What Will They Think if I Start Writing Online?”
🔒 I Understand The Effect A Lot Better Now
🔒 Don’t Let the Spotlight Effect Stop you From Doing What You Want to Do
🔒 Last Words

Let’s start!

Early Release: The Multiplier Mindset

Before we begin today’s article, I am happy to share that my book, The Multiplier Mindset: How to Move from Senior Engineer to Tech Leader in the Age of AI, is now available as an early release on the O’Reilly platform.

You can check what the book is all about here, the first 3 chapters + the planned index of the book (not final). Also the cover art is currently in progress, so this one is the generic version.

To check the 3 chapters, I have 100 one-month complementary subscriptions for the Engineering Leadership readers (each worth $49). All you need to do is just fill in this form, and you’ll automatically get the individual subscription.

Get the subscription

You’ll also get access to all the books, including the infamous Designing Data-Intensive Applications, AI Engineering, videos, audiobooks, courses, etc.

Now, let’s dive into today’s article.

What Exactly is the Spotlight Effect?

There are many ways we could describe it, but this explanation resonates most with me:

It’s an effect where we overestimate how much other people notice us, think of us, or judge our actions. We feel like we’re standing under a spotlight on a stage. But in reality, everyone else is busy worrying about their own spotlight.

The spotlight effect comes from a natural bias in perspective (not selfishness). We are the center of our own world, so the brain automatically assumes we’re also more central in other people’s worlds than we really are.

It’s an unfortunate effect that often holds us back from doing something that we’d like to do, due to overthinking of what others will think. Let me share a practical example from an experiment next.

Practical Example From the Experiment Conducted by Thomas Gilovich in the Early 2000s

In this experiment, researchers wanted to test whether individuals really are as noticeable as they believe they are in everyday situations.

Participants, who were college students, were asked to wear an embarrassing T-shirt, most famously one featuring Barry Manilow, who at the time was considered uncool by many students.

After putting on the shirt, each participant was instructed to walk into a room where other students were already seated and working on a task, such as filling out questionnaires.

After leaving the room, the participants were asked to estimate how many people noticed the image on their T-shirt. On average, they believed that about half of the people in the room had noticed it.

However, when the researchers asked the other students in the room whether they had noticed the T-shirt, the results were very different. Only about 20 to 25 percent of the observers actually noticed what the participant was wearing.

The findings clearly demonstrated the spotlight effect: people tend to believe they are the center of attention far more than they truly are. In reality, most individuals are too focused on their own thoughts and concerns to pay close attention to others.

Now that you know and understand the spotlight effect, let me share some of my personal examples from my 12+ career in the engineering industry.

As a Self-Taught Engineer, I Believed People Thought I Wasn’t Qualified Enough

I also believed that people would judge me for not having a degree.

That was especially the case when I didn’t have a lot of confidence in my skill set yet and overall understanding of what I could really bring to the table when joining a company as an engineer.

I remember it like it was yesterday, when I hesitated applying to full-time engineering roles (I had a student job as an engineer at the time), but then I just clicked the button “Send” almost by accident.

Well, it turned out to be one of the best decisions I made, to just click the button, how funny is that!

While it’s true that I wasn’t fully qualified for some roles, much of that doubt existed more in my head than in reality.

This especially turned out to be true when I got my first full-time role as an engineer (you can read the full story of how I got it here). Even though my impostor syndrome was going through the roof, I had a lot of motivation and drive to learn, improve, and do great work.

I’ve quickly got a grasp of the codebase, the projects, and have become productive. And the reality was actually the following: The company, my manager at the time, and people I worked with, really didn’t care about me having a degree or not, they only cared if I was able to do the work needed and if I had potential to grow.

Similarly, I Thought People Regularly Think I Wasn’t Qualified Enough to Be a Senior Software Engineer

At the time I started with my first full-time role, I thought I’d never be good enough to become a Senior Software Engineer, so I always had that in the back of my head.

And even when I actually became a Senior Software Engineer, those thoughts have just become more common. “He doesn’t have a degree”, “He doesn’t have enough experience”, etc.

That’s the kind of thoughts I put in my own head, while others were too busy to think about that, as they had their own problems.

Funny enough, I still go for new things and challenges, even though I have these second thoughts in my head. And the thrill of a challenge is what has shown to prevail over the spotlight effect.

I didn’t know anything about the spotlight effect at that time. I just knew I was motivated and driven when given new challenges.

It would be much worse if my thoughts were the blocker for not actually going for the next step. A similar thing happened when I first became a manager.

When I First Became a Manager, I Believed Everyone was Thinking I was too Young to Be a Manager

Read more

Read more

Intro

Building elite engineering teams is not just about hiring great engineers. It’s about designing the systems that help them succeed: how you hire them, how quickly they get up to speed, and how they grow inside the company.

OpenAI has developed their specific approach across all three.

Their hiring process focuses on identifying strengths rather than forcing every candidate through identical interviews. New engineers are encouraged to ship code early and take ownership from day one. And growth inside the company happens continuously through feedback, impact, and strong judgment rather than fixed promotion cycles.

I recently had the pleasure of speaking with Sulman Choudhry, Head of Engineering, ChatGPT.

This is the second part of the 2-part article based on my conversation with Sulman. Make sure to also read the first part to learn about OpenAI’s engineering culture:

And, in this article, we take a closer look at how OpenAI hires, onboards, develops engineers, and what makes their engineering teams so effective.

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

- 1. OpenAI’s hiring process
- 3 things that make their hiring process different
- They tailor their hiring process based on the candidate
- A new type of interview that has been very successful for them
- They prefer a mix of both very senior and very junior talent
- 2. Growing inside OpenAI
- No fixed cycles for promotions, instead they can happen anytime throughout the year
🔒 What do they look for when promoting an engineer to a lead role?
🔒 3. Onboarding process
🔒 They have a defined 30, 60, and 90-day plan
🔒 2 common mistakes engineers make when onboarding
🔒 4. Knowledge sharing
🔒 5. The difference between an average team and the elite engineering team
🔒 Last words

Let’s start!

1. OpenAI’s hiring process

Their hiring process is fairly standard and similar to what many big tech companies do. It typically starts with a recruiter screening call, followed by technical and behavioral interviews, and then the offer stage.

For more senior candidates, the process may also include additional steps such as executive conversations or follow-up interviews.

The initial screening is almost always conducted remotely. On-site interviews are more common for senior candidates. And they find in-person interviews to be valuable because they give both the candidate and the team a better sense of fit.

Executive conversations and later-stage interviews can take place either on-site or virtually. Overall, the process is fairly standard.

In addition to traditional hiring, the company also brings in talent through acqui-hires and acquisitions of other companies. In those cases, the focus is not only on what teams are building but also on identifying exceptional individuals and maintaining a very high bar for talent.

3 things that make their hiring process different

These 3 things make their hiring approach a bit different from other companies:

1. They are starting to test for AI literacy, though that’s still in a pilot phase.

2. They intentionally design interviews to highlight candidates’ strengths rather than forcing everyone through the exact same process.

3. They encourage calculated risk-taking in hiring.

They want recruiters and hiring managers to take thoughtful risks because those often lead to the best outcomes.

And when a risk doesn’t work out, they focus on accountability and learning from it. That mindset ultimately helps them build a very strong and high-density talent team.

They tailor their hiring process based on the candidate

The part of the process Sulman feels strongly about is tailoring interviews to focus on people’s strengths. When hiring processes are too strict and everyone goes through the exact same interviews, you can miss on strong candidates.

Sulman mentioned a good example: Their iOS codebase is written in Swift and uses SwiftUI. However, many large tech companies still have older codebases built in Objective-C. Because of that, a lot of experienced iOS and macOS engineers are much stronger in Objective-C than in Swift.

They realized they were losing good candidates because they were being evaluated only through Swift interviews. Some of them failed, not because they were weak engineers, but because they didn’t yet have deep experience with Swift.

So they changed the process.

If someone has a strong Objective-C background, they allow them to interview using Objective-C. The goal is to evaluate people based on their strengths. At the end of the day, a good engineer can learn a new programming language quickly.

In fact, some of the best iOS engineers they’ve hired recently are people who might have struggled in a Swift-only interview but performed very well in Objective-C.

A new type of interview that has been very successful for them

They recently introduced a new type of interview. They describe it as a combined product and technical deep dive.

In this interview, candidates are given a problem that is mostly an AI-first, AI-native problem. They are asked to think about the problem and how they would approach building a product around it. There is no prework required.

During the interview, the candidate and interviewers work through the problem together. They discuss what the product specification might look like and what kinds of systems and architectures would be needed to build it.

This format has proven to be a very high signal for them. It helps evaluate a candidate’s intuition about AI models, their ability to collaborate, and their engineering judgment when designing systems and solutions.

Another benefit of this interview is that it works well across different roles. Because responsibilities across teams are becoming more blurred, other functions have also shown interest in using it.

For example, product leadership is considering using the same format when interviewing product leaders.

They prefer a mix of both very senior and very junior talent

In recent years, many companies shifted toward hiring only senior engineers. But, they prefer a mix of both very senior and very junior talent.

Because of that, they invest heavily in hiring new graduates and building a strong internship program. Many interns eventually join the company full-time, and new college graduates also make up an important part of the hiring pipeline.

Another successful source of talent has been very early-stage startups. In many cases, small groups of recent graduates start building products together instead of joining large companies. These teams often bring strong motivation, creativity, and ownership, which have made them very successful hires.

They also rely heavily on personal networks, especially for leadership roles. Leaders are expected to have a strong eye for talent and the ability to attract and motivate great engineers to join their teams.

As a result, many engineers say one of the reasons they joined the company is because their friends are there, or some of the best people they’ve worked with are already there. That network effect has become an important driver of hiring for them.

2. Growing inside OpenAI

The philosophy around performance management is intentionally different from what is common in many large tech companies.

At many companies, performance reviews happen once or twice a year, and a lot of time is spent preparing formal reviews, giving feedback, and making promotion decisions during those cycles.

In contrast, their approach focuses on more continuous, real-time performance management. Formal review cycles sometimes become just a formality or are even canceled because feedback is already happening regularly.

Managers spend time throughout the year aligning on expectations and calibrating performance. For example, they hold regular meetings with their leadership team to review people.

In these meetings, they might discuss engineers who joined in the past 90 days and evaluate how they are performing, making sure they are receiving timely feedback and support.

In other cases, they might review how the most senior engineers in the organization are doing. These conversations help managers stay aligned on performance and expectations across teams.

Much of the performance management happens through regular one-on-one meetings and small calibration sessions rather than large formal reviews.

No fixed cycles for promotions, instead they can happen anytime throughout the year

If someone consistently demonstrates that they are operating at the next level, they can be promoted without waiting for a specific review period.

The overall philosophy is to provide feedback and recognition as quickly as possible.

Rather than relying heavily on large annual recognition programs, the focus is on understanding what matters to each person and recognizing their contributions close to the time the work was done.

This creates a much tighter and more effective feedback loop for them.

What do they look for when promoting an engineer to a lead role?

Read more

Read more

Intro

How do the teams behind ChatGPT actually work?

From the outside, it’s easy to imagine thousands of people, complex hierarchies, and long product roadmaps. In reality, the organization is much smaller and operates very differently from most traditional tech companies.

Teams are highly technical, roles often overlap, and many ideas start from the bottom up rather than from top-down planning. Engineers frequently own problems end-to-end, research and product development happen side by side, and experimentation is a core part of the process.

In this article, we’ll look inside OpenAI’s engineering culture and explore how the teams building ChatGPT are structured, how ideas turn into real products, and what principles guide the way they build AI systems.

I recently had the pleasure of speaking with Sulman Choudhry, Head of Engineering, ChatGPT.

We talked about the structure of the teams building ChatGPT, their process, culture, hiring, growing inside the company, onboarding, and knowledge sharing.

In today’s article, you can expect to read about the structure of the teams building ChatGPT, their process, and culture. And next week, on Wednesday, we’ll go through hiring, growing inside the company, onboarding, and knowledge sharing.

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

- The structure of teams that are building ChatGPT
- They have far more engineers than other roles
- An interesting and unique aspect of how they work
- They hire engineers in two extremes
- They try to create an environment where people can experiment, take risks, and explore ideas
- Turning an idea into an actual product, how do they know when it makes sense?
- Most of the ideas come from the bottom up
🔒 The scaling challenge when something becomes successful
🔒 They don’t work with a detailed roadmap, instead a lot gets figured out in real time
🔒 4 core pillars of OpenAI’s engineering culture
🔒 Variance is a big part of their engineering culture
🔒 Last words

Let’s start!

The structure of teams that are building ChatGPT

A key thing inside the engineering organization that’s building ChatGPT is the clear distinction between horizontal infrastructure teams and vertical product teams.

Horizontal teams focus on shared infrastructure. These are the teams responsible for things like reliability, quality, developer efficiency, and latency.

They try to anticipate infrastructure needs before they become obvious. For example, as ChatGPT has become more multimodal, with voice and video, they hired the author of the WebRTC standard to lead the team responsible for their real-time communication infrastructure.

Vertical teams, on the other hand, focus on specific user problems and metrics. They are organized around experiences or use cases, such as improving the core product experience, building for power users, or developing new model capabilities.

The second important thing is that they try to make teams as end-to-end as possible.

A big lesson Sulman mentioned from building AI-native products is that it’s valuable to blur the line between research and engineering. In many cases, software engineers are directly iterating on models and post-training them.

And sometimes research and engineering even sit within the same team.

Similar to how product, design, and data science used to be grouped together, they have included research in that same team structure. They’ve found this approach to significantly increase development speed and iteration.

They have far more engineers than other roles

Sulman mentioned that the team is much smaller than most people would expect.

For example, in a typical company, the ratio of product managers to engineers might be around 1 to 8. For them, it’s closer to 1 to 30. And in the Codex team, the ratio is even higher: 1 to 40.

One reason for this is that the roles are starting to blur.

Engineers often own problems end-to-end, they help define the problem, write the specs, and build the solution. Product managers sometimes prototype with code, and designers don’t just work in Figma, they also write code.

Because of this, teams are becoming smaller and more unified, almost like a single group rather than many separate functions.

An interesting and unique aspect of how they work

One idea they strongly believe in is letting many ideas develop at the same time.

They hire very smart people, and smart people usually have good ideas. So they try to create an environment where they can experiment and build on those ideas.

They avoid bringing too much structure too early, because that can sometimes kill creativity.

A good example is Codex. When they were building the first version, there were about three to five teams working on the same problem in parallel.

Later, at the right time, they’ve brought those teams together and aligned on one direction. That process helped them move faster and ultimately build a better product.

Another important concept at OpenAI is DRI (Directly Responsible Individual).

At OpenAI, every project has a DRI. But unlike some companies where there’s a separate DRI for design, product, or engineering, their DRI owns the entire project.

They have full visibility, decision-making authority, and accountability for the final result. This structure helps teams move faster and work more efficiently.

They hire engineers in two extremes

They use what people often call a barbell approach.

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.

Tools like Codex have helped make this possible by lowering the barrier to working in different technical areas. As a result, someone who joins as a mobile engineer might quickly become a full-stack engineer and work across the entire product.

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.

They try to create an environment where people can experiment, take risks, and explore ideas

That mindset comes from their origins as a research organization. Even their engineers often work the way researchers do, trying new ideas and seeing what works before formalizing anything.

Because of that, they usually add structure only after they see real potential in something.

Codex is a good example. At one point, three to five different teams were working on the same idea. Some were part of the organization building ChatGPT, and others were outside of it.

Once it became clear that there was a big opportunity, that’s when they created a team fully responsible for it.

This is a common pattern for them:

1. Ideas start informally

2. They get incubated inside existing teams

3. If they show strong potential, they create dedicated teams around them

This approach works well because building something from zero to one is very different from scaling it from one to a hundred.

Early on, you need flexibility and exploration. Later, you need focused teams and more structure.

Turning an idea into an actual product, how do they know when it makes sense?

At a high level, they usually look at two things: breadth and depth.

First, breadth: are enough people using the product? “Enough” is somewhat subjective, but Sulman mentioned that usually, they have a good sense ahead of time of what healthy adoption should look like.

Second, depth: are people actually benefiting from it, and do they love using it?

Beyond usage, they also ask whether the product aligns with their long-term mission and strategy. If it does, it’s something they will be more likely to keep investing in.

So the main questions are:

• Are people using it and finding real value in it?

• Does it align with our long-term goals?

Sometimes a project may not have strong adoption yet, but the idea is still promising, so they continue investing in it. Other times, something may have traction but doesn’t fit their long-term direction, and in that case, they may decide to move away from it.

Most of the ideas come from the bottom up

At the top level, everyone is aligned around one mission: building AGI that benefits humanity and is developed safely.

Leadership usually provides only high-level direction, often in the form of a few key metrics that represent progress toward that mission.

Beyond that, most ideas come from the bottom up.

People who are passionate about a problem area look at those goals and propose ways to move the mission forward. But instead of writing long documents or product specs, the most common way to propose an idea is simply to build something.

Often, someone quickly prototypes an idea and then shares a demo or a short video. That becomes the starting point for discussion:

• Are we excited about this?

• Why does it matter?

• If we go all in on this, what would it look like?

This approach can create some chaos. For interesting ideas, you might have three, four, or even five people exploring the same direction at once. But eventually the work converges, and teams align around the best version of the idea.

Sulman mentioned that around 80% of ideas come from the bottom up, which is a big part of what makes the environment so creative.

The scaling challenge when something becomes successful

Read more

Read more

Intro

Software engineering is changing.

For years, our industry relied on clearly defined roles: frontend, backend, QA, DevOps, manager, and architect. Titles were clear, and responsibilities (depending on the company) have been decently defined.

But that clarity is now fading.

Today, companies care less about your title and more about your impact. Engineers are expected to think about the product and business. Managers are expected to be more hands-on. The boundaries are blurring more and more.

With better tools, AI-assisted engineering, and smaller teams, versatility is becoming more and more expected. Software engineering is becoming position-less → and that shift is changing what it means to be valuable.

In today’s article, I am sharing what makes you a valuable engineer/engineering leader at this time, and also what you should do to be successful and have many opportunities moving forward!

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

- The trend of position-less basketball
- The trend of position-less software engineering
- We can already see this shift happening with the engineering roles getting closer together
- This trend is just going to be more and more popular
🔒 Both really great generalists and specialists are multipliers
🔒 With specialists, the focus is a lot more on a deep understanding of a relevant topic
🔒 Both are valid paths to take
🔒 Last words

Let’s start!

The trend of position-less basketball

I am a big fan of basketball and have been since I was a child. I also played a lot of basketball over the years, and I have always enjoyed watching games, both national team games, European, and NBA games as well.

Last year in April, together with my family, we went to see the Lakers game in LA and also the Warriors game in San Francisco. We had a great time.

I’ve been watching basketball now for close to 30 years, and I’ve seen how the game has changed over the years. In the 1990s and 2000’s, there was a big focus on Centers, where every team was looking to get a great center, and the focus was a lot more on the post game + mid-range shots.

At the beginning of the 2010s, the game became a lot more focused on 3-point shots and layups, where teams started to avoid mid-range shots, and players got penalized by coaches if they attempted them.

And now in 2020’s, the game has become a lot more position-less. There’s a trend of having great “generalists” on the basketball team, who can do everything on the floor, from rebounding, scoring 3-point shots, handling the ball, and passing on a high level as well.

While at the same time, specialists are very important. Players who can score 3-point shots on a very high percentage and also play defense on a very high level. Because they have special assignments that contribute to the team’s success.

Now that we understand the basketball side better, I promise, I’ll make the analogy to software engineering quickly!

The trend of position-less software engineering

Here’s how the evolution applies to software engineering.

In the 1990s and early 2000’s, there weren’t a lot of different positions as we have today, there were more or less testers, analysts, and programmers. And in many cases, programmers did everything, as mostly Desktop GUIs (Windows, Mac, UNIX) and command-line interfaces were built.

In the late 2000’s and early 2010’s, we’ve seen a big change in how software is built, especially when web applications became a lot more popular. And with the invention of AngularJS in 2010, there was a huge need for engineers to be more proficient in JavaScript, and so the frontend and backend separation became a lot clearer.

QA engineers gain popularity as well, and automated testing started to get traction, as before, there were more or less just manual testing.

Then of course, agile methodologies became popular, so the roles such as Scrum Master, Delivery Manager, and also engineers specialised a lot more in different technologies and languages.

And now, with the tools getting better and better for developing software, and of course, AI being more and more popular, and AI-assisted engineering being the best way to build software, we can see the shift in software development changing.

Companies are looking for multipliers who can provide impact, instead of just engineers knowing a particular programming language (already expected).

Similar to basketball, engineers are expected to be good at many different things. I like to call such engineers generalists, and then there is also a need for people with specific knowledge, who can also think outside of the box.

But the way I see it is that companies need the majority of the engineers to be really great generalists, while in a minority to be extreme specialists, who think outside of the box.

So, for this reason, positions are becoming less and less clear, as generalists can do so many things well, and with tools getting better and better. And then, of course, specialists working on special assignments and providing their unique point of view.

We can already see this shift happening with the engineering roles getting closer together

For middle managers, e.g., (Sr.) Engineering Managers, it’s becoming more and more common to be expected to take on Staff Engineer roles if needed, and Staff+ Engineers taking on manager hats if needed.

And the same for Architects as well → taking on a Staff Engineer role or manager role if needed.

This has shown to be very true, especially when Amazon started its initiative of increasing the ratio of managers to individual contributors by 15%.

And when a Big Tech company does something, we often see an effect where a lot of other companies are doing a similar thing. So, many other companies have done a similar thing, which ultimately added more expectations and “multiple hats”.

So, that’s why we are seeing a lot of managers taking more of a hands-on work and also Staff Engineers and architects taking, in some cases, also a manager role as well.

2. And also a similar trend for PMs and Engineers.

The role “Product Engineer” is getting more and more popular, and being product/business-minded is just going to be more and more important for all engineering roles.

I am seeing a lot of startups and mid-size companies hiring for product engineers. A good example is Lovable, one of the fastest-growing startups in the EU, which is hiring product engineers who own the why, what, when, and also the how.

And only recently, they have started to look for their first product managers.

And very similarly goes for OpenAI as well, their engineers are owning projects from idea to execution and focusing on things such as distribution and user testing.

The OpenAI’s Codex team has only 1 product manager and 2 designers, while everyone else is an engineer in the 40-person team. Engineers are automatically expected to have the product/business mindset.

This trend is just going to be more and more popular

We can already see that some of the popular AI companies are using titles like “Member of technical staff” for engineers, leads, researchers, etc. It matters less and less about the title, but all about the impact.

And also, I recently had the pleasure of talking with Sulman Choudhry, Head of Engineering, ChatGPT. He mentioned that OpenAI likes to hire engineers in 2 extremes:

1. Really great generalists

2. Experts in a really specific thing who think outside of the box

Which is exactly what we are talking about today.

Similar to basketball, the same is being the case with software engineers. Position-less software engineering with the focus on great generalists and specialists is becoming the norm, in my opinion.

Both really great generalists and specialists are multipliers

Read more

This week’s newsletter is sponsored by Redis.

AI Isn’t Slowing Down. But the Constraint Is Shifting.

Redis has forecasted that the next wave of AI failures won’t come from weak models, but from poor context engineering. Getting context engineering right will be a make-or-break for companies building AI apps: reducing latency, controlling cost, and enabling scale.

Their 2026 predictions break down what engineering leaders must prepare for:

• Agents won’t struggle with reasoning. They’ll struggle with finding the right data.

• Agent frameworks that stay open, extensible, interoperable, unfussy, will be the ones that stick.

• Everyone will become a coder, and the volume of apps will spike.

Before latency and cost become the constraint, read the 2026 predictions.

Read the full predictions

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

Intro

AI is no longer just a tool engineers use, but it’s also heavily influencing how engineering teams are structured, how decisions are made, and how software gets built.

I’ve seen this especially in startups and mid-size companies trying to adjust the engineering org structures by creating AI-native engineering teams, but in my opinion, few teams have truly embraced it like OpenAI’s Codex team.

Behind products like the Codex app, IDE extensions, and the open-source coding agent is a relatively small group of around 40 people operating with an unusually high level of autonomy, speed, and trust.

Their work spans from low-level systems engineering, large-scale distributed infrastructure, product design, research, and user-facing experiences, and in all of the work, they heavily utilize AI.

What makes the Codex team especially interesting isn’t just what they build, but how they work. They’ve embraced AI as a core layer of their workflow: from planning and onboarding to code review, testing, and prioritization.

It’s a team with minimal hierarchy, very few meetings, and a single product manager to move at a pace that would otherwise seem unrealistic.

I recently had the pleasure of speaking with Thibault Sottiaux, Head of Codex.

And this is the second part of the 2-part article. Make sure to also read the first part to learn about what exactly AI-native teams are and how to build them.

And in this article, we’ll go through how OpenAI’s Codex team works and leverages AI → their team structure, development philosophy, use of Codex internally, and the lessons other engineering teams can apply as we move toward an AI-native future.

Let’s start!

The Codex team is around 40 people

And inside the team, there are many smaller teams that work on different projects, some including: Open-source coding agent, Codex IDE extensions, Codex app, and others.

They run with a strong emphasis on empowerment and local decision-making. It’s closer to a modern version of Bell Labs.

Individuals are trusted to make decisions because the pace of change demands it.

The Codex team has 1 Product Manager for the whole team, 2 designers, and others on the team are engineers with various expertise.

Here is an example that Thibault has mentioned of how effective their PM is.

How their PM works very effectively

The Codex team is effectively run by a single product manager. The PM has scaled himself into something like a 100× PM by using Codex. Watching him work is unreal, it’s on another level.

He uses Codex to dig through user feedback, triage issues, and prioritize work in real time. During a one-hour bug bash session recently, the whole team was testing the app and logging issues. As the issues came in, the PM was instantly categorizing them, setting priorities, and assigning them to owners.

They went through over 100 issues in that single hour, and most were fixed within 24 hours. That kind of speed and coordination came from the PM’s planning and decision-making, but it simply wouldn’t be possible without AI.

The work they do and the profiles of engineers working on the team

A lot of the work is low-level systems engineering, mostly with Rust.

The work is done on the Codex harness, which is an internal software framework and runtime logic that powers the Codex AI coding agent, essentially the part of the system that orchestrates how Codex behaves, interacts with users, and runs tasks consistently across different interfaces.

And then there’s work on the open-source repo, Codex CLI coding agent, a tool you can run locally to help with coding tasks directly from your terminal.

On top of that, there’s backend infrastructure that connects the GPUs to the systems that run the models.

They also work on the Responses API, which is the core API interface for generating model outputs which is also how Codex talks to the models to do things like read files, run commands, or analyze code.

On top of that, they’ve built their own backend that handles the authentication, usage tracking, and sending requests and responses back and forth, so everything works reliably at scale. It’s a large distributed systems effort, and the team maintaining it is on on-call duty.

Then there are frontend and full-stack engineers building all their user-facing experiences where people actually use Codex.

They also have research profiles on the team, who work on various research to ensure the best OpenAI models are created.

Development process

They start with an overall strategy, and from there, the focus is on inspiring people and giving them the autonomy and ownership to do their best work, while still holding them accountable.

The most successful projects usually come from very small teams, often just two or three people. Sometimes an entire feature is built by a single engineer who owns everything end-to-end:

• planning, implementation,

• launch, positioning, communication,

• and then iterating based on user feedback.

That kind of full ownership is strongly encouraged on the Codex team. Most ideas also come bottom-up, driven by people on the team getting excited about trying something new.

They also work very closely with research teams. Often, they’re inspired by new research directions or things they know are coming, and they build ahead of time, whether that’s foundational infrastructure or new product experiences.

It’s overall a very creative process for them. No one has fully figured out the right way to supervise and steer agents yet, and the Codex app is just one expression of their thinking.

Their process also contains a lot of experimentation and ideation. Not everything ships, but people are encouraged and rewarded for exploring new ideas, and they only launch the very best ones.

They keep things very lean and minimize meetings as much as possible

When meetings do happen, they’re usually spontaneous and driven by real needs. The office is set up to encourage in-person collaboration, and the leadership team makes itself extremely available so issues can be resolved in minutes or hours at worst.

They make decisions very quickly. The cost of making mistakes is much lower because Codex is always available. They can try things, observe what happens, and change course fast if needed.

As a result, they optimize heavily for speed and velocity. A lot of the processes that worked a few or even two years ago just don’t scale anymore, so they’ve essentially reinvented how they work.

The onboarding buddy for new engineers on the team is Codex

This is what I have already mentioned in the article: How to Build AI-Native Engineering Teams.

Thibault shared that Codex walks new hires through onboarding, sets up their entire computer, and helps them understand the codebase, projects, and existing features. It basically acts like a highly skilled engineering mentor.

From initial setup to being productive, most of the onboarding process is handled by the AI tool. As a result, onboarding is much faster than it used to be.

At OpenAI, they also have a strong culture of shipping on day one. It’s really important for every engineer to provide value as soon as possible.

Normal traditional teams have the goal to ship code to production within the first week. In their team, that should be on the first day.

With that kind of culture and systems in place, new hires can arrive with no prior context, quickly understand the system, and ship meaningful features on their first day.

Now, let’s go to the part on how they leverage AI to be productive.

How Codex team uses AI

Read more

Intro

AI is changing how software is built at a pace most organizations aren’t prepared for, especially larger companies.

Smaller companies tend to adjust more quickly, but larger companies require more time to adopt new processes or implement significant changes.

One thing I am seeing across small to mid-size companies is that AI usage is a lot more common. That’s also where the term “AI-native teams” has come up.

In today’s article, we are going through all about what it actually means to build an AI-native engineering team.

Not teams that simply add AI tools on top of existing processes, but teams that rethink how work gets done from the ground up.

We’ll look at how the most effective teams operate today, which skills matter most, how leaders should adapt, and what practical changes make the biggest difference when building fast, high-impact engineering organizations in the age of AI.

To help us with this, I had the pleasure of speaking with Thibault Sottiaux, Head of Codex.

We talked all about AI-native engineering teams, his advice for engineering leaders building such teams, and also how the Codex team works, their process, and how they leverage AI to be successful in their work.

In today’s article, we are focusing on AI-native teams and on Sunday’s article there’ll be a deepdive on the OpenAI’s Codex team, how they work, their process and how they are leveraging AI, so make sure to not miss the Sunday’s edition as well!

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

- What does “AI-native” actually mean in practice for an engineering team?
- The most effective AI-native teams tend to be very small
- Most important skills for engineers in AI-native teams
- Ownership and accountability is crucial
- Meetings should be kept at the minimum
🔒 AI tools are the new onboarding buddy for such teams
🔒 When such teams can move so fast, it’s really important to build proper guardrails
🔒 Advice for engineering leaders building AI-native engineering teams
🔒 Last words

Let’s start!

What does “AI-native” actually mean in practice for an engineering team?

An AI-native team is, above all, nimble and adaptive. Models and tooling are evolving so quickly that teams must continuously reinvent how they work, almost weekly, in order to keep finding and eliminating productivity bottlenecks.

And being AI-native goes beyond simply using AI tools. It means continuously identifying and eliminating bottlenecks across the entire software engineering lifecycle.

That means questioning everything:

• Planning, strategy

• Prioritization of features, bugs

• Code generation, code review

None of it is sacred, and everything can and should be continuously improved.

What AI-native teams do well is: identifying where work slows down and applying AI to remove those bottlenecks.

The most effective AI-native teams tend to be very small

Teams of 3 or 4 people, with strong collaboration, can move really fast, and in creative ways, which outperform much larger groups.

A good example is Sora, which went from the first line of code to public release in 28 days with 4 people. Similar to Atlas and the Codex app as well.

The Codex app team, for example, is remarkably small, fewer than 3 core contributors, yet it operates with a really high output and impact.

The full Codex team is around 40 people working on different projects, some including: Open-source coding agent, Codex IDE extensions, Codex app, and other projects.

They run with a strong emphasis on empowerment and local decision-making. It’s closer to a modern version of Bell Labs.

Individuals are trusted to make decisions because the pace of change demands it.

Interestingly, the Codex team has 1 Product Manager for the whole team, 2 designers, and others on the team are engineers with various expertise.

An important thing for all the engineering leaders → you cannot become the bottleneck. It’s a must that you design the organization + adjust yourself as well, so that speed, autonomy, and experimentation are built in by default.

I’ll be sharing a lot more details on how the Codex team works, their process, and how they leverage AI to be successful in their work in the article that will go out on Sunday. Make sure not to miss it!

Most important skills for engineers in AI-native teams

Some of the most important skills haven’t really changed, AI has just made it more obvious. Critical thinking and strong technical fundamentals are still essential traits for engineers.

What’s becoming more important is adaptability.

Deeply optimizing a single setup or workflow over many years, like mastering one editor configuration, is no longer a real advantage. Engineers need to be willing to try new tools, adopt new workflows, and continuously adjust how they work.

Another skill that’s clearly rising in importance is empathy. Being able to understand users, ask the right questions, and decide which problems are actually worth solving matters more than ever.

When you combine adaptable workflows with strong user empathy, you get engineers who are dramatically more effective.

AI and tools like Codex are leveling the playing field. They give everyone on the team the ability to be highly productive. As a result, the real differentiator is no longer raw output, but who is solving the most meaningful problems.

Going forward, people skills and problem-solving abilities are what truly set engineers apart.

Ownership and accountability are crucial

Engineers are empowered to own the full projects from start to finish. They initiate the ideas of what would be great projects to work on, and then they take full ownership and accountability for finishing them successfully.

And also very importantly, continuously improving them!

On the Codex team, they always have people work together on projects, as there’s a lot of exchange of ideas that way.

They found that people get much more excited to solve problems together, and it also helps when you have more ideas, and diversity of people who might know a certain field a bit better and share their knowledge across the team.

Meetings should be kept to a minimum

Meetings should be done more or less to align on things to ensure that people work together efficiently. In the Codex team, they like to utilize their office space to meet and align, and also work together on specific things.

No daily meetings, retrospectives, sprint planning, etc. Everything is optimized to ensure that people can get as much work done as possible → fewer interruptions, more focus time.

And the focus should be on the impact. As I always like to say:

When you trust your people and empower them, in many situations, you’ll be surprised by what kind of amazing things they’ll come up with.

AI tools are the new onboarding buddy for such teams

Read more

Read more

Intro

AI is definitely transforming the way we work, communicate, and make decisions. We use it daily for many different things, both personally and professionally.

However, with every good thing, there are also downsides. And one of the downsides is the tension that AI creates between different groups of people, especially technical and less technical.

In today’s article, I’ll share 3 real-world examples of the tension I am seeing, and I’ll provide tips on how to communicate the right way, so there won’t be any friction or resentment on both sides.

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

- 1. Unrealistic expectations from executives to engineering leaders
- My advice to resolve such tensions
- 2. Product Managers Underestimating the Effort <> Engineers Providing Huge Timelines
- Put yourself in their shoes
🔒 My advice to resolve such tensions
🔒 3. Engineers That Focus on Speed and AI Tools <> Engineers That Rarely Use AI Tools
🔒 My advice to resolve such tensions
🔒 Last words

Let’s start!

1. Unrealistic expectations from executives to engineering leaders

Let’s start with the first tension I am seeing, and that has been especially common in mid-to-end 2025. From my experience, it’s now getting a bit better, but I can see or hear a lot of unrealistic expectations in current times as well.

Here are some of the unrealistic expectations I have heard:

• Believing AI is a “Plug and Play” solution

• Expecting AI to eliminate all manual work

• Underestimating the cost and complexity of building internal LLMs

• Assuming AI will just magically understand the whole context of the specific domain

• Expecting AI to replace entire teams

• Assuming AI will just work without failures

• Thinking that there are no ethical, legal, and security risks

• Assuming AI will exponentially increase the performance over time

Such expectations automatically create friction because there is a clear misalignment between what actually can be achieved and the expectations.

My advice to resolve such tensions

1. My advice to executives

• It all starts with setting the right goals and not letting FOMO (fear of missing out) get to you

Instead of: “We need to use AI for everything, or we’ll fall behind” → Define what actual business problems are or what actual inefficiencies in the process currently exist, then evaluate if AI is the best tool.

• Don’t try to do a full-scale “AI transformation” all at once

I rather recommend doing small experiments, trying out different tools, and seeing how things are going. After you see it working well, you can use a certain tool on more important parts.

• Focus on creating a good culture

There is no better productivity hack than a good culture. No AI can replace that. If you try to lead with fear → it will backfire in the long term.

2. My advice to engineering leaders

• Make sure to educate yourself on how others are utilizing AI tools

These two articles will help with that:

• Be confident and manage expectations correctly

Especially when executives inside the company are experiencing FOMO regarding AI, it’s really important to stay composed and not get rattled.

Make sure to educate, provide pros and cons, and don’t just go straight to saying yes to requests like “We need to start using this AI tool, or we’ll fall behind”.

These articles will help:

2. Product Managers Underestimating the Effort <> Engineers Providing Huge Timelines

This tension has been part of the engineering industry for quite a while, but now with AI being more and more popular, it has just increased further.

The tension is that one side is being overly optimistic, and the other side is being overly pessimistic. The goal should be that both sides work together to find the best scenario for the team.

Here are some of the phrases I have heard (from PMs):

• I’ve created this app in Lovable, just copy & paste this code

• Here is the prompt. Just run it in your codebase, and we should be good to go

• I’ve used Claude Code and was able to build this feature in minutes

Here are some of the phrases being too pessimistic (from engineers):

• This is not possible

• This will take 3-6 months to finish

• Ahh, this is too complex

Put yourself in their shoes

For both engineers and product managers, it’s really important to try to put yourself in the position of the other and ask yourself: “How would I feel if I were on the other side?”

This is crucial because if you look at it from both perspectives, you can see what their pain points and challenges are, and you can better understand why they might be saying that. Let’s go through them:

• Product managers

A lot of product managers these days are also dealing with quite unrealistic expectations (similar to what I mentioned above for engineering leaders). Often, they are working around tight deadlines, and some are expected to make miracles happen in a short amount of time.

Such expectations put product managers in a weird position where they are forced to utilize different tactics to speed up the delivery. And the problem comes especially with less technical product managers, who may have a bit of an optimistic view on how engineering really works.

• Engineers

We’ve all been bitten by being too optimistic, so that’s the reason why a lot of engineers put the estimation to be a lot more pessimistic than it should be.

This is what has happened quite a few times to me personally:

And also at the same time, as engineers, we are proud of what we do, and if someone (especially a less technical person) tries to tell us that something can be done a lot faster than it is possible, it hurts our pride.

But the important part, as I mentioned above, is to have mutual understanding. Engineers need to understand the pain points of product managers, and product managers need to understand why saying something might not be the best thing to say.

My advice to resolve such tensions

Read more

Read more

Intro

Last week, together with , we did a deepdive on the importance of building a good relationship with your manager and also how to do it. If you haven’t read it yet, I highly recommend doing so:

Today, we are going a level deeper, we are going through the importance of building good relationships across the organization and also externally with people.

To be more precise, we’ll talk about social capital. What that is, why it’s very important, how to build it + what makes it so important if you want to grow in your career.

It’s especially a crucial concept to understand for engineering leadership roles or if you wish to grow into a leadership role.

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

- Financial Capital vs Social Capital
- What Exactly is Social Capital?
- Yes, You Should Care About It as an Engineer or Engineering Leader
- The Concept of Building and Using Your Social Capital
🔒 How to Build Social Capital?
🔒 1. Make Yourself Approachable
🔒 2. Proactively Help Others When You Can
🔒 3. Talk With People Even if it’s not Necessary
🔒 4. Credibility, Being Human, and Social Proof
🔒 Last words

Let’s start!

Financial Capital vs Social Capital

Often, in our industry, we hear things such as “X company is offering a total compensation of Y for that specific role”, or an engineer is saying that they are making X amount of total compensation (Financial capital).

While how much you make is very important, there is also another type of capital that is crucial, and that is social capital.

Without it, you won’t be able to get your initiatives accepted, even if you have all the reasons for them to be so. As I like to say:

It’s not only about WHAT and WHY when it comes to ideas, but WHO initiates the idea is crucial.

Managers or stakeholders will only accept ideas where they believe that the risk versus reward ratio is more tilted to the side of the reward.

Unfortunately, ideas coming from people with low social capital will be seen as a lot more risky in comparison to people who have high social capital.

Let’s define what exactly social capital means next.

What Exactly is Social Capital?

We can define it in many different ways, but we’ll make it practical for our use case. I like to refer to social capital as a value that comes from relationships.

It’s the benefits you get from who you know, how well you trust each other, and how connected you are.

The more people you know and the higher your trust level + the better overall relationship you have with them, the higher your social capital will be.

The higher your social capital in your organization, the easier it will be for you to get ideas and suggestions to be accepted.

An example of a Software Engineer 1 with high social capital:

• Technically competent (not necessarily the best coder)

• Regularly helps colleagues debug issues

• Communicates clearly with PM, manager, and other teams

• Mentors junior engineers

• Active in internal Slack channels and occasional tech meetups

• Trusted by managers and peers

An example of a Software Engineer 2 with low social capital:

• Technically strong engineer

• Works mostly independently

• Rarely communicates outside assigned tasks

• Avoids meetings and informal discussions

• Doesn’t help others unless asked

• Has little visibility with leadership

• Not active in any communities

The key thing to understand is that despite strong technical skills, weak relationships and low visibility limit influence and opportunity.

Yes, You Should Care About It as an Engineer or Engineering Leader

As I mentioned at the beginning of this article, as an engineering leader, you should care about it a LOT more, because your work highly depends on how good of relationships you have been able to build across the organization.

You mostly get things done through others, and with low social capital, you are not able to do that.

At the same time, for engineers, it’s also really important, and it’s going to be just more and more as time goes on.

I’ve mentioned this before in some of the previous articles that relationships are the #1 important thing at work, and if you are able to build good working relationships, it can really make a big difference in your day-to-day.

Many engineers tend to focus a lot more on technical skills, while totally neglecting the aspect of social capital, and that tends to be the #1 mistake of why they don’t get promoted or worse, can mean why they get laid off.

Let’s go through a very important concept next, building and using social capital.

The Concept of Building and Using Your Social Capital

When you help others and when you are talking with others and building relationships, you are increasing your overall social capital. But then at the same time, when you need help or when you need a favor → you are using your social capital.

It’s all about balancing giving and taking. If you always take, you tend to completely lose your whole capital, and people won’t be happy to help and support you.

At the same time, you won’t be able to influence decisions or get your ideas accepted if you don’t give first and provide value to people.

So, this is my recommendation: focus on giving first, and people will be a lot more prone to returning the favor.

Now that we understand what social capital is and how important it is for both engineers and engineering leaders, let me share my top tips for building your social capital.

How to Build Social Capital?

Read more