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

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

Engineering Leadership LIVE is an evening for that conversation.

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

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

Secure your spot at the event

Looking forward to seeing you there!

Gregor

This week’s newsletter is sponsored by Codacy.

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

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

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

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

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

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

Control the AI in your repos

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

Intro

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

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

• How they multiply others

• What makes them successful

• How they use AI

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

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

Let’s introduce our guest author and get started.

Introducing Anton Zaides

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

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

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

The 5 areas of responsibility

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

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

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

• Product building

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

• Team support

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

• Customer support

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

• Technical direction

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

• The team’s future

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

Focusing on things that the team needs most

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

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

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

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

My current EM role is very different.

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

My time is better spent focusing on two other areas:

• The engineers themselves

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

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

• Customer support

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

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

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

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

How to be a truly product-minded EM

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

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

I divide being product minded into three parts.

1. Product involvement

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

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

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

To get access to customers:

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

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

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

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

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

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

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

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

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

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

2. Business understanding

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

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

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

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

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

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

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

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

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

3. Extreme dogfooding

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

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

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

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

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

Build a team that doesn’t depend on you

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

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

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

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

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

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

There’s also advocacy.

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

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

My approach to AI adoption

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

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

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

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

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

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

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

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

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

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

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

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

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

Using AI personally

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

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

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

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

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

Final advice for engineering leaders

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

• Stay a part-time engineer

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

• Become product oriented

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

• Get to know the people you work with

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

Last words

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

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

Feedback or addition? Make sure to 💬 comment.

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

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

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

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

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

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

Get in touch

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

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

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

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

Check the benefits of the paid plan

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

Intro

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

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

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

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

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

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

Let’s start!

What is a forward deployed engineer?

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

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

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

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

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

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

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

Why the role exists

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

They help:

• Increasing adoption of the product

• Customize implementations for specific customers (if needed)

• Gather feedback from customers to improve the product itself

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

What a forward deployed engineer at Salesforce does

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

Help customers get value from technology faster.

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

• What systems are already in place

• Where customer data lives

• How that data flows across systems

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

Example use cases:

• Adjusting the data flow

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

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

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

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

• Implementing the right guardrails for the customer

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

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

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

1. Salesforce FDEs (internal)

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

• Gather feedback on product features

• Test new features in live environments

• Help improve the product

2. Partner FDEs

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

• To deliver specific implementations for a customer

• Provide direction or solution design

• Have support from Salesforce FDEs

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

What a forward deployed engineer at OpenAI does

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

FDEs are expected to:

• Design, architect, and develop full-stack solutions

• Build production AI systems and integrations

• Deploy advanced AI models on customer infrastructure

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

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

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

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

What a forward deployed engineer at Palantir does

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

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

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

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

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

FDEs need to address questions like:

• What products are we deploying for this use case?

• Why are we deploying them?

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

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

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

Should you become a forward deployed engineer?

Read more

This week's newsletter is sponsored by Postman.

The ROI of AI-Native Engineering

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

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

Download the report to learn:

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

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

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

Get the report

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

Intro

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

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

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

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

In this article, we’ll go through:

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

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

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

1. Salesforce Bets on AI Agents

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

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

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

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

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

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

Headless 360

The subtitle on the announcement page says it all:

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

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

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

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

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

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

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

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

Agentforce Vibes

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

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

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

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

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

Agentforce

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

• open-sourcing Agent Script

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

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

• ADLC (Agent Development Lifecycle)

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

• Agentforce Labs

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

2. 3 Key AI Trends From Salesforce AI Research Team

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

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

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

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

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

Simulation environments

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

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

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

A big part of this is synthetic data.

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

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

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

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

Ambient Intelligence

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

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

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

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

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

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

Agent-to-agent communication

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

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

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

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

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

Quoting from the study:

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

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

3. How Salesforce Engineers Use AI to Build Their Products

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

Let’s get to the first example.

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

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

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

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

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

Planning is where they use AI a lot

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

It asks simple questions, like:

• What do you want to build?

• How should it work?

• What are the requirements?

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

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

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

The main idea is simple:

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

Code quality and creating tests

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

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

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

They run this tool at different stages:

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

• when the PR is opened, it will run automatically

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

This helps catch problems early.

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

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

Observability is an important use case for AI

They have a tool called Scale Center.

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

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

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

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

It can also help fix issues (with AI):

• find the root cause

• explain what went wrong

• suggest a fix

• create a PR with changes

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

Every engineer can use AI tools that work for them

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

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

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

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

Last Words

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

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

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

Feedback or addition? Make sure to 💬 comment.

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

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

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

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

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

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

Get in touch

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

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

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

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

Check the benefits of the paid plan

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

Intro

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

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

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

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

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

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

Community chat

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

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

• Connect with everyone

• Special opportunities

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

Join the community chat

Let’s start with today’s article!

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

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

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

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

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

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

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

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

US companies tend to innovate a lot more than EU companies

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

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

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

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

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

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

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

Let’s go to the next one.

EU companies are a lot less prone to taking risks

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

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

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

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

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

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

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

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

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

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

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

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

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

Read more

This week's newsletter is sponsored by Atono.

Your engineers are moving faster. Are they building the right things?

Atono surveyed 350 engineering professionals to find out where AI product development actually breaks down. The problems weren’t primarily about tooling, resourcing, or engineering capacity.

They were upstream, in planning, in how product knowledge is shared, and in the gap between what product teams decide and what engineering teams receive.

The Context Gap Industry Report breaks down exactly where teams lose velocity and where engineering leaders can get it back.

In the report, you’ll find:

• Why 52% of teams have no shared AI context, and why larger orgs are significantly worse

• How planning ambiguity silently doubles the cost of development work

• Why AI adoption at the code layer, without clarity at the planning layer, mostly accelerates rework

• What the teams with the least rework are doing differently

If you’re responsible for delivery across one or more teams, this report shows where the real leverage is.

Download free report

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

Intro

Just got back from the trip in San Francisco, where I talked with different companies/people and also went to the Salesforce TDX conference. Will be sharing some of the insights from my conversations in upcoming articles.

I’ll be coming back to SF in May as well, so definitely feel free to reach out if you want to meet!

One of the companies I had the pleasure to meet and get to know was Weave.

I had the pleasure of meeting with them at their office, which has a clear “hacker” vibe, especially since other startups share the space as well, and it feels like a big group of people all working and building cool stuff.

Most of the time, I spent talking with Andrew Churchill, Co-Founder & CTO, and Adam Cohen, Co-Founder & CEO. And also been in touch with Brennan Lupyrypa, Founding GTM Engineer, for quite some time.

Today, I am sharing insights on how they work and build their product.

Let’s start!

They are building an engineering intelligence platform for the AI era

They’re a seed-stage startup with a team of 10, growing to 13 or 14 soon. The new hires over the next month will all be engineers. They all work in-person in San Francisco, typically five (or more) days a week.

They are building a platform that analyzes what engineers do, how much work gets done, its quality, and how effectively AI is used, then helps teams use those insights to make better decisions and improve.

Their tech stack is straightforward: frontend in React and TypeScript, backend in Go, and ML and agent work in Python.

One of the more advanced areas they’re working on is training their own models to analyze engineering work. They build on top of open-source LLMs and apply fine-tuning and reinforcement learning to improve them.

The main tools they are using

• AI coding tools

Their main development workflow is split between Cursor and Claude Code. Some engineers use one, some the other, it’s mostly a matter of preference, and people switch over time.

Both tools are great from their pov, and the team focuses on building shared skills and context that work across both.

They haven’t built their own coding or background agents, since it’s not the best use of time at their current stage. Instead, they’ve focused on 2 high-impact internal tools.

• 2 self-built internal tools

One is a CLI that gives access to their full local development environment, where engineers can easily handle tasks like running migrations or connecting to staging without needing extra help.

The other is an internal admin dashboard. They initially used Retool, but moved away from it to build their own solution directly in their app. This allows both technical and non-technical team members to quickly access data, troubleshoot issues, and make changes, like toggling features or enabling paywalls, without involving engineers.

This internal dashboard has been a major productivity boost for them. It enables self-service across the team, speeds up debugging, and is easy to iterate and add more things when needed.

• PM/Doc tools

They use Linear as their main task backlog and prioritization tool. Roughly 60% of work is tracked there, but not everything, as speed is a core priority for them, so if something can be done immediately, they just do it without creating a task.

Linear is mainly used for work that isn’t handled right away, and they often tie customer requests to those tasks.

They also make use of Linear’s integrations, for example, turning Slack discussions into tickets without needing to open the UI. Overall, Linear is their closest thing to a full task tracking system, but they intentionally keep it lightweight.

They also use Notion, though not much for engineering. They prefer keeping documentation close to the code rather than in a separate tool, since it’s easier to maintain and more accessible for their AI agents.

Their process for building a new feature from 0 → 1

For more complex work, they usually start with a quick 30-minute discussion. They’ll gather, sketch ideas on a whiteboard, and align on the initial approach, what the MVP looks like, who the first users are, and how they’ll validate and iterate.

Their engineering team is small, so most projects are owned by a single person. Even when multiple people are involved, the work is typically split into parallel, loosely connected streams rather than tightly coordinated efforts.

From there, they try to move quickly and focus on shipping early. Features are released behind flags, often tested internally first since they’re building for engineers and use the product themselves every day. This allows them to quickly assess whether something is actually useful.

If a feature is driven by a specific customer request, they’ll build it and share it early with that customer, even if it’s rough, and iterate rapidly based on feedback until it’s ready for broader release.

They avoid heavy upfront planning. They rarely write detailed specs or PRDs, and instead rely on clear direction, high ownership, and fast iteration to get to the right outcome.

Engineers are highly empowered to build things they believe will be useful

Many features start as small “side projects” rather than formal initiatives.

For example, their internal dashboard wasn’t planned as a dedicated project, it evolved gradually alongside other work, as a side quest, done with agents running in the background with occasional check-ins in between other main tasks.

This same pattern applies to other features. Iterations, experiments, and smaller improvements often come from individual initiative.

Another example that Andrew has mentioned is a custom dashboard feature that emerged because an engineer took a strong interest in it, built it in parallel with other work, tested it with a few users, and then rolled it out more broadly.

Overall, important features don’t always start as top priorities for them, they often grow organically from engineers exploring and iterating on ideas they see as valuable.

How do they decide what to build vs what not to build?

They run a weekly session to review everything that’s come through. During these sessions, they decide what matters most and ensure the highest-priority items are aligned with what engineers are working on.

They also use this time, along with occasional longer discussions, to set a broader direction. This includes identifying key bets, understanding where the product is headed, and incorporating customer feedback.

The goal is to keep the most important initiatives consistently at the top of the priority list.

Compared to more traditional workflows, this process is much more lightweight and frequent. In the past, similar alignment might have happened monthly or quarterly because planning and execution were more expensive.

Now, because AI tools allow them to move much faster, alignment happens weekly to keep pace with rapid iteration.

This flexibility works because engineers aren’t blocking everything else to pursue a single idea. Instead, they can explore multiple ideas in parallel, so new ideas can be tested without disrupting core priorities.

They are very anti-meetings, especially for engineers

Long gaps between meetings make it hard to focus, so they avoid interrupting deep work whenever possible.

The only meeting they have is a daily stand-up at 9 AM with the whole company attending. It helps keep everyone aligned and moving in the same direction.

For project planning or kicking off a new project, they’d usually spend around 30 minutes after the stand-up meeting to avoid breaking up focus time.

Most day-to-day collaboration happens informally. Engineers sit together in the same area, making it easy to quickly turn and discuss things in real time instead of relying on meetings.

They also find working together in the office more enjoyable than working remotely. It creates a stronger sense of connection, shared energy, and teamwork as they tackle hard problems together.

They try not to plan projects more than one month ahead

They have clear strategic pillars for the next three to six months and a broader vision for the next one to five years. But they don’t plan projects in detail more than a month ahead.

This is intentional, as things change too quickly. Many of the areas they’re working on today, like agent observability, weren’t even on the radar a couple of months ago. As new trends emerge and customer needs shift, priorities evolve just as fast.

Because of that, long-term, detailed planning would quickly become outdated. Instead, they stay flexible and adapt as new opportunities appear.

They don’t require human code reviews

Every pull request is reviewed by multiple AI tools, including Cursor Bugbot, GrepTile, Cubic, Wispbit, and Continue. Running several reviewers in parallel increases the chances of catching issues. And if even one of them flags something important, it’s worth it.

It is important to mention that they are going to make an internal version similar to the Continue AI code review tool, as they see it as a really great one, so they’ll support their version of it.

They continuously evaluate how effective each tool is and adjust their setup over time. When recurring issues come up, they try to encode those learnings into their AI reviewers, automating feedback wherever possible.

Human code reviews are optional for them. Engineers can ask for input if they want it, but it’s not required, which helps maintain speed while still allowing collaboration when needed.

New engineers initially get more hands-on review of their code

Their first few PRs are reviewed closely, often line by line, to build alignment and ensure they understand the codebase. But this goes down quickly, after a couple of PRs, reviews become lighter, and soon, engineers are trusted to work independently.

The expectation is clear: engineers own their code. They need to understand what they’re building and take responsibility for it. With that ownership and support from AI reviewers, there’s less need for mandatory human reviews on every change.

This approach significantly increases development speed. While it can introduce some risk to quality, they see the tradeoff as worth it. Bugs do happen, but they’re usually fixed quickly, often within minutes, which helps maintain trust with users.

They continue to monitor this balance and are investing more in automated testing, including AI-driven QA, to reduce risk as the team grows.

They believe that deeply understanding the system is essential to being a great engineer

They are a good example of an AI-native team, but throughout our conversation with Andrew, it has become clear that while AI tools are powerful, deeply understanding the tech and the domain that you work with is essential in order to be successful.

They draw a clear distinction between “vibe coding” and being an effective engineer who knows how to do AI-assisted engineering. The latter requires strong system-level understanding, which allows you to guide and coordinate AI agents with intention.

And not just blindly asking tools to fix issues, such engineers use context and judgment to ensure solutions fit into the broader system. Without that understanding, relying on AI can quickly lead to messy, hard-to-maintain code.

They favor AI-assisted PRs instead of agentic PRs

With AI tools like Devin or OpenClaw, you can assign them a user in GitHub, and they can open PRs based on your requirements themselves (Agentic PRs).

Andrew mentioned that while such tools are great, they find it a lot more draining when you need to closely review such PRs created, and wait for the fix.

When you work with tools such as Cursor or Claude Code, you have the full context of the change that you are working on, so you gradually develop the context of the changes and ensure its also implemented correctly.

So, you are the one who opens a PR, but the change is done through AI-assisted engineering. That’s the preferred way of working for them.

Investigating and debugging production issues is a great use case for AI for them

When a problem is reported, tools like Claude Code can often identify the root cause in a single pass, something that used to take much longer.

Previously, debugging required manually digging through logs, session recordings, and data sources. Now, with the right setup, AI can follow a similar process automatically.

They still take a “trust but verify” approach, but AI usually gets to the correct root cause. And if it’s not correct, they review its reasoning, which helps them find the root cause much faster.

A key enabler is giving AI structured access to the right systems:

• production logs,

• a read-only replica of the database,

• monitoring tools (they use SigNoz, an open-source alternative to Datadog),

• codebase context,

Doing that allows AI to debug issues much faster and more effectively.

As a result, handling production issues is far more efficient. Even engineers on support rotations can spend time on other things, since diagnosing problems takes significantly less effort.

Most of their code is AI-generated

They are regularly tracking how much of their code is AI-generated versus manually. And interestingly, as we were talking, Andrew pulled out his phone and mentioned that last week their percentage was 75%.

So, for them, it is rather an exception to go into the IDE and type out the code manually.

And funnily, Andrew mentioned that he is probably the most likely on the team to fall back to more manual approaches, mostly out of habit.

Additional use cases for AI

• Planning and research

When starting a new project, they often run deep research to explore possible approaches and existing solutions.

For example, when training a recent model, they spent significant time researching different reinforcement learning methods and how they might apply (or not) for their case.

• Recruiting process

AI also plays a major role in their recruiting process. Most steps are automated or AI-assisted, outbound sourcing is handled by agents, and take-home assignments are graded by AI (which proved accurate enough that they stopped double-checking manually).

Candidates are allowed to use AI on take-homes, since that reflects real-world work. The only exception is an initial technical interview focused on problem-solving, where AI isn’t used.

• GTM Internal tools

The go-to-market team builds internal tools to automate workflows like outreach. One example is LinkedIn messaging automation: responses from prospects flow into Slack with AI-generated reply suggestions, which the team can quickly review and edit.

There are more (similar) kinds of tools that are built quickly by people outside of pure engineering and deployed with minimal overhead, something that would have been much harder and slower in a pre-AI environment.

Bonus: 3 cases where AI is not working as well for them

For the end, Andrew also mentioned the 3 cases where AI is not as good for them, and those are:

• Building user interfaces

They find that AI often defaults to patterns from its training data, which don’t always match their product’s style or standards, especially for UI. If left unguided, the results can feel slightly off.

To address this, they actively guide the output to ensure it aligns with their design, taste, and overall consistency across the product.

• Bigger architectural decision

They find that AI struggles with broader architectural decisions, especially when the required context goes beyond what fits in a single context window.

This is where human engineers provide the most value: bringing system-wide understanding, long-term thinking, and judgment. They ensure decisions fit into the bigger picture, align with future use cases, and follow the right overall direction.

If they can close this gap, they believe it would unlock even more value from AI agents.

• Estimations

And a funny one for the end. They find that AI is surprisingly unreliable at estimating effort. Because it’s trained on human data, it tends to give traditional timelines, breaking work into phases that sound like they’ll take weeks.

But in practice, it can often complete the same work in minutes. This mismatch makes its estimates somewhat meaningless (and funny).

Last words

To wrap it all up, what stood out the most is how intentional everything at Weave feels.

They’re not just using AI because it’s a “hot new thing”, they’re rebuilding how engineering teams operate around it. Speed is a priority, but not at the expense of understanding. Autonomy is high, but paired with strong ownership.

And while AI does a large share of the work, humans are still very much in the driver’s seat when it comes to judgment, context, and direction.

Special thanks to the Weave team for sharing all these insights. And also for great hospitality and swag!

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

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

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

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

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

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

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

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

Let’s start!

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

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

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

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

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

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

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

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

Let’s get more into that next.

The Role of Engineers is Changing

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

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

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

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

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

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

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

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

In Bigger Companies, the Change is Much Slower

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

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

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

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

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

Should You Become a Great Generalist or Extreme Specialist?

Read more

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

Read more

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

🎁 Engineering Leadership Community Chat

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

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

• Connect with everyone

• Special opportunities

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

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

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

For example:

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

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

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

You can access the chat here:

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

Intro

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

Is becoming an engineering manager still worth it in 2026?

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

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

Let’s start!

I Became a Manager in 2020

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

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

And because I didn’t know which direction to pursue, I wasn’t convincing my manager in 1:1 meetings that a certain “next step” would fit me best. So, when I eventually got offered a Team Lead position, the manager was actually surprised that I was for it, as they thought that I wouldn’t be.

It’s really important that you at least have some idea of what the next step would be, as then people will automatically know that when a certain role opens: “I know Gregor would be a good fit, as they are already working toward progressing to that role”.

So, after I became a Team Lead, I started managing a cross-functional team, and I’ve made many mistakes -> what made me a good engineer didn’t make me a good manager. You can read about my mistakes in this article.

Over the course of a few months, I persevered and started to get the hang of the new role. Things have started to look better.

After about six months in the role, my manager left the company. Following a discussion with my skip-level manager, I became the new engineering manager and started leading three teams.

That was also the time when I started to realize that the management path was the right choice for me, as my set of skills and overall personality have been a good fit for it.

Things have progressed very fast after that.

After about a year, I became a Head of Engineering at a different company, then Interim CTO at that company, and later VP of Engineering at a different company and was shortly promoted to the CTO role.

You can read my full career progression here: How I Grew From Engineer to CTO.

Now, let’s go through the difference between becoming a manager in 2020 and today, in 2026.

The Difference Between Then and Now

There has been quite a big shift in the industry, and roles have changed quite a bit. The IC path became a lot more standardized and also normalized, which is really great.

In 2020, there were some Staff/Principal/Distinguished level roles, but not a lot of companies had them. The overall mindset was “You need to become a manager in order to grow in your career”, but shortly after that, the IC path gained a lot more popularity.

Still, to a certain extent, if you wish to grow to a CTO role someday, you need management experience. That hasn’t changed.

Maybe you can get away with not having a lot of experience with management if you are a startup CTO, but for sure, if you are a CTO for a scale-up or a mid+ sized company, that’s when you need to become a good manager.

And that’s something that it’s a lot harder to learn in the IC track, as there it’s all about leadership and influence without having direct authority.

Another key difference is that salaries have become quite similar regarding the IC track versus the management track, so just pure salary is less of a motivating factor today, as it was in the past, when the only way to make more was to become a manager.

Today, we can even see that some of the IC roles are even paid more; for example, Meta has recently been offering huge salaries to people who are extremely good in the ML space.

There are also 2 big shifts that have started happening recently:

1. Amazon’s increase in the manager-to-IC ratio

After Amazon raised the manager-to-IC ratio by at least 15%, a lot of other companies did a similar thing.

2. Architect, EM, and Staff Engineer roles became a lot closer

A lot of the people reported taking on additional responsibilities as part of their current responsibilities. I’ve seen Tech Leads taking the manager role as well, while also potentially being architects, and the same goes for EMs and architects, expecting to take on the 2 other roles if needed.

A similar shift has happened in engineering and PM roles, where the product engineer role has become increasingly popular. Companies like OpenAI, Anthropic, Lovable, etc., are all looking for engineers who can also wear a product hat and own their projects end-to-end.

So, overall, roles have come a lot closer together, and I fully believe that these days (and in the future) it’s less about the title and more about what impact a certain individual can bring to the organization. That’s what is most important for the companies.

And I’ve also seen this repeating trend in different companies now, which I first got introduced to by speaking with Sulman Choudhry, Head of Engineering, ChatGPT. They like to hire engineers at two extremes.

Let me also share an important difference between then and now, next!

Middle Management Was Always Hard, But It Became Even Harder These Days

I like to say that one of the toughest roles in tech is being a middle manager, as you need to be really good at managing up (leadership, stakeholders, your manager), sideways (peers), and also downwards (your team(s)).

You need to be great at understanding both tech and the business, as you act as a translator for both parts, and good communication is crucial. You need to be a really great generalist in order to do well in the role.

And especially in current times, there tends to be a lot more unrealistic expectations from the leadership team and other stakeholders, which is caused by FOMO (fear of missing out) thinking that a certain AI tool should provide an immense impact to the business.

That’s why the role has become even harder, as there are a lot more managing such expectations, and it can be really problematic for less experienced EMs, who haven’t yet built good credibility inside and/or outside of the company.

Even experienced EMs can struggle with this. I’ve seen cases where EMs just gave up on really pushing back.

Another reason is that, as you are less involved in the fine details of building, you may miss out on using the latest tools, but the plus side is that building has become even more accessible for managers, as with AI tools and good overall engineering understanding, you can ramp up on a certain codebase and become productive a lot quicker.

Now that we understand the differences in detail, let me share my answer if I would still go for the management route in 2026, next!

If I Were a Senior Software Engineer Looking to Progress to the Next Step in 2026, Would I Still Go the Manager Route?

Read more

This week’s newsletter is sponsored by Stigg.

Most engineering teams discover the gap between billing and usage enforcement the hard way. AI features ship. Adoption grows. Then one day an enterprise customer asks why a request got blocked while an identical one went through, and nobody has a clean answer.

The problem isn’t billing. Billing is working exactly as designed. The problem is that billing records what happened after execution. It was never built to decide what’s allowed while the system is running. And it’s just one layer in a monetization stack that most teams only realize is incomplete once AI hits production.

Shai Betito, VP of Engineering at Stigg, breaks down why this distinction matters more than most teams realize until it’s already painful:

• Why limits stop being simple counters under concurrency and become a consistency problem at scale.

• How a single request can touch multiple organizational dimensions simultaneously, and why resolving that correctly in milliseconds is a fundamentally different challenge than monthly reconciliation.

• Why identity-based access control breaks under AI workloads. Automated pipelines don’t have seats, and the control model has to change accordingly.

A technical breakdown of a class of infrastructure problems that appears after AI reaches production, written by engineers who’ve had to solve it.

Find out what's missing from your AI product's infrastructure:

Read the article

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

Intro

Based on recent reports, we can see that AI adoption in companies is increasing. As AI becomes more common in the workplace, the hiring process must reflect its presence.

From my conversations with engineering leaders from companies like OpenAI, Meta, and others, I’ve learned that there is an increased expectation in AI fluency, especially for engineering and product roles.

Companies are starting to understand that AI is becoming an important part of the day-to-day work that tech professionals are doing.

The question we want to answer today is how can we actually check for AI fluency in technical interviews? To help us with this, Hamid Moosavian, director of engineering at Xe, our guest author, will share practical insights on how to evaluate candidates.

Let’s introduce our guest author and get started.

Introducing Hamid Moosavian

Hamid Moosavian writes First 90 Days for Engineering Managers, a biweekly newsletter of practical management tips, and is the creator of the free First 90 Days Kit, a collection of copy-ready templates for new engineering managers. Hamid is also director of software engineering, Americas, for Xe.

Your engineers are already using AI in their work. Your engineering candidates probably are, too. But how do you know whether candidates are using AI well if you’re not interviewing for it? Hamid walks us through the importance of including AI in your interviews and how to do it.

Over to you, Hamid!

Your Tech Interview Process Shouldn’t Be AI Resistant

When Copilot and similar AI pair-programmers emerged, most teams made their hiring processes AI resistant. The logic was simple: If candidates used AI during assessments, their real skills couldn’t be evaluated.

That approach is outdated.

By the end of 2025, over half of professional developers were using AI daily. Some surveys put the number at 97% when including those planning to adopt it. AI assistants have become standard tools for productivity.

At the same time, senior engineers and tech leads started sharing examples of poorly reviewed AI code. The pattern is clear: Some developers use AI as a thinking partner and ship better code, while others blindly accept suggestions and generate unmaintainable systems.

The tool isn’t the problem. How people use it is.

The comparison to Google and Stack Overflow is obvious. No one expects developers to avoid documentation or search engines. But we do expect them to use these resources well.

This situation changes what good hiring looks like. The goal is no longer to prevent AI use. It is to evaluate how candidates use AI and whether they produce clear, maintainable code even when the tool misleads them.

Companies like Meta and Canva have already made this shift. More are following.

Here’s what to understand about AI fluency and how to update your process.

What AI Fluency Actually Means

Let’s first be more specific about AI fluency. I suggest the following framework, though you can adjust categories to fit your context.

Level 0 AI Avoidant: Is skeptical of AI tools and refuses to use them. Relies on memorization or traditional resources. Sees AI as cheating and won’t trust AI-generated code. Struggles with productivity when peers use AI assistance.

Level 1 AI Dependent: Uses AI-generated code without understanding or verification. Accepts the first suggestion, can’t explain what the code does, and gets stuck when AI gives wrong answers. Can’t debug AI output.

Level 2 AI Competent: Uses AI for boilerplate, refactoring, unit tests, and repetitive tasks but reviews output critically. Catches obvious errors, tests generated code, and explains what AI suggested and why they accepted or rejected it.

Level 3 AI Advanced: Knows when not to use AI. Combines AI with deep technical knowledge to explore edge cases and verify assumptions. Treats AI as a thought partner, not a decision-maker. Works effectively with or without AI.

What do these levels look like in practice? Let’s break down the patterns that separate competent and advanced users from the rest.

Level 2 and 3 engineers share these habits:

• Context-rich prompting: Provide relevant code snippets, file paths, and project constraints rather than vague or broad requests.

• Incremental integration: Generate code in small chunks, test after each step, and commit frequently.

• Critical review: Read all generated code line by line, check for edge cases and architectural fit, and validate against project standards.

• Security awareness: Verify package names (up to 20% of AI suggestions reference nonexistent packages), check for hardcoded secrets, and validate input sanitization.

• Appropriate skepticism: Treat AI as a pair programmer, not autopilot. Can proceed when AI is wrong or unavailable.

AI fluency shows up differently across engineering tasks. In debugging, it means using AI to generate test cases or explain error messages. In code review, it means catching issues you might miss manually. In architecture discussions, it means exploring design patterns without letting AI make final decisions.

Here’s what this looks like in practice:

A Level 1 engineer might prompt like this:

Create a POST endpoint for user registration.

A Level 2 or 3 engineer provides context and constraints:

Using Express.js with TypeScript, generate the boilerplate for a POST endpoint at /api/users that:

- Accepts JSON payload with email and name
- Includes Joi validation
- Uses async/await error handling
- Returns 201 on success, 400 on validation errors

I’ll add the business logic afterward.

You want engineers who can code without AI but also use AI fluently to improve their productivity.

Remember, though, AI is not a magic wand. It’s just a very powerful tool. Think of it like a power saw: It can cut through work 10 times faster than a hand saw, but without proper technique and safety measures, you can lose a finger. You still need to know carpentry; the tool just amplifies the skill.

Why Companies Are Making This Shift (and Why You Should Consider It Too)

The traditional approach to technical interviews is changing. Companies are realizing that if AI tools are standard in daily work, they should be part of the hiring process too.

Why? Because you want to see how candidates actually work, not how they perform under artificial constraints. The closer your test mirrors reality, the more reliable the results. Interviews should predict job performance, and job performance now includes AI.

Who’s already making the shift

Companies like Meta, Canva, and Intuit are testing a new approach. They’re not just allowing candidates to use AI tools like Copilot but observing how they use them.

Goldman Sachs has given its engineers access to GitHub Copilot and Gemini Code Assist and is even holding competitions to promote creative AI use among developers.

At Meta, candidates work with an IDE and AI chat window for writing code, debugging, and creating unit tests. Evaluation focuses on how effectively candidates use AI as a tool, integrating it into their process for daily engineering work.

The evaluation format is moving away from pure data structures and algorithms (DSAs) toward project-based tasks that mimic real engineering challenges. Interviewers assess problem-solving, code quality, verification, and communication, specifically how candidates prompt, debug, and justify AI suggestions.

Candidates must demonstrate control. Doing so shows that they’re the primary engineer, not a passive AI user. They should be catching subtle errors in AI-generated code and iterating on solutions. They should be articulating their prompts, reasoning, and trade-offs. They should be asking targeted questions to get efficient, accurate results.

Many Fortune 500 companies still share Amazon’s stance against AI interviews. But a growing number are embracing this shift, wanting to hire engineers who leverage new tools to enhance their skills.

Addressing the skeptics

Companies that don’t allow AI in technical assessments have a valid concern. They argue that allowing AI means everyone gets the same AI-generated solution, candidates don’t show their true skills, and AI covers for their weaknesses. Allowing AI does require redesigning the technical evaluation. Without it, you won’t collect meaningful signals.

However, that’s exactly what you want to test: how candidates differentiate when everyone has access to the same tools. Judgment becomes more critical than ever.

The evaluation shifts from “Does it work?” to “How was it built?” Discussions focus on key decisions, major choices, and code structure. Qualities like thoroughness become crucial: writing detailed prompts, refining them when needed, reading responses attentively, and reviewing proposed solutions carefully.

These habits separate engineers who think about tech debt and maintainability from those who just want working code.

Why This Matters for Your Company

Properly evaluating AI fluency leads to better hires in several ways.

Cost implications: When you evaluate candidates using the tools they’ll use on the job, you get a clearer signal faster. Instead of watching them struggle with boilerplate syntax, you see how they think about architecture, edge cases, and trade-offs, things that actually matter in the role.

Quality of hire: Here’s an example drawn from life. Let’s say you hire an intermediate front-end developer who writes good CSS and understands the front end well enough for the level. You give them Copilot access. Suddenly they move fast but create unmaintainable code. They’re using Copilot for the first time or using it irresponsibly. Your hire failed because you didn’t test what they’d actually do on the job.

Karat recently argued that interviews should mirror the job. Its blog states that preventing AI use hampers hiring engineers who can adapt to new tech. Its data suggests that watching how candidates interact with a large language model provides a stronger signal of seniority than traditional whiteboarding. If you’re not collecting this signal, you’re missing valuable input.

Competitive risk: Your competitors are already evaluating candidates’ AI fluency, and you’re losing AI-fluent candidates to them. You don’t need to pivot immediately, but start making your assessment more comprehensive.

Future-proofing: The skill gap is widening. For most product engineering roles, candidates who aren’t AI fluent today will struggle within six months. AI fluency signals that candidates are good learners who stay current and adapt to new tools. This is a strong indicator of future development potential.

These benefits stem from one principle: When interviews mirror how engineers actually work, you get a clearer signal and fewer post-hire surprises. Test the real workflow, and you’ll hire for the real job.

We’re at the beginning of this shift. My projection is that any company hiring product engineers at scale will eventually include an AI-fluency component, whether hands-on testing or interview questions. Since AI is becoming integral to developers’ work, it must be addressed during hiring. Otherwise, you risk unpleasant surprises.

How to Evaluate AI Fluency in Your Interviews

Read more

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

Read more

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