Today, we cover:

1. Junior and mid-level engineers at Amazon can no longer push AI-assisted code without a senior signing off. What happened when Amazon’s own AI coding tool went rogue in production, and what changed after.

2. What happened when a missile hit a Cloud data center? Iranian strikes hit AWS data centers. Cloud resilience meets actual war.

3. Donald Knuth is shocked by how good AI has become at solving an 88-year-old open math problem and at a one-hour AI session.

4. What happens when you let Claude Code pick tools for you? What Claude Code picks by default when you ask it to build something, and what it quietly ignores.

5. LLMs are not reading your code. 750,000 debugging experiments show your AI assistant is more of a pattern-matching machine, not a reasoning machine.

6. Should Juniors Code with AI? Anthropic tested this. The answer is more complicated than you’d expect.

So, let’s dive in.

Sponsor this newsletter

1. Junior and mid-level engineers can no longer push AI-assisted code without a senior signing off at Amazon

Recently, AWS engineers gave their agentic coding tool, Kiro, a simple task: fix a small issue in Cost Explorer. Kiro's response was to delete the entire environment and rebuild it from scratch. That took down a customer-based service for 13 hours!

But the problem that it was not the first time. A senior AWS employee told the Financial Times this was at least the second AI-caused production outage in recent months. The first involved Amazon Q Developer. Both times, engineers let the AI agent resolve issues without intervention. The employee described both incidents as "entirely foreseeable."

AWS's response was basically that this was a user error, not an AI issue. Their argument is that the engineer had broader permissions than expected. This is technically true, but a human engineer with the same permissions probably wouldn't have destroyed the entire environment to fix a minor bug.

After this, they introduced mandatory peer review for production access, staff training, and measures to protect resources. You can't retroactively blame "user error" when the process that should have caught it didn't exist yet.

However, the bigger picture here is organizational. Amazon first mandated 80% weekly Kiro usage and tracked it as a corporate OKR. Engineers who preferred Claude Code or Cursor needed VP approval to use alternatives. Around 1,500 engineers pushed back on internal forums.

However, after a few recent incidents in production at AWS, they decided to reduce the trend of "high blast radius" caused by "Gen-AI assisted changes". Junior and mid-level engineers can no longer push AI-assisted code without a senior signing off at AWS

Folks from Amazon concluded that "novel GenAI usage for which best practices and safeguards are not yet fully established".

This story is something we will see in more and more companies. AI-coding hype is all over the place, and we don’t have good enough guardrails or best practices for dealing with it. They make us much faster, but they also make us make more mistakes.

2. What happened when a missile hit a Cloud data center

On March 1, 2026, Iranian strikes hit three AWS data centers. Two data centers were in the United Arab Emirates, and one was in Bahrain.

We've spent 15 years treating cloud resilience as a software problem: availability zones, redundant power, auto-scaling, and cross-region replication. It is good engineering, all of it, but none of it was built with missiles in mind.

The UAE region has three availability zones, and the strikes took out two. AWS's redundancy model can survive the loss of a single zone, but not an attack on multiple zones.

Many users reported issues in their systems: Careem, Snowflake, Emirates NBD, First Abu Dhabi Bank, and Abu Dhabi Commercial Bank all had problems. These companies did not ignore the importance of having multi-AZ, but they still had issues. The problem was actually with the region, not just with the individual companies.

Iran's IRGC said it targeted the Bahrain facility specifically because AWS hosts U.S. military workloads. That boundary between commercial cloud and military infrastructure has been gone for years. Most of us just didn't think about what that means when the shooting starts.

We should also not forget that the Red Sea has 17 submarine cables running through it. These cables carry most of the traffic between Europe, Asia, and Africa. The Red Sea is facing problems due to the Houthis' threats. This means that both the Red Sea and the Strait of Hormuz are facing major problems simultaneously. The Red Sea and the Strait of Hormuz have never had problems like this before.

3. Donald Knuth is shocked by how good AI has become at solving

Famous computer scientist Knuth is now 88 years old. He wrote The Art of Computer Programming starting in 1962, and won the Turing Award in 1974.

Recently, he published a paper on how AI helped him solve a problem. He wrote at the start: "Shock! Shock!"

Here is what happened:

1. The problem

Knuth was stuck for weeks on an open graph theory problem he was preparing for a future volume of TAOCP. The problem involves a 3D grid of points. You can think of it as an m×m×m cube. Each point connects to three neighbors. The challenge is to find a single rule that traces three distinct paths through the entire cube, each visiting every point exactly once.

That kind of path is called a Hamiltonian cycle. Knuth had worked it out for a 3×3×3 cube. His friend Filip Stappers confirmed it worked up to a 16×16×16 cube by running it on a computer. But no one could find a general rule that worked for any size.

2. The session

Stappers gave the problem to Claude Opus 4.6 with one strict rule: after every attempt, write down what you tried and what you learned before moving on. Claude worked through 31 explorations over about an hour. It tried simple formulas, brute-force search, geometric patterns, and statistical methods. Most hit dead ends.

At attempt 25, it essentially told itself: "The search approach won't get us there. This needs actual mathematical reasoning." At attempt 31, it found a construction that worked.

3. The construction

Claude found a surprisingly simple rule for navigating the cube: at each point, look at where you are and follow a small set of conditions to decide which direction to move next. That's it. No complex formula, no special cases beyond a handful of boundary checks. Stappers ran the resulting program against every odd cube size from 3 to 101. It produced perfect results every time.

Then, Knuth wrote a formal proof, generalized the construction, and showed that there are exactly 760 valid solutions of this type for all odd cube sizes.

Then another researcher used GPT and Claude together as collaborating agents and found an even better solution that covered both cases. The problem that had been open for years, odd and even sizes, is now fully solved. Knuth's reaction was: "We are living in very interesting times indeed."

His closing line: "It seems I'll have to revise my opinions about generative AI one of these days."

From Donald Knuth, that sentence lands differently than it would from anyone else.

Linus Torvalds also admitted to vibe coding. Yes, that Linus. The one who called 90% of AI marketing "hype." He published a hobby project called AudioNoise, a digital guitar pedal effects, which he built to learn signal processing

Torvalds revealed that he had used an AI coding tool in the README for the repo:

"Also note that the Python visualizer tool has been basically written by Vibe-Coding. I know more about analog filters—and that’s not saying much—than I do about Python. It started out as my typical “google and do the monkey-see-monkey-do” kind of programming, but then I cut out the middle-man—me—and just used Google Antigravity to do the audio sample visualizer."

But here's what people miss: he wrote all the core C code himself, including filters and audio processing. Basically, the stuff he wanted to learn.

He only used AI for Python, a language he admits he barely knows. If the script breaks, nothing happens.

We can see here that a larger shift is underway. When someone as rigid as Torvalds uses AI, it gives permission to the purists who still feel guilty about it.

But here's the catch: most people won't mention this, but Torvalds can spot bad AI output because he understands the fundamentals. He knows enough to smell when the code is wrong, even in a language he doesn't write daily.

That's the prerequisite. Juniors who vibe code features they don't understand can't debug them when they break.

Knowing when to code manually matters more now than knowing how to code everything manually.

4. What happens when you let Claude Code pick tools for you?

Researchers from Amplifying sent 2,430 open-ended prompts to Claude Code across 3 models, 4 project types, and 20 categories. In those prompts, they did not mention any tools, but just asked, "What should I use?" The results were interesting and important to understand.

Here is what they found:

1. Build over buy is the default

Custom/DIY is the single most common "recommendation" in the dataset: 252 picks across 12 of 20 categories. If you ask Claude Code to add feature flags, he will build a system with env vars and React Context. If you ask it to add auth to a Python project, it will write a JWT from scratch every single time. When an agent can build a working solution in 30 seconds, it often does.

This is something we should be aware of, because building a new auth system could be fast for AI, but it could still have security issues or bugs, and we would still need to maintain it. When deciding whether to build or buy, we should consider multiple factors before choosing, and not let AI make the decision for us.

2. A default tech stack exists

Where Claude Code does pick third-party tools, it converges hard:

• GitHub Actions owns CI/CD at 94%

• Stripe owns payments at 91%

• shadcn/ui owns UI components at 90%

• Vercel is a must for JavaScript projects.

The rest of the list: PostgreSQL, Tailwind CSS, Zustand, pnpm, Resend, Vitest.

What is important here is that these tools may not be the best option for your project, but these are what the model will choose for you. They choose them not because they are the best fit for our project, but because they find them in use in the wild (mostly on GitHub). So, the decision on the tech stack should be ours, not the AI model.

3. Redux is dead in AI-assisted code

Redux didn't get any primary picks in these 2,430 prompts. The model knows it exists, with 23 mentions and 2 alternative recommendations, but never actually chooses it.

Zustand wins state management at 65% instead. Express has it even worse, where it doesn't show up as a primary pick, an alternative, or even a passing suggestion.

4. Newer models prefer newer tools

This is the clearest signal from this dataset. Prisma goes from 79% in Sonnet 4.5 to 0% in Opus 4.6. Drizzle takes over completely. In Python projects, Celery usage collapses from 100% to 0% as newer models prefer FastAPI's built-in background tasks. It tracks with what appeared in more recent training data.

5. Context-awareness is real

The same model picks Vercel for JavaScript and Railway for Python. Drizzle for Next.js, SQLModel for FastAPI. This is not a fixed list; the agent reads the stack and adapts, which is more useful than a blanket recommendation.

6. Being absent from primary picks isn’t the same as being invisible

This is something worth noting in the report. A few technologies, such as Netlify, SendGrid, and Jest, were never chosen as the primary option. But they kept showing up as second choices. The model knows these tools and still recommends something else first. That gap is the one worth closing.

If we're using AI coding agents for greenfield projects, we're increasingly inheriting a default stack. Worth knowing what that stack is.

5. LLMs are not reading your code

We keep calling LLMs “AI coding assistants,” but we all know that writing code and understanding it are not the same. Researchers from Virginia Tech and Carnegie Mellon University just ran 750,000 debugging experiments across 10 models to assess how well LLMs actually understand code.

What they found out is that you should not blindly trust your AI coding assistant when debugging.

Here are the findings:

1. A renamed variable breaks the debugger. Researchers created a bug, confirmed that the LLM found it, then made changes that don’t touch the bug at all, such as renaming a variable or adding a comment. In 78% of cases, the model could no longer find the same bug, but it was still there. The variable names and comments changed, and that was enough.

2. Dead code is a trap. Adding code that never runs reduced bug-detection accuracy to 20.38%. Models treated dead code as live and flagged it as the source of the bug. But the bug was in another line. So, LLMs cannot reliably distinguish “this runs” from “this never runs.”

3. Models read top-to-bottom, not logically. 56% of correctly found bugs were in the first quarter of the file, and only 6% were in the last quarter. The further down the file's code, the less attention the model pays to it. If the bug lives in the bottom half of your file, the model is already less likely to find it.

4. Function reordering alone cut accuracy by 83%. Changing the order of functions in a Java file caused an 83% drop in debugging accuracy. The code still remained the same. Where the code physically sits in the file matters more to the model than what the code does.

   So, obviously, this is a sign of pattern recognition, not real code understanding.

5. Newer models weren’t actually much better. Claude improved by ~1% between 3.7 and 4.5 Sonnet on this task, and Gemini improved by ~1.8%. Every model release comes with a new benchmark leaderboard and new headlines. But the ability to reason about code under realistic conditions is improving slowly.

   

   Of course, all of these models where pre Opus 4.5 era, so it would be interesting to see how they do now.

6. These were best -case conditions

The study used single-file programs with ~250 lines, and each had a clear description of what the code should do. The authors say this was intentional. They wanted the best-case conditions. Real production code is multi-file, cross-module, and poorly documented. It will perform worse for sure.

6. Should Juniors Code with AI?

We assume AI helps junior developers ramp up faster, allowing them to learn the codebase more quickly, ship sooner, and close the skill gap with seniors.

Anthropic just ran a randomized controlled trial that challenges this. 52 developers learned a new Python library for async programming, half with AI assistance, half without. The AI group scored 17% lower on comprehension tests. That's nearly two letter grades (50% vs 67%, p=0.01).

The largest gap was in debugging. But this is the exact skill juniors need to catch errors in AI-generated code.

AI didn't even make them faster. The AI group finished about 2 minutes earlier, but the difference wasn't statistically significant. Some participants spent up to 30% of their time just writing prompts.

So, how can we use AI to determine whether you learn at all? The study identified six interaction patterns. Three scored below 40%, three scored above 65%.

Those who were low scorers delegated everything to AI, starting manually and progressively offloading work. They used AI as a debugging crutch without building understanding. Those who scored highly generated code and asked follow-up questions. They requested explanations of the code and asked more conceptual questions.

This implies that unrestricted AI access during onboarding creates a capability gap. We get faster task completion today, but we lose the debugging instincts needed to validate AI output tomorrow.

We should take this into account before we onboard new junior developers.

More ways I can help you

• 📱 You Can Build A LinkedIn Audience 🆕. The system I used to grow from 0 to 270K+ followers in under two years, plus a 50K-subscriber newsletter. You’ll transform your profile into a page that converts, write posts that get saved and shared, and turn LinkedIn into a steady source of job offers, clients, and speaking invites. Includes 6-module video course (~2 hours), LinkedIn Content OS with 50 post ideas, swipe files, and a 30-page guide. Join 400+ people.

• 📚 The Ultimate .NET Bundle. 500+ pages distilled from 30 real projects show you how to own modern C#, ASP.NET Core, patterns, and the whole .NET ecosystem. You also get 200+ interview Q&As, a C# cheat sheet, and bonus guides on middleware and best practices to improve your career and land new .NET roles. Join 1,000+ engineers.

• 📦 Premium resume package. Built from over 300 interviews, this system enables you to quickly and efficiently craft a clear, job-ready resume. You get ATS-friendly templates (summary, project-based, and more), a cover letter, AI prompts, and bonus guides on writing resumes and prepping LinkedIn. Join 500+ people.

• 📄 Resume reality check. Get a CTO-level teardown of your CV and LinkedIn profile. I flag what stands out, fix what drags, and show you how hiring managers judge you in 30 seconds. Join 100+ people.

• ✨ Join my Patreon community and my shop. Unlock every book, template, and future drop, plus early access, behind-the-scenes notes, and priority requests. Your support enables me to continue writing in-depth articles at no cost. Join 2,000+ insiders.

• 🤝 1:1 Coaching. Book a focused session to crush your biggest engineering or leadership roadblock. I’ll map next steps, share battle-tested playbooks, and hold you accountable. Join 100+ coachees.

Want to advertise in Tech World With Milan? 📰

If your company is interested in reaching founders, executives, and decision-makers, you may want to consider advertising with us.

Love Tech World With Milan Newsletter? Tell your friends and get rewards.

Share it with your friends by using the button below to get benefits (my books and resources).

Share Tech World With Milan Newsletter

Track your referrals here.

Nick is a senior staff software engineer at PayFit and the author of Architecture Modernization (Manning). His focus areas are legacy migration, domain-driven design, and continuous delivery.

Nick will walk us through exactly how he works: how he plans features, how he structures AI workflows as state machines, how he enforces architecture rules deterministically, and how he keeps AI-generated code from quietly degrading quality over time.

In particular, we are going to talk about:

• How Nick approaches AI tools. Try it on everything, timebox the experiments, and track what actually pays off.

• Agentic coding workflow. Nick models his development process as a state machine with typed transitions and enforced invariants. The workflow itself has unit tests.

• Planning and PRDs. How he structures requirements before any code is written, and why he spends real time here before touching Claude Code.

• Implementing features autonomously. Claude runs the full cycle from requirements to pull request, with guardrails that block non-compliant code from landing.

• Code quality and architecture rules. Lint rules, dependency constraints, and why deterministic checks beat asking Claude to follow conventions.

• Code reviews. Here Nick talks about his layered approach to code reviews: CodeRabbit, local review agents, and his own eyes on every PR before anything ships.

• Testing with TDD. How he runs Claude through a strict red-green cycle with verified pre- and post-conditions at every step.

• Tooling and techniques. His custom CLI setup and a few smaller tricks are worth stealing.

So, let’s dive in.

Unblocked: Context that saves you time and tokens (Sponsored)

Stop babysitting your coding agents. Unblocked gives them the organizational knowledge to generate mergeable code without the back-and-forth. It pulls context from across your engineering stack, resolves conflicts, and cuts the rework cycle by delivering only what agents need for the task at hand.

Check it out

1. Who is Nick?

Hi, I’m Nick. I’m a Senior Staff Software Engineer at PayFit, a European payroll and HR company. I’m the author of a book called Architecture Modernization (Manning). Legacy modernization, along with software architecture, domain-driven design, and continuous delivery, are my main areas of focus. I’m based in London, UK.

2. How do you use AI tools in general?

The current strategy is to use it everywhere. Figure out what works and what doesn’t. That’s basically my current philosophy. Every time I do anything, I try to use AI to help me. Sometimes I don’t have time, and I just need to get stuff done, though, and I can’t afford to experiment, e.g., 3 hours trying to get AI to create perfect diagrams vs just doing it myself. But I make an effort to at least timebox it with AI.

For example, I was recently working on resolving customer support tickets, and I thought, “Wouldn’t it be great if I had a tool that allowed me to keep track of all this and act as a memory for my AI agents so they could work on 10 customer support tickets in parallel?” My initial thought was “it’s the peak season, I can’t really afford to let a backlog of tickets build up while I’m playing around with AI," but then I said to myself, “well just spend 1 hour on it and see what happens?”

The break-even point came within 2-2.5 days. I had built a custom tool (UI, investigation subagents, etc.) and resolved the number of tickets I would have done manually. By the end of the week, I felt 20 - 40% more productive than I would have been without it. In fact, it was funny because at the end of the week, I was working on a ticket when another ticket was raised. While I was working on the first ticket, I had Claude using the process I’d built to work on the new ticket. Then there was an issue where some highlighted that the 2nd ticket was causing issues for some clients and needed to be prioritised.

At that point, I checked in on Claude, and he’d already figured out the root cause and the exact code causing the problem. And this wasn’t a simple bug; it spanned 3 codebases and required correlating data from 3 different data sources to identify where the inconsistency was introduced.

What I built in a week was still quite basic. But like I said: the ROI was achieved within 3 days, AND I now have a version that I can keep iterating and improving (both the underlying AI system and the UI for managing it all), so the potential long-term ROI and learning insights I can apply to other initiatives is significant. And all because I pushed myself to “come on, let’s do that 1-hour timebox. ”

But it doesn’t always work out; sometimes it ends in wasted time and frustration. That’s why it’s important to understand that getting the best results usually requires an investment.

3. What is your main agentic workflow for coding?

It depends on the repository. You can see an example from one of my open-source projects here: https://github.com/NTCoding/living-architecture.

I try to have a very strict, repeatable workflow so that AI can autonomously implement features, and I know that all steps, checks, rules, and reviews will be completed without exception.

I’m currently working towards a more hook- and event-driven workflow. This is a major differentiator because you can apply fine-grained rules deterministically based on your workflow's current state.

Basically, you model your workflow as a state machine (like an aggregate in DDD). The workflow has rules and invariants, and stores its internal state in persistence. This can be written in full code with 100% test coverage. Every time AI does something wrong, you write a failing test and implement - for example, not allowed to commit code during the “planning” phase.

This is an example of the PR-creation state machine step:

export const submittingPrState: ConcreteStateDefinition = {
  emoji: '🚀',
  agentInstructions: 'states/submitting-pr.md',
  canTransitionTo: ['AWAITING_CI', 'BLOCKED'],
  allowedWorkflowOperations: ['record-pr'],
  forbidden: { write: true },

  allowForbidden: { bash: ['git push', 'gh pr'] },

  transitionGuard: (ctx) => {
    if (!ctx.state.prNumber) return fail('prNumber not set. Run record-pr first.')
    return pass()
  },
}

In this state:

• 🚀SUBMITTING will be prefixed to each agent message so I can always see the current state

• The instructions in `states/submitting-pr-md` will be injected into the current conversation when the agent transitions to this state (and it will also be re-injected if the agent makes an error and needs reminding)

• The agent can transition to `AWAITING` or `BLOCKED` from this state. If it tries to transition to another state, it will be blocked (and the prompt in `states/submitting-pr.md` will be re-injected into the error message)

• The agent can invoke the worfkflow operation `record-pr` which will update the state of the workflow, it cannot call other workflow methos

• The agent cannot write any files

• The agent is allowed to use `git push` and `gh pr` => even though these are globally forbidden

• When the agent tries to transition to a new state, the transition will fail if `ctx.state.prNumber` has not been set => that is a requirement of this phase, to create the PR and record the PR number. The agent’s job here is not done until that obligation is fulfilled (the following workflow steps depend on it, the whole workflow is broken without it)

Remember that this is all real code, so you can fully unit test it.

4. How do you plan first?

How I plan depends on the type of project, e.g., building an open-source project vs. a complex legacy migration.

For my open source projects, I have a PRD expert agent (a product requirements expert). This agent helps me to discuss a project, define the requirements, shape the architecture, and produce a structured PRD file that lists dependencies.

A structure of PRD is as follows:

# PRD: [Feature Name]
**Status:** Draft | Planning | Awaiting Architecture Review | Approved

## 1. Problem
[What problem, who has it, why it matters]

## 2. Design Principles
[What we're optimizing for, trade-offs, WHY]

## 3. What We're Building
[Requirements with detail]

## 4. What We're NOT Building
[Explicit scope boundaries]

## 5. Success Criteria
[How we know it worked]

## 6. Open Questions
[Uncertainties to resolve - Draft only]

## 7. Milestones
[Major checkpoints - Planning only]

### M1: [Name]
[What's delivered at this checkpoint]

#### Deliverables
- **D1.1:** [Deliverable name]
  - Key scenarios (happy path + known edge cases)
  - Acceptance criteria
  - Verification
- **D1.2:** [Architecture deliverable, if this milestone introduces changes]
  - What doc to update and why
  - Verification

### M2: [Name]
...

## 8. Parallelization
[Work streams that can proceed in parallel]

## 9. Architecture
[Added during architecture review]

```yaml
tracks:
  - id: A
    name: [Track name]
    deliverables:
      - M1
      - D2.1
  - id: B
    name: [Track name]
    deliverables:
      - D1.2
      - M3

Once that is done, I have a command to create tasks, which creates tasks in GitHub (as GitHub issues). The reason I like to use GitHub is that when you create a pull request, it links to the issue, so code reviewers (human and AI) can review the PR against the full source of truth.

I usually spend quite a lot of time discussing PRDs, and my PRD expert is set up as a coach who asks good questions and challenges me. It’s not just a robotic step-by-step process.

For legacy migration projects, I have a team of agents who scan codebases, map the current state, identify migration options, and produce draft ADRs for me to review. Things like “identify all the API endpoints in the codebase, and do a full end-to-end analysis (use a separate subagent for each API endpoint to optimize context window usage” and “compare the API endpoint in the legacy with existing API endpoints in the target system, which is the best fit, or should we create a new endpoint?” I actually provide these agents with very structured and precise instructions and analysis criteria. I try to put my exact thought process on paper rather than giving AI too much freedom.

5. How do you implement the initial code structure?

My default approach is an autonomous dev workflow. I kick off Claude, and it will implement the whole feature. The goal is to create a pull request that passes all checks and has been reviewed by code review agents and CodeRabbit (see below for more information).

The following shows an extract from a `docs/workflow.md` file. This is written primarily for the agent. It describes the states and what command to use in each state. As you can see, I have a mix of slash commands and real code (I strive for determinism where possible).

Claude then follows my TDD workflow to implement requirements. I have various checks in place, like pre-commit hooks, that ensure Claude cannot commit code that does not compile or lint. I have also banned operations like `git commit “–no-verify”` so Claude cannot work around the guard rails I have put in place.

Wherever possible, I try to leverage full code. E.g., I have a script that creates a GitHub PR, waits for all checks to pass, and fetches the PR feedback. Anything written in an agent’s prompt or a markdown file is too unreliable, and I have lost so much time pleading with agents to follow processes. As I mentioned in step 3, I’ve also been working towards a more deterministic workflow, which reduces reliance on the agent reading this file and doing the right thing (this file is still useful).

With real code, you get determinism and unit tests to verify it works the exact same way every time:

describe('executeCompleteTask', () => {

 it('passes workflow steps in correct order', () => {
    executeCompleteTask()

    const steps: unknown[] = mockRunWorkflow.mock.calls[0][0]
    const stepNames = steps.map((s) => {
      const step = s && typeof s === 'object' && 'name' in s ? s : null
      return step?.name
    })
    expect(stepNames).toStrictEqual([
      'verify-build',
      'code-review',
      'submit-pr',
      'fetch-pr-feedback',
    ])
  })

…
}

7. How do you improve code quality and correctness of AI-generated code?

Continuous improvement is the key. Every time your agent produces bad code, you need some way of updating your harness to ensure that it does not produce similar code in the future. The best way to do this is to use deterministic tools.

I have a lot of lint rules: file size rules, function complexity rules, naming rules, code comment rules, banned syntax (I don’t let Claude use “as” or “let” in TypeScript. I force it to write type-safe and immutable code.

In addition, I use a dependency cruiser to enforce architecture rules, such as that files in the “domain” folder cannot depend on files in the “infra” folder. I have a DDD/CQRS architecture that I use, and it is defined here: https://github.com/NTCoding/claude-skillz/tree/main/separation-of-concerns

So the documentation defines this structure:

features/              platform/              shell/
├── checkout/          ├── domain/            └── cli.ts
│   ├── entrypoint/    │   └── tax-calc/
│   ├── commands/      └── infra/
│   ├── queries/           ├── external-clients/
│   ├── domain/            ├── http/
│   └── infra/             ├── cli/
│       ├── mappers/       ├── persistence/
│       └── persistence/   ├── config/
│                          └── logging/
└── refunds/
    ├── entrypoint/
    ├── commands/
    ├── queries/
    └── domain/

Defines rules for enforcing the structure (rules are used during planning, development, and review).

SoC-006: Entrypoints are thin translation layers

Entrypoints translate between the external world and commands/queries: parse external input → invoke command/query → map result to external response. Nothing else.

Entrypoints own: input parsing, output formatting, interactive prompts (progress bars, spinners), and exit code mapping. When entrypoint/ grows large, extract infrastructure helpers to features/{name}/infra/.

And provide dependency-cruiser rules to enforce the convention that, even if Claude makes a mistake, the pre-commit hooks and PR checks will fail if there is a dependency violation.

Here is a rule that says a feature (aka a vertical slice) cannot depend on another vertical slice:

// --- Feature isolation rules ---
// Features are independent vertical slices. No feature may import from another.
// The $1 capture group ensures imports within the same feature are allowed.
{
  name: "no-cross-feature-imports",
  severity: "error",
  comment: "Features must not import from other features",
  from: { path: "features/([^/]+)/.+" },
  to: {
      path: "features/([^/]+)/.+",
      pathNot: "features/$1/.+"
  }
},

I find that Claude Code really struggles to make simple decisions about where to put code, so having strict rules and clear guidelines is key.

8. How do you do code reviews?

Depends on the project and team conventions. One thing that I use everywhere is CodeRabbit. It is quite amazing. I have it set up on all my pull requests, both personal projects and at work.

The great thing about CodeRabbit is that not only can it identify bad and insecure code, but it can also be configured to read all your coding standards and ADRs and find violations. It also stores learnings, and you can even tell it “next time remember to review <this>” or “don’t suggest <that>”.

Sometimes I also run CodeRabbit via CLI before creating a branch.

Read more here on how to use CodeRabbit for code reviews:

Tech World With Milan Newsletter

How to do code reviews with AI tools

Writing code has never been easier, but delivering great software is now more complex than ever. AI tools have pushed our productivity to new levels, allowing developers to write code much faster, teams to ship more features, and delivery to increase…

Read more

8 months ago · 40 likes · 5 comments · Dr Milan Milanović

In addition, I have dedicated code review agents that run locally: code review, architect review, test review, QA check (does the work actually implement the required functionality), and bug check.

I have a strictly enforced workflow on some projects that prevents a pull request from being created until these reviews have run. The basic idea is to create a hook that blocks Claude from running the command directly and forces Claude to use a script that enforces the correct usage of the tool:

Hook wiring to block `git push`:

{
    pattern: /\bgit\s+push\b/,
    reason:
      ‘Blocked: Direct git push bypasses required workflow. Use /complete-task command instead, which runs the complete verification pipeline (lint, test, code review, PR submission) and prevents orphaned changes.’,
},

Then a script which enforces local code review before submitting a PR:

runWorkflow<CompleteTaskContext>(
   [verifyBuild, codeReview, submitPR, fetchPRFeedback],
   buildCompleteTaskContext,
   (result: WorkflowResult, ctx: CompleteTaskContext) => formatCompleteTaskResult(result, ctx),
)

One of the things I found with agentic code reviews is to be precise. Rather than saying “review the code for these <principles>”. I say, “For each modified file, review the file against each code review principle (I give them codes like CR-001 and write an audit table.” It forces the agent to get into the details rather than letting the agent decide to optimise for speed or efficiency when you actually want correctness and robustness.

I also review the code myself. I don’t feel safe deploying anything to production that I haven’t reviewed myself. The main thing for me is: giving feedback on a PR is a process failure. The AI didn’t do it right the first time, so I try to ensure the feedback I provide is built into the harness and automatically applied in the future.

9. How do you create tests?

I’ve used TDD throughout my career, and I push my agents to use something that resembles it. The focus is on writing tests first, obviously, and implementing them with the simplest possible solution, with structured pre-conditions for state transitions.

Example state definition:

<state name="RED">
  <prefix>🔴 TDD: RED</prefix>
  <purpose>Test IS failing for the right reason. Implement ONLY what the error message demands.</purpose>

  🚨 CRITICAL: You are in RED state - test IS CURRENTLY FAILING. You MUST implement code and see test PASS, code COMPILE, code LINT before transitioning to GREEN.
  DO NOT transition to GREEN until you have:
  1. Implemented ONLY what the error message demands
  2. Executed the test with Bash tool
  3. Seen the SUCCESS output (green bar)
  4. Executed compile check and seen SUCCESS
  5. Executed lint check and seen PASS
  6. Shown all success outputs to the user

  <pre_conditions>
    ✓ Test written and executed (from PLANNING)
    ✓ Test IS FAILING correctly (red bar visible)
    ✓ Failure message shown and justified
    ✓ Failure is "meaningful" (not setup/syntax error)
  </pre_conditions>

  <actions>
    1. Read the error message - what does it literally ask for?
    2. 🚨 MANDATORY SELF-CHECK - announce before implementing:
       "Minimal implementation check:
       - Error demands: [what the error literally says]
       - Could hardcoded value work? [yes/no]
       - If yes: [what hardcoded value]
       - If no: [why real logic is required]"

       Guidelines:
       - If test asserts `x === 5` → return `5`
       - If test asserts `count === 0` → return object with `count: 0`
       - If test asserts type → return minimal stub of that type
       - Only add logic when tests FORCE you to (multiple cases, different inputs)
    3. Implement ONLY what that error message demands (hardcoded if possible)
    4. Do NOT anticipate future errors - address THIS error only
    5. Run test (use Bash tool to execute test command)
    6. VERIFY test PASSES (green bar)
    7. Show exact success message to user (copy/paste verbatim output)
    8. Run quick compilation check (e.g., tsc --noEmit, or project-specific compile command)
    9. Run lint on changed code
    10. If compile/lint fails: Fix issues and return to step 5 (re-run test)
    11. Show compile/lint success output to user
    12. Justify why implementation is minimum
    13. ONLY AFTER completing steps 5-12: Announce post-condition validation
    14. ONLY AFTER validation passes: Transition to GREEN

    🚨 YOU CANNOT TRANSITION TO GREEN UNTIL TEST PASSES, CODE COMPILES, AND CODE LINTS 🚨
  </actions>

  <post_conditions>
    ✓ Implemented ONLY what error message demanded
    ✓ Test executed
    ✓ Test PASSES (green bar - not red)
    ✓ Success message shown to user verbatim
    ✓ Code compiles (no compilation errors)
    ✓ Code lints (no linting errors)
    ✓ Compile/lint output shown to user
    ✓ Implementation addresses ONLY what error message demanded (justified)
  </post_conditions>

  <validation_before_transition>
    🚨 BEFORE transitioning to GREEN, verify ALL with evidence from tool history:
    ✓ Test PASSES (green bar) - show verbatim output
    ✓ Code compiles - show output
    ✓ Code lints - show output
    ✓ Implementation addresses ONLY what error demanded - justify

    If ANY evidence missing: "⚠️ CANNOT TRANSITION - Missing: [what]" → stay in RED.
  </validation_before_transition>

  <critical_rules>
    🚨 NEVER transition to GREEN without test PASS + compile SUCCESS + lint PASS
    🚨 IMPLEMENT ONLY WHAT THE ERROR MESSAGE DEMANDS - no anticipating future errors
    🚨 DON'T CHANGE TEST TO MATCH IMPLEMENTATION - fix the code, not the test
  </critical_rules>

  <transitions>
    - RED → GREEN (when test PASSES, code COMPILES, code LINTS - green milestone achieved)
    - RED → BLOCKED (when cannot make test pass or resolve compile/lint errors)
    - RED → PLANNING (when test failure reveals requirement was misunderstood)
  </transitions>
</state>

Currently, I rely solely on prompts to enforce the TDD workflow. I don't use deterministic workflows for this, but in the future I’m tempted.

I have very strict lint rules on the tests, like:

• 100% test coverage mandatory (build will fail without it)

• maximum assertions per test: 4

• no conditional assertions

• file size limit: 400 (forces AI to break up tests into descriptive chunks, and use patterns like it for each)

I also have a code-review agent focused on testing.

10. What are some useful techniques you use?

I have my own CLI tool for starting Claude code.

It runs `claude –system-prompt` to start the session. And it builds a system prompt based on specific personas I have. For example, I run `cl prd opus`. This will start a Claude code session using my PRD expert system prompt.

The benefits of this:

1. Embedding in the system prompt increases compliance

2. Dedicated system prompt means avoiding loading unnecessary content - when my PRD system prompt is loaded, I don’t need to load all my rules about unit tests, for example

3. Embedding in the system prompt is more efficient than reading files after the session has started

11. Anything else worth mentioning?

Build your own tools. One of the great things about AI is that it’s so easy to build simple tools. I built a whole project management tool to help me plan and deliver legacy modernization projects. I can build whole features in one Claude Code terminal while I’m waiting for Claude to finish some work in another terminal - it’s basically free.

My advice is to think about the task you are working on and ask yourself: What kind of CLI command, UI, or knowledge management tool would help me be more productive? How can I automate some of the annoying bits so I only need to focus on the important parts?

Then ask your AI agent to help you design a tool.

More ways I can help you

• 📱 You Can Build A LinkedIn Audience 🆕. The system I used to grow from 0 to 270K+ followers in under two years, plus a 50K-subscriber newsletter. You’ll transform your profile into a page that converts, write posts that get saved and shared, and turn LinkedIn into a steady source of job offers, clients, and speaking invites. Includes 6-module video course (~2 hours), LinkedIn Content OS with 50 post ideas, swipe files, and a 30-page guide. Join 300+ people.

• 📚 The Ultimate .NET Bundle. 500+ pages distilled from 30 real projects show you how to own modern C#, ASP.NET Core, patterns, and the whole .NET ecosystem. You also get 200+ interview Q&As, a C# cheat sheet, and bonus guides on middleware and best practices to improve your career and land new .NET roles. Join 1,000+ engineers.

• 📦 Premium resume package. Built from over 300 interviews, this system enables you to quickly and efficiently craft a clear, job-ready resume. You get ATS-friendly templates (summary, project-based, and more), a cover letter, AI prompts, and bonus guides on writing resumes and prepping LinkedIn. Join 500+ people.

• 📄 Resume reality check. Get a CTO-level teardown of your CV and LinkedIn profile. I flag what stands out, fix what drags, and show you how hiring managers judge you in 30 seconds. Join 100+ people.

• ✨ Join My Patreon community and my shop. Unlock every book, template, and future drop, plus early access, behind-the-scenes notes, and priority requests. Your support enables me to continue writing in-depth articles at no cost. Join 2,000+ insiders.

• 🤝 1:1 Coaching. Book a focused session to crush your biggest engineering or leadership roadblock. I’ll map next steps, share battle-tested playbooks, and hold you accountable. Join 100+ coachees.

Want to advertise in Tech World With Milan? 📰

If your company is interested in reaching founders, executives, and decision-makers, you may want to consider advertising with us.

Love Tech World With Milan Newsletter? Tell your friends and get rewards.

Share it with your friends by using the button below to get benefits (my books and resources).

Share Tech World With Milan Newsletter

Track your referrals here.

What I've found over more than twenty years of building software across different domains is that engineers who delivered the most value to projects and companies weren’t the most productive coders. The ones that brought the most value were those that started first with thinking, asking questions, pushing back on requirements, analyzing, and making a plan. Sometimes, during this process, they found out that coding is not even necessary. And this was the best outcome.

This habit was valuable. This year, when AI can write code much faster than us, it’s become even more important to bring value to your company without only coding.

In particular, we’re going to talk about:

• The identity trap. The common mistake is treating software engineering as code output. It shifts the focus to questions, intent, and what the work is meant to change.

• Code is a liability, not an asset. Every line of code has to be maintained, understood, and changed later, so the real goal is not to write more, but to solve the problem with less.

• What happens when you skip the thinking. It’s easy to fix the wrong problem when you jump straight into implementation. The difference is between moving fast in code and being right about the problem.

• Why do we default to coding anyway. There is a reason why teams rush into code-first behavior. Incentives, praise, deadlines, and org structure all push it in the wrong direction.

• AI amplifies this even further. What changes when code becomes cheap to produce? AI can speed up execution, but it also leads to poor framing, weak judgment, and unnecessary code scaling.

• What thinking-first actually looks like. There is a simple way to clarify the problem before coding, using short notes, lightweight documents, feedback, and quick prototypes to test assumptions.

• The engineer’s real job description. The focus moves from coding to judgment, trade-offs, architecture, validation, and deciding what should never be built in the first place.

Let’s discuss this deeper.

Unblocked: Context that saves you time and tokens (Sponsored)

Give Cursor, Claude, and Copilot the organizational knowledge they need to generate code that is ready for git push. Unblocked synthesizes your code, PR history, conversations, docs, and runtime signals to surface the right context for each task.

Check it out

1. The identity trap

The idea that a software engineer is only as good as the code they write is just not true. People think that if you write a lot of code, you become a good software engineer. They look at things like how many lines of code you commit, how many pull requests you merge, and how many features you ship. If we use that way of thinking, then a computer program that can write code is already a software engineer, and most people are not, especially now in the AI age. That way of thinking is wrong.

A software engineer does not start by thinking about what tools or computer programs to use. They start by asking questions:

• What problem are we trying to solve with this?

• Who are we trying to help?

• Why is it important to solve this problem?

• What will happen if we do not do this and do something else?

Some people just focus on writing the code, which is what developers do. Software engineers think about the outcomes of their work.

When you write code, you want to make sure the code works properly. But software engineering is different. It is about making code that can handle problems when they happen. It should be easy to understand and fix, and other people should be able to work on it even if they did not write it. Software engineering also considers how it affects systems connected to it. It is like looking at the picture and thinking about how all the parts work together.

2. Code is a liability, not an asset

This is something we need to understand from the start. Even though our job is mainly focused on the code, we need to have it, not want it. The reason is that every line of code you write needs to be maintained, it needs to be understood by you in the future and your colleagues, and eventually changed when new requirements arrive. Nothing of this is free. Code is not valuable until what it does earns more than what it costs to keep it running.

The thing is that a lot of code never gets to this point. Code capabilities are assets, but code itself is a liability you incur to produce those capabilities. The goal is to implement the business capability with as little code as possible.

Jeff Atwood said the best code is no code at all. Code you do not write does not have bugs, does not need tests. Never needs to be cared for. If you can solve a problem by deleting code, changing the way you do things, or using a tool that already exists, then you have done your job well.

This is not about being against code, but about knowing when to use it. It's the code itself that we need to be careful with. We should think carefully about when to write it. Code is what we are trying to be disciplined about.

3. What happens when you skip the thinking

Let me walk through the example. I have seen this same thing happen many times. Let’s say we get a ticket which says: “Users are saying that the checkout is slow. We probably need to fix the problem with the performance.”

The engineer would look at the code, see how this functionality works, then identify a slow DB query and maybe add some indexes. Sometimes it would add tests too. The problem is fixed.

Then, three weeks later, the ticket gets reopened. It turns out that people are still leaving the checkout without paying. The slow database query was not the problem. People were leaving the payment form because it had many fields to fill out, not because it was slow. Nobody reviewed the data on how people use the website before they started working on the problem. So the engineer made the checkout faster. That was not what people were really having trouble with.

Now lets look at what happens when the engineer thinks about the problem.

Before they start coding, the engineer asks: What does “slow checkout” really mean to the website's users? They look at data on how people use the website, and they talk to two people who work in support. They read feedback from the last three months. They find out how many people are leaving the checkout at the payment form, and they write down something like this:

“Users are leaving the checkout at the payment form. The data shows that people are having trouble with all the fields they have to fill out, not that it is slow. My idea is that if we make the form shorter, more people will finish checking out.”

The engineer spent 2 hours thinking about the problem and came up with a correct solution. They made a form and tested it against the old one. It worked. 18% more people finished checking out, and the code change was 40 lines.

The first engineer was really fast at coding. The second engineer actually solved the checkout problem.

💡 Weeks of coding can save you hours of planning.

4. Why we default to coding anyway

Unfortunately, we often do coding first because that is how we measure and reward engineering work.

The way we measure things is how fast we complete our tasks, not by looking at problems to avoid. Promotions are given to someone based on the number of features they delivered, more than anything else. Nobody gets praise for removing code or making something simpler, even when it improves the system. Engineers are just smart people who follow the rules. This is a great example of Goodhart's Law.

This is a problem on the organizational level, not just with individuals. We see it when individual people make decisions. The goal is to show that we are making progress. Progress looks like we are writing code, because the clock is ticking from the moment we take the ticket. So, engineers write code before they really understand the problem, the organization rewards them, and we end up with something that’s not what we wanted, and then everyone is confused. This is only accelerated with AI (read more in the next section).

But, there is another way this can go. In teams where everyone can talk to each other and see how users are affected, we usually understand the problem naturally. The problem is worse in organizations where it takes a long time to see how a line of code affects the business, and it has to go through many teams and people.

5. AI amplifies this even further

AI coding tools have made it really easy to generate code. A lot of code. A good engineer with the tool can make a working draft in just a few minutes that would have taken hours before. This sounds like a good idea, but it really depends on what happened before they started using the tool.

Think of an AI tool like a person who builds something the way you tell them to. If you give them an idea of what you want, they will do a good job quickly. If you are not clear about what you want, they will still build something quickly, but it will be the wrong thing built. The tool cannot determine whether it is doing what it is supposed to. Only the engineer can do that.

In 2025, a METR study found that some experienced developers worked on their projects with and without AI tools. The developers thought they would be 24% faster with AI tools. After using the tools, they thought they were 20% faster. But the actual result shows that they were 19% slower. Researchers said this was mainly due to over-optimism about AI and lower AI reliability.

Also, folks from GitClear looked at 153 million lines of code. They found that when AI tools were used, there was four times more copied code and the code was changed more often. We are producing more and more code, but the question is what will really be needed.

Of course, AI models become better and better, but we still need to know what code is really needed and what isn’t.

When the engineer thinks carefully before using the AI tool, things are different. We can say that AI tools actually help good engineers do their job better. The better the engineer's plan is, the better the AI tools' results will be.

AI tools do not make everything equal. They make it so that engineers need to be even better at their job.

6. What thinking-first actually looks like

I want to be clear about this because saying “think before you code” can sound like a reason to have a lot of meetings and make documents that nobody actually reads. If we delegate problem-solving to AI, we skip the phase of understanding the problem. Bypass the “why” and jump into “how”. And this means if we don’t know how to assess architecture decisions, AI will just help us go faster in the wrong direction. And recent research from Anthropic confirms that.

What I found in all this hype about AI is that everyone is focused on execution, but no one is focused on thinking or decision-making. Defining products and problems will be more important than implementation in the future.

So, here is what I usually do: before I start writing code for something that’s not simple, I write one paragraph in a note. This paragraph answers:

• What is the real problem?

• Who does it affect?

• How will I know when it is fixed?

Half the time, writing this paragraph helps me find a problem that I did not know was there (because writing is best thinking). This helps close the gap, or keep it flat, as an assumption before I start.

For larger projects, I use a short document that outlines the problem, the options, and enables the following:

• Figuring out what the problem is. You have to know what you are trying to solve. Do not just listen to what the customer says they want. Look deeper into what they need.

• Understand the business. When you make decisions about technology, you are making business decisions. If you come up with a solution that’s really cool from a technical standpoint but doesn't help the business, it is a waste of time.

• Decompose. Find patterns and use abstraction to get rid of details that’re not important.

• Planning. The goal is to think things through in a way before you start working on the solution. The outcome goes in the document.

• Communicte. Get their feedback to make sure you are not missing anything. When you are working on a project, the requirements serve as a contract among the engineers, stakeholders, and users. If everyone is not on the page, the project can get out of hand, and you may miss your deadlines.

• Prototype to test assumptions. And here comes AI. Make the simplest version possible to see if it works before you put a lot of time and money into it. This way you can make sure that your idea is a one before you invest too much in it.

We should note that Google and Amazon also both do this. Amazon has a process called Working Backwards that requires a press release and a list of asked questions to be written before any code is written, before any money is spent, and before any new employees are hired. The goal is to stop ideas before they use up engineering resources. Most proposals are not approved. That is okay, as most proposals should not be approved.

7. The engineer’s real job description

The job of a software engineer in 2026 is not about writing a lot of code quickly. It is about understanding the problem and figuring out what we really need. This means turning ideas into clear technical requirements and asking questions that others might not think of.

It is also about making decisions on what to build and what to buy. A software engineer has to know what to skip and remember that every new feature is a risk. The engineer must consider whether the feature's benefits justify the cost of maintaining it.

Then, about architectural judgement. Deciding how to build software, in which direction. If we make this mistake early, it will be costly to fix it later.

Software engineers also have to keep an eye on the code that AI generates (for now). They have to review this code just like they would review code written by a new team member. This means catching mistakes that the AI might make because it does not understand the context. So, we still need to validate its output.

Sometimes the best thing to do is to remove code. This can actually be a feature.

AI can generate large amounts of code, but it cannot decide what code to generated at the first place. It cannot figure out whether a feature is really needed or weigh the pros and cons of a business decision. These things require human judgment. They are the harder parts of the job.

Being good at coding is still important. What that means is changing. It shifted to knowing when code is necessary and whether the generated code is correct in terms of business value. A software engineer has to understand how all the parts of a system work together.

8. Conclusion

The expensive mistakes in software do not come from simple coding errors. They come from trying to fix the issue.

When we really understand a problem, we write code to solve it. The hard work is in thinking, asking questions, and defining the problem. That’s where the real engineering happens. Everything else is just implementing the solution.

When you get a task assigned to you, take a moment to write down two things before you start coding: what is actually not working and how you will know when it is working correctly. If you make this a habit, it will make a difference in what you build than any tool or technology will.

The best software engineers have always known this. The code is the last part of solving a problem.

The best code is no code. And if you must code, remember: every line is a promise you’re making to the future.

If you liked this post, consider subscribing to email updates about my new posts or sharing it on Hacker News.

More ways I can help you

• 📱 You Can Build A LinkedIn Audience 🆕. The system I used to grow from 0 to 260K+ followers in under two years, plus a 49K-subscriber newsletter. You’ll transform your profile into a page that converts, write posts that get saved and shared, and turn LinkedIn into a steady source of job offers, clients, and speaking invites. Includes 6-module video course (~2 hours), LinkedIn Content OS with 50 post ideas, swipe files, and a 30-page guide. Join 300+ people.

• 📚 The Ultimate .NET Bundle. 500+ pages distilled from 30 real projects show you how to own modern C#, ASP.NET Core, patterns, and the whole .NET ecosystem. You also get 200+ interview Q&As, a C# cheat sheet, and bonus guides on middleware and best practices to improve your career and land new .NET roles. Join 1,000+ engineers.

• 📦 Premium resume package. Built from over 300 interviews, this system enables you to quickly and efficiently craft a clear, job-ready resume. You get ATS-friendly templates (summary, project-based, and more), a cover letter, AI prompts, and bonus guides on writing resumes and prepping LinkedIn. Join 500+ people.

• 📄 Resume reality check. Get a CTO-level teardown of your CV and LinkedIn profile. I flag what stands out, fix what drags, and show you how hiring managers judge you in 30 seconds. Join 100+ people.

• ✨ Join My Patreon community and my shop. Unlock every book, template, and future drop, plus early access, behind-the-scenes notes, and priority requests. Your support enables me to continue writing in-depth articles at no cost. Join 2,000+ insiders.

• 🤝 1:1 Coaching. Book a focused session to crush your biggest engineering or leadership roadblock. I’ll map next steps, share battle-tested playbooks, and hold you accountable. Join 100+ coachees.

Want to advertise in Tech World With Milan? 📰

If your company is interested in reaching founders, executives, and decision-makers, you may want to consider advertising with us.

Love Tech World With Milan Newsletter? Tell your friends and get rewards.

Share it with your friends by using the button below to get benefits (my books and resources).

Share Tech World With Milan Newsletter

Track your referrals here.

The book isn’t about programming, per se. It’s about the good engineering practices that Google has used over the years and decades to keep a healthy codebase.

In particular, it is about what happens after you write the code: how you evolve it, share it, test it, and eventually delete it.

Here’s what I learned:

• Software Engineering ≠ Programming. Programming is writing code. Engineering is asking what happens to that code over the next decade, and who pays the price when it breaks.

• Hyrum’s Law and the Beyoncé Rule. Every observable behavior of your system becomes someone’s dependency, whether you documented it or not. The fix? Test everything you care about, or don’t complain when it breaks.

• Shift Left. A bug caught in your editor costs seconds. The same bug in production costs your reputation. Google learned this the hard way with GWS in 2005.

• Code Review Is Not a Bug Filter. Most teams use it to catch bugs. Google uses it to transfer knowledge, enforce ownership, and keep a billion lines of code from turning into a mess. The mechanics are simple. The discipline behind them is not.

• Don’t Use Mocking Frameworks. Mocks test how something was done, not what actually happened. Google’s pendulum swung hard, and many engineers now avoid mocking frameworks entirely.

• Small Frequent Releases. A 3-line deploy is easy to debug, but a 50-commit mega-release is a weekend ruined. DORA research proves this isn’t just intuition.

• Upgrade Dependencies Early and Often. A patch bump is a coffee break. Three major versions behind is a quarter-long migration project. The math always favors staying current.

• Measuring Productivity. Google’s GSM framework (Goals, Signals, Metrics) prevents you from measuring what’s easy instead of what matters.

• The Culture Chapters. Psychological safety beats 10x developers. The genius myth is toxic. And “because I said so” is a leadership failure.

• What Doesn’t Work, Even at Google. Dependency management gave the authors nightmares. SemVer is an estimate, not a guarantee. And yes, the Google product graveyard is ironic.

• Now What? Here is a filter to decide which of these ideas actually fit your team and which don’t.

So, let’s dive in.

Your AI Writes Code Faster Than You Can Review It (Sponsored)

Code review is the bottleneck — slow, inconsistent, and noisy. Qodo is a multi-agent AI code review platform built to surface real issues, not noise. Specialized agents reason with the full codebase and PR history context. Benchmarked #1 in precision and recall. Now with rules that auto-discover your standards, enforce them in every PR, and measure adoption.

Try Qodo free

1. Software Engineering ≠ Programming

This is the core message of the entire book. Titus Winters described it in Chapter 1, and it changed how I think about my work. In general, we use terms like programming and engineering in the same or similar context, yet I always felt that this is not the same.

Programming is about producing code. You take a task and write code to solve it. You get the tests green, you ship them, and you move on.

Software engineering is what happens before and after that. It’s when you take that piece of code and start asking questions like:​

• Why are we doing this at all?

• How does this impact our users?

• How will this code evolve as requirements change?

• How does this scale, not just technically, but organizationally?

As Titus Winters puts it: “Software engineering is programming integrated over time.” That little phrase carries enormous weight. It means every line of code has a lifespan, and your job as an engineer is to think about the full cost of that lifespan, not just the fun part where you write it.

A quick script for a Black Friday marketing page? That’s programming. The payment system that will process millions of transactions over the next decade? That demands engineering.​

2. Hyrum’s Law and the Beyoncé Rule

These two concepts are my favorites from the book, and they come up together for a good reason.

Hyrum’s Law

It is probably the book's most cited concept. Named after Hyrum Wright (one of the book’s curators), the law states:

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

This sounds theoretical until it bites you. The classic example is hash iteration order. The Java HashMap API explicitly states that no orderings are guaranteed, but when Google attempted to update Java versions (which varied hash orderings), many tests failed. The engineers had written tests with assertions using containsElementInOrder() on HashMap outputs. Some people had even used hash iteration order as an inefficient random number generator. Google’s solution was defensive randomization, which means they altered their JDK to vary the hash iteration order each time it ran, making it impossible to rely on the unspecified behavior. Python and Go did this independently. So, we can learn from here that pointing fingers at engineers won’t fix the issue. It will make it impossible to make the mistake instead.

Hyrum’s Law applies outside the Google bubble. In 2024, Recall.ai released a change that prepended a colon to S3 URL paths. This is a completely valid character in a URL. The customers’ apps were broken because a transitive dependency (the yarl library) auto-normalized URLs by URL-decoding “safe” characters, which invalidated the S3 signature. No one had parsed the URLs directly. The dependency three levels deep had established an implicit contract.

Hyrum’s Law is essentially the software version of entropy. You can mitigate it, but you can never fully eliminate it. The more users you have, the more your implicit interface, the behavior nobody documents but everyone depends on, grows alongside your explicit one. This is why backward compatibility is so hard and why breaking changes are so expensive at scale.

The Beyoncé Rule

This rule says it simply: If you liked it, you should have put a test on it.

Let’s say that you fix a small bug’s not a big deal. But Joe from the billing team had been relying on that bug to make his code work. Now Joe’s stuff is broken. Who’s at fault?​

The Beyoncé Rule says: if Joe liked that behavior, he should have written a test for it. When your fix breaks his test, you see it immediately: “Oh, gotta fix Joe’s code too.” And because Joe tested everything he cares about, you can fix his code without needing to understand all its gnarly details.​

We introduced these practices in our projects, so when a bug is reported with a fix, we first write tests to prove that the bug was fixed. The test methods comment section included the Jira ticket number, so we could track it back to the bug itself.

The deeper lesson here is about shared ownership. In a large codebase, anyone might touch your code. Tests become a communication mechanism. They tell the rest of the organization what behaviors matter to you. Without tests, you’re relying on tribal knowledge, and that doesn’t scale.

3. Shift Left

This concept is simple but powerful: the earlier you find a mistake, the cheaper it is to fix.

Google Web Server (GWS), the Google Search engine infrastructure, was in a crisis state in 2005. More than 80% of the production pushes resulted in user-impacting bugs that had to be rolled back. The tech lead made it mandatory for the engineers to automate the testing of new code. Bugs were reduced by half within a year, despite record numbers of new changes. Today, GWS has tens of thousands of tests and releases every day with very few customer-visible failures.

This clearly explains Google’s testing philosophy. The book encourages a strongly lean test pyramid:

• ~80% small (unit) tests

• ~15% medium (integration) tests

• ~5% large (end-to-end) tests

Most importantly, Google tests are divided by size (resource usage), not the traditional unit/integration categorization. Small tests run in a single process, a single thread, and without any I/O, network, or disk access. Medium tests may use multiple processes on localhost. Large tests can run across machines. The important characteristics being optimized are speed and determinism.

Flaky tests get special mention. With Google’s 0.15% flakiness level, even a monorepo of that size still yields thousands of flakes per day. The book states that with ~1% flakiness, tests become useless altogether – engineers stop caring about them and begin to ignore failures.

Three cultural interventions distributed testing throughout Google. New employee orientation classes introduced testing as best practice – within two years, engineers trained in testing outnumbered the pre-testing culture:

• “Test Certified,” a five-level biannual program, encouraged 1,500+ projects to adopt testing procedures through a public dashboard that generated social pressure.

• “Testing on the Toilet” is a one-page testing advice posted in stalls starting in April 2006. They evolved into what the authors describe as “the longest-running and most profound impact of any of the testing initiatives.”

In practical terms, shifting left means adding many quality checkpoints into the development process:

• Static analysis happens in your editor. It finds typos, wrong function calls, and type mismatches in real time. Cost to fix: seconds.

• Unit tests take a few seconds to run. They verify your code does what you think it does. Cost to fix: minutes.

• Integration tests take a few minutes. They validate that your system’s components work together and can catch edge cases that unit tests miss. Cost to fix: an hour or so.

• Code review takes a few hours. It’s a human-powered quality gate that answers the question: Does this follow team norms? Is the approach sensible? This is also one of the best mechanisms for knowledge sharing on any team. Cost to fix: maybe half a day.

• QA takes hours or days. Everything works together as expected? Cost to fix: days, maybe a week.

• Users in production will find everything you missed, and expose you to edge cases you never thought possible. Cost to fix: potentially enormous, both technically and reputationally.

The further right you go, the more expensive the fix becomes. This is why Google invests so much in static analysis tools such as Tricorder, fast unit-test infrastructure, and pre-submit checks that run before code is even submitted for review. The hope is to find as much as possible before a human ever has to look at it.​

4. Don’t Use Mocking Frameworks

Chapter 13 in the book about test doubles is one of the most surprising in its recommendations: always choose real implementations over fakes and stubs, and use mocking only as a last resort. When mocking frameworks first came to Google, they “seemed like a hammer fit for every nail.” It was easy to write very focused tests. However, the price was paid later on, as tests became “something that required constant effort to maintain while rarely finding bugs.” The pendulum has now swung far in the other direction, with many Google engineers choosing not to use mocking frameworks at all.

The underlying issue with mocks is that they test how something was done, not what happened as a result. A test for a payment processor might check that the pay() method was called with the correct arguments in a mocked test, but it can’t tell you if the payment actually went through. A fake is a lightweight implementation that keeps track of state, allowing you to call processPayment() and then check getMostRecentCharge() to see what actually happened. Google went so far as to include an @DoNotMock annotation in their ErrorProne static analysis tool. When an API is mocked tens of thousands of times throughout the codebase, it “severely constrains the API owner’s ability to make changes,” because mocks are used in tests that violate the API contract in ways that real implementations and fakes simply can’t.

Here is the example with a mock:

Now the same test with a fake:

Now imagine this mock repeated 10,000 times across your codebase. Every refactor that changes how pay() it works breaks all of them, even if the payment still works perfectly.

The trade-off is that fakes must be invested in. The team that owns the real implementation should maintain the fake, using contract tests that verify against both. If there are only a few consumers, it may not be worth writing a fake. But for popular APIs, the boost to productivity is huge.

Here is an overview of mocks, stubs, and fakes:

5. Code Review Is Not a Bug Filter

Most teams treat code review as a quality gate. Someone checks your logic, clicks approve, and the change ships. That’s not what Google does, and the gap matters more than you’d think.

The book is explicit: checking code correctness is not the primary benefit Google gets from code review. The bigger payoffs are comprehension, knowledge sharing, and long-term maintainability. A change that succeeds but that no one else can understand is already a problem. Code that can’t be understood can’t be changed, and code that can’t be changed can’t be maintained.

The process is more formalized than most teams think: a peer LGTM (is this correct and understandable?), an owner sign-off (is this right for this part of the codebase?), and a readability approval (does it follow language standards?). One person can play all three roles, and often does. But breaking them out is important. Each role examines a different aspect, so no one reviewer has to grapple with the whole thing at once.

Two things make the entire system tick. Changes remain at 200 lines, and feedback is provided within 24 working hours. A third of Google’s changes affect a single file. Small changes are carefully read, but big changes are just skimmed. It’s just human nature, and Google designed the system to work with it, not against it.

The quote that has stuck with me the most is this: “If you’re writing it from scratch, you’re doing it wrong.” Code is a liability. Every line of code is a maintenance burden for the future. Code review is where this reality gets enforced, not as a punishment, but as a forcing function that just slows you down enough to ask yourself: does this need to exist, does it make sense to someone else, and will it hold up in two years?

On the human side, the book is clear: “You are not your code.” It is only natural to feel a sense of ownership over something you have created. The instant you submit code for review, the code no longer belongs to you. Every comment in a code review is a thing that needs to be done, not a criticism of the code. Even if you do not agree with a comment, explain why and ask the person to take another look at the code.

The book closes the chapter with five practices worth keeping on your wall:

• Be Polite and Professional. If something looks wrong, ask first. Don’t assume it’s a mistake. You might be missing context. And if you’re the author, treat every comment as a TODO, not a verdict.

• Write Small Changes. A 200-line diff gets read. A 2,000-line diff gets approved. Keep changes focused on a single issue, and the feedback you get back will actually be useful.

• Write Good Change Descriptions. The first line of your description shows up in email subjects, code search results, and future debugging sessions. “Fix bug” tells nobody anything. Write one sentence explaining what changed and why.

• Keep Reviewers to a Minimum. One reviewer is almost always enough. More reviewers means slower turnaround and diffuse responsibility. If you need a second opinion, ask for it explicitly.

• Automate Where Possible. Static analysis, formatting, test coverage, anything a machine can catch shouldn’t need a human reviewer’s attention. Save that attention for the decisions that actually require judgment.

6. Small Frequent Releases

A small release is easier to manage, understand, and revert. That’s the lesson. But it’s astonishing how many teams still batch up weeks of work into a giant deploy, then spend the next three days debugging what went wrong.

The logic is simple: when something breaks in production, a small release makes it obvious which change caused the problem. A giant release with 50 commits? Good luck finding the problem.

Google also tracks velocity in commits per second company-wide. To maintain this, they have invested in CI/CD infrastructure that makes it easy to deploy small changes. Feature flags enable them to separate “deploying code” from “turning on a feature,” so they can deploy code continuously even if the feature is not ready for end-users.

The research by DORA (DevOps Research and Assessment) confirms this with data: teams that perform continuous delivery, with daily or hourly releases, achieve superior results across all fronts: speed, quality, stability, and developer satisfaction.

Titus Winters explicitly references DORA's work as providing causal, rather than merely correlative, evidence that trunk-based development and continuous delivery lead to better technical outcomes.

7. Upgrade Dependencies Early, Fast, and Often

Same thing as releases, but for your third-party code.

Upgrading from version 4.5.8 to 4.5.9 is no big deal. It’s a patch version update, a quick test run, and you’re done. Upgrading from version 4.5.8 to 4.8.0 might need a few changes, some deprecated APIs, and a config change, but it’s doable in an afternoon.

But upgrading from 4.5.8 to 7.0.0? Oh boy, it’s gonna hurt. Even if all the intermediate versions were backward-compatible, the sheer difference can still be huge. The implicit interfaces (Hyrum’s Law strikes again!) have changed so much that it’s a project in itself to upgrade.

The book is clear about this: “The hardest unsolved problem in software engineering is dependency management.” Google’s monorepo system is a big help in this regard, but for the rest of us, the best solution is simple: keep your dependencies as up to date as possible. Smaller, more frequent updates are always cheaper than larger, less frequent migrations.

One powerful insight from the book: the expert should make the update, not the consumer. If you deprecate a function, don't just tell everyone "please upgrade." They won't. You go into their code and make the update yourself. You're the expert on what needs to change; you'll do it fast. Everyone else has to context-switch, read the migration guide, find time in their sprint... it'll never happen.

8. Measuring productivity is a must

Chapter 11 deserves its own section because the framework it introduces is the Goals/Signals/Metrics (GSM) framework. This is one of the most immediately useful tools in the entire book.

Before measuring anything, Google's research team asks a series of triage questions: Is this worth measuring? Will the result change a decision? Does the decision-maker trust the type of data we'll produce? If the answer to any of these is "no," they don't waste the effort. This alone is a radical idea in an industry obsessed with metrics.

The GSM Framework

When measurement is worthwhile, they structure it in three layers:

• Goal: The desired end result, phrased without reference to any specific metric. (”Engineers write higher-quality code.”)

• Signal: How you’d know you’ve achieved the goal, what you’d like to measure, even if you can’t. (”Engineers report learning from the process.”)

• Metric: A measurable proxy for the signal, what you actually measure. (”Proportion of engineers reporting they learned about four relevant topics, via survey.”)

The power of GSM is that it prevents the streetlight effect, measuring what’s easy to measure rather than what matters. By starting with goals and working down, you ensure that your metrics trace back to something meaningful.

QUANTS: The Five Dimensions

Google’s research team divides productivity into five components to ensure that improving one dimension doesn’t quietly degrade another:

• Quality of code: What is the quality of the code produced?

• Attention of engineers: Can engineers reach a flow state? Are they distracted?

• iNtellectual complexity: How much cognitive load does a task require?

• Tempo and velocity: How fast can engineers complete their work?

• Satisfaction: How happy are engineers with their tools, products, and work?

The book's sharpest warning concerns individual measurement: "If productivity metrics are used for performance reviews, engineers will be quick to game the metrics, and they will no longer be useful." The only way to make these measurements work is to measure aggregate effects, never individuals. Google's productivity research team includes behavioral economists specifically to understand incentive structures and prevent Goodhart's Law from corrupting their data.

One surprising finding: "It has routinely been our experience at Google that when the quantitative and qualitative metrics disagree, it was because the quantitative metrics were not capturing the expected result."

The critical takeaway: if a measurement isn’t actionable, it isn’t worth taking. After every research study, Google’s team prepares a list of concrete recommendations: a new tool feature, a documentation improvement, a process change. If the result can’t drive an action, the measurement was wasted.

9. The Culture Chapters: The Stuff Nobody Wants to Talk About

The first several chapters of the book address culture: teamwork, knowledge sharing, psychological safety, and leadership. As Titus Winters noted in his GOTO talk, software engineering has always been about two things: time and people. We teach engineers to code on their own, but once they join a team, it becomes a team sport.

Some ideas that resonated with me:

• The Genius Myth is toxic. True success is achieved through team effort, not by a single 10x developer. The Genius Myth is just another manifestation of our insecurity. The book cites Project Aristotle, Google’s famous study that discovered psychological safety is the most critical component of an effective team.​ Read here why and how this impacts engineering teams:

  Tech World With Milan Newsletter

  Why do some engineering teams consistently outperform others?

  What makes a great team stand out? It’s not just technical skills or years of experience—it’s something deeper. Over two decades, I’ve seen how some teams thrive while others struggle, and the difference often comes down to how people interact, communicate, and support each other. Building a high-performing team requires more than just assembling talent…

  Read more

  a year ago · 44 likes · 3 comments · Dr Milan Milanović

• “Because I said so” is a leadership failure. If there’s disagreement, explain your reasoning. Lead people to a change in decision-making through teaching, not authority. As leaders, we always have power and authority, but we should not enforce it. From my experience, knowledgeable people are more likely to work with leaders who are facilitators (servant leaders) rather than authoritarians.

• Ask dumb questions. Titus describes chairing a C++ standards subcommittee and deliberately asking naive questions to ensure everyone in the room had truly re-learned the material before voting. Modeling that it’s OK to not know things creates a culture where people actually learn.​

• Delegate to the most junior person who can handle it (with appropriate oversight). This is a direct counter to Fred Brooks's “surgical team” model. The team grows, and the senior engineers get freed up to tackle the next impossible thing.​

• The reason most teams don’t fail because of bad code is that they lack trust. We can go back far enough in any team conflict, and you’ll find a crack in one of three things: humility (you believe your way is the only way), respect (you stopped caring about the person, not just the work), or trust (you’d rather do it yourself than let someone else drive).

• Learn from your mistakes by documenting them. When something bad happens, like an incident, create a postmortem. A postmortem isn’t about blame, but about recording the truth while it’s still hot. Inside, we should include the entire timeline, the actual root cause (not something generic like “human error”), and finish with action items that have real people and real deadlines. The lessons section is where most teams skimp. That’s a problem. That’s the part that makes the next incident shorter.

Taking all of this into account will lay the foundations on which your team can create significant value and not lose control when things get hard.

10. What the authors admit doesn't work, even at Google

Titus Winters is remarkably clear about the book’s limitations. In a GOTO podcast interview, he describes the dependency management chapter as giving him “literal nightmares”: there are many ideas about what doesn’t work, but no clear, cheap, scalable solution. His guiding principle: “I prefer any number of version control problems over a single dependency management problem.” The book’s critique of semantic versioning is pointed: SemVer is fundamentally an estimate, not a proof of compatibility. A major version bump due to a breaking change in the function Bar falsely blocks upgrades for consumers who only use the function Foo. And patch versions, supposedly safe, routinely violate Hyrum’s Law.

Winters also admits the culture chapters are “a little bit aspirational”; they don’t perfectly describe Google’s reality. Critics note the irony of Google recommending “don’t release things without a plan to support them long-term” while maintaining a notorious product graveyard.

On the what I missed side, we can say that one of the book’s “real weaknesses” is its rare provision of empirical evidence for its claims beyond “it works for Google.” With this, the book would have had much greater value than it does.

11. Practical Takeaways You Can Apply Tomorrow

Not every Google practice translates to every organization. The authors themselves are explicit about this: don’t blindly copy what Google does. Understand the why behind their methods and adapt the what to your context.

That said, here’s what’s universally actionable:

• Write tests for everything you care about. The Beyoncé Rule works at any scale.

• Review the process, not just the code. Define who gives sign-off on correctness, ownership, and readability on your team. If one person is doing all three for every change, that's a bottleneck.

• Invest in your build system and CI pipeline. The ROI compounds over time.

• Ship smaller, more frequently. Whatever your current release cadence is, try halving it.

• Keep dependencies fresh. Set up Dependabot or Renovate and stop ignoring those PRs.

• Replace mocks with fakes where possible. Your test suite will thank you.

• Measure with intent. Use the GSM framework before creating any new dashboard or metric.

• Treat documentation like code. Review it, maintain it, deprecate it when it’s stale.

• Create psychological safety on your team. It’s the foundation on which everything else is built.

The book is available for free at abseil.io/resources/swe-book, and it’s one of the best investments of reading time for any software engineer or tech lead.

Bonus: The Top 100 Software Engineering Books on Goodreads

I analyzed the top 100 software engineering books on Goodreads, and here are the results.

• The most-read book isn’t the highest-rated. The Phoenix Project has 49,000+ ratings at 4.26. Clean Code has 23,000+ at 4.36. “Designing Data-Intensive Applications” beats both with a 4.7 and only 10,000 ratings.

• Old books still deliver. K&R’s “The C Programming Language” (1978) has a rating of 4.44. “Structure and Interpretation of Computer Programs” (1984) scores 4.47. The classics aren’t nostalgia, they’re still the standard.

• System design content is rising fast. Alex Xu’s System Design Interview books both rank in the top 15. Five years ago, these didn’t exist.

• The bottom of the list is telling. “Effective DevOps” sits at 3.41. Some architecture pattern books hover around 3.7. High expectations, mixed execution.

The full visualization shows all 100 books ranked by rating, color-coded from green (4.7) to red (3.4).

Here is the full list.

More ways I can help you

• 📱 You Can Build A LinkedIn Audience 🆕. The system I used to grow from 0 to 260K+ followers in under two years, plus a 49K-subscriber newsletter. You’ll transform your profile into a page that converts, write posts that get saved and shared, and turn LinkedIn into a steady source of job offers, clients, and speaking invites. Includes 6-module video course (~2 hours), LinkedIn Content OS with 50 post ideas, swipe files, and a 30-page guide. Join 300+ people.

• 📚 The Ultimate .NET Bundle 2025. 500+ pages distilled from 30 real projects show you how to own modern C#, ASP.NET Core, patterns, and the whole .NET ecosystem. You also get 200+ interview Q&As, a C# cheat sheet, and bonus guides on middleware and best practices to improve your career and land new .NET roles. Join 1,000+ engineers.

• 📦 Premium resume package. Built from over 300 interviews, this system enables you to quickly and efficiently craft a clear, job-ready resume. You get ATS-friendly templates (summary, project-based, and more), a cover letter, AI prompts, and bonus guides on writing resumes and prepping LinkedIn. Join 500+ people.

• 📄 Resume reality check. Get a CTO-level teardown of your CV and LinkedIn profile. I flag what stands out, fix what drags, and show you how hiring managers judge you in 30 seconds. Join 100+ people.

• ✨ Join My Patreon community and my shop. Unlock every book, template, and future drop, plus early access, behind-the-scenes notes, and priority requests. Your support enables me to continue writing in-depth articles at no cost. Join 2,000+ insiders.

• 🤝 1:1 Coaching. Book a focused session to crush your biggest engineering or leadership roadblock. I’ll map next steps, share battle-tested playbooks, and hold you accountable. Join 100+ coachees.

Want to advertise in Tech World With Milan? 📰

If your company is interested in reaching founders, executives, and decision-makers, you may want to consider advertising with us.

Love Tech World With Milan Newsletter? Tell your friends and get rewards.

Share it with your friends by using the button below to get benefits (my books and resources).

Share Tech World With Milan Newsletter

Track your referrals here.

The problem is that most knowledge in our industry has a short lifespan. Most frameworks peak between 2 and 5 years. When you become really good at that technology, it could already become a legacy.

With the rise of AI code generators, it has accelerated much faster than before. People are vibe-coding with technologies they never learned properly.

On the other hand, people who invest in fundamentals can quickly adopt new technologies because they understand the underlying principles. So, instead of rushing to learn a new framework this month, we should spend more time learning things that don’t change.

In the rest of the article, we are going to talk about:

1. Framework lifecycles really are short. If you’ve been around long enough, you’ve watched popular frameworks rise, peak, and fade within a few years. The data clearly shows this: Frontend frameworks have a half-life measured in months.

2. Why fundamentals matter. Programming languages differ, but bad naming is bad everywhere. Frameworks change, but design patterns don’t. When your app has problems in production, the answer never comes from the docs. It comes from understanding how things actually work and learning from that.

3. AI amplifies fundamentals and exposes their absence. AI writes 41% of code today, but it can’t make architectural trade-offs or read between the lines of a business requirement. Without fundamentals, debugging AI-generated code is just guessing.

4. Meet the Expert Generalist. Every wave of automation was supposed to replace developers: compilers, cloud, and now AI. Instead, each one raised the bar. The developers who thrive aren’t prompt engineers, but generalists who understand systems, trade-offs, and intent.

5. The 80/20 Rule of Learning. Spend 80% of your learning time on fundamentals and 20% on frameworks. You’ll pick up frameworks on the job anyway. Nobody’s going to teach you distributed systems or clean architecture for you.

So, let’s dive in.

Multi-Agent Code Review That Catches Real Issues (Sponsored)

Code review's been stuck. Either it's slow (manual), noisy (AI tools), or misses critical things. Qodo 2.0 is different. With the highest precision & recall, it finds critical issues that other code review tools miss, while limiting noise. By learning from your codebase & PR history, Qodo provides fixes that developers actually use.

Learn how

1. Framework lifecycles really are short

If you’ve been around this industry long enough, you’ll have witnessed many a framework come and go. Ever heard of frameworks like GWT, Apache Tapestry, Backbone.js, or Knockout.js? Yes, they were very popular back in the day, and you needed to read a lot of docs to understand them.

An analysis by Stack Overflow of JavaScript framework traffic clearly shows this trend. The rise, peak, and gradual decline all occur within a couple of years. Around 2011, Backbone, Knockout, and Ember were the ‘it’ frameworks. By 2015, Angular 1.x was no longer supported, and Angular 2.0 required developers to rewrite their applications.

There’s even a hierarchy of technology longevity: language choices last 10+ years, databases 7–10 years, backend frameworks 3–5 years, and frontend frameworks around 18 months. If you’re debating all of those equally, you’re just wasting time.

The data on the code half-life also confirms this. Erik Bernhardsson has analyzed 26+ open-source projects and calculated a median half-life of 3.33 years. Frontend frameworks such as Angular are at the very short end of this scale, at just 0.32 years, whereas Linux has a figure of 6.6 years. Again, the further up the stack you go, the shorter the lifespan becomes.

2. Why fundamentals matter

When you understand fundamentals, you understand the principles and concepts on which various frameworks and programming languages work. This helps you become adaptable and flexible in programming, using various technologies, or when the framework you’re using fails to do something.

Programming languages differ, yet design smells are similar across them. Bad naming is bad in all languages. Frameworks are different, while design patterns are similar. Technological stacks differ, but the principles of concurrency, data structures, distributed systems, and clean architecture are similar.

A good understanding of fundamentals helps you use these frameworks in a more efficient and effective manner, since you also know how to make those frameworks suitable for what you need. You’re not just following a tutorial, but you are understanding what is happening under the hood.

Take, for instance, the web application that allows users to upload/share images. Let's suppose this web application was written using a popular web framework, such as Ruby on Rails. Maybe you vibe-coded it fast, and it works well at the start. But over time, as your user base grows, you hit performance issues. Now, what do you do? Identifying root cause is not easy, as you need to understand how your code works on the infrastructure, what is happening there, how to read logs (and understand them), etc. A developer who knows fundamentals can identify such a bottleneck and propose a solution, e.g., use CDN, optimize image shares, add (proper) caching, use a different kind of storage, etc.

So, the solution doesn’t come from the docs or coding agents. It comes from a deep understanding of how things work.

Can you learn fundamentals through frameworks?

We should note that frameworks can be a good way to learn basic concepts, like when learning Ruby with Rails, you can learn about ACID, ORMS, etc. Learning a thing or two about functional programming with React too, or learning CSS with Bootstrap.

There is also the fact that nobody really does everything from first principles. You didn’t learn programming by reading papers by Turing. You learned it in a welcoming environment where you can experiment and get immediate feedback. The famous debate between Knuth and McIlroy tells us everything we need to know. Don Knuth wrote a 10-page literate programming document from first principles for a word-frequency counter. Doug McIlroy solved it in a 6-line shell script using Unix tools. “If we did everything from first principles, then nothing would get done.”

And then of course there’s the deeper question: what exactly are “Fundamentals” anyway? Some will say it’s algorithms and math, others will point to software engineering, which encompasses design, testing, deployment, and lifecycle issues.

The distinction between “Fundamentals” and “Frameworks” is much less clear than we think.

3. AI amplifies fundamentals and exposes their absence

With AI tools generating an estimated 41% of all code today, you might think the fundamentals matter less. Why would we bother to understand what’s underneath if AI writes the code?

Because AI writes code, but you own the responsibility.

AI coding assistants are great for syntax, boilerplate code, and pattern suggestions. However, they’re bad with context. They don’t attend the meetings where the senior leadership team talks about cost vs. performance. They don’t understand that a customer service system has to be designed for five 9s, whereas the in-house dashboard can tolerate downtime. They can’t read between the lines when someone says the application has got to be fast, but really they mean “make it cheap.” They cannot connect the dots.

The statistics show the risks, too: 48% of AI-generated code is at high risk of security vulnerabilities, and defects are 1.7 times more likely to be found in AI-generated code without proper review. Only 33% of developers trust AI-generated code completely. That means most AI code needs the same scrutiny as junior developer code. Someone has to understand it enough to catch what's wrong.

Debugging, reviewing, and validating AI code have thus become crucial skills, and you cannot do them without a strong foundation!

Without fundamentals, debugging code written by an AI is almost impossible. You won’t be able to explain why a program is working, when a program will fail, or even be able to adjust a program to work for unknown scenarios. Your AI helper could help, but it also leads you to the wrong road, where the price of fixing it would be too high.

So, we can say that the most valuable developers in the age of AI are not those who can generate the best prompts. It is someone who knows what is happening behind the scenes. Someone who knows they can take output from AI and improve it, and secure it against long-term failure.

AI without fundamentals is a liability.

4. Meet the Expert Generalist

Every great advance in program development has followed the same pattern. Early assembly-language programmers were told that the existence of compilers would leave them behind. Instead, it enabled them to develop at a much higher level of abstraction. The operations engineer was told that cloud computing would put their profession out of business. Instead, it has enabled an explosion of new projects, companies, and engineering jobs.

​This is the same with AI. Lowering barriers to entry doesn’t eliminate the need for skills; it increases it. As AI does more and more of the code, inevitably, there is less and less of the hard work left for humans: “understanding systems, making architectural decisions, making trade-offs, and expressing intent.”

This is well explained by the Jevons Paradox. In 1865, economist William Jevons had observed something interesting: as steam engines became more efficient at burning coal, coal consumption went up, not down. Why? Efficiency unlocked new use cases. Suddenly, coal made economic sense for industries that had been unable to afford it before.

This effect is now showing in tech. As the costs of AI tokens dropped 10x, usage went up 100x. Companies now use more tokens per task because they can afford higher accuracy.

As Renaissance scholars pioneered the integration of the arts, sciences, and engineering, developers who excel in this AI-enhanced world must reinvent themselves as polymaths, as Werner Vogels notes in his article “The Dawn of the Renaissance Developer”. They realize that systems are living, dynamic environments that constantly change, affecting services, APIs, databases, infrastructure, and human interactions. They are masters of what they produce, in terms of quality, safety, and intent. They are also knowledgeable in areas where AI cannot assist.

That said, we need to become Expert Generalists by improving our curiosity, systems thinking, systems design, architecture, communication skills, ownership, business acumen, and more. Also, we need to become good at code verification and review, because when AI makes mistakes, we need to know how to handle them.

The “expert generalist” might be thought of as an engineer who can walk into a messy new problem, quickly understand the system, identify the right levers, and solve it without hand-holding, weeks later. Not a jack-of-all-trades, but a high-agency connector with depth in all the important areas.

5. The 80/20 Rule of Learning

So, how do you schedule your learning time to accomplish this? Well, there is a powerful heuristic to consider: 80 percent of your learning time should be spent on fundamental topics, and 20 percent on frameworks, libraries, and tools.

Why? Well, because you’ll probably end up learning all those frameworks on the job, dealing with real-world problems. Nobody will teach you patterns for distributed computing, clean code, and good system design on the job. That’s all on you.

When you start to learn something, think about how the Lindy Effect affects it. This effect states that the longer something has been in use, the more likely it is to continue being used. C, SQL, HTTP, and REST are decades old, but still everywhere. That hot new framework will probably be gone in two years. So don't rush to learn every new tool.

Remember, time is your best filter. Invest in fundamentals that transfer across jobs, teams, and domains. Let the hype settle. What survives is worth learning.

So, when talking about the fundamentals, these are the basics that are worth your time reading about:

• Algorithms. The fundamentals of problem-solving. One should always be aware of time and space complexity when making trade-offs, whether or not you are coding a sorting algorithm.

• Data Structures. Understanding when to use a hash map, a tree, a queue, etc., is like the difference between writing code that works and writing code that works well.

• Software Design & Architecture. Patterns such as MVC, microservices versus monoliths, SOLID principles, and clean, modular code guide how to organize a system. A developer who can design clean abstractions and APIs can adopt any framework, since good design logic doesn’t change.

• Design Patterns. Frameworks come and go, but patterns like Observer, Strategy, and Factory seem ubiquitous. Once you recognize these, they seem to pervade all frameworks.

• Distributed Computing Patterns. In the age of Microservices and Cloud Native Applications, knowledge of the CAP Theorem, Eventual Consistency, and Fault Tolerance is vital.

• Testing. Knowing the ins and outs of writing good tests, the concept of test pyramids, and TDD gives you the courage to refactor and change code without fear.

• System Design. Arguably, the biggest value of this skill, and one that cannot be understated, begins at the senior level and beyond.

• Clean Code. Writing code that other humans (and future you) can understand. That skill is what compounds most over a career.

If you’re really serious about investing in fundamentals, the following books have stood the test of time and will continue to do so:

• The Pragmatic Programmer by David Thomas and Andrew Hunt is the classic guide to craftsmanship in software development. It’s about thinking about how to construct software, not just about writing it.

• Code Complete 2 by Steve McConnell: The bible of software construction. Pretty dense but very practical and applicable for any language and stack.

• Designing Data-Intensive Applications by Martin Kleppmann. It explains how distributed systems work, covering storage engines, replication, partitioning, transactions, and consistency models. Here you can learn why your database behaves the way it does and how to build systems that scale without falling apart. Check my detailed review of the book.

• Design Patterns: Elements of Reusable Object-Oriented Software by the Gang of Four. The original patterns book. Some patterns have fallen out of favor, but understanding them gives you a vocabulary for discussing design across any team or technology.

• Introduction to Algorithms by Cormen, Leiserson, Rivest, and Stein (CLRS)- The bible of algorithms. You don’t have to read it cover to cover, but it is worth keeping on your shelf and referring to it regularly.

• Clean Code by Robert C. Martin. Opinionated and sometimes controversial, but its core message about writing readable, maintainable code is universal.

Check my full book recommendations for the books that learn you fundamentals:

Tech World With Milan Newsletter

Learn things that don't change

Have you ever wondered why some technologies are still around, and some have disappeared? The Lindy effect tells me developers will still use C# and SQL when I retire. This concept in technology and innovation suggests that the future life expectancy of a non-perishable item is proportional to its current age. In other words…

Read more

2 years ago · 1127 likes · 24 comments · Dr Milan Milanović

As well as my short book on 100+ books that changed my life.

6. Conclusion

The next time you feel tempted to spend your weekend learning the latest “hot” framework, take a step back and ask yourself: Will this be relevant in five years’ time?

Of course, frameworks come and go, and JavaScript has an overfilled graveyard of them. AI is churning out code by the minute, and while some developers are limited to programming strictly within the rules of their specific framework, they will soon be passed by. Not by AI, but by other developers who grasp what is actually happening under the hood.

Learn your frameworks, as it’s necessary to ship. But the actual meat should be the fundamentals. That’s all that carries across companies, teams, and over the decades. And they don’t expire.” In an age when AI writes code for you, fundamentals are the only things that make you adaptable and resilient.

Remember, frameworks will come and go, but the underlying principles of good design will always stay. Focus on fundamentals. They don't expire, and they make learning new tools much easier.

Bonus: The Missing Semester of Your CS Education by MIT

Check this free course at MIT called “The Missing Semester of Your CS Education” that covers topics no one ever tells you about: the shell, Git, debugging, profiling, continuous integration, and setting up a development environment.

The kind of skills that people use every single day, and that they had to figure out on their own.

All lectures are available online and have video recordings. It has been translated into 14 language varieties, including Serbian.

Worth bookmarking, whether you’re a junior dev or a senior engineer looking to fill in the gaps.

The Missing Semester

More ways I can help you

• 📱 You Can Build A LinkedIn Audience 🆕. The system I used to grow from 0 to 260K+ followers in under two years, plus a 49K-subscriber newsletter. You’ll transform your profile into a page that converts, write posts that get saved and shared, and turn LinkedIn into a steady source of job offers, clients, and speaking invites. Includes 6-module video course (~2 hours), LinkedIn Content OS with 50 post ideas, swipe files, and a 30-page guide. Join 300+ people.

• 📚 The Ultimate .NET Bundle 2025. 500+ pages distilled from 30 real projects show you how to own modern C#, ASP.NET Core, patterns, and the whole .NET ecosystem. You also get 200+ interview Q&As, a C# cheat sheet, and bonus guides on middleware and best practices to improve your career and land new .NET roles. Join 1,000+ engineers.

• 📦 Premium resume package. Built from over 300 interviews, this system enables you to quickly and efficiently craft a clear, job-ready resume. You get ATS-friendly templates (summary, project-based, and more), a cover letter, AI prompts, and bonus guides on writing resumes and prepping LinkedIn. Join 500+ people.

• 📄 Resume reality check. Get a CTO-level teardown of your CV and LinkedIn profile. I flag what stands out, fix what drags, and show you how hiring managers judge you in 30 seconds. Join 100+ people.

• ✨ Join My Patreon community and my shop. Unlock every book, template, and future drop, plus early access, behind-the-scenes notes, and priority requests. Your support enables me to continue writing in-depth articles at no cost. Join 2,000+ insiders.

• 🤝 1:1 Coaching. Book a focused session to crush your biggest engineering or leadership roadblock. I’ll map next steps, share battle-tested playbooks, and hold you accountable. Join 100+ coachees.

Want to advertise in Tech World With Milan? 📰

If your company is interested in reaching founders, executives, and decision-makers, you may want to consider advertising with us.

Love Tech World With Milan Newsletter? Tell your friends and get rewards.

We are now close to 50k subscribers (thank you!). Share it with your friends by using the button below to get benefits (my books and resources).

Share Tech World With Milan Newsletter

Track your referrals here.

Across the teams I’ve led and coached, the same loop keeps showing up. Developers judge themselves by an eight-hour ideal, then feel behind when only a few hours produce real output. But high-focus work has a ceiling. Treating 3 to 4 hours as the primary objective leads to better software and less burnout.

In the rest of the article, we are going to talk about:

1. The cognitive ceiling. Research by Ericsson, Mark, and Newport shows that 3-4 hours is the daily maximum for concentrated effort. Beyond that, diminishing returns.

2. Where developer time actually goes. Data reveal that the median coding time is 52 minutes/day. Meetings consume 11+ hours per week, pushing peak coding to the afternoons when mornings should be prime.

3. The cost of interruptions. 23 minutes to recover from one interruption. For programmers, 30-45 minutes to rebuild the full context. A single meeting can destroy an entire afternoon.

4. Flow as a force multiplier. Csikszentmihalyi’s research: 500% increase in productivity in the flow state. But flow requires 15-25 minutes of uninterrupted time just to begin.

5. Strategies for deep work. There are four strategies of deep work listed by Newport: Monastic, Bimodal, Journalistic, and Rhythmic, and some practical techniques are time-blocking, batch communication, and focusing on

6. Why managers should care. Protecting manager time is more valuable than adding more processes. No-meeting days, async defaults, and reasonable deadline setting provide big wins for cycle time and quality.

So, let’s dive in.

1. The cognitive ceiling is real, and lower than you think

Cal Newport, a full-time professor of computer science at Georgetown University and author of the excellent “Deep Work” book [1], describes “deep work” as “professional activities performed in a state of distraction-free concentration that push your cognitive capabilities to their limit”. When you are in such an optimal state, you’re not only completing high-leverage work in an efficient way, but it’s also being done at an optimal quality. It’s a bit like being in “flow” or being “in the zone”, a state described in psychological terms as “Csíkszentmihályi” (full absorption and energized focus)!

But here’s the challenge: such mental strains can be limited. Newport shows us that most individuals should expect that they can perform what Newport refers to as “deep work” for an average of four hours per day.

Of course, this is further substantiated by traditional psychological research by K. Anders Ericsson, one of America’s most prominent psychological researchers. Ericsson studied competitive violinists [2], showing that they indeed engaged in “concentrated blocks of practice, or 4 hours of concentrated effort, before they became tired.” So, despite what certain individuals set as their objective, four hours of concentrated “deep work” is obviously an apex after which one’s performance naturally declines significantly.

Software development isn’t any different. Coding, particularly creative problem-solving or architecting systems, is mentally intensive work. Pushing beyond the 3-4 hour mark for sustained, high-concentration coding usually leads to diminishing returns. I’m sure you’ve felt it-that late-afternoon slowdown where you’ve been staring at the screen but not actually producing much.

The pattern repeats across different domains. Famous mathematician Henri Poincaré worked 2 hours in the morning and 2 hours in the evening. G.H. Hardy only worked mornings. Charles Darwin, B.F. Skinner and C.S. Lewis both worked in 3-4 hour writing schedules.

Gloria Mark’s attention research at UC Irvine [3] paints an even clearer picture. Her findings discovered we now spend an average of just 47 seconds on any screen before shifting attention, down from 2.5 minutes in 2004. “Our minds are just not equipped to be able to focus for long extended periods of time,” Mark says. “We have limited attentional resources or cognitive resources.”

2. What developers actually do with their time

The difference between perceived and actual coding time is interesting. An analysis by Software.com of more than 250,000 developers [4] found that the median developer spends only 52 minutes per day writing or editing code, or about 4 hours 21 minutes per week. Only 10% of developers code for more than 2 hours a day, while 40% code for more than 1 hour.

Where does the time go? Software engineers typically have 10.9 hours of meetings each week, according to an analysis of 1.5 million meetings done by Clockwise [5].

Engineering managers spend 18 hours in meetings each week, almost half of a standard 40-hour workweek. Developers at large organizations have 12.2 hours of meeting time each week, whereas developers at smaller organizations have 9.7 hours.

After a day of “meetings,” “admin,” “code reviews,” and “collaboration,” engineers have a mere 19.6 hours of focus left each week, most of it in unusable chunks.

Peak coding time shows how meetings eat mornings. Software.com found that 45% of all workday coding occurs between 2 pm and 5 pm, while only 10% occurs between 9 am and 11 am. Developers are not naturally afternoon coders. Their mornings are just consumed by standups, syncs, and ceremonies. As the report itself notes, “If more companies protected mornings, we might see an increase in the global average code time per day.”

3. The high cost of interruptions

An interruption, however, comes with a hidden cost. According to Gloria Mark’s research [3], it takes a person exactly 23 minutes and 15 seconds to fully resume a prior task after an interruption.

For programmers, however, this cost is much higher. According to research conducted at Georgia Institute of Technology [6], it takes 10-15 minutes for programmers to resume their work by starting to edit their code, but a full rebuilding of their prior mental context takes 30-45 minutes.

This dynamic is captured perfectly by Paul Graham in his influential 2009 essay on the maker’s schedule: “For someone on the maker’s schedule, having a meeting is like throwing an exception. It doesn’t merely cause you to switch from one task to another; it changes the mode in which you work.”

A single meeting doesn’t just destroy its allotted time; it “can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.” Even anticipating an afternoon meeting makes developers “slightly less likely to start something ambitious in the morning.

Learn more about why context-switching is the main productivity killer:

Tech World With Milan Newsletter

Context-switching is the main productivity killer for developers

Have you ever wondered what the biggest productivity killer for developers is? There are many, but one stands out—and it’s often underestimated…

Read more

a year ago · 168 likes · 8 comments · Dr Milan Milanović

4. Flow state: the programmer's force multiplier

Mihaly Csikszentmihalyi, in his research [7][8] identify flow, which is “the state of being completely involved in an activity for its own sake, when the ego disappears and time flies by.” This illustrates the importance of protecting time for deep work. His 10-year study found that people achieved a productivity rate 500% higher when in a flow state than in a normal state.

Flow, for a software developer, means the difference between tedium and breakthroughs.

Csikszentmihalyi found that the balance between challenge and skill was the key to flow, or its absence. The absence, in other words, of too much or too little challenge causes one or the other.

Therefore, it can be stated that Flow, or deep focus, is one of the most powerful predictors of high performance in software teams. Teams that frequently feel they can deliver more value, more quickly, and with greater satisfaction. But most engineers rarely feel it.

Flow is not something that occurs naturally. It requires protection from the forces that drain it.

5. How to get in the flow while coding

Given that 3-4 hours of deep coding is probably the most one can hope for, the objective should then be to make every minute of that time count. The key is effective time management and setting boundaries around one’s schedule.

Here are some things that have personally worked for me and have also been effective for the teams that I manage:

1. Create a distraction-free environment. Close Slack. Silence notifications. Use visible status indicators to signal deep work mode. Even seeing a notification breaks concentration, even when you don’t respond to it.

   

2. Set clear goals before every coding session. Not “work on the backend” but “make the authentication endpoint return proper error responses.” The aspect of specificity allows for clear engagement with what one wants to achieve. Before the actual engagement, one should be clear about what “done” means.

3. Tackle hard problems during peak cognitive hours. The “research on circadian rhythm [9] reveals that cognitive performance can vary by as much as 9 to 40 percent depending on the time.” The most relevant fact for programmers is that “most adults experience their best problem-solving skill during mid-morning to early afternoon (about 10 am-2 pm). Afternoon energy wanes after lunch, but then surges again during late afternoon.” Evening people, known as “owls”, peak at different times than morning people, ”larks.” Code most intensely at your “personal cognitive peak” but protect those times “ruthlessly.”

4. Time-block for maker schedules. Proactively block 2-4 hour chunks on your calendar for deep work. Cluster meetings at the end of the day or on specific days. Set one goal for each work block, and break it into three actionable tasks. Focus on one task at a time. After work sessions reflect, do you need to change the length of time, do some tasks before others, etc. Here is an example of how I structure my day for deep work:

   

5. Eliminate context switching. Context switching is the biggest productivity killer. Batch out two communication windows a day rather than trying to be immediate responders. Close browser windows that aren’t relevant to the current task underway. Treat your attention as the scarce resource it is.

   

6. Work in focused sessions, not marathon sprints. The usual 25-minute pomodoro schedule is entirely inadequate for complex development tasks, just enough time for entering flow state before you are timer-interrupted. Take your breaks between intervals. The aim is for maximum quality, not maximum hours, within your cognitive abilities.

   

7. Reflect and compound your learning. Ericsson’s research on deliberate practice attests that it’s not time on task but reflective thinking that can produce expertise. One can conclude each in-depth coding session by mindful reflection on what worked, what got in my way, and what I will try differently tomorrow.

Four Deep Work Strategies

In this book, Cal Newport identifies four methods for incorporating deep work into your schedule [1]. Each depends on how much control you have over your time, and how long you can stay disconnected.

• The Monastic Strategy involves the effective elimination of shallow work. Consider Donald Knuth, for example, who decided to remove email in 1990 so that he could focus, without distraction, on computer science research.

• The Bimodal Strategy carves your week into deep and shallow days. So, maybe Monday to Wednesday you’re unreachable, then Thursday and Friday you handle meetings and emails.

• Rhythmic Strategy: Execute deep work at a same hour each day - no exceptions. Jerry Seinfeld uses the “don’t break the chain” approach.

• The Journalistic Strategy means seizing deep work whenever a window opens. Meeting canceled? Thirty free minutes? Drop into focus mode immediately.

For most developers, Rhythmic Strategy works the best. Set your mornings aside to code, uncommitted to any of Slack’s reactive tempts. Most of the people find mornings as the part of the day with the most energy.

But the Journalistic approach is interesting too. The idea of moving into deep focus for even 30-45-minute chunks between meetings sounds efficient. The only problem is to convince yourself you’re doing deep work when you’re actually just context-switching all day. That’s not focus-that’s fragmentation dressed up as productivity.

6. Why engineering managers should care

The rationale for “saving” developers’ time boils down to simple arithmetic. If developers have an average allocation of only 52 minutes of actual coding per day, but all the interruptions they cause take away an additional 23+ minutes in “makeup” time, it means that one message eats nearly half a developer’s daily allocation just by itself!

TechSmith ran an experiment eliminating meetings entirely, yielding a 15% increase in feeling productive, with 85% of employees stating they would trade meetings for async communication going forward. According to a Microsoft survey of 31,000 employees, inefficient meetings ranked #1 as a workplace productivity distraction.

The evidence strongly supports the idea that the best productivity activity for an engineering manager doesn’t involve adding processes or meetings, but instead removing them.

Here are a few recommendations for managers:

• Fine-tune your schedule so that you can have uninterrupted mornings

• Schedule no-meeting days (we do no-meeting Wednesdays)

• Asynchronous should be the default rather than synchronous communication

• Allow for creative exploration by setting realistic deadlines that allow for it

It’s necessary to understand that it’s better to have only 3 or 4 hours of actual, focused work than to fall for the commonly held misconception that one increases productivity with 8 hours, only to do so with interruptions.

To measure the impact of these actions, one can assess cycle time reduction, team satisfaction, and engagement score, as well as quality metrics such as bug rates and rework percentage.

7. Conclusion

The bottom line is this: 3-4 hours per day of real, deep programming is not a problem with your work habits, but a hard limit on how much useful cognitive load you can have in a day. Rather than fighting this, accept it and fit around it.

Optimize what you can control. You might not control ad-hoc production issues or a customer escalation that wrecks a planned focus block. But you can turn off notifications for a couple of hours, or let your team know you’ll be available after lunch instead of before.

You can negotiate with your product manager that the team needs two mornings per week free of meetings to improve output. You can improve your own habits, like not scheduling back-to-back meetings that mentally drain you, so that even when you do get a free hour, you’re too fried to code.

Most importantly, you need to change your mindset. Doing “half focus” for 8 hours is not better than doing “deep work” for 4 hours. Trust me, in any situation, you can guarantee that “deep work” will always win in terms of results generated in comparison with “half focus.” Once you accept this, you can stop apologizing for “not being busy” and stop envying the people who always look productive.

The objective is, of course, to make every coding work-hour worth more, rather than simply working more hours.

You will, over time, realize that consistently entering that flow state for a few hours every day leads to higher-quality code, reduced bug risk, and innovative solutions, not to mention a greatly improved work-life balance.

Remember, folks, coders are marathon runners, not sprinters, and while marathon runners occasionally sprint, that’s not feasible over 26.2 miles.

Your energy is one of the most valuable resources on the planet, so conserve it.

A note on AI coding assistants

Tools like Copilot, Cursor, and Claude don’t extend our deep work hours. They just move our focus. Instead of writing code from scratch, you’re working with an AI assistant and reviewing its output. That’s still mentally demanding work. You need the same context, the same judgment, and the same focus level to catch the subtle bugs that AI can introduce.

AI maybe handles mechanical tasks faster, but the 3-4 hour ceiling isn’t about typing speed. It’s about how long your brain can sustain high-quality decision-making under load. That limit doesn’t change just because the code appears on screen faster.

Where AI genuinely helps is during your shallow hours. Drafting documentation, generating boilerplate, answering quick “how do I do X in this library” questions, these tasks drain focus when done manually. Offloading them to AI preserves your deep work budget for actual architectural thinking and complex problem-solving.

The trap is using AI to produce more code than you can mentally process. More output doesn’t mean more value if you can’t reason clearly about what you’ve built.

The goal isn’t to generate more lines per day. It’s to spend your limited cognitive resources on the decisions that matter most.

Use AI to protect your deep work hours, not to pretend you have more of them.

8. References

1. Newport, Cal. Deep Work: Rules for Focused Success in a Distracted World. Grand Central Publishing, 2016.

2. Ericsson, K. Anders. Research on expert performance and deliberate practice.

3. Mark, Gloria. Studies on workplace interruptions (University of California, Irvine).

4. Software.com. 2021 Global Code Time Report.

5. Clockwise 2022 Software Engineering Meeting Benchmark Report

6. C. Parnin and S. Rugaber, "Resumption strategies for interrupted programming tasks," 2009 IEEE 17th International Conference on Program Comprehension, Vancouver, BC, Canada, 2009, pp. 80-89, doi: 10.1109/ICPC.2009.5090030

7. Csíkszentmihályi, Mihály. Flow: The Psychology of Optimal Experience. Harper & Row, 1990.

8. Csíkszentmihályi, Mihály. Flow, the secret to happiness, TED Talk.

9. Valdez, P. et al. (2023). Diurnal variation in variables related to cognitive performance: a systematic review. Chronobiology International, 40(8), 1091–1110

More ways I can help you

• 📱 You Can Build A LinkedIn Audience 🆕. The system I used to grow from 0 to 260K+ followers in under two years, plus a 49K-subscriber newsletter. You’ll transform your profile into a page that converts, write posts that get saved and shared, and turn LinkedIn into a steady source of job offers, clients, and speaking invites. Includes 6-module video course (~2 hours), LinkedIn Content OS with 50 post ideas, swipe files, and a 30-page guide. Join 300+ people.

• 📚 The Ultimate .NET Bundle 2025. 500+ pages distilled from 30 real projects show you how to own modern C#, ASP.NET Core, patterns, and the whole .NET ecosystem. You also get 200+ interview Q&As, a C# cheat sheet, and bonus guides on middleware and best practices to improve your career and land new .NET roles. Join 1,000+ engineers.

• 📦 Premium resume package. Built from over 300 interviews, this system enables you to quickly and efficiently craft a clear, job-ready resume. You get ATS-friendly templates (summary, project-based, and more), a cover letter, AI prompts, and bonus guides on writing resumes and prepping LinkedIn. Join 500+ people.

• 📄 Resume reality check. Get a CTO-level teardown of your CV and LinkedIn profile. I flag what stands out, fix what drags, and show you how hiring managers judge you in 30 seconds. Join 100+ people.

• ✨ Join My Patreon community and my shop. Unlock every book, template, and future drop, plus early access, behind-the-scenes notes, and priority requests. Your support enables me to continue writing in-depth articles at no cost. Join 2,000+ insiders.

• 🤝 1:1 Coaching. Book a focused session to crush your biggest engineering or leadership roadblock. I’ll map next steps, share battle-tested playbooks, and hold you accountable. Join 100+ coachees.

Want to advertise in Tech World With Milan? 📰

If your company is interested in reaching founders, executives, and decision-makers, you may want to consider advertising with us.

Love Tech World With Milan Newsletter? Tell your friends and get rewards.

We are now close to 50k subscribers (thank you!). Share it with your friends by using the button below to get benefits (my books and resources).

Share Tech World With Milan Newsletter

Track your referrals here.

In lean thinking, waste is essentially any activity or output that adds no value from the customer’s perspective. In other words, it’s work that the user wouldn’t want to pay for.

Eliminating such waste has been a core principle of lean manufacturing since Toyota’s rise in the mid-20th century, and pioneers like Mary Poppendieck have shown how these lean principles apply to software development.

In this post, we’ll explore the classic “Seven Wastes” of software development and go beyond them, drawing on new insights from research and practice. Our goal is to help both engineers and managers identify waste in their workflows and share best practices to eliminate it, thereby improving productivity, quality, and team morale.

In particular, we are going to talk about:

1. Seven Wastes of Software Development. The traditional model of Poppendieck et al.’s work in Lean for Code. Deals with incomplete work, additional functionality, relearning, handoffs, waits, context switching, and defects.

2. Beyond the Seven. Sedano et al.’s work has provided further empirical validation, expanding the taxonomy to include nine types: wrong features, backlog mismanagement, over-engineering, cognitive load, psychological distress, communication, and code waste from AI-generated code.

3. Practices to reduce waste. How to make the waste visible with value stream mapping, control thrashing with WIP limits, keep from relearning through knowledge-sharing rituals, and eliminate handoffs with cross-functional teams.

So, let’s dive in.

1. Seven Wastes of Software Development

In Lean Software Development: An Agile Toolkit (2003) and later in Implementing Lean Software Development (2006), Mary and Tom Poppendieck identified seven categories of waste in software projects. These map closely to the original seven manufacturing wastes (like inventory, overproduction, defects, etc.) but are tailored to the realities of software work. If you’re not creating real value, chances are you’re creating waste.

The Poppendiecks’ seven wastes are:

1. Partially done work. Any work in progress that’s not usable by customers yet is effectively a software inventory. This could be code that’s been written but not integrated, tested, documented, or deployed. Such half-done work ties up effort without delivering value, may become obsolete, and creates uncertainty.

2. Extra features. Building features that aren’t really needed or used by end users (feature creep). Extra features cost money to develop, test, and maintain, while adding complexity and potential bugs to the system.

3. Relearning. The waste of knowledge loss when the team needs to relearn something that it previously knew. This usually comes from poor documentation or siloed expertise, where people don’t share or discuss knowledge. If a developer has to rediscover how to solve a problem that has previously been solved, or if new team members have to figure out what departed team members knew, then that’s relearning.

4. Handoffs. Each time work is transitioned from one person to another or from one team to another, there is always a chance that information will be lost or corrupted. This could mean throwing requirements over the wall to development, code to testing, or code to operations. Each time work is transitioned, there is a risk of miscommunication and delays.

5. Delays. All waiting is simply a waste. Waiting for approvers, for clarification, for a decision, for work from another team, for a build or test environment, for instance, is all delay and therefore waste. Each day a feature takes longer to deliver is a day its value is not delivered to the customer.

6. Context switching. That’s the productivity loss when people juggle multiple tasks or projects simultaneously. Every time a developer switches from one project or bugfix to another, there’s a high cost to getting their mind back into the context of that work.

7. Defects. Just like in manufacturing, a classic form of waste is defects or bugs, or quality issues. When a defect is noticed late, most likely by users or during a later testing phase, it results in rework: stopping new work, going back, fixing the issue, and likely redoing tests, among other steps. The cost of defects isn’t just the time to fix, but it is also the disruption to the team’s flow and, most importantly, the damage to customer trust.

These seven wastes, identified by the Poppendiecks, gave the software community a powerful lens for seeing inefficiencies in our processes. By mapping what we do to these categories, engineers and managers can start asking: “Which of these wastes do we encounter daily, and how can we reduce them?”

Once you become familiar with the “waste checklist,” you’ll spot waste everywhere, in unnecessary steps, avoidable rework, and time spent waiting or context-switching. The next step is figuring out how to eliminate it.

“The most successful development occurs when developers talk directly to customers or are part of business teams” - Mary Poppendieck

2. Beyond the Seven: Modern Insights

The original seven wastes are not the only forms of waste in software development. As the industry has evolved, researchers and practitioners have observed additional types of waste that hinder software teams.

An empirical study by Sedano et al. (2017) spent over two years observing eight software projects and uncovered a broader taxonomy of nine wastes. Some overlap with the classic seven, but others extend into new dimensions of inefficiency.

According to their findings, software projects can waste effort through the following, as shown in the table below:

Let’s unpack a few of these newer categories. The first and probably the most important one is building the Wrong Feature/Product. This is perhaps the ultimate waste of time, delivering something neither users nor the business actually need. It’s related to “extra features,” but goes deeper: it means whole features or even products were the wrong thing to build in the first place.

The next pressing problem is the mismanagement of the Backlog. This waste is associated with poor management of the work backlog. This can be a redundant set of work items, very frequent re-prioritizing of work items (commonly termed backlog thrash), or pursuing multiple tasks at the same time. This can also result from ignoring critical bug fixes.

One common waste we see in software projects is over-engineering. Over-engineering occurs when engineers develop a system that has a more complex architecture than is required to address the problem at hand. Maybe the code has been too abstract, the architecture too complex, or the feature's options too many.

The next important waste is Cognitive Load. This is a reference to the effort your brain makes on things that don’t actually contribute to your project in the future. This is sometimes called “the tax your brain pays for messy code.” If a coder has to understand complex code to complete a task, they are using working memory to process it, which is extraneous cognitive load.

Psychological distress is a more human-centric type of waste. This one involves high stress and low morale that a team may experience. Some reasons for this type of waste could be unrealistic deadlines, pressure, or conflicts. When team members are demoralized, they become unproductive, which is a complete waste of the talent you have on your hands.

One of the key factors is ineffective communication. This type of waste comes from the cost of miscommunication or a lack of communication within and around the team. This may be a requirement that was not communicated well (resulting in rework) or a lack of communication within a team that works in silos. Sometimes key feedback is lost in asynchronous communication.

A new and emerging form of code waste over the last two years is AI-generated code, which doubles code churn. An analysis of 211 million lines of code by GitClear found that code churn doubled from 2021 to 2024 as AI coding assistants proliferated. Copy/pasted code increased from 8.3% to 12.3% while refactored/moved code dropped from 25% to under 10%. AI-generated code “resembles an itinerant contributor, prone to violate DRY-ness.”

Also, a 2025 METR study found that AI tools slowed experienced developers by 19% on familiar codebases.

It’s insightful to see how these nine observed wastes relate to the lean wastes. For instance, knowledge loss in this list is essentially the same as “relearning”, the loss of tacit knowledge due to team churn or silos.

Waiting/multitasking corresponds to delays. However, the inclusion of new concepts, such as psychological distress or ineffective communication, helps address issues of teamwork and communication that weren’t necessarily part of the original list of seven. Then the concept of AI-related waste is entirely new to us, and we have never encountered it.

Combining all frameworks yields an extended taxonomy:

The takeaway is that waste hides in many forms, from technical rework to human factors to process and planning glitches. Modern agile/lean practitioners often compile these into extended lists to help leaders systematically identify and fix waste in their organizations. The key is to continuously refine our awareness of waste and avoid being limited by a single static list.

3. Practices to reduce waste in Software Development

The challenge of identifying waste begins with waste identification. What must teams do to eliminate, at least minimize, these types of waste?

One, you want to make this process visible. You want to map the process from idea to deployed software and identify where the wait states, rework cycles, and handoffs occur. Where are the wait states in your process? Just like the value-stream mapping in the factories, you can do the same thing in your software process. Your team can look at this map, point to a spot, and say, “Oh, this step of the process feels like a time suck.”

To prevent spending too much time on the incorrect or additional feature, you should practice rigorous prioritization and validation. Adopt the MVP mentality: “The smallest thing that can deliver value, to get in the hands of the customer.” Validate your approach through customer interviews, A/B testing, or a prototype to ensure you’re headed in the right direction before spending too much dev time.

After that, one would need to limit multitasking and partially finished work by using WIP at both the team and individual levels. Kanban boards can be a great tool here. If a column is at its limit, team members swarm to finish what’s in progress before starting new work. This encourages completion over starting new tasks and reveals bottlenecks (e.g., if “Waiting for QA” is always full, you have a quality process issue causing delay). By keeping WIP low, you’ll shorten delivery times and reduce the mental load on engineers. Little’s Law tells us that high utilization creates long queues (Lead time = WIP / Throughput), so don’t max people out at 100% all the time.

Another thing to remember is to prevent relearning and knowledge loss, create a culture of continuous learning and sharing. Tactics include:

• Pair programming (two heads solve and remember problems together)

• Regular lunch-and-learn sessions or guild meetings

• Internal wikis or knowledge bases for documentation

• Post-mortems for major incidents (to capture lessons learned).

When someone discovers an important fix or insight, encourage them to share it widely, perhaps with a quick demo or an internal blog.

Many handoffs and delays can be eliminated by restructuring teams. Instead of separate departments tossing work over the fence, move toward cross-functional feature teams that have all the skills needed (analysis, development, testing, ops) to deliver end-to-end.

Strive for T-shaped team members who, while having a specialty, can stretch to do basic tasks in other domains to avoid blocking the flow. In today's world, those are mostly full-stack engineers, as deep expertise is now much easier to gain with AI tools.

Many wastes (backlog, thrash, wrong features, defects, etc.) can be traced to communication gaps. This is either with stakeholders or within the team. Invest in practices that tighten feedback loops:

• Daily stand-ups to surface impediments

• Sprint reviews for obtaining feedback from stakeholders

• Retrospectives to reflect on what’s not working in the process

Encourage open communication so team members can raise issues early. Also, clearly communicate the requirements, for instance, by using acceptance criteria, examples, or prototypes to avoid misinterpretations that require rework.

When in doubt, a quick face-to-face (or video) conversation can save days of back-and-forth emails.

Finally, don’t forget the human side. Stop wasting morale and talent. In other words, avoid putting developers into constant context-switching or firefighting in “rush mode.” Sustain the pace to keep the team safe from burning out. A steady velocity is better than heroic spurts followed by crashes.

And don’t forget to celebrate successes while allowing failures to become learning opportunities (enforcing a no-blame culture).

Learn more about context-switching:

Tech World With Milan Newsletter

Context-switching is the main productivity killer for developers

Have you ever wondered what the biggest productivity killer for developers is? There are many, but one stands out—and it’s often underestimated…

Read more

a year ago · 166 likes · 8 comments · Dr Milan Milanović

By keeping your team’s psychological well-being in mind, you are actually protecting productivity: reasonable work hours, support for learning, and psychological safety to speak up. A motivated, engaged team will naturally find and fix more waste in their own work, while a disengaged team might resign themselves to it.

4. Conclusion

In the end, we should note that waste will always exist in some form. We cannot eliminate all of it, but the goal is to hunt it down and remove it continuously. For software teams, this means periodically reviewing how you work and asking, “Is this step really adding value? If not, how can we do it better or not do it at all?” Over time, minor improvements (automation here, a process tweak there, a bit of refactoring over there) compound into significantly faster and smoother delivery.

As a reminder, waste directly impacts efficiency, even morale. Time spent on non-value-added activities means time that’s not spent on innovation or on delivering quality. Engineers and managers must work together to help pinpoint areas of waste and prototype a possible solution. Where applicable, data will be used to identify areas that significantly affect productivity.

Once you know how to identify software development waste, you can apply the proper methods to eliminate it and end up with a better process that delivers value to customers much faster.

As Mary Poppendieck showed us, software engineering can’t be viewed merely as a process of writing software, but as a process of removing the obstacles in the way of software creation.

And remember not to suspend development for weeks to remove waste, as this could reduce morale and customer satisfaction. Some of the waste may not be worth removing. Stability is often more important than raw speed (unless you’re a high-growing startup).

Here’s to less waste and more value in your development journey!

More ways I can help you

• 📱 You Can Build A LinkedIn Audience 🆕. The system I used to grow from 0 to 260K+ followers in under two years, plus a 49K-subscriber newsletter. You’ll transform your profile into a page that converts, write posts that get saved and shared, and turn LinkedIn into a steady source of job offers, clients, and speaking invites. Includes 6-module video course (~2 hours), LinkedIn Content OS with 50 post ideas, swipe files, and a 30-page guide. Join 300+ people.

• 📚 The Ultimate .NET Bundle 2025. 500+ pages distilled from 30 real projects show you how to own modern C#, ASP.NET Core, patterns, and the whole .NET ecosystem. You also get 200+ interview Q&As, a C# cheat sheet, and bonus guides on middleware and best practices to improve your career and land new .NET roles. Join 1,000+ engineers.

• 📦 Premium resume package. Built from over 300 interviews, this system enables you to quickly and efficiently craft a clear, job-ready resume. You get ATS-friendly templates (summary, project-based, and more), a cover letter, AI prompts, and bonus guides on writing resumes and prepping LinkedIn. Join 500+ people.

• 📄 Resume reality check. Get a CTO-level teardown of your CV and LinkedIn profile. I flag what stands out, fix what drags, and show you how hiring managers judge you in 30 seconds. Join 100+ people.

• ✨ Join My Patreon community and my shop. Unlock every book, template, and future drop, plus early access, behind-the-scenes notes, and priority requests. Your support enables me to continue writing in-depth articles at no cost. Join 2,000+ insiders.

• 🤝 1:1 Coaching. Book a focused session to crush your biggest engineering or leadership roadblock. I’ll map next steps, share battle-tested playbooks, and hold you accountable. Join 100+ coachees.

Want to advertise in Tech World With Milan? 📰

If your company is interested in reaching founders, executives, and decision-makers, you may want to consider advertising with us.

Love Tech World With Milan Newsletter? Tell your friends and get rewards.

We are now close to 50k subscribers (thank you!). Share it with your friends by using the button below to get benefits (my books and resources).

Share Tech World With Milan Newsletter

Track your referrals here.

Below, I share the most impactful essays I learned from each. These range from pragmatic engineering advice to philosophical insights, but all influenced how I think and work as an engineer and leader.

I hope that by reflecting on what I learned, you might find these lessons helpful too (and perhaps be inspired to read the original essays if you haven’t).

Here they are, in no particular order:

1. Choose Boring Technology (2015) by Dan McKinley

2. Parse, Don’t Validate (2019) by Alexis King

3. Things You Should Never Do, Part I (2000) by Joel Spolsky

4. The Majestic Monolith (2016) by David Heinemeier Hansson (DHH)

5. The Joel Test (2000) by Joel Spolsky

6. How to Design a Good API and Why It Matters (2007) by Joshua Bloch

7. The Rise of “Worse is Better” (1989) by Richard P. Gabriel

8. The Grug-Brained Developer (2022) by Carson Gross

9. Software Quality at Top Speed (1996) by Steve McConnell

10. Don’t Call Yourself a Programmer (2011) by Patrick McKenzie

11. Bonus: How To Become a Better Programmer by Not Programming (2007) by Jeff Atwood

So, let’s dive in.

GitHub Actions analytics - what’s actually happening (Sponsored)

You’re running GitHub Actions, but you don’t know which jobs are slow, why they’re failing, or if that optimization you shipped actually worked.

Depot’s new GitHub Actions analytics gives you performance trends, resource utilization, and job-level insights across all your workflows. Track duration changes over time, spot jobs maxing out CPU or memory, and get specific recommendations on which runners to upgrade or downgrade.

Filter by repo, workflow, or job. Click into individual runs to see logs and metrics. See exactly which jobs waste resources and which ones need more power.

Check out the analytics

Sponsor this newsletter

1. Choose Boring Technology (2015) by Dan McKinley 🔗

Early in my career, I was easily caught up in the “next big thing” or shiny object syndrome: the latest frameworks, databases, or tools. Dan McKinley’s Choose Boring Technology was a revelation that permitted me to ignore the hype cycle, basically.

McKinley argues that every team has a limited number of “innovation tokens” to spend on new technology, so you must spend them wisely. In other words, innovation is a scarce resource; use it where it truly differentiates your product, and use proven, reliable tech for everything else.

McKinley’s advice is to favor technologies with well-understood failure modes and decades of documentation, the “boring” choices like MySQL, Postgres, Cron, etc., which are boring because they work so well.

He says that when choosing a tool, “the best tool is the one that occupies the ‘least worst’ position for as many of your problems as possible,” since keeping a system running reliably in the long term far outweighs any short-term development convenience.

After reading McKinley’s message, I started to think differently about new tech stacks. I stopped feeling guilty about using “boring” languages and frameworks (who said “legacy”?). Instead of trying every new JavaScript library or cloud service, I now double down on a few stable choices that I know inside out.

This has made me a faster and more effective engineer.

My projects have fewer surprise issues, onboarding new team members is easier (because the stack is common and well-documented), and we spend less time fighting our tools.

“Choose Boring Technology” taught me that innovation is a budget; spend it where it counts. Don’t waste it on reinventing the wheel. Use boring tech for most things so you can innovate where it truly matters (in your product’s unique domain).

It’s a lesson in pragmatism that has improved both my productivity and my team’s.

2. Parse, Don’t Validate (2019) by Alexis King 🔗

This essay is about leveraging static types to build more robust software. Alexis King’s Parse, Don’t Validate changed how I think about handling input data in any language.

The core idea is simple but profound: whenever you validate data, instead of returning an error or a boolean flag, write a function that parses the data into a richer type. By doing so, you make invalid states unrepresentable in your program.

Before this essay, I approached input checking with a defensive mindset.

For example, a reports endpoint with query params:

GET /reports?from=2025-01-01&to=2025-12-31&limit=500000

In a “validate” style, I’d add helpers like validateRange(from, to) and validateLimit(limit), then keep passing string/int deeper. One missed guard later, an unbounded limit hits production, and the database eats a massive query.

King describes this pattern as pushing invalid data forward and relying on repeated checks (“shotgun parsing”).

The fix comes from flipping the flow: parse once at the boundary into a richer type, then run the rest of the system on that type.

So instead of “validate + keep primitives”, I parse into a ReportQuery value object:

• DateRange guarantees from ≤ to and enforces a maximum span

• PageSize guarantees 1…1000

• Core code accepts only ReportQuery, never raw params

Now invalid states cannot enter the domain model, so a forgotten validation cannot happen, there’s nowhere for raw limit or raw dates to flow.

Instead of littering checks everywhere, I now think in terms of designing data types that enforce those checks at construction.

3. Things You Should Never Do, Part I (2000) by Joel Spolsky 🔗

Early in my career, I fell into the trap Joel Spolsky describes in “Things You Should Never Do: Part I.” Namely, I have wanted to rewrite a messy legacy codebase from scratch, more than once. Spolsky’s essay stopped me in my tracks and probably saved me from disastrous rewrites.

The key lesson is: never throw away working code and start over. The old code might be ugly, but it includes years’ worth of bug fixes and hard-earned knowledge.

If you rewrite from scratch, you are throwing away all that knowledge and likely reintroducing bugs that were solved long ago.

Spolsky uses Netscape as the example. They famously decided to rewrite Navigator from the ground up, and in the years it took, Internet Explorer ate their lunch. Joel explains that old code appears messy to new eyes because “it’s harder to read code than to write it”.

Every experienced engineer looks at a large codebase and sees some complex parts and thinks they could do it better. But those parts often exist for very valid reasons: each weird bit might be a fix for a specific user bug, a workaround for an OS quirk, a performance tweak.

As Joel writes:

“That two-page function that grew warts is full of bug fixes; each fix took weeks of real-world usage to discover and days to fix… If you throw away the code and start over, you throw away all that knowledge and all those fixes”.

I realized I had been underestimating the value of legacy code. We can say that legacy code generates revenue, and that is true.

After reading this essay, I changed my approach. When encountering a legacy module, I resist the urge to make big bang changes. Instead, I refactor iteratively, improve it piece by piece, write tests around it, and slowly modernize it.

In this regard, we should not forget also what Fred Brooks taught us in his 1975 book “The Mythical Man Month”.

An architect’s first work is apt to be spare and clean. He knows he doesn’t know what he’s doing, so he does it carefully and with great restraint. As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to be used ‘next time.’ Sooner or later the first system is finished, and the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system.

This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable. The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one.

4. The Majestic Monolith (2016) by David Heinemeier Hansson (DHH) 🔗

Around 2015-2016, microservices were all the rage. Everyone was breaking apart monolithic applications into dozens of tiny services. I’ll admit I was swept up in the “microservices mania” for a while, until I read DHH’s The Majestic Monolith.

This essay was a contrarian breath of fresh air at a time when it seemed every system had to be as distributed as Netflix or Amazon.

DHH’s message:

Not every problem needs microservices; in fact, most don’t.

For the majority of products (especially with small teams), a well-structured monolith is not only good enough, but it’s also actually a better choice than a distributed mess of services.

One line that stuck with me was DHH’s reference to the #1 rule of distributed computing: “Don’t distribute your computing if you can avoid it!” Every time you split a process into separate services, you introduce a world of complexity, network calls, fallible connections, synchronization challenges, deployment and DevOps overhead, and so on.

DHH argues (persuasively) that microservice architectures make sense for huge companies with thousands of engineers working on independent components, not for the average product team of 5, 10, or even 50 developers.

Copying the architecture of Google or Amazon when you’re not operating at their scale is essentially cargo culting.

The “Majestic Monolith” essay gave me the confidence to push back on reflexive microservices adoption. DHH not only defends monoliths but also celebrates them: he urges embracing the monolith with pride and making it majestic.

A monolith done right, with clear modular boundaries but deployed as a single integrated system, has enormous advantages for a small team. It’s simpler to develop, test, deploy, and understand. There’s one database (usually), one deployable, and one place to look if something goes wrong.

The essay gave me the phrase “You are not Amazon” as a gentle reminder, i.e., design for your scale and complexity, not somebody else’s.

➡️ Read more about Modular Monoliths:

Tech World With Milan Newsletter

What is a Modular Monolith?

Microservices are popular for their scalability but come with complexity and operational overhead. They have become a big hype in the industry, and you can see microservices everywhere. On the other side, modular monolith offers a middle ground—keeping the simplicity of a monolith while allowing for future scalability. Here’s why it might be the right c…

Read more

a year ago · 154 likes · 10 comments · Dr Milan Milanović

5. The Joel Test (2000) by Joel Spolsky 🔗

Sometimes significant insights come in simple packages. The Joel Test is one of those. In a short blog post, Joel Spolsky presented 12 yes-or-no questions to quickly assess the health of a software team and process.

It’s basically a checklist:

It’s a quick test that takes about 3 minutes and gives you a gut feel for how good a team is. And you know what? It works. I’ve used the Joel Test in every team I’ve joined (or led) as a starting diagnostic, and it has never failed to identify gaps or dysfunctions almost immediately.

After using this test multiple times, I’ve essentially internalized it as a guiding principle for team practices. When I became a team lead, I introduced my team to the Joel Test in one retro. We were about 8/12 at the time; we identified the four “No” answers and worked on them over the next quarter.

The improvement reflected in our output: we had fewer bugs, onboarded new devs faster, and generally felt more in control.

Joel suggests that a score of 12 is perfect, 11 is acceptable, and any score below 10 indicates serious problems.

It’s a quick litmus test. Of course, it’s not complete; there are things it doesn’t cover (like code quality, architecture, etc.). But it covers the essentials of software engineering hygiene.

6. How to Design a Good API and Why It Matters (2007) by Joshua Bloch 🔗

As I grew from writing small scripts to designing libraries and services for others to use, I realized how critical yet complex API design is. Joshua Bloch’s talk/essay “How to Design a Good API and Why it Matters” became my API design bible. It fundamentally changed how I design and evaluate interfaces.

Bloch’s core messages can be distilled into a few rules:

• Public APIs, like diamonds, are forever. You get one chance to get it right, so put in the effort up front. This taught me that once you publish an API (whether a library method, a service endpoint, etc.), it’s hard to change because users start to depend on it.

• APIs should be easy to use and hard to misuse. It means a good API makes the everyday things simple and the wrong things difficult or impossible. For example, if a class shouldn’t be created directly, provide a factory or builder to guide usage instead of leaving foot-guns lying around.

• Good naming and documentation are part of API design. Bloch said “names matter” and that every API is a little language on its own. If I can’t come up with a clear name for a method, that’s often a sign that the method’s purpose isn’t clear, or that it's doing too much.

After reading Bloch’s guidance, I started doing something new: API reviews. Whenever we design a new module or service interface, I’ll gather a couple of engineers (sometimes from other teams) and simulate API usage before we implement it.

We basically pretend to be the consumer of our API: is it obvious how to instantiate this? Does the workflow make sense? Are we exposing too much that could be misused? This practice has caught many issues early.

One more thing Bloch highlighted is thinking about evolution: A good API should be extensible in the future (where possible). This influenced me to design with “future-proofing” in mind. For example, using interface types instead of concrete classes if I suspect we might want to change the implementation later, or reserving unused enum values for future expansion, etc.

And critically, it taught me to avoid breaking changes. If an API needs to change, try to do so by adding new methods or endpoints rather than changing the contracts of existing ones. Because once people depend on it, breaking it will cause pain.

➡️ Learn more about APIs

Tech World With Milan Newsletter

How to learn API?

Our daily work as software engineers involves creating or utilizing these APIs. Creating well-designed REST APIs is crucial; not only should they be easy to work with and concise, but they should also be well-designed against misuse to prevent future issues…

Read more

a year ago · 241 likes · 4 comments · Dr Milan Milanović

7. The Rise of “Worse is Better” (1989) by Richard P. Gabriel 🔗

This essay comes from the world of Lisp in the late ’80s. Still, Richard Gabriel’s “The Rise of Worse is Better” contains a timeless software philosophy that influenced my approach to architecture and product design. The premise is that “worse” solutions often beat “better” ones in the real world, where “worse” and “better” have specific meanings.

In Gabriel’s terms, the “MIT approach” to design (aka “the Right Thing”) values completeness, consistency, and correctness, aiming for an ideal system.

On the other side, the “New Jersey approach” (“worse is better”) values simplicity and practicality, even if the solution is incomplete or slightly less elegant.

The interesting claim Gabriel makes is that the New Jersey style (examples are Unix and C) tends to win in the marketplace over the MIT style (classic Lisp machines), because simpler systems get adoption and can evolve. In contrast, perfect ones often never leave the lab.

This was eye-opening for me. It explained many historical outcomes: why C and Unix (with all their flaws) dominated, while more “perfect” systems fell by the wayside. Unix/C was simple enough to port to small machines, easy to understand (well, relatively speaking), and satisfied just enough requirements to be useful.

Once widely adopted, they could be gradually improved. As Gabriel put it, a software system that’s 50% ideal but widely used will spread and, over time, maybe grow to 90% of the perfect. Whereas a system that tries to be 100% ideal from the start often never gets there, or gets there too late, after the “worst” solution has eaten the world.

Understanding “worse is better” changed my attitude toward seeking perfection. I am, by nature, someone who likes elegant and perfect solutions. But I’ve seen in my experience that a simple solution that’s good enough today beats a perfect solution delivered next year.

“The Rise of Worse is Better” basically taught me that sometimes, good enough is not just good enough, it’s actually the optimal strategy for long-term success.

Simplicity has its own quality. In a world of limited time and resources, a simple system that people can use and adapt will often outcompete a “perfect” system that’s perpetually in development.

8. The Grug Brained Developer (2022) by Carson Gross 🔗

This one is a bit different. It uses a caveman-style character (“Grug”) who shares simple but surprisingly helpful programming advice. “The Grug-Brained Developer” might be written in a playfully sarcastic style, but it hit me with some very real truths about over-engineering and complexity.

The central theme is that modern developers often make things far too complex for no good reason, and that a “grug brain” (simple, caveman-like thinking focused on fundamentals) can usually produce better outcomes.

One of the funniest and most insightful parts is where Grug identifies the “Eternal Enemy”: Complexity. “Complexity is bad. Say again: complexity is terrible.” This refrain is both amusing and accurate. It explains in plain language what many of us have learned the hard way - every unit of complexity in your codebase or system is an opportunity for things to go wrong (and for developers to get confused).

Grug’s advice often boils down to “say no” to unnecessary changes, features, or abstractions. I laughed at how he puts it: “No, grug not build that abstraction.” It’s a caricature, but honestly, it made me more comfortable pushing back.

As I’ve grown into senior roles, I’ve found that one of the most valuable things you can do is protect the codebase from unnecessary complexity, whether that means not adopting a trendy new microframework or avoiding a premature microservice split (see Majestic Monolith above).

Another thing the Grug essay validated is the importance of iteration and emergent design. There’s a section where Grug talks about not factoring or abstracting too early. Instead, build things simply until you truly understand the problem, then refactor as needed.

The “grug” approach is to make something tangible first (even if it's not perfectly abstract), then evolve it as you identify clear pain points.

9. Software Quality at Top Speed (1996) by Steve McConnell 🔗

Steve McConnell’s article “Software Quality at Top Speed” changed how I work. It showed me that clean code and fast delivery aren’t opposites. The usual thinking is that if you want to go fast, you cut corners on quality, skip tests, skip design, crank out code, and fix issues later.

McConnell (the author of the famous book “Code Complete”), backed by data, argues the opposite: higher quality leads to faster development. In his words, projects with the lowest defect rates also have the shortest schedules. When I first read that, it was almost counterintuitive, but the more I thought about it and saw it in real projects, the more it rang true.

The article cites studies (such as those from IBM and Capers Jones) showing that poor quality is a significant cause of schedule overruns and even project cancellations.

Basically, every bug is a time thief. When you rush and introduce defects, you will inevitably pay the time back (with interest), debugging, retesting, and firefighting in production.

McConnell gave concrete examples: a team under pressure might cut design and code review time to “save time,” but they end up spending more time later in test/fix cycles or rewriting buggy components.

One interesting anecdote from the article was the cost of a shortcut, a scenario in which a team hacked in a feature to meet a deadline, only to have it bite them hard a couple of months later, requiring a significant rework. McConnell broke down how the supposed shortcut meant they spent more overall time: first building the hack, then debugging the problems it caused, then ripping it out and doing it properly anyway.

McConnell also emphasizes practices like code reviews, design reviews, and automated testing as high-leverage activities. For example, code inspections can remove a large percentage of defects early, dramatically reducing the test/debug burden.

As McConnell notes, projects that achieve>95% bug removal before release tend to meet their schedules and keep customers happy.

That became a sort of quality bar for me: aim to catch everything virtually before it goes out the door.

10. Don’t Call Yourself a Programmer (2011) by Patrick McKenzie 🔗

This essay by Patrick McKenzie (better known as patio11) was less about coding and more about how to frame my career and value as a software engineer. McKenzie’s core argument: “Programmer” as a job title can pigeonhole you as a commodity in the eyes of businesses. It’s better to describe yourself in terms of the business value you create, not the specific activities you do.

He wrote that calling yourself a programmer sounds to business people like “anomalously high-cost peon who types some mumbo-jumbo into a computer”, essentially, someone potentially replaceable or outsourceable.

That stung, but I realized he was right. Non-technical execs often don’t understand what coding is; they know it’s expensive and wish they had less of it. And here we come proudly wearing the label “Programmer.”

McKenzie suggests that instead, you present yourself as “someone who increases revenue or reduces costs”, the coding is incidental to that. This was a revelation to me. It shifted my perspective from skills-centric (“I know X language, I can build Y”) to value-centric (“I solve Z problem for businesses, which saves them $N or helps them gain M customers”).

I started rewriting my resume, LinkedIn, and even how I spoke in interviews or performance reviews. For example, instead of saying “Implemented a .NET service to process e-commerce transactions,” I would say “Built an online payment solution that processed $10M in transactions in the first year, increasing our company’s revenue by 5%.”

This essay also introduced me to the concept of Profit centers vs. cost centers in a company and helped me understand the kind of company I work for. Programmers are typically seen as cost centers (a necessary expense), whereas roles like sales or trading are profit centers (they directly generate revenue). And this especially holds for service companies.

McKenzie’s point is that if you can align yourself with profit by working on projects that directly drive revenue or by being the go-to person for solutions that save money, you put yourself in a much stronger career position.

11. Bonus: How To Become a Better Programmer by Not Programming (2007) by Jeff Atwood 🔗

When I first saw the title of Jeff Atwood’s blog post “How To Become a Better Programmer by Not Programming,” I did a double-take. Not programming? Isn’t the whole mantra “practice, practice, practice”? But Atwood’s piece makes an important point: after a certain baseline of coding skill, what differentiates great developers isn’t just more coding, it’s the “everything else”.

In other words, to truly improve, you have to broaden your skills beyond writing code.

Bill Gates is quoted as saying that after 3-4 years of programming, you kind of plateau in pure coding ability. Additional years don’t necessarily make you much better at algorithmically coding.

Atwood (and Gates) suggest that to get better after that, you need to understand the context around the code: the users, the domain, the collaboration with others, the design, etc. Jeff writes, “the only way to become a better programmer is by not programming” - put down the IDE and broaden your perspective.

I used this in a few concrete ways:

• I started learning more about the business domain I was working in. Instead of seeing that as someone else’s job, I engaged more with product managers, attended customer feedback sessions, and learned the industry's vocabulary (becoming more product-minded as an engineer).

• I put more effort into communication and people skills. Jeff highlights that great engineers often excel at bridging engineering with other areas, such as marketing and customer service. This nudged me to volunteer to present engineering plans to various departments, mentor juniors, or coordinate more with QA and Ops.

• I diversified my technical interests. I started reading more about design, UX, and even fields like graphic design or systems thinking. I’m a backend engineer primarily, but I've dabbled in front-end work and studied some data science concepts, not to master them all, but to broaden my horizons.

Atwood’s essay essentially told me: get out of the coding bubble. I can attest that following this advice has made me a much better developer in the holistic sense. I’ve seen developers who only code and ignore everything else; they often hit a ceiling.

They might be great at cranking out features, but those features might miss the mark, be hard to integrate, or they might struggle to work in a team.

On the other hand, developers who spend time not coding, thinking, discussing, and learning about the world end up making more impactful contributions when they do code.

➡️ Another great post from Jeff that impacted me is “The Best Code is No Code At All” (2007), where he states what every experienced developer knows but hates admitting: code is a liability, not an asset. Every line you write creates a future maintenance burden. Every new feature multiplies the surface area for bugs.

The essay opens with Rich Skrenta’s observation that code rots, requires maintenance, and has bugs that need to be found. But Atwood goes deeper: the problem isn’t the code, it’s us. Developers love writing code. We solve every problem with more code. This instinct is our enemy.

Wil Shipley’s framework makes the tradeoffs explicit. Every coding decision balances brevity, features, speed, time spent, robustness, and flexibility. These dimensions oppose each other. The answer? Start with brevity. Increase other dimensions only as testing requires.

12. Conclusion

These essays, each in its own way, have shaped my philosophy and approach to software development. If you haven’t read some of these, I highly recommend them. They might change how you think about software, too.

Ultimately, the common thread in all of them is a kind of wisdom beyond code: whether it’s about avoiding hype, making invalid states impossible, learning from old code, right-sizing architecture, managing complexity, investing in quality, or stepping back to see the bigger picture. They speak to the craft and culture of creating good software.

Each essay gave me insight that I carry into my daily work. Together, they form a toolkit of principles I wish I had known from the start.

I hope sharing them (and what I learned) gives you something valuable to take away, too.

Happy coding, and happy not-coding!

📰 What I read daily (you can subscribe to it too!)

I use Mailbrew to pull my daily reading into one place: Hacker News, Product Hunt, Reddit, and a few tech blogs I follow. It’s basically my morning scan of what’s happening in tech.

I kept it private until now, but figured I’d open it up for my readers. If you want to see what I’m reading each day, here’s the link.

More ways I can help you

• 📱 You Can Build A LinkedIn Audience 🆕. The system I used to grow from 0 to 260K+ followers in under two years, plus a 49K-subscriber newsletter. You’ll transform your profile into a page that converts, write posts that get saved and shared, and turn LinkedIn into a steady source of job offers, clients, and speaking invites. Includes 6-module video course (~2 hours), LinkedIn Content OS with 50 post ideas, swipe files, and a 30-page guide. Join 300+ people.

• 📚 The Ultimate .NET Bundle 2025 🆕. 500+ pages distilled from 30 real projects show you how to own modern C#, ASP.NET Core, patterns, and the whole .NET ecosystem. You also get 200+ interview Q&As, a C# cheat sheet, and bonus guides on middleware and best practices to improve your career and land new .NET roles. Join 1,000+ engineers.

• 📦 Premium resume package 🆕. Built from over 300 interviews, this system enables you to quickly and efficiently craft a clear, job-ready resume. You get ATS-friendly templates (summary, project-based, and more), a cover letter, AI prompts, and bonus guides on writing resumes and prepping LinkedIn. Join 500+ people.

• 📄 Resume reality check. Get a CTO-level teardown of your CV and LinkedIn profile. I flag what stands out, fix what drags, and show you how hiring managers judge you in 30 seconds. Join 100+ people.

• ✨ Join My Patreon community and my shop. Unlock every book, template, and future drop, plus early access, behind-the-scenes notes, and priority requests. Your support enables me to continue writing in-depth articles at no cost. Join 2,000+ insiders.

• 🤝 1:1 Coaching. Book a focused session to crush your biggest engineering or leadership roadblock. I’ll map next steps, share battle-tested playbooks, and hold you accountable. Join 100+ coachees.

Want to advertise in Tech World With Milan? 📰

If your company is interested in reaching founders, executives, and decision-makers, you may want to consider advertising with us.

Love Tech World With Milan Newsletter? Tell your friends and get rewards.

We are now close to 50k subscribers (thank you!). Share it with your friends by using the button below to get benefits (my books and resources).

Share Tech World With Milan Newsletter

Track your referrals here.

Today, we cover:

1. 95% of developers use AI, yet 30% don’t trust the code it writes. DORA’s 2025 report reveals that teams are moving faster while breaking more things (hello, outages). AI amplifies whatever system you have. Strong teams with good practices get better. Dysfunctional teams with fragmented workflows accelerate the chaos.

2. TypeScript has just become the most used language on GitHub. It is projected to grow by 1 million contributors in 2025. Also, India has overtaken the US in open-source contributions.

3. 89% of developers use AI daily, but only 24% design APIs for it. The 2025 State of the API Report by Postman exposes a critical gap: developers are AI-native, but APIs aren’t built for AI agents. Also, 70% are aware of MCP, but only 10% use it.

4. AI is moving from software to the physical world. InfoQ’s trends report shows the next frontier: AI entering robotics and real-world systems. Google’s Gemini Robotics and NVIDIA’s AI-to-deployment pipeline are bringing language models into physical environments. This isn’t just software anymore.

5. ThoughtWorks flags the AI antipatterns to avoid. What’s working: MCP, agentic workflows, curated shared instructions. What’s not: AI-accelerated shadow IT, naive API-to-MCP conversion, text-to-SQL failures.

So, let’s dive in.

One size does not fit all: A guide to multitenant authorization (Sponsored)

When an enterprise signs up for a SaaS product, the “Admin, Editor, Viewer” model breaks. Role explosion follows - thousands of tenant-specific role variants that cripple engineering velocity and stall enterprise deals.

Static roles weren’t designed for the complexity of today’s multitenant systems. Every enterprise has unique organizational structures, matrix reporting, and regional compliance requirements that demand contextual, granular permissions.

This ebook shows you how to implement dynamic, tenant-aware authorization that scales, namely:

• Why fixed roles break at enterprise scale (and what role explosion actually looks like)

• How to implement authorization that mirrors each tenant’s organizational reality

• Architecture patterns for separating platform-wide rules from tenant-specific policies

• The PEP/PDP/PAP pattern and policy-as-code workflows

• Real examples from leading SaaS companies scaling authorization across thousands of tenants

Get the blueprint to eliminate role explosion before it blocks your enterprise growth.

Download FREE eBook

Sponsor this newsletter

1. DORA 2025 report

DORA’s 2025 report, based on input from 5,000 professionals, confirms what many suspected: AI adoption is now universal. 95% of developers use AI.

More than 80% believe it increased their productivity.

But 30% don’t trust the code it generates.

That tension tells the real story. Teams are moving faster while breaking more things.

AI adoption now improves software delivery throughput, a reversal from 2024 findings. But instability rose alongside it.

Here are the main findings:

1. Seven team profiles

DORA calls out seven team archetypes, from those still stuck on basics to those it labels “harmonious high achievers.” Some teams move fast but can’t keep systems stable. Others ship less often and sustain quality with lower burnout.

The key isn’t tools or process checklists, it’s how the team performs under stress. Pressure exposes gaps in collaboration, ownership, and culture. DORA’s data shows AI doesn’t fix dysfunction; it amplifies what’s already there. Good teams get stronger. Fragmented ones spin faster and fall apart quicker.

That’s why adoption stats alone mean little. They don’t reflect real impact. The question isn’t how fast you fold AI into your stack. It’s whether your team’s setup and norms let it improve outcomes rather than magnify chaos.

2. The capabilities that matter

DORA’s new AI Capabilities Model identifies seven foundational practices that amplify the positive impact of AI.

• Clear and communicated AI stance. Developers need to know which tools are permitted and how they’re expected to use them. Ambiguity creates two problems: people either use AI less than they could because they’re afraid of overstepping, or they overstep boundaries they are unaware of.

• Healthy data ecosystems. AI models are only as good as the data they train on. When internal data is high-quality, accessible, and unified rather than siloed, the benefits of AI for organizational performance multiply.

• AI-accessible internal data. Generic foundational models are helpful, but AI connected to your repositories and documentation improves effectiveness and code quality.

• Strong version control practices. Frequent commits amplify individual effectiveness. Regular use of rollback features amplifies team performance.

• Working in small batches. This longstanding DORA capability is even more important in the AI era. Small batches amplify product performance and reduce friction for AI-assisted teams, even if they slightly reduce perceived individual effectiveness.

• User-centric focus. The most striking finding in the report. Teams without a user-centric focus experience negative performance impacts from AI adoption. The technology not only fails to help, but it also actively harms team performance.

• Quality internal platforms. Platform engineering adoption hit 90%. High-quality platforms serve as the distribution layer, scaling AI benefits from individual productivity gains to organizational advantages.

3. Value Stream Mapping as a force multiplier

Value stream management emerged as critical for AI success. Teams that visualize and analyze their workflow from idea to customer can direct AI toward actual constraints.

Without that systems view, productivity gains get absorbed into downstream bottlenecks. You optimize the wrong step while the fundamental constraint chokes flow. VSM ensures local improvements translate into measurable team and product performance.

What can we learn from this?

Stop treating AI adoption as a tools problem. It’s a systems problem.

Before purchasing additional AI licenses, ask: Can we visualize our software delivery value stream on a whiteboard? Do our developers know which AI tools are permitted and why? Is our internal data accessible to AI, or locked in silos? Can our platform handle increased velocity without experiencing any issues?

The organizations winning with AI aren’t the ones with the best models. They’re the ones who redesigned their systems to carry the gains.

Your choice: Fix the system, or watch AI expose every crack you’ve been ignoring.

2. ThoughWorks Technology Radar - Volume 33 (November 2025)

ThoughtWorks has released Volume 33 of its Technology Radar, tracking shifts in AI infrastructure, agentic workflows, and emerging antipatterns.

What stands out in this edition:

1. Infrastructure orchestration of AI

AI workloads are pushing teams to orchestrate large GPU fleets for training and inference. Model sizes now exceed the capacity of a single accelerator, driving distributed training and multi-GPU setups.

Platform teams are building complex pipelines and tuning for throughput and latency. Kubernetes remains the foundation, but GPU-aware scheduling is becoming essential.

Tools like Kueue, topology-aware placement, and gang scheduling help co-locate multi-GPU jobs on fast interconnects. Topology is now a first-class scheduling concern.

2. Agents elevated by MCP

The Model Context Protocol (MCP) and agents dominate this Radar. Major vendors are adding MCP support; it’s becoming the standard for powering agents and enabling semi-autonomous work.

Context engineering proves critical for optimizing behavior and resource use.

New protocols such as A2A and AG-UI reduce boilerplate in multi-agent applications.

Teams are experimenting with AGENTS.md files and anchoring coding agents to reference applications. Each Radar brings innovation; last time RAG, this time agentic workflows.

3. AI coding workflows

AI is embedded across the software value chain, from understanding legacy code to forward engineering. Teams are learning to provide better knowledge to coding agents.

AGENTS.md files and MCP servers like Context7 fetch up-to-date documentation. AI must amplify the entire team, not just individual contributors.

Curated shared instructions and custom commands ensure knowledge diffusion.

Designers use UX Pilot and AI Design Reviewer; developers prototype with v0 and Bolt.

But complacency with AI-generated code remains a concern. Human judgment is still indispensable.

4. Emerging AI anti-patterns

AI adoption surfaces both effective practices and antipatterns. Self-serve UI prototyping with GenAI can lead to AI-accelerated shadow IT.

Naive API-to-MCP conversion is spreading as MCP gains traction. Text-to-SQL solutions haven’t met expectations.

Spec-driven development risks reverting to heavy up-front specification and big-bang releases.

Teams should watch for patterns that degrade over time, slow feedback, or obscure accountability.

In more detail:

Techniques:

• ✅ Adopt: Continuous compliance, Curated shared instructions for software teams, Pre-commit hooks, Using GenAI to understand legacy codebases

• 🧪 Trial: AGENTS.md, AI for code migrations, Delta Lake liquid clustering, Self-serve UI prototyping with GenAI, Structured output from LLMs, TCR

• 🔍 Assess: AI-powered UI testing, Context engineering, GenAI for forward engineering, LLM as a judge, Small language models, Spec-driven development, Team of coding agents, Topology-aware scheduling

• 🛑 Hold: AI-accelerated shadow IT, Capacity-driven development, Complacency with AI-generated code, Naive API-to-MCP conversion, Text to SQL

Platforms:

• ✅ Adopt: Arm in the cloud

• 🧪 Trial: Apache Paimon, DataDog LLM Observability, Delta Sharing, Dovetail, Langdock, LangSmith, Model Context Protocol (MCP), n8n, OpenThread

• 🔍 Assess: AG-UI Protocol, A2A Protocol, Amazon S3 Vectors, Ardoq, CloudNativePG, Karmada, Oxide, Restate, SkyPilot, Uncloud

Tools:

• ✅ Adopt: ClickHouse, NeMo Guardrails, pnpm, Pydantic

• 🧪 Trial: AI Design Reviewer, Claude Code, Cleanlab, Context7, Data Contract CLI, Databricks Assistant, NVIDIA DCGM Exporter, UX Pilot, v0

• 🔍 Assess: Augment Code, Azure AI Document Intelligence, Docling, E2B, Kueue, MCP-Scan, Power user for dbt, Serena

Languages and frameworks:

• ✅ Adopt: Fastify, LangGraph, vLLM

• 🧪 Trial: Crossplane, DeepEval, FastMCP, LiteLLM, MLForecast, Nuxt, Phoenix, Presidio, Pydantic AI, Tauri

• 🔍 Assess: ADK, Browser Use, DeepSpeed, Drizzle, Java post-quantum cryptography, Langflow, Mem0, OSCAL, Vercel AI SDK

This Radar emphasizes managing AI infrastructure at scale while navigating the complexity of agentic systems. Security and governance matter as much as capability.

3. The Octoverse 2025 report

The Octoverse 2025 report was released on November 01 and covers GitHub data from September 1, 2024, to August 31, 2025.

1. TypeScript takes the crown

For the first time, TypeScript overtook both Python and JavaScript to become the most used language on GitHub in August 2025. This marks the most significant language shift in more than a decade.

TypeScript grew by 1 million contributors in 2025 (+66% YoY). Modern frameworks now scaffold with TypeScript by default, and AI-assisted development works better with stricter type systems.

Python remains dominant for AI and data science with 2.6 million contributors (+48% YoY). JavaScript still has a massive user base (2.15M contributors), but growth slowed as developers moved to TypeScript.

Nearly 80% of new repositories used just six languages: Python, JavaScript, TypeScript, Java, C++, and C#.

2. Developer growth hits record pace

More than 36 million developers joined GitHub this year, over 1 new developer every second. The platform now has 180M+ developers.

The release of GitHub Copilot Free in late 2024 accelerated this. 80% of new developers use Copilot within their first week. AI is now part of the default developer experience.

Developers created 230 new repositories every minute, merged 43.2 million pull requests per month (+23% YoY), and pushed nearly 1 billion commits (+25% YoY).

3. India overtakes the US in open source contributions

India now has the most significant public and open-source contributor base in the world. India added 5.2 million developers in 2025 (14% of all new accounts) and is on track to account for one in three new developers by 2030.

Over the past five years, India, Brazil, and Indonesia have more than quadrupled their developer numbers.

4. AI becomes standard infrastructure

More than 1.1 million public repositories now use an LLM SDK (+178% YoY). Of these, 693,867 were created in the last 12 months alone.

The top AI infrastructure projects driving growth:

• vllm-project/vllm (model inference)

• ollama/ollama (local model runner)

• huggingface/transformers (model loading/fine-tuning)

• continue-dev/continue (AI coding assistant)

• ragflow (AI orchestration)

Coding agents created 1+ million pull requests between May and September 2025. Average fix times for critical vulnerabilities improved by 30%, dropping from 37 to 26 days.

4. 2025 State of the API Report

Postman surveyed over 5,700 developers, architects, and executives about how APIs are evolving in an AI-driven world. This year’s report reveals a gap: developers are AI-native, but most APIs aren’t yet built for AI agents. Organizations that close this gap fast will pull ahead.

Here are the key findings:

1. API-first development jumped 12%

82% of organizations now use some level of API-first approach, with 25% fully API-first (up from 13% in 2024). These organizations treat APIs as products, not projects.

And it shows in revenue: 43% of fully API-first companies generate more than 25% of total revenue from APIs.

2. Developers use AI, but APIs aren’t ready

89% of developers use AI tools daily, but only 24% design APIs for AI agent consumption. 60% still designed primarily for humans only.

This mismatch creates problems: AI agents need machine-readable schemas and predictable patterns that most APIs don’t provide.

3. AI Agents are the new security threat

51% of developers worry about unauthorized or excessive API calls from AI agents, making it the top security concern. Traditional security models weren’t built for machine-speed exploitation or persistent automated attacks.

Organizations need dynamic rate limiting, agent identification, and enhanced monitoring.

4. APIs drive real revenue

65% of organizations generate revenue from APIs. Among those, 74% get at least 10% of total revenue from API programs, and 25% generate more than half their revenue from APIs.

Investment follows: 46% plan to spend more on APIs in the next 12 months.

5. MCP awareness is high, but adoption is low

70% of developers are aware of the Model Context Protocol (MCP), but only 10% use it regularly. Another 24% plan to explore it.

MCP promises to standardize how AI agents discover and invoke APIs, but agents are already calling APIs without it.

Make your APIs agent-ready now, regardless of which protocol wins.

6. Collaboration still breaks down

93% of teams face collaboration blockers, which are:

All of this slows the teams down.

And this matters more as APIs become business-critical: when documentation lives everywhere, it becomes unreliable everywhere.

5. InfoQ AI, ML, and Data Engineering Trends Report - 2025

InfoQ’s latest trends report maps where AI, ML, and data technologies are heading. The shift is clear: AI is moving from software to the physical world.

Here are the key insights:

• Physical AI is the next frontier. AI is entering robotics. Google’s Gemini Robotics On-Device and NVIDIA’s complete AI-to-deployment pipeline are bringing language models into physical systems. This isn’t just software anymore.

• AI Agents are evolving fast. Agents now orchestrate complex workflows, not just single tasks. Amazon Bedrock Agents, Claude Subagents, and OpenAI’s ChatGPT Agent are making production-ready systems possible without infrastructure headaches.

• RAG has become a commodity. Retrieval Augmented Generation is standard in enterprise applications. It’s no longer experimental; it’s how companies access and use their knowledge bases.

• Model Context Protocol (MCP) enables interoperability. Anthropic’s new standard lets different AI systems share data without custom integrations. OpenAI, Microsoft, and Google are already adopting it. This makes multi-agent systems practical.

• AI is now a co-creator, not just an assistant. Development teams are using AI to build, test, and ship entire applications. The role has shifted from “help me code faster” to “build this with me.”

• Multi-modal models are here. Language models now process text, images, audio, and video together. This enables richer understanding and more accurate outputs across different data types.

• Human-Computer Interaction is being redesigned. AI interfaces are changing how we interact with software. The focus is shifting toward embedding information where people actually need it, rather than forcing them to adapt to rigid interfaces.

More ways I can help you

• 📱 You Can Build A LinkedIn Audience 🆕. The system I used to grow from 0 to 260K+ followers in under two years, plus a 49K-subscriber newsletter. You’ll transform your profile into a page that converts, write posts that get saved and shared, and turn LinkedIn into a steady source of job offers, clients, and speaking invites. Includes 6-module video course (~2 hours), LinkedIn Content OS with 50 post ideas and templates, swipe files, and a 30-page guide. Join 300+ people.
  📚 The Ultimate .NET Bundle 2025 🆕. 500+ pages distilled from 30 real projects show you how to own modern C#, ASP.NET Core, patterns, and the whole .NET ecosystem. You also get 200+ interview Q&As, a C# cheat sheet, and bonus guides on middleware and best practices to improve your career and land new .NET roles. Join 1,000+ engineers.

• 📦 Premium resume package 🆕. Built from over 300 interviews, this system enables you to quickly and efficiently craft a clear, job-ready resume. You get ATS-friendly templates (summary, project-based, and more), a cover letter, AI prompts, and bonus guides on writing resumes and prepping LinkedIn. Join 500+ people.

• 📄 Resume reality check. Get a CTO-level teardown of your CV and LinkedIn profile. I flag what stands out, fix what drags, and show you how hiring managers judge you in 30 seconds. Join 100+ people.

• ✨ Join My Patreon community and my shop. Unlock every book, template, and future drop, plus early access, behind-the-scenes notes, and priority requests. Your support enables me to continue writing in-depth articles at no cost. Join 2,000+ insiders.

• 🤝 1:1 Coaching. Book a focused session to crush your biggest engineering or leadership roadblock. I’ll map next steps, share battle-tested playbooks, and hold you accountable. Join 100+ coachees.

Want to advertise in Tech World With Milan? 📰

If your company is interested in reaching founders, executives, and decision-makers, you may want to consider advertising with us.

Love Tech World With Milan Newsletter? Tell your friends and get rewards.

We are now close to 50k subscribers (thank you!). Share it with your friends by using the button below to get benefits (my books and resources).

Share Tech World With Milan Newsletter

Track your referrals here.

Fast-forward to today: I’m a Top 100 LinkedIn creator with over 264,000 followers, my posts regularly rack up thousands of reactions, and I’ve leveraged LinkedIn to become a recognized authority in tech.

How did I transform from an “invisible” engineer into a trusted expert on the world’s largest professional network? This story will reveal my path and the playbook for mastering LinkedIn as an engineer, from mindset shifts and profile tweaks to content systems and community engagement.

In particular, we will talk about:

1. Why LinkedIn matters for tech people. LinkedIn isn’t a resume site anymore. It’s a publishing platform where your ideas compound over time. Here, we cover why engineers should care about building a presence, from career opportunities to learning and credibility.

2. My story. How I went from 2,000 to 100,000 followers in six months. We will talk about the two mindset shifts that made it possible.

3. Detailed steps to grow your LinkedIn audience. Ten concrete steps to build your LinkedIn presence from scratch. Covers profile optimization, content systems, posting frameworks, engagement tactics, and analytics.

4. Common mistakes. The profile errors, algorithm penalties, and engagement failures that kill reach. What to avoid so your content actually gets seen.

5. The payoff. What happens when you do this consistently. Recognition, opportunities, improved communication skills, and a community that opens doors you didn’t know existed.

6. BONUS: Prompt to create a viral LinkedIn post. You can use this prompt structure to create many viral LinkedIn posts, with different input parameters and styles.

So, let’s dive in.

You Can Build A LinkedIn Audience (Full Course)

You know your craft. This course helps people know you.

It shows the system I used to grow from 0 to 100K followers in six months, now 260K+, plus a 49K-subscriber newsletter.

After this course, you will be able to:

• Turn your profile into a page that converts visitors into followers, leads, or offers

• Write posts that earn saves, comments, and profile views instead of silence

• Use LinkedIn as a steady source of job offers, clients, and speaking invites

Inside you get:

• 6-module video course (~2 hours of my best advice) walking through profile, content, engagement, and monetization

• LinkedIn Content OS (Notion) with 50 post ideas, templates, and an engagement tracker

• Swipe files, Canva layouts, and a full LinkedIn guide on 30 pages. All you need.

• Tips and tricks only a few know.

👉 Launch price: $79 only this week (then $149)

Start You Can Build A LinkedIn Audience

1. Why LinkedIn matters for people in Tech

If you’re an engineer or tech leader, you might wonder whether building a presence on LinkedIn is worth it. I once treated LinkedIn like a static online resume, like everyone else, but I learned that LinkedIn works best when you treat it as a publishing platform where your ideas compound over time.

In other words, consistently sharing insights on LinkedIn can create outsized career leverage.

Here’s why engineers should care about LinkedIn:

• Professional network & mentorship. LinkedIn is the largest professional network. It’s a place to connect with fellow engineers, mentors, and industry leaders in a professional environment. By engaging on the platform, I met 100+ interesting people – some became friends and collaborators. Your network truly becomes your net worth here.

• Career opportunities. A strong LinkedIn presence means recruiters come to you. Whether you’re hunting for a job, consulting gigs, or speaking opportunities, visibility on LinkedIn leads to inbound offers for roles and projects.

• Continuous learning. The platform is rich with content, from engineering best practices to leadership lessons. By curating a quality feed, you can learn from others’ experiences daily. LinkedIn broadened my perspective and even improved how I communicate as an engineering leader.

• Personal brand & credibility. Regularly sharing valuable content helps you gain authority in your niche. Over time, people begin to associate your name with the topics you post about. I became known for my insights on tech and leadership, giving me credibility that extended beyond LinkedIn. A strong personal brand also gives you leverage for promotions or negotiations (you’re seen as an expert, not just an employee).

• Career flexibility. With a broad audience, you have more options. You can pivot careers, launch a side project or startup, or sell a product more easily when thousands of industry people know who you are. An audience makes your career less dependent on any single employer and opens doors to new ventures.

In short, LinkedIn is a high-leverage tool for engineers. It’s the only major social network dedicated to professionals (nearly 1 billion users), and great technical content can still reach a massive audience even if you’re not famous or extroverted.

2. My story

My LinkedIn journey truly began in mid-2022. At that time, I was a Principal Engineer offline, but virtually unknown on LinkedIn. As I have always liked learning and sharing my knowledge, my current mentor suggested that I increase my visibility outside my company and start writing more. And of course, one of the first networks for that was LinkedIn.

Posting felt intimidating; I thought, “It can feel pointless or self-promotional at first.” To overcome this, I first made two key mindset shifts that set the foundation for my growth.

1. Mentorship over self-promotion: Instead of seeing content as bragging, I treated LinkedIn as a chance to mentor and help others at scale. I asked myself, “What knowledge do I have that could help a junior engineer or a past version of me?” “What are some pain points developers have in the industry, but don’t have proper solutions?” I started sharing tips on system design, career growth, and cloud architecture for developers and architects in my audience.

2. Visibility over perfection: As an engineer, I initially had perfectionist tendencies, spending days polishing a post that I never actually published. I learned on LinkedIn that “consistent visibility beats perfect silence.” In practice, that meant forcing myself to hit “Post” regularly, even if a piece wasn’t 100% polished. Each post became a data point to learn from, rather than a masterpiece. This bias for action, quantity leading to quality, was crucial to my rapid growth.

The results of these mindset shifts were almost immediate. Once I started sharing value generously and frequently, my network exploded. In just 6 months, I rocketed from ~2,000 to 100,000 followers. I had effectively compounded years’ worth of career learnings into a growing library of LinkedIn posts, and the community took notice.

Yet, the follower count was less important than the impact, opportunities, and connections that I created along the way.

3. Steps to grow a LinkedIn audience from scratch

Here are the steps you can follow to grow your audience from scratch.

Step 1: Positioning

Positioning was the foundation of all this profile work. I defined exactly who I wanted to serve and the problem I would solve for them. In my case, I help software engineers advance their careers (the who) by sharing proven insights on tech leadership and architecture (the what and how). This clarity made my profile cohesive; every element (headline, about, posts) told a consistent story of “CTO who mentors engineers.”

For your profile, ask yourself the same four questions:

1. What problem do I solve?

2. Who has that problem?

3. What makes my perspective different?

4. What do I want to be known for?

Answering these will give you a positioning line and content focus that sets you apart.

When you make it, then you define your concrete goals, pick 2-3 topics you want to be known for, and define your audience. This will help you later to identify their pain points and write about how to solve them.

Step 2: Set up your profile

Now, when we properly position ourselves, we need to do the profile optimization steps that make a difference:

1. Crystal-clear headline. Most people just list their job title, but the headline should state their value proposition. Craft a 220-character headline that combines what you do, who you help, and how you help them. (Formula: “What you do | Who you help | Outcome”). For example, rather than “CTO at TechCorp”, a headline could be “CTO mentoring developers into architects | Writing about cloud & leadership | 20+ engineers coached.” This tells people exactly why they should follow or connect with you.

2. Branded banner. Instead of the default blue background, create a simple graphic with a tagline about you and a URL. The banner is prime real estate to visually convey who you are, whether it’s “Cloud Architect | Speaker | Helping you master AWS” or highlighting a key achievement. Don’t leave it blank. Use it to instantly communicate your brand or direct viewers to something valuable (like your blog or course).

3. Storytelling “About” section. A structure that works is: Present – Past – Value – Call to Action. For example, I opened with what I do now (“CTO and writer helping engineers grow”), then told a brief story of feeling invisible despite 15 years in tech, and how sharing on LinkedIn changed my career. I conclude with how I can help others do the same, and a call to action to join my newsletter. The key was a hook in the first two lines (since that’s what shows before “see more”), and an authentic tone. Try to keep paragraphs short and skimmable.

4. Featured and extras: Use the Featured section to showcase your best products, posts, and articles. Here I added links to my newsletter and course landing page. Additionally, I updated the Experience section to focus on accomplishments and the unique credentials that give me authority (e.g., by mentioning that I led cloud migrations impacting millions of users). This is what gives you credibility: a big company you worked at, a PhD, a major project, or even a personal story that shows your expertise.

5. And also don’t forget to enable Creator mode. When you enable it, the Follow button will be the default, and people will be able to follow you without connecting.

Step 3: Defining your content pillars

With the profile in shape, the next challenge is showing up consistently on the feed. Occasional posting will not move the needle, so we need a sustainable Content System (sometimes dubbed a “Content OS”).

To this end, I designed a system that enables publishing 3-5 times per week without burning out. But before we start writing, we need to decide on our topics or content pillars first.

The suggestion is to choose 2-3 core themes to write about repeatedly. These were the topics you want to be known for. For me, the pillars were software engineering/architecture, engineering leadership/career growth, and cloud computing.

Sticking to a few pillars helps ensure that content is relevant to our target audience (developers and tech leads) and also makes idea generation easier.

With pillars set, you have a filter for your content.

Step 4: Brainstorm a Content Matrix

To generate a flood of post ideas, you can use a simple but powerful technique: a grid of topics vs formats. For example, you can list your content pillars and a handful of effective post formats/angles (e.g., how-to guides, inspirational stories, contrarian takes, comparisons, “X vs Y”, present vs future trends, etc.).

Here is one example:

The content matrix ensures you never run out of content and keeps your feed varied.

In my course we learn how to make this matrix by using AI tools.

Step 5: Use a Content Framework

Consistency isn’t just about posting often; it’s also about format consistency. I use a few proven post structures that make writing easier and ensure my content is engaging.

We’ll dive into these in the next section (Storytelling Frameworks), but having go-to templates (like a story post format, a list post format, etc.) lets me draft posts faster.

For instance, if today is a “technical tips” post, we might default to a list of do’s and don’ts with a quick intro and summary (framework: Hook → List → Summary → CTA). If tomorrow is a narrative, we would use this Story → Lesson template.

All of these templates are available in my LinkedIn Content OS.

Step 6: Storytelling and post frameworks

Technical folks often struggle with storytelling, but I found it to be a superpower on LinkedIn. People love stories, so tell one story with one clear lesson.

Early on, I shifted from just sharing tips in a dry manner to wrapping them in relatable anecdotes – essentially turning my posts into mini case studies or personal stories. Each story post followed a simple structure: Story → Lesson → CTA.

For example, I wrote about a time I turned down a $200K job offer (story) and what it taught me about aligning career moves with personal values (lesson), then invited others to share if they’ve faced similar decisions (call-to-action). This post got massive engagement because it was human and specific, not just “advice in a vacuum.”

Beyond stories, I rotate through several post frameworks. These are like templates that make your content punchier and help you avoid staring at a blank page.

Here are a few go-to LinkedIn post types (and how you can use them as an engineer):

Notice how each framework delivers value or insight and often includes a story or example. I cycle through these to keep my feed fresh.

One day, I would drop a list of actionable dev tips; another day, a personal story about a mistake; then a contrarian take on a popular tech practice. This mix prevents audience fatigue and positions you as a multidimensional thinker.

Importantly, I always write in a conversational, first-person tone, as if mentoring a colleague over coffee. No corporate jargon or “resume speak.” Engineers appreciate candor and clarity.

My posts often include little storytelling details (to paint a scene) and then break down the takeaways. I also make my content skimmable, using short paragraphs, bullet points, or emojis to create visual breaks.

Finally, I almost always end posts with a CTA (Call to Action) – a question or prompt that invites the audience to engage. Something like “Have you experienced this?”, “Agree or disagree?”, or “What would you have done?”. This not only drives huge comment threads (boosting the post in the algorithm) but also turns posts into conversations where everyone can learn.

Step 7: Establish a posting cadence

You should treat LinkedIn like a publication with a regular schedule and be committed to posting nearly every weekday. In fact, my weekly content calendar often looked like this:

• 4 technical/industry posts

• 1 fun/relatable post

• 1 personal development/leadership post,

• 1 “promo” or community post (e.g., inviting people to my newsletter).

For example: Monday to Thursday, I share tech insights or stories; Friday, something light or humorous about work culture; Saturday, a deeper personal growth lesson; and maybe Sunday, a short motivational note. This mix kept different segments of my audience engaged and showcased multiple sides of my personality.

You don’t have to post daily, but consistency is key, whether it’s twice a week or five times. Choose a sustainable rhythm. Tools like scheduling software (Typefully, Buffer, etc.) can help you queue posts in advance.

Step 8: Batch and reuse content

An efficiency hack you can employ is batch-creating content. Instead of writing every morning under pressure, you can set aside a block of time to draft multiple posts at once (when ideas are flowing). Many top creators use this batching method to stay ahead.

You should also not be shy about repurposing: a tweet that performed well on X (Twitter) might be expanded into a LinkedIn post, a LinkedIn post that resonated might be repurposed as a newsletter section, and so on. This “create once, publish everywhere” mindset means each idea works harder for you.

In fact, one of my writing tricks (called Lean writing) is to test ideas on Twitter first (where the bar for virality is high and feedback is instant) and then bring the best ones to LinkedIn with more polish.

Step 9: Engaging with the Tech community

Posting great content is only half of the LinkedIn game. The other half, which many engineers overlook, is actively engaging with others. This means commenting on others’ posts, replying to every comment on your own posts, and generally being visible in the community.

In the early days, before you get a large audience, you can grow by commenting on influential people’s posts. You should follow top voices in tech leadership and be one of the first to leave a meaningful comment when they post. This tactic is golden for newcomers. By engaging on popular posts (authentically, not spammy), you “borrow” the poster’s audience, people see your comment, and if it’s insightful, they visit your profile.

Another engagement routine you should follow is being active on your own posts. When you do post, don’t drop it and disappear. The first hour after posting is “golden hour”, so you need to be online to reply to comments, answer questions, and encourage discussion.

This early engagement signals to LinkedIn that the post is interesting, thereby amplifying its reach. In fact, the LinkedIn algorithm heavily favors posts that get engagement in the first 60-90 minutes. Data shows every comment you receive can increase the post’s reach by about 4% in your network (and ~3% in the commenter’s network).

You should treat the comment section like a forum, responding, asking follow-up questions, and even debating politely. This dedication helped foster a loyal community. People know you’ll actually read and respond, so they’re more likely to comment. And more comments = more visibility. It’s a virtuous cycle.

Another growth move you can take is to collaborate with other creators. You can join a few Slack/Discord groups of content-creating professionals where they informally support each other (NOT engagement pods in the spammy sense, but real peers giving feedback and sometimes boosting each other’s posts). By engaging in these communities, you can expand your reach beyond your immediate followers.

If you get the chance, appear on webinars, podcasts, or LinkedIn Live sessions with others in your niche.

💡 One specific tip for busy engineers: schedule some “LinkedIn time” for engagement just as you would for coding or emails. I spend about 20-30 minutes each morning and again in the evening on LinkedIn, not mindlessly scrolling, but engaging with intent. In those windows, I’ll comment on a few posts from people I follow, respond to DMs, and review any interesting discussions.

Consistency here matters too. The algorithm notices when you’re active and will start surfacing your name more often. Plus, people you regularly interact with are more likely to see your posts (LinkedIn’s feed shows content from those who have engaged with each other before). So yes, being social pays off.

Step 10: Track analytics

Posting and engaging with people isn't enough; you need to track the results of your work. Your Analytics section shows three numbers: profile views (your CTR), post impressions (your reach), and search appearances (your SEO).

If profile views are low, your headline is probably wrong. People see your content, but don’t click your name. Test a clearer, more specific version, not “Software Engineer,” but make a position statement in terms of: I help [WHO] achieve [WHAT] using [HOW]. In the technology space, this could be anything from “Get insights into AI daily” to “I teach you to TDD in React.”

Check engagement types next. Reactions are dopamine. Comments mean you sparked a thought. Saves mean you taught something. End posts with specific questions: “Have you dealt with this database scaling issue?” beats “What do you think?”

Also, look at audience demographics. If 90% of your followers are entry-level but you want a senior role, your content is too basic. Shift to architectural trade-offs and system design.

Measure monthly. If impressions are low, fix your hooks. If demographics are wrong, increase technical depth. If growth is flat, connect with people who engage with your posts.

Treat your profile like a product, measure, ship improvements, and check the logs. Double down on what works.

4. Common mistakes

Profile optimization failures remain shockingly common despite a dramatic impact on visibility. Profiles with photos receive 9x more connection requests, and users are 7x more likely to have profiles viewed with photos, yet many engineers still use low-quality images or skip photos entirely.

Algorithm penalties destroy reach for specific behaviors. More than five hashtags trigger spam filters, external links in the post body reduce reach by 25-40% (always place in the first comment instead), AI-generated content faces 30% less reach and 55% less engagement, and posting multiple times within 24 hours reduces the newest post’s reach.

Engagement bait phrases like “Like if you agree” or “Comment YES” are now systematically deprioritized. Overly promotional content, product or service sales, or face-to-face selling can result in a 70%+ reduction in reach; the platform explicitly penalizes active selling.

Engagement mistakes include posting without engaging with others’ content (you should comment on others’ posts 80% more than posting your own), not responding to comments on your posts during the critical first hour, and organizing engagement pods where people agree to like each other’s posts (LinkedIn detects and devalues this behavior).

5. The Payoff

All this effort, optimizing your profile, pumping out content, and engaging with the community, will pay off in the end. It is not just about vanity metrics; it can change your career trajectory.

The most visible result, of course, is the follower count. I grew from essentially zero audience to 260k+ followers in about 2.5 years. This made me one of the most-followed engineering voices on LinkedIn. That kind of reach means whenever I post, tens of thousands of people see it, a powerful position to be in for spreading ideas. Even if your goal isn’t 200k followers, the point is that steady posting and improvement lead to a compounding audience.

As your follower count grows, so does your industry recognition. You will start getting tagged in others' posts as an expert, invited to speak at virtual conferences, and interviewed on tech podcasts. I became known for “that CTO who shares great and free advice on LinkedIn.” This authority can be self-reinforcing: being chosen as one of the Top 100 LinkedIn creators in the world (per a Taplio ranking over the last three years) further boosts my credibility.

Even if you’re not aiming for “LinkedIn influencer” status, being recognized as a thought leader in your niche (even on a small scale) can lead to opportunities like guest blogging, panel invitations, or being consulted for advice. It’s a great feeling when peers at other companies have heard of you because of your content.

Perhaps the most tangible benefit: your LinkedIn presence becomes a magnet for opportunities. You will begin receiving weekly messages about job openings. Additionally, your consulting sideline will take off, inbound leads from people who enjoy your content and want your help with their tech strategy.

If you ever decide to change jobs or launch a startup, you now have a huge platform to tap into for hiring or marketing. Your LinkedIn audience is like a career safety net and launchpad in one.

Also, an often-overlooked benefit: creating content forces you to clarify your thinking and communicate more effectively. Explaining complex tech concepts in simple LinkedIn posts improved my ability to get to the point, useful when briefing executives or writing design docs.

Also, engaging with diverse commenters gave me empathy for perspectives outside my immediate bubble. This showed up in my leadership style, making me more patient and open to feedback.

In a sense, writing online regularly is like training in public speaking or teaching; you get more articulate over time. So even aside from the external wins, you personally grow through the process.

Perhaps the most rewarding aspect for me has been the community I cultivated. I essentially created a tribe of engineers and techies who interact not just with me but with each other. My comment sections have become mini-forums where people exchange ideas.

I mentored dozens of engineers through comments and DMs, and even launched a newsletter and Discord group off the back of my LinkedIn following, where deeper discussions happen.

For someone who started out feeling “invisible” in the industry, this sense of belonging and contributing is a huge personal win. Some of the folks I met via LinkedIn have become business partners and close friends. You can’t put a price on that.

🎁 Bonus: Prompt to create a viral LinkedIn post

This prompt makes ChatGPT follow a clear flow: hook → story → lesson → CTA, with clean spacing and punchy emphasis. Copy it, fill the blanks, and publish.

ROLE: You are a seasoned LinkedIn thought leader and professional copywriter, writing posts earning comments, saves, shares.

TASK: Ghostwrite one text-only LinkedIn post using the inputs below. Optimise for comments and shares, while staying credible.

INPUTS (fill in; facts only):
- Topic / core insight:
- Target reader:
- Credibility (facts only; bullets):
- Proof points (numbers + time window):
- Stakes (what ignoring costs):
- CTA (pick 1: Comment / Share / Follow / DM):
- Tone (pick 1: Educational / Storytelling / Data-driven / Debate-starting):
- Voice: swearing (yes/no), directness (low/med/high), humor (low/med/high):
- Personal story (optional, 3–6 lines):

HARD RULES:
- No invented metrics, clients, employers, credentials, timelines, outcomes.
- No hashtags, links, or AI mentions.
- No mention of AI. No mention of instructions.
- No ALL CAPS.
- 1–2 sentences per paragraph, frequent line breaks.
- First-person “I”, address “you”.

ENGAGEMENT CHECKLIST (must hit all):
- First 2 lines create curiosity + tension.
- Include one quotable “save/share” line (standalone line).
- Ask one comment question forcing a specific example:
  “X vs Y — which do you pick, and why? Give one real example.”
- Include 3 concrete specifics (numbers, timeframes, tools, mistakes, before/after).
- Deliver 1–3 takeaways as bullets or numbered lines.

FORMAT + FLOW:
Hook → story/problem → takeaways → CTA.

CTA FORMAT:
- Comment: ask for a word or short phrase.
- DM: “DM me the word: KEYWORD.”
- Follow/Share: one line, direct.

ANTI-FLUFF BLACKLIST (avoid):
game-changer, leverage, crush it, authenticity, unlock, synergy, “nobody talks about”, ever-changing, cutting-edge, dive deep, robust, seamless, empower, at the end of the day

QUALITY LOOP (internal; do not output steps):
1) Draft 2 hook options, each ≤ 210 characters. Pick the stronger hook.
2) Draft the full post.
3) Edit pass: cut repeats, vague claims, filler.
4) Final scan: ≤ 1,600 characters; checklist passes.

OUTPUT RULE:
- If inputs missing, list them as bullets and stop.
- Else return only the final post text.

More ways I can help you (Including Black Friday discount of 30% until the end of this week):

• 📚 The Ultimate .NET Bundle 2025 🆕. 500+ pages distilled from 30 real projects show you how to own modern C#, ASP.NET Core, patterns, and the whole .NET ecosystem. You also get 200+ interview Q&As, a C# cheat sheet, and bonus guides on middleware and best practices to improve your career and land new .NET roles. Join 1,000+ engineers.

• 📦 Premium Resume Package 🆕. Built from over 300 interviews, this system enables you to craft a clear, job-ready resume quickly and efficiently. You get ATS-friendly templates (summary, project-based, and more), a cover letter, AI prompts, and bonus guides on writing resumes and prepping LinkedIn. Join 500+ people.

• 📄 Resume Reality Check. Get a CTO-level teardown of your CV and LinkedIn profile. I flag what stands out, fix what drags, and show you how hiring managers judge you in 30 seconds. Join 100+ people.

• ✨ Join My Patreon Community and My Shop. Unlock every book, template, and future drop, plus early access, behind-the-scenes notes, and priority requests. Your support enables me to continue writing in-depth articles at no cost. Join 2,000+ insiders.

• 🤝 1:1 Coaching. Book a focused session to crush your biggest engineering or leadership roadblock. I’ll map next steps, share battle-tested playbooks, and hold you accountable. Join 100+ coachees.

Want to advertise in Tech World With Milan? 📰

If your company is interested in reaching founders, executives, and decision-makers, you may want to consider advertising with us.

Love Tech World With Milan Newsletter? Tell your friends and get rewards.

We are now close to 50k subscribers (thank you!). Share it with your friends by using the button below to get benefits (my books and resources).

Share Tech World With Milan Newsletter

Track your referrals here.

I’ve sat through hundreds of these meetings from both sides. As an engineer, I dreaded the awkward silences and forced small talk. As a manager, I watched talented developers zone out while I asked generic questions about their week. We were all doing it wrong.

The turning point came when I realized something fundamental: we’d been treating 1:1s like project management meetings when they’re actually relationship and career accelerators. This isn’t about tracking tickets or reviewing code. It’s about the conversations that shape careers, build trust, and solve the human problems that no amount of documentation can fix.

Research backs this up dramatically. Teams with regular, well-run 1:1s show engagement rates that are triple the average. They ship better code, have lower turnover, and handle conflict before it explodes. Yet most engineering organizations run these meetings on autopilot, wasting many hours per year per person on conversations that could’ve been emails.

The difference between exceptional 1:1s and terrible ones isn’t complicated. It comes down to understanding who owns the meeting, what belongs in it, and how to make the awkward parts productive. Once you get these fundamentals right, everything else follows.

In particular, we will talk about:

• Why 1:1s matter. How 1:1s differ from other meetings and why they’re critical for engineer retention and team performance. The real purpose behind these meetings that most people miss.

• This is your meeting, not your manager’s. Who owns what in a 1:1 and why treating it like a status update kills its value. How both engineers and managers should prepare and show up.

• Agenda: Use a flexible framework. The People/Product/Process framework and how to apply it without becoming rigid. Structure as a safety net, not a script.

• Great questions lead to great answers. Questions that unlock real conversations versus ones that get you nowhere. Specific examples and the 70/30 listening rule that changes everything.

• Have the awkward conversations. Creating psychological safety and bringing up the topics you can’t discuss anywhere else. Why discomfort signals you’re doing it right.

• Make the logistics matter. The practical details that make or break 1:1s: frequency, duration, documentation, and pre-work.

• For managers: Stop talking and start coaching. Shifting from problem-solver to coach. How to develop decision-makers instead of creating dependencies on you.

• What to avoid. Common mistakes that destroy the unique value of 1:1 time.

• Start simple, then iterate. Evaluating whether your 1:1s work and how to improve them over time.

So, let’s dive in.

Master Protobuf: Build APIs That Don’t Break (Sponsored)

Your API works perfectly. Then someone adds a field. Half of your services break in production.

This free workshop shows you how to build APIs that evolve without exploding.

In 1 hour, you’ll learn:

• How to catch breaking changes at compile time, not in production, validation patterns that actually prevent incidents

• Battle-tested API design patterns from teams handling billions of requests

• Why Protobuf matters beyond gRPC, event streaming, data pipelines, and anywhere you need consistent data types

• Real answers to your specific Protobuf challenges, interactive Q&A throughout

Skip years of painful lessons. Learn what works from engineers who’ve already been through it.

Join the live workshop on November 19th at 9:00 AM PDT | 12:00 PM EDT | 5:00 PM BST.

Register free

Sponsor this newsletter

Why 1:1s matter

A 1:1 isn’t just another meeting. It’s dedicated personal time with your direct report. In fact, 1:1s aren’t about the work itself; they’re about the person who does the work. When you treat 1:1s as optional or purely tactical check-ins, you lose one of your best chances to build trust, surface issues early, coach growth, and retain great engineers. Consistent, well-run 1:1s can transform a team’s performance and morale.

Think of a 1:1 as a safety valve and springboard: a place to catch problems before they explode, and to nurture an engineer’s development before they stagnate. It’s their time to talk freely, and your time to listen and support. Keep that purpose in mind at all times.

This is your meeting, not your manager’s

First-time managers obsess over task management in 1:1s. They open Jira, review tickets, and turn the entire session into a status sync. This is the cardinal mistake. Your manager already has dashboards, standups, and async updates for tracking work. The 1:1 exists for things that don’t fit anywhere else.

• For engineers: Come prepared with what matters to you (have an agenda!). It could be: career goals, work priorities, or personal development. The meeting should cover your career growth, relationships with teammates, obstacles blocking your work, and feedback in both directions.

• For managers: Your job is to empower employees to solve their problems and help them navigate roadblocks. Remember, the 1:1 is their forum; encourage them to add to the agenda. But as the manager, you should have a few prompts ready to kindle a meaningful discussion.

Finally, set a welcoming tone. I like to begin with a bit of genuine small talk: ask about their weekend, their new house plant, or how their life’s been lately. Be personable. Showing that you care about them as a human (not just a coder) helps build the trust needed for candid conversations.

The ownership distinction matters. As the engineer, you own the agenda and pre-work. As the manager, you’re ultimately responsible for the relationship and outcomes. This tension is intentional.

Agenda: Use a flexible framework (not a status checklist)

The 1:1 is a higher-leverage conversation. As one seasoned engineering manager told me, “The 1:1 should focus on the employee’s needs, not just status updates.” In other words, it’s a forum for topics that don’t fit neatly into Jira tickets or team meetings.

That said, having a loose structure or framework can ensure you cover important ground. One effective format I’ve used is the classic “People, Product, Process” approach

• People (5min): How are team dynamics and relationships? (e.g., “How are things going with the team?”). This can reveal interpersonal issues or successes.

• Product (10min): What’s the focus of their work? (e.g., “What have you been working on lately?”). Not a detailed status, but a high-level view of progress, victories, or blockers.

• Process (10min): Are there any tools, process issues, or general improvements that would make their work life better? (e.g., “Anything we can do to make your day-to-day easier or happier?”).

This structure is just a guide – adapt it to what works for you. The goal is to touch on the person, their work, and the environment. Often, I won’t even formally announce these sections; I keep them in mind to steer the conversation. If the discussion naturally dives deep into one area, that’s fine. You don’t need to cover every category every time, as long as the conversation is valuable.

Throughout the 1:1, let the employee lead as much as possible. If they come in with something pressing to discuss, run with that. Your framework is a safety net to ensure you don’t miss topics that matter, not a rigid script.

Great questions lead to great answers

Great 1:1s are driven by open-ended, thought-provoking questions - and a lot of listening on your part. If you’re doing most of the talking, something’s off. A good rule of thumb is to let the direct report talk ~70% of the time, with you talking 30% (mostly asking questions, guiding gently, and clarifying).

Resist any urge to dominate the conversation or fill every silence. Silence can be golden. It often means the other person is thinking. Give them space to reflect and respond.

When you do ask questions, avoid the generic and shallow. “How’s it going?” will usually get you “Good, you?” and then awkward silence. Instead, ask deeper questions that encourage reflection and honesty.

For example, instead of “Everything on track?”, you might ask, “What’s been the most challenging part of this project for you?” Compare “How’s the team?” to “Who’s someone on the team you’ve enjoyed working with lately – and anyone who’s been hard to work with?”

The latter invites a meaningful answer. Dig past the surface: if they give a short, safe answer, follow up with “Why?” or “Tell me more about that.”

And remember: listen actively. Show you’re listening by maintaining eye contact (or active engagement on video calls), nodding, and occasionally paraphrasing what you heard. This is their time to be heard. Your job is mostly to listen, understand, and ask the right follow-up questions.

Examples of great 1:1 questions:

• What’s something you’re proud of this week? (Or something that frustrated you?)

• Is anything blocking your progress or draining your energy lately?

• How do you feel about the team’s collaboration and communication recently?

• What skills or areas do you want to grow in over the next few months?

• What’s one thing I could do better to support you or make your job easier?

These kinds of questions spark dialogue beyond “everything’s fine.” They can uncover hidden issues or aspirations. As the manager, pay attention to both what’s said and what isn’t. If a report consistently says “All good” but seems hesitant, gently probe further or rephrase the question next time. Over time, as trust grows, they’ll open up more.

How to listen properly?

👂 In general, there are three levels of listening:

1. We listen for content. Here, we notice what is said, words, facts, etc.

2. We listen for structure. Here, we notice behavior, emotions, and so on.

3. We listen deeply. Here, we notice the whole picture, including values, beliefs, motivation, etc.

Combining all this, we will connect with people on a deeper level, so they feel like: “Wow, this person understands me, this person values me, I can talk to this person…”.

And remember that you have two ears and one mouth. This is not a coincidence!

Think about this before your next conversation.

Have the awkward conversations

The best 1:1s include topics you couldn’t discuss openly in Slack or standup. This is where you commit to saying the awkward things. “I’m confused about our team’s direction.” “Working with John has been frustrating.” “I don’t think I’m growing here.”

These conversations require psychological safety, which you build through consistent follow-through. When your manager commits to removing a blocker, they must actually do it. When you raise concerns, they should acknowledge them rather than getting defensive. Trust accumulates through dozens of small promises kept.

Share what motivates you and what drains you. Talk about areas where you want to grow. Express gratitude for what’s working and confusion about what isn’t. The vulnerability feels uncomfortable, but it’s precisely what makes 1:1s valuable.

For managers: Ask directly for feedback on how you’re doing. “What can I do better?” and “How are these 1:1s working for you?” are the fastest ways to improve. Most engineers won’t volunteer this feedback unless you explicitly request it.

Make the logistics matter

Consistency is non-negotiable. Weekly meetings give you 4x as many opportunities to catch problems early as monthly meetings do. Every canceled 1:1 without immediate rescheduling chips away at your relationship. Engineers judge managers by how they treat these meetings. Treat them as your highest priority calendar item.

Next, set up a shared document. Notion, Google Docs, whatever, with reverse-chronological entries. Each week gets a date header with the three sections underneath. This running history creates mutual accountability. Write things down visibly during the meeting, notes, and action items. When your manager types “Finished database migration” while you’re talking, it shows they’re paying attention.

Here you can check out my Notion template - 1:1s for Engineering leaders, which you can use immediately.

So, start the week with your 1:1 early enough to surface blockers, but not at 8 am when nobody wants to discuss career growth. Thirty minutes is the right default. If you’re consistently running over, extend to 45. If you finish early regularly, the meeting probably isn’t serving its purpose.

The pre-work matters enormously. Engineers should send a brief weekly wrap-up the day before: current priorities, any blockers, and what’s on their mind. Managers must read this before the meeting. Showing up unprepared signals disrespect more than anything you could say.

For managers: Stop talking and start coaching

Most engineering managers talk too much in 1:1s. They solve problems that engineers could solve themselves. They give advice before understanding the real issue. They fill silences that would’ve led to breakthrough conversations.

I’ve learned this from my experience, but when I learned more about coaching and how powerful it is, I realized that it is more than just managing people.

What we want to achieve:

• Create psychological safety first. Your engineer needs to know they can say “I’m struggling” or “I disagree with our technical direction” without consequences. Build this by asking real questions and actually listening to the answers. “What’s on your mind?” beats “How’s everything going?” every time. The second question invites “fine.” The first invites truth.

• Wear your coaching hat, not your solving hat. When an engineer brings you a problem, resist the urge to fix it immediately. Ask “What have you already tried?” and “What would you do if you had to decide right now?” You’re developing decision-makers, not creating dependencies on you. The hardest part is staying quiet when you know the answer. Do it anyway.

• Make room for the messy stuff. Engineers often need to process emotions before they can solve problems. When someone vents about a frustrating code review or difficult teammate, don’t jump to solutions. Let them talk it out. Say “Tell me more” or just nod. Sometimes the venting itself is the solution. They’ll often talk themselves into clarity without you saying a word.

• Hold people accountable without micromanaging. End each topic with “What’s your next step?” not “Here’s what you should do.” Write it down. Follow up next week. If they didn’t do it, ask “What got in the way?” not “Why didn’t you do this?” The first question uncovers systemic blockers. The second creates defensiveness.

• Ask for reverse feedback every month. “What could I do differently to support you better?” works better than generic “How am I doing?” questions. Be specific: “Was there a moment this month where I could’ve handled something better?” When they give you feedback, say thank you and act on it. Nothing builds trust faster than changing behavior based on their input.

Remember: your success is measured by your team’s growth, not by how many problems you personally solve. The best engineering managers leave 1:1s having said less than 30% of the words. If you’re doing more than that, you’re probably managing too much and coaching too little.

Learn more about how to be accountable:

Tech World With Milan Newsletter

How to be Accountable?

This week’s issue brings to you the following…

Read more

2 years ago · 47 likes · Dr Milan Milanović

What to avoid

Here are a few things you should avoid in 1:1s:

• Don’t use 1:1s only for status updates. If you’re spending 25 minutes reviewing what shipped, you’re wasting the unique value of dedicated one-on-one time. Handle that async or in team meetings.

• Don’t dominate the conversation as a manager. If you’re talking more than 50% of the time, you’re doing it wrong. The engineer should drive the agenda and the discussion.

• Don’t skip the follow-through. Dropped commitments erode trust faster than anything else. If you said you’d investigate the CI pipeline issues, do it before the next 1:1 and report back.

• Don’t share notes or gossip. What’s said in a 1:1 stays private. The moment engineers think you’re repeating their concerns to others, they’ll stop being candid.

• Don’t cancel without immediate rescheduling. This signals that the meeting, and, by extension, the engineer, is not a priority. Protect this time fiercely.

Most of these were mistakes I made during my 1:1s when I started working with people. Taking this into account will greatly improve your 1:1s with your people.

Start simple, then iterate

Good 1:1s feel like good product-market fit. Are you both excited for the meeting? Is the structure delivering increasing value? Would you be disappointed if you couldn’t have them anymore?

If the answer is no, ask for feedback on the 1:1s themselves. Try the People/Product/Process framework for a month. Write things down. Show up consistently. Listen more than you talk. Most importantly, remember these meetings exist to make engineers more effective and fulfilled in their work.

The best 1:1s are the ones where difficult topics surface early, small problems stay small, and trust compounds week after week. They’re not always comfortable, but they’re always worth it. Engineers who master 1:1s, from either side of the table, accelerate their careers and build stronger teams.

Weekly 1:1s are 30 minutes that determine whether engineers stay or leave, whether they grow or stagnate. Run them like they matter, because they do.

More ways I can help you:

• 📚 The Ultimate .NET Bundle 2025 🆕. 500+ pages distilled from 30 real projects show you how to own modern C#, ASP.NET Core, patterns, and the whole .NET ecosystem. You also get 200+ interview Q&As, a C# cheat sheet, and bonus guides on middleware and best practices to improve your career and land new .NET roles. Join 1,000+ engineers.

• 📦 Premium Resume Package 🆕. Built from over 300 interviews, this system enables you to craft a clear, job-ready resume quickly and efficiently. You get ATS-friendly templates (summary, project-based, and more), a cover letter, AI prompts, and bonus guides on writing resumes and prepping LinkedIn. Join 500+ people.

• 📄 Resume Reality Check. Get a CTO-level teardown of your CV and LinkedIn profile. I flag what stands out, fix what drags, and show you how hiring managers judge you in 30 seconds. Join 100+ people.

• 📢 LinkedIn Content Creator Masterclass. I share the system that grew my tech following to over 100,000 in 6 months (now over 255,000), covering audience targeting, algorithm triggers, and a repeatable writing framework. Leave with a 90-day content plan that turns expertise into daily growth. Join 1,000+ creators.

• ✨ Join My Patreon Community and My Shop. Unlock every book, template, and future drop, plus early access, behind-the-scenes notes, and priority requests. Your support enables me to continue writing in-depth articles at no cost. Join 2,000+ insiders.

• 🤝 1:1 Coaching. Book a focused session to crush your biggest engineering or leadership roadblock. I’ll map next steps, share battle-tested playbooks, and hold you accountable. Join 100+ coachees.

Want to advertise in Tech World With Milan? 📰

If your company is interested in reaching founders, executives, and decision-makers, you may want to consider advertising with us.

Love Tech World With Milan Newsletter? Tell your friends and get rewards.

We are now close to 50k subscribers (thank you!). Share it with your friends by using the button below to get benefits (my books and resources).

Share Tech World With Milan Newsletter

Track your referrals here.

In October 2025, a race condition in AWS’s DNS automation caused a regional endpoint to be emptied. 113 services crashed. Recovery took 15 hours. Two months earlier, a null pointer in Google Cloud caused Service Control, the gatekeeper for every API request, to crash. 50+ services went dark for seven hours.

And in July 2024, CrowdStrike deployed a bad configuration file to kernel-mode drivers worldwide. 8.5 million Windows machines are locked in boot loops. Airlines grounded flights, and hospitals canceled surgeries.

These weren’t sophisticated attacks or infrastructure failures. They were simple bugs: a race condition, a missing null check, a bad config file. But at this scale, simple bugs become catastrophic.

This post breaks down what actually happened in each incident.

In particular, we will talk about:

1. DNS race condition caused the large AWS outage. How a time-of-check-to-time-of-use bug emptied DynamoDB’s endpoint and took down 113 services for 15 hours

2. How a null pointer at Google Cloud crashed the Internet. Why a missing null check in Service Control brought down 50+ services across 40+ regions for seven hours

3. A single deployment that made the whole world stop. How CrowdStrike’s kernel driver update locked 8.5 million Windows machines in boot loops

4. Bonus: When Azure’s safety checks failed. How a config change bypassed validation and took down Azure Front Door, and dozens of Microsoft services, for 8 hours.

So, let’s dive in.

Sponsor this newsletter

1. DNS race condition caused the large AWS outage

At 2:50 AM Eastern on October 20, 2025, a DNS race condition in DynamoDB’s automation caused the us-east-1 regional endpoint (in the northern Virginia cluster) to be emptied. Within minutes, 113 AWS services began to fail. Ring cameras lost recordings, banking apps crashed, and Snapchat, Fortnite, and Slack went dark.

The outage began at 11:48 PM PDT (2:48 AM EDT) on October 20. DynamoDB DNS was restored at 2:25 AM PDT, roughly 3 hours after the outage. But cascading failures kept services down for 12 more hours.

For engineers building resilient systems, this incident reveals uncomfortable truths about race conditions, dependency chains, and the hidden fragility of cloud-native architectures.

The full AWS report can be read here.

The root cause: a race condition

AWS’s DynamoDB uses an automated DNS management system split into two components. The DNS Planner monitors load balancer health and generates DNS configuration plans. Three DNS Enactor instances (one per availability zone) independently apply these plans to Route 53. The design assumed race conditions were acceptable due to eventual consistency.

On October 20, this assumption proved to be wrong. DNS Enactor #1 experienced unusual delays applying an old plan. Meanwhile, the DNS Planner continued generating new plans. DNS Enactor #2 raced through these newer plans and executed a cleanup process, deleting “stale” plans just as Enactor #1 completed its delayed run.

The staleness check, performed hours earlier at the start of processing, was now meaningless. Enactor #1 overwrote Route 53 with outdated data. Enactor #2 detected the “old” plan and triggered deletion, emptying all IP addresses from dynamodb.us-east-1.amazonaws.com. The regional DynamoDB endpoint vanished from DNS entirely.

This is a classic time-of-check-to-time-of-use (TOCTOU) vulnerability. The staleness check occurred when processing started, but the actual write happened hours later. In distributed systems with high latency, checking the state at the beginning but applying changes at the end creates a massive window for inconsistency.

AWS recognized the severity immediately. They disabled the DNS Planner and Enactor automation globally, not just in us-east-1, pending fixes. This revealed an uncomfortable truth: the race condition existed in all regions but had only been triggered in one.

This is not the first time that incident happens in this region. There were outages in 2021, 2020, and even in 2012 too.

The cascading problem

DynamoDB recovered at 2:25 AM PDT, just under 3 hours after the incident began. But this is where the story gets worse.

The DropletWorkflow Manager (DWFM), which manages leases for physical hosts (droplets) and orchestrates state changes across the EC2 fleet, lost connectivity to DynamoDB. When DNS failures prevented health checks, leases across the entire fleet timed out. EC2 marked servers as unavailable and blocked new instance launches due to “InsufficientCapacity” errors.

After DynamoDB recovered, DWFM attempted to re-establish leases for the entire EC2 fleet at once. At AWS’s scale, processing took longer than the lease timeout periods. Work completed, then immediately timed out, queuing more work in an infinite loop. DWFM entered a death spiral, unable to make forward progress. Engineers required 3 additional hours of manual intervention to break the cycle.

This reveals a fundamental pattern: lease-based systems work perfectly under normal load but collapse under stress when processing time exceeds timeout periods. Your recovery automation can become the failure mode.

The dependency multiplier

With EC2 launches impaired, Lambda couldn’t create execution environments. ECS, EKS, and Fargate couldn’t start containers. Network Load Balancers experienced a different problem: health checks flapped on newly launched instances due to network state lag in the Network Manager, which was processing a massive backlog of delayed state changes.

These flapping health checks triggered automatic DNS failover across availability zones. AWS disabled automatic failover at 9:36 AM PDT to stabilize the system, then re-enabled it at 2:09 PM PDT once backlogs cleared.

Amazon Connect failed because it depends on Lambda and NLBs. Redshift queries broke. STS authentication failed. CloudWatch degraded. The dependency chain looked like this: DynamoDB DNS → DynamoDB APIs → DWFM → EC2 launches → Network Manager → NLB health checks → Lambda, ECS, EKS, Fargate → 100+ dependent services.

One empty DNS record brought down 113 services. The root cause was fixed in roughly 3 hours. Cascading failures took an additional 12 hours to resolve. Full EC2 recovery happened at 1:50 PM PDT, with most services returning to normal by 2:20 PM PDT.

How AWS outage made water beds stuck

One of the interesting incidents relating to this outage, was the problem with The Eight Sleep smart beds. These smart beds use water-based thermal regulation controlled entirely through cloud infrastructure. When AWS failed, beds continued executing their last program, typically preheat routines for morning wake-up, with no ability to accept new commands. No local control existed. Users described sleeping in a sauna as beds locked at 110°F, some stuck in inclined positions unable to flatten.

CEO Matteo Franceschetti apologized and quickly shipped “Outage Access”, direct local app-to-device communication via Bluetooth when cloud infrastructure is unavailable.

Takeaways for building resilient systems

Even though we miss details from the AWS post-mortem, especially why DNS Enactors slowed down and deleted all DNS records, there are a few lessons we can learn from:

• Audit your staleness checks for TOCTOU vulnerabilities. Any pattern where you check the state at the beginning but apply changes at the end creates race condition windows. Use atomic operations, compare-and-swap at write time, optimistic locking with version numbers, or distributed consensus protocols for critical state changes.

• Your recovery automation needs circuit breakers. Monitor recovery process queue depths, implement exponential backoff, add rate limiters that account for queue depth rather than just throughput, and test recovery under production-scale load.

• Map your dependency chains and identify blast radius multipliers. Draw the actual dependency graph for your critical services. Where does one foundational service failure cascade? Implement bulkheads between service layers, add timeout and retry budgets at each layer.

• Test when recovery and failure happen simultaneously. Most chaos engineering tests individual component failures or clean recovery scenarios. The AWS outage became catastrophic because recovery systems continued to run while failures persisted. Test what happens when automated cleanup runs while delayed operations are still in flight.

• Rethink what multi-region actually means. AWS disabled DNS automation globally after a failure in us-east-1, proving the bug existed everywhere. Ensure control planes are truly independent within each region, without hidden dependencies on a primary region. Test complete region isolation, including management operations.

What can we conclude from this

The uncomfortable truth: even with world-class talent, formal verification methods, extensive chaos engineering, and decades of operational experience, distributed systems remain fundamentally hard. The complexity of hyperscale creates emergent failure modes that are nearly impossible to predict or fully test.

The question isn’t “could this happen to us?” The question is, when it happens to you, will you survive it? The next outage is already brewing somewhere in your stack. Your job is to ensure you’ve designed enough redundancy, eliminated enough tight coupling, and built enough circuit breakers so that when a latent race condition triggers, your systems degrade gracefully.

2. How a Null pointer at Google Cloud crashed the Internet

On June 12, 2025, at 10:45 AM PDT, a policy change with blank fields was entered into Google’s Spanner database and replicated globally within seconds. Service Control, the gatekeeper for every Google Cloud API request, processed this corrupted data, encountered a null pointer exception, and crashed. Within minutes, Spotify, Discord, Gmail, Drive, Vertex AI, and hundreds of other services went down. Recovery took seven hours.

A missing null check caused 50+ services across 40+ regions to crash.

The full Google report can be read here.

Service Control - Google Cloud’s single point of failure

Every API call to Google Cloud passes through Service Control. Provisioning a VM, querying BigQuery, uploading to Cloud Storage, etc. Service Control validates authorization, enforces quotas, checks policies, and logs audits. This centralized architecture creates efficiency but also a critical vulnerability: when Service Control fails, Google Cloud fails (single point of failure).

The system runs as a distributed control plane with regional instances sharing policy metadata through global Spanner replication. Policy updates propagate worldwide within seconds. Under normal conditions, this provides consistent authorization decisions with minimal latency. During this outage, it distributed failure at the speed of light.

Service Control’s responsibilities, quota enforcement, policy validation, audit logging, and usage metering make it essential for everything. Google Workspace products depend on it. Third-party apps depend on it. Google’s own services depend on it. Distributed systems engineers call this “fate-sharing” architecture. Hundreds of services are tied to the health of a single component.

The hidden bug

On May 29, Google deployed new quota policy checking code to Service Control. The code contained a null-pointer vulnerability in a path that was never exercised during testing. No feature flag protected it, no mechanism to disable the logic without redeploying a new binary.

The bug was simple. The new code failed to validate policy fields before processing them:

instead of

Encountering blank values triggered an unhandled exception that crashed the entire Service Control process.

The bug remained dormant for 14 days because the policy structure that would have triggered it hadn’t appeared in testing or production. The regional rollout gave false confidence; the code was successfully deployed everywhere because it wasn’t being used.

It is interesting that static analysis missed it, but also code reviews and testing.

When speed becomes a problem

Spanner replicates data globally within seconds for strong consistency. This normally ensures authorization decisions remain coherent worldwide. During this outage, it became the mechanism for distributing failure at the speed of light.

The corrupted policy data entered Spanner and reached every region before engineers could intervene. No validation checkpoints existed before global distribution, no schema validation, and no content checks.

The system prioritized consistency and speed over safety, assuming data entering the pipeline would always be valid. This created what ThousandEyes called an “unintentional failure vector”, a resilience feature that became a pathway for amplifying disruption.

The diagram below shows why instant global replication became a failure amplifier. Note that the same consistency mechanism that makes Google Cloud reliable under normal conditions guaranteed that a single bad data commit would corrupt every region simultaneously.

The error signature

ThousandEyes monitoring revealed that different services and regions experienced different error types, and the same request could produce different errors in rapid succession.

HTTP 401 Unauthorized hit Spotify hardest; authentication succeeded, but authorization failed because corrupted policy data read as “no permissions.” HTTP 403 Forbidden meant Service Control misinterpreted blank fields as explicit denials. HTTP 500 Internal Server Error indicated mid-authorization crashes. HTTP 503 Service Unavailable was caused by a complete system overload due to crash loops. Timeouts meant instances were completely unresponsive.

The most diagnostic pattern was error cycling. Identical requests returned timeouts, then 403s, then 500s, then 401s, with no pattern. This occurred when load balancers distributed requests across Service Control instances that failed independently, each in a different state. The randomness proved this was a distributed authorization problem, not an infrastructure failure.

The cascading impact

More than 50 Google Cloud services failed across 40+ regions. Google Workspace products went down. Hundreds of third-party applications stopped working.

Core infrastructure services failed immediately; IAM couldn’t authorize operations; Cloud Storage denied API access; and Compute Engine’s management plane became unavailable. Running VMs continued because they didn’t need fresh API calls, but nothing new could be created.

Data services saw comprehensive failures. BigQuery couldn’t authorize dataset access. Cloud SQL connections failed. Firestore operations stopped. These failures halted analytics pipelines and prevented applications from reaching their databases.

Vertex AI was completely halted for over six hours due to complex dependencies. Developer tools and serverless platforms failed, Cloud Run deployments, Cloud Functions execution, and App Engine access all stopped. These failures hit hundreds of millions of users.

Spotify reported 46,000+ outages, with HTTP 401 errors consistently returned. Discord went down, Shopify degraded, Snapchat couldn’t authenticate, and GitLab CI/CD pipelines stopped. The downstream impact revealed the deep dependency chains in modern cloud architecture.

This was fundamentally an authorization failure, not an authentication failure. Users’ identities verified successfully. Corrupted policy data prevented systems from determining what authenticated users could do.

What went wrong

Here are some critical failures:

• No feature flag. The new quota-checking logic was deployed actively across all regions with no gradual enablement, no canary testing, and no ability to disable it without emergency redeployment. A feature flag could have enabled it for internal projects first, then gradually increased the canary percentages with monitoring.

• No null check. The bug was trivial, a missing null check that any programmer could write in seconds. But the consequences were catastrophic because the code assumed data would always be valid.

• No replication validation. Spanner’s instantaneous replication had no validation checkpoints. Metadata updates need schema validation, automated smoke tests in canary regions, health checks between propagation stages, and rollback mechanisms. Consistency doesn’t require instant propagation. A staged rollout over minutes, with validation gates, reduces the blast radius.

• No graceful degradation. Service Control crashed instead of degrading when it encountered unexpected data. Resilient design would log warnings, fall back to previous known-good policy versions, or implement “fail-open” mode. Circuit breakers could have detected repeated failures and prevented the processing of corrupted data.

• No randomized backoff. The us-central1 “herd effect” showed what happens when thousands of instances restart simultaneously. Exponential backoff with jitter is standard: delay = base_delay * 2^attempt + random(0, jitter). This prevents thundering herds and distributes the load during recovery. Its absence turned recovery from minutes into hours.

The lesson

Distributed systems break globally in seconds but take hours to repair. Breaking is passive; failures cascade automatically. Recovery is active; it requires human intervention, careful coordination, staged rollouts, monitoring at each step, and defensive measures to prevent recovery from causing secondary failures.

The concentration of critical functions in Service Control created a single point of failure despite massive investment in redundancy. Horizontal scaling means nothing if all instances fail simultaneously from a corrupted global state. True resilience requires diversity, different systems with different dependencies, different code paths, and different failure modes.

For software engineers, this outage reinforces the basic principles, null checks, error handling, feature flags, and comprehensive testing, which are not optional. The most sophisticated distributed database, the largest cloud infrastructure, and decades of collective engineering experience couldn’t prevent catastrophic failure from a missing null check.

Reliability is built on layers of defensive practices, each simple in itself but essential when combined. Skip any one of them, and a minor bug becomes a global disaster.

3. A single deployment that made the whole world stop

On July 19, 2024, at 4 AM, our customers started reporting errors. We checked Azure, and SQL databases weren’t responding. The status page showed Central US was down across all three availability zones. Then we realized: this wasn’t just Azure.

8.5 million Windows machines worldwide were stuck in boot loops. Airlines grounded flights. Hospitals canceled surgeries, and emergency services went offline.

What actually happened

CrowdStrike’s Falcon Sensor runs in kernel mode. That means it operates at the same privilege level as device drivers, below the operating system, with direct hardware access. This positioning lets it detect threats that normal applications can’t see. But kernel code has no safety net. One error crashes the entire system.

Windows requires certification for kernel drivers, but that process takes weeks. CrowdStrike built a workaround: Channel Files that update threat detection logic without touching the driver itself. Fast updates, no recertification needed. Channel File 291 was supposed to improve behavioral protection.

Instead, it tried to read from a NULL memory pointer.

In C# or Java, this throws an exception that the runtime catches. In C++, running in kernel mode, it triggers an immediate system crash. The machine reboots, loads the driver, hits the same error, and crashes again. Infinite loop.

The full CrowdStrike report can be read here.

The Timeline

1. 04:09 UTC: CrowdStrike deploys the update globally. Within minutes, machines start crashing. Because Falcon is a boot-start driver, it loads before Windows; affected machines can’t boot into the OS to receive a fix.

2. 05:27 UTC: CrowdStrike identifies the problem. 78 minutes after deployment.

3. 06:27 UTC: They roll back the update.

But the damage is done. IT teams have to manually fix each machine: boot into Safe Mode, navigate to C:\Windows\System32\drivers\CrowdStrike, delete the file matching C-00000291*.sys, reboot. For organizations with thousands of machines, this takes days.

The bigger problems

This exposed three systemic issues.

1. First, the kernel-mode trap. Security software needs deep system access to catch sophisticated threats. But that access creates fragility. Microsoft pushes vendors toward user-space solutions, but effective endpoint protection still requires kernel privileges. The industry hasn’t solved this tension.

2. Second, the certification bypass. Windows driver certification exists to prevent exactly this kind of failure. But it’s too slow for security software that needs daily updates. CrowdStrike’s Channel Files were a pragmatic workaround that backfired.

3. Third, the deployment model. CrowdStrike pushed this update to millions of machines simultaneously, without a gradual rollout. In cloud infrastructure, this would be unthinkable. But endpoint security treats every machine as critical; you can’t leave some exposed while testing. This creates pressure to deploy fast and broadly.

What can we learn from this

• Test configuration like code. CrowdStrike’s error wasn’t in their driver; it was in a configuration file. Many teams skip rigorous testing for config because it seems less risky. Wrong. Treat config as code. Run it through the same validation, testing, and review. Write automated tests that catch type mismatches and NULL references.

• Use staged rollouts everywhere. Deploy to 1% of machines first. Monitor for crashes. CrowdStrike could have caught this in minutes with a proper canary. The delay would have been hours. The alternative was a global outage.

• Build an automatic rollback. When deployment causes crashes, the system should detect the pattern and revert without human intervention. CrowdStrike identified the problem in 78 minutes, but manual intervention was still required on millions of machines.

• Avoid unmanaged languages when you can. C and C++ give you control but require perfect discipline. A single NULL check would have prevented this incident. Managed languages like Rust, C#, or Java make entire classes of errors impossible. If you must use C++, run static analyzers that catch NULL dereferences. Use address sanitizers in testing. Require multiple reviews for any pointer operations.

• Design for recovery. If your software can brick a system so thoroughly that someone needs physical access to fix it, you’ve created a support nightmare. Build remote recovery mechanisms. Implement version pinning. Create fallback modes that disable problematic components without taking down the entire system.

The reality

CrowdStrike fixed its code, but the architecture that enabled the failure remains. Kernel-mode drivers will continue to cause system-wide crashes. Fast-update mechanisms will continue to bypass safety checks. And somewhere, another NULL pointer is waiting.

This wasn’t incompetence. CrowdStrike employs talented engineers. It was the result of competing pressures: ship fast, maintain security, and work within architectural constraints that make testing hard. Those pressures haven’t changed.

You can’t eliminate all risks. But you can reduce them. Test everything, including config. Deploy gradually. Use languages that prevent common errors. And when you’re writing code that touches millions of systems, remember: the cost of being wrong is measured in billions.

Check the VOID Database of many other incident reports.

Bonus: When Azure’s safety checks failed

A single configuration mistake took down Azure Front Door for over 8 hours and dragged down dozens of Microsoft services with it.

Yesterday, on October 29, 2025, an invalid config change slipped past Azure’s safety checks and corrupted AFD nodes globally. As nodes failed, traffic shifted to healthy ones, but that overloaded them too. The cascade hit everything from Azure Portal to Entra ID to Databricks.

15:45 UTC – Impact begins. AFD nodes start failing.

16:04 UTC – Monitoring alerts fire. Investigation starts.

17:30 UTC – Microsoft blocks all new config changes.

17:40 UTC – Rollback to last known good config begins.

18:45 UTC – Manual node recovery starts. Traffic gradually reroutes.

00:05 UTC – Incident mitigated. 8 hours, 20 minutes total.

We saw that Alaska Airlines and Hawaiian Airlines said they were currently experiencing disruptions to key systems, including our websites, due to Azure. If passengers are unable to check in online, the airlines encourage them to visit an agent at the airport to obtain their boarding pass.

The root cause wasn’t human error. A software defect let the bad config bypass validation entirely. Microsoft caught it within 20 minutes, blocked all new changes, and started rolling back. But recovery took hours because they had to reload configs across thousands of nodes without triggering another overload.

The incident exposed a gap in Azure’s deployment pipeline. Their guardrails were in place, but didn’t fire. Microsoft says they’ve added validation layers and rollback controls, but this is the kind of failure that shouldn’t happen at cloud scale.

Customer config changes are still blocked as of this report. If you’re running production workloads on AFD, that’s worth noting.

Here is the preliminary report, a full one to follow.

More ways I can help you:

• 📚 The Ultimate .NET Bundle 2025 🆕. 500+ pages distilled from 30 real projects show you how to own modern C#, ASP.NET Core, patterns, and the whole .NET ecosystem. You also get 200+ interview Q&As, a C# cheat sheet, and bonus guides on middleware and best practices to improve your career and land new .NET roles. Join 1,000+ engineers.

• 📦 Premium Resume Package 🆕. Built from over 300 interviews, this system enables you to craft a clear, job-ready resume quickly and efficiently. You get ATS-friendly templates (summary, project-based, and more), a cover letter, AI prompts, and bonus guides on writing resumes and prepping LinkedIn. Join 500+ people.

• 📄 Resume Reality Check. Get a CTO-level teardown of your CV and LinkedIn profile. I flag what stands out, fix what drags, and show you how hiring managers judge you in 30 seconds. Join 100+ people.

• 📢 LinkedIn Content Creator Masterclass. I share the system that grew my tech following to over 100,000 in 6 months (now over 255,000), covering audience targeting, algorithm triggers, and a repeatable writing framework. Leave with a 90-day content plan that turns expertise into daily growth. Join 1,000+ creators.

• ✨ Join My Patreon Community and My Shop. Unlock every book, template, and future drop, plus early access, behind-the-scenes notes, and priority requests. Your support enables me to continue writing in-depth articles at no cost. Join 2,000+ insiders.

• 🤝 1:1 Coaching. Book a focused session to crush your biggest engineering or leadership roadblock. I’ll map next steps, share battle-tested playbooks, and hold you accountable. Join 100+ coachees.

Want to advertise in Tech World With Milan? 📰

If your company is interested in reaching founders, executives, and decision-makers, you may want to consider advertising with us.

Love Tech World With Milan Newsletter? Tell your friends and get rewards.

We are now close to 50k subscribers (thank you!). Share it with your friends by using the button below to get benefits (my books and resources).

Share Tech World With Milan Newsletter

Track your referrals here.

Dejan Dunjerski is one of those who built the MDCS into what it is today. He’s a Principal Software Engineer who successfully replatformed Azure SQL Managed Instance without customers noticing, while scaling the service by a factor of 10.

Before that, he created an AI expert system for troubleshooting millions of databases, back when no one in academia had researched the problem.

This interview breaks down how he thinks about problems, makes architectural decisions, and what actually separates senior engineers from principal ones.

In particular, we will talk about:

• Who is Dejan. From building his first program in high school to selling electronic logbooks, the path wasn’t linear.

• What is his career journey. Three pivotal projects at Microsoft: building the first open-source database in Azure SQL, creating an AI troubleshooting system that had not been researched, and replatforming a live service with 10 times the growth.

• What were the biggest challenges in advancing to Principal Engineer. POCs, research in uncharted territory, and managing dependencies that don’t respect your timeline. The technical challenges that force you to negotiate, influence, and solve problems no one else figured out.

• What separates a senior from a principal engineer. Seniors identify problems and propose solutions. Principals implement them and get others to join.

• How to balance technical depth and breadth. Know the details of what you own. Windows codebase analysis, log mining, and dashboard patterns that help you focus. Breadth matters, but depth in your domain prevents surprises.

• How to make proper architectural decisions. Start with the simplest solution, then figure out what needs to change and where. Workarounds compound.

• What early challenges shape system design. Building an OS from scratch at the university, designing for 8 billion users before having any, and implementing open-source databases in Azure SQL. Each one forced a different kind of thinking.

• How Dejan's problem-solving evolved over time. Still chasing simplicity and making changes at the right level. The difference now: planning beyond sprints and avoiding short-term workarounds when dependencies slip. Sometimes, helping the dependency team delivers faster than waiting.

• How does he manage productivity with multiple responsibilities. Don’t procrastinate on 30-second tasks. Block time for deep focus.

• How does he stay current with AI. Understand the essence of new technology, then use it for its intended purpose. LLMs are a library you can query; no need to read every book.

So, let’s dive in.

Zero Trust for AI: Securing MCP Servers eBook (Sponsored)

MCP servers are becoming critical components in AI architectures, but they are creating a fundamental new risk that traditional security controls weren’t designed to address.

Left unsecured, they’re a centralized point of failure for data governance.

This eBook will show you how to secure MCP servers properly, using externalized, fine-grained authorization. Inside the ebook, you will find:

• How MCP servers fit into your broader risk management and compliance framework

• Why MCP servers break the traditional chain of identity in enterprise systems

• How role-based access control fails in dynamic AI environments

• Real incidents from Asana and Supabase that demonstrate these risks

• The externalized authorization architecture (PEP/PDP) that enables Zero Trust for AI systems

Get the practical blueprint to secure MCP servers before they become your biggest liability.

Download free eBook

Sponsor this newsletter

1. Who is Dejan?

Who am I? That is a question I also ask myself from time to time 😀. I was born in Belgrade in 1987 as the third child in my family (I have two older sisters). I had the privilege to learn a lot from my family (sisters, parents, and grandparents).

Being surrounded by engineers and professors, and having my sisters' patience to take their little brother to see the world, was essential to who I am today.

In the meantime, I have completed my studies at Mathematical Grammar School and earned a PhD in the School of Electrical Engineering. Very keen on sailing and skiing, and passionate about photography.

Most recently, I have become a husband and father, so in all the free time I can get, I am trying to pass the family tradition and knowledge to the young ones :)

2. What is your career journey?

I built the first program in the 2nd grade of high school. I have also successfully sold electronic logbooks for airplanes to several companies on a few occasions.

From that day to this, I have been focused on problem-solving and understanding the essence of the problem.

During my tenure at Microsoft, I have consistently been driven by a hunger for knowledge and a desire to accomplish tasks effectively. When you are done with one thing, there will be another from which you can learn even more.

I must admit that I have had a very interesting ride within MSFT so far. From the early days of the Azure SQL team in Serbia, where I had the opportunity to build the proof of concept for the first open-source database in Azure SQL, to creating an AI-powered expert system for troubleshooting millions of databases, I have been involved in significant projects.

Over the last five years, I have been responsible for the entire Azure SQL Managed Instance platform, where we successfully replatformed the compute, networking, and storage layers without customers noticing the change, while achieving a 10x increase in service growth in parallel. Tons and tons of learning.

The role of Principal Engineer is just a title. What is more important is the mindset. Focusing on the problem and its essence, trying to find creative solutions, and having a 'get-the-stuff-done' mentality is what has brought me to where I am now.

3. What were some of the biggest challenges you faced while advancing to a Principal Engineer position?

I had three big challenges:

1. First, I had the opportunity to build the POC in 2015. of the Azure MySQL service on the Azure SQL platform. In two months, I have gained a comprehensive understanding of the entire Azure SQL architecture, from the connectivity, provisioning, and data plane perspectives.

2. Second, building an AI expert system for DB troubleshooting that, at the time, no one in the world (even in academia) had researched. This was challenging from the perspective of what we should do, and the usual approach of building a small POC to achieve value didn’t work well. For this one, we had to conduct extensive research in both related and unrelated fields to make progress.

3. Third, again, the non-technical challenge is running a generally available service, performing a replatforming effort with numerous dependencies, where, for each and every dependency, you cannot rely on the timeline that partner teams provide to you. Here I had to learn how to negotiate, ask for support, go with the flow, etc :)

Whether these three learnings brought me to the Principal level position, I don’t know, but these were the challenges that, if I hadn’t solved, I wouldn’t be where I am today.

4. What’s the most important difference between senior and principal engineers?

It is the scope and the desire to lead and change the stuff. When you encounter a problem, the mindset of a senior engineer is to share the problem and propose a solution, while a person with a principal-level mindset will identify the problem, devise solutions, and attempt to implement one.

As part of this process, the leading aspect is evident in practice when the person asks others to join the party and starts influencing the larger group of people (more than 10) in a formal or informal manner.

Additionally, a Principal Engineer must possess strong communication and presentation skills. Usually, people have full context in their minds; however, very few are good at transferring that context to others.

For success and advancement in a career, understanding the other side and finding ways to explain and present your ideas to others so that they can understand you is essential.

So, for the principal level is important:

1. Focus on the tech and building the right pieces at the right level of the tech stack,

2. Focus on the essence of the problem and not on the form,

3. Don’t give up easily

5. How should Principal Engineers balance technical depth and breadth?

Both breadth and depth are important; it certainly depends on the project you are working on. There is no silver bullet. However, what is very important is that for the area you own or are responsible for, you need to be aware of all those small details. The devil is usually in the details, and those details will bite you, so better for you to know about them proactively.

To illustrate, on one of the projects, before making a decision, I examined the Windows codebase and determined how Windows containers work. This understanding helped me influence my team and other teams.

When I realized that this approach could speed us up and that it worked, I continued using it every time I was unsure about something.

Other useful practices include data science analysis of the logs. Alternatively, when discussing the service, dashboards provide a broad view, helping you focus on and investigate the depth of the most important aspects.

6. How do you make architectural decisions in complex projects?

Simplicity is the king! I start by searching for the simplest possible solution and then examining what we need to change and at what level to achieve it.

That approach helps avoid the usual pitfall where we start from what we have now and how we can slightly modify it, and then, after the third iteration, you end up with a 10 times more complex code/architecture/system that no one knows how to deal with.

Instead, it is better to understand what the problem is, where the best possible place to solve it is, and why it cannot be solved immediately (if it cannot be solved there).

Although it may seem easier and faster to create a workaround, with a bit of extra effort, making a change in the right place or resolving the blocker that prevented you from making a change will definitely pay off.

7. What early-career technical challenge shaped your system-design approach?

There are a few projects that helped me understand the system design and architecture. First of all, at the faculty, we had a class where we had to develop an operating system from scratch, which helped me understand why, on certain occasions, a sandglass spins while you are doing something with your machine.

Then I attempted to build a simple game, imagining that the entire world would play it (8 billion users), and I tried to put the necessary architecture in place.

As I mentioned, I was one of two individuals tasked with implementing an open-source database in the existing Azure SQL architecture, which motivated me to learn the details down to the lowest level.

At a later stage, I read two books on System Design Interview and Designing Data-Intensive Applications, which helped me understand that all the knowledge I had acquired over the years is actually described in those books in a very detailed way.

8. How has your technical problem-solving evolved since your senior engineer days?

Not that much; I used to strive for simplicity and make changes at the right level. One change that is evident is that I now make plans for a longer period, rather than just for a single sprint.

It is quite often that teams and individuals optimize for the short term and 6-month sprints. On one of the projects, since the dependency was not ready at the time, we opted for a short-term implementation that was more complex.

Since the dependency was not delivered on time, we ended up with a more complex solution than we would have had if we had accounted for the delay or just planned a longer delivery.

Hence, I am avoiding workarounds as much as possible and striving to offer help to the dependency teams and the delivery in their code base, if that will expedite the end-to-end story.

9. How do you manage your day-to-day productivity, given multiple responsibilities?

Do not procrastinate! Whatever can be done in under 30 seconds, do it immediately.

Yes, that can bring a lot of distraction, but then you have to dedicate a certain period of time to focusing on just a few very important topics or decisions that you need to make. I have also tended to spend some time working on things that are important but not critical in terms of time.

Also, when motivated, I do not quit that easily, and I am willing to push things through till the very end. When it comes to practices, meditation has helped me achieve superb focus on certain things.

Sailing, another hobby I truly enjoy, helped me build endurance and taught me that in life, sometimes when there are strong winds, it's best to lower your sails and wait for the storm to pass.

10. How do you stay current with rapid technological advancements, such as AI?

Things may be evolving at a rapid pace; however, a basic set of problems that needs a solution remains. I tend to understand the essence of the new technology and how it works in practice. Then I am using these new tools for their intended purpose.

For example, I have been approaching LLMs as one big library that is being read by the models; hence, I do not need to lend the book and read it one by one, but I have a single book that I can ask any type of question I might need.

On a day-to-day basis, I use it for basic tasks and to remind myself of certain topics in a more efficient manner.

11. Do you have any recommended learning resources to share with us?

Here are a few books I can recommend:

• Designing Data-Intensive Applications, Martin Kleppmann (O’Reilly, 2017): patterns for reliability, scalability, and consistency.

• System Design Interview, Alex Xu (ByteByteGo, 2020): concise system patterns and trade-offs for interviews.

• Leadership and Self-Deception. The Arbinger Institute (Berrett-Koehler, 2015)- Mindset shifts for leading engineers.

• The Mom Test, Rob Fitzpatrick (2013): Extracting Honest Signals from Customer Conversations.

• Thinking, Fast and Slow, Daniel Kahneman (FSG, 2011): biases and heuristics that shape decisions.

• Zero to One, Peter Thiel with Blake Masters (Crown Business, 2014): monopoly design and contrarian bets.

• Sapiens, Yuval Noah Harari (Harper, 2015): long-view context for products and behavior.

Milan here again. Thank you, Dejan, for your time and a great overview of the Principal Engineer role at Microsoft.

➡️ Here you can read my full review of the book “Designing Data-Intensive Applications”.

More ways I can help you:

• 📚 The Ultimate .NET Bundle 2025 🆕. 500+ pages distilled from 30 real projects show you how to own modern C#, ASP.NET Core, patterns, and the whole .NET ecosystem. You also get 200+ interview Q&As, a C# cheat sheet, and bonus guides on middleware and best practices to improve your career and land new .NET roles. Join 1,000+ engineers.

• 📦 Premium Resume Package 🆕. Built from over 300 interviews, this system enables you to craft a clear, job-ready resume quickly and efficiently. You get ATS-friendly templates (summary, project-based, and more), a cover letter, AI prompts, and bonus guides on writing resumes and prepping LinkedIn. Join 500+ people.

• 📄 Resume Reality Check. Get a CTO-level teardown of your CV and LinkedIn profile. I flag what stands out, fix what drags, and show you how hiring managers judge you in 30 seconds. Join 100+ people.

• 📢 LinkedIn Content Creator Masterclass. I share the system that grew my tech following to over 100,000 in 6 months (now over 255,000), covering audience targeting, algorithm triggers, and a repeatable writing framework. Leave with a 90-day content plan that turns expertise into daily growth. Join 1,000+ creators.

• ✨ Join My Patreon Community and My Shop. Unlock every book, template, and future drop, plus early access, behind-the-scenes notes, and priority requests. Your support enables me to continue writing in-depth articles at no cost. Join 2,000+ insiders.

• 🤝 1:1 Coaching. Book a focused session to crush your biggest engineering or leadership roadblock. I’ll map next steps, share battle-tested playbooks, and hold you accountable. Join 100+ coachees.

Want to advertise in Tech World With Milan? 📰

If your company is interested in reaching an audience of founders, executives, and decision-makers, you may want to consider advertising with us.

Love Tech World With Milan Newsletter? Tell your friends and get rewards.

We are now close to 50k subscribers (thank you!). Share it with your friends by using the button below to get benefits (my books and resources).

Share Tech World With Milan Newsletter

Track your referrals here.

Trucking Hub tackled the challenge with DocuSense™, our GenAI-driven intelligent document processing platform. In just a few months, we’ve successfully processed over 100,000 documents with unprecedented accuracy and speed, setting a new standard for document automation in logistics.

In this article, we will talk particularly about:

1. The Rate confirmation problem. Manual processing breaks down when freight volumes explode and document formats vary wildly across thousands of brokers.

2. Understanding the workflow. Rate confirmations are sent via email attachments, broker portals, fax-to-email systems, and mobile uploads. Each channel creates unique processing challenges, from multiple attachments to poor image quality.

3. Business and technical hurdles. High manual costs and error-prone data entry drain resources. Technically, we face diverse document formats, including scanned versus digital PDFs, which require different approaches, as well as complex multi-field extraction at scale. Performance demands near real-time processing without sacrificing accuracy.

4. Architecture principles. We built for accuracy, scalability, and flexibility with a modular pipeline. The system adapts to new document types through configuration changes, not code rewrites. Core design separates ingestion, OCR, AI understanding, and post-processing into independent, scalable components.

5. Azure AI implementation. Direct OpenAI SDK integration gives us precise control over model interactions and error handling. We enforce structured JSON responses, externalize prompts for rapid iteration, and track performance metrics across the entire pipeline.

6. Production results. 90% accuracy, 70% faster processing, 2x reduction in manual work. We’ve processed over 100,000 documents, achieving 25-30% cost savings and seamless scaling to new broker formats.

So, let’s dive in.

Control AI agents with conversation modeling, not prompt engineering (Sponsored)

Most developers attempt to control AI agents by crafting more effective prompts. It doesn’t scale. Add more rules, and the model forgets earlier ones. Add complexity, and behavior becomes unpredictable.

Parlant takes a different approach: it defines journeys, guidelines, and tools in natural language and dynamically manages context, ensuring your agent knows exactly which rules apply at each conversation point. Think declarative conversation modeling instead of wrestling with prompts.

Already running in production for financial services and healthcare.

Build your agent now!

Sponsor this newsletter

1. Introduction

A rate confirmation is a formal document outlining the costs associated with transporting goods that is provided by a carrier to a shipper or their broker. The rate confirmation will include information about the particular goods being transported, the shipment’s origin and destination, the shipment’s date range, and the relevant rates.

Because it clarifies the fees that will be incurred for a shipment, a rate confirmation is crucial. The parties involved in the cargo may be able to avoid miscommunications and disagreements thanks to this document.

Rate confirmation processing in trucking has traditionally relied on manual data entry, basic OCR tools, or rigid RPA systems. While these approaches were effective when document volumes were manageable and formats predictable, today’s freight market demands a better solution.

The explosion of digital freight matching, spot market volatility, and the sheer variety of document formats from thousands of brokers and shippers have pushed traditional systems to a breaking point.

Manual processing isn’t just slow, it’s expensive and error-prone. A single misread rate or incorrect pickup time can result in thousands of dollars in detention fees or lost loads. Meanwhile, existing automation tools struggle with the diverse range of formats that trucking companies encounter daily.

DocuSense™ emerged from the need for intelligent, adaptable document processing that could handle the chaos of real-world trucking documentation, which is built natively into Trucking Hub.

2. Rate Confirmation Process

A typical workflow begins when a carrier accepts a load from a broker or shipper. The broker sends a rate confirmation detailing pickup/delivery locations, dates, commodity information, and agreed rates. Carriers must review, acknowledge, and often countersign these documents before dispatching trucks.

The complexity multiplies when carriers handle hundreds of loads daily from dozens of different brokers, each using their own document formats and systems. Some send structured PDFs, others use image-based documents, and many still rely on faxed confirmations that arrive as low-quality scans.

Rate confirmations reach carriers through multiple channels, creating a complex ingestion challenge:

1. Email attachments. The majority arrive as PDF attachments to designated email addresses

2. Broker portals. Direct downloads from TMS (Transportation Management System) integrations

3. Fax-to-email. Legacy systems still send faxed documents converted to email attachments

4. Mobile uploads. Drivers photographing and uploading physical documents from the field

Each channel presents unique challenges. Emails may contain multiple attachments, with only one being the actual rate confirmation. Portal downloads often include supplementary documents, and mobile uploads frequently suffer from poor image quality or orientation issues.

3. Challenges

Implementing an advanced document processing solution for trucking presented both business and technical challenges.

Business challenges

Despite many brokers using digital documents, a substantial portion of rate confirmations were effectively handled in a manual or semi-manual way. This led to several business pain points:

• High manual effort and inefficiency: Human staff had to open emails or portals, download PDF rate confirmations, and transcribe numerous fields into our systems. This manual data extraction was slow and introduced delays in the dispatch and billing process.

• Operational cost: The more time employees spend on low-level data entry, the higher the operational cost. As load volumes grew, scaling the process meant either hiring more staff or risking backlogs – both undesirable outcomes.

• Error-prone process: Manual entry is inevitably prone to errors – a misplaced decimal in a rate or a wrong pickup date can lead to financial discrepancies or service failures.

Overall, the business needed a solution to speed up document handling, lower costs, and improve accuracy – thereby freeing our team to focus on higher-value tasks, such as exception handling and customer service.

Technical challenges

Processing rate confirmation documents at scale comes with significant technical hurdles, too:

• Diverse document formats: We receive rate confirmations from countless brokers and shippers, each using their own template or layout. There is no single standard. Some are one-page documents with a simple table, others are multi-page contracts with terms and conditions. Key information (locations, prices, dates, etc.) can appear in different positions or formats across documents.

• Scanned vs. digital PDFs: Some documents are digitally generated PDFs (which contain text that can be extracted directly), while others are scanned images or fax printouts embedded in PDFs. The latter requires reliable Optical Character Recognition (OCR) to convert images to text. Low-resolution scans, noise, or poor print quality can all hinder text extraction.

• Complex data to extract: Each rate confirmation typically contains 10-15 key fields we need to capture (load number, pickup location, delivery location, pickup date/time, delivery date/time, rate amount, weight, truck type, etc.), sometimes along with a list of line items or stops. Capturing all this accurately is non-trivial, especially when a document spans multiple pages or has extensive fine print.

• Volume and performance: At our peak, we might process dozens of documents per hour. The solution must handle spikes and volume gracefully. We needed to evaluate the trade-off between accuracy and speed in our choice of technologies, so that we could process documents in near real-time without sacrificing quality.

4. Design

We sought a system that could accurately handle a wide range of documents at scale. But also, to adapt quickly to new formats without heavy coding, and fit into our users’ workflow (providing a good experience for any human reviewer).

Principles

So, our design philosophy centers on the following core principles:

• Accuracy. At the heart of DocuSense™ is the goal of high precision in data extraction. We leverage proven OCR technology and advanced GenAI models to ensure that each field (e.g., load number, addresses, rates) is identified correctly from the document.

• Scalability. DocuSense is built to handle large volumes of documents in a pipeline fashion. The architecture enables the horizontal scaling of OCR and LLM processing tasks, allowing us to add more processing workers as the document inflow grows without requiring a redesign of the system. We also utilize asynchronous workflows to manage high-throughput operations.

• Flexibility. A key design aim was to make the platform adaptable to new document types, formats, and use cases with minimal code changes. Instead of hardcoding for “rate confirmations” only, DocuSense was designed in a modular way, with components for ingestion, OCR, parsing, etc., that could be reconfigured or extended.

  For example, we can define new data extraction templates via configuration or prompt changes, rather than writing new code, to onboard a different document type (like bills of lading or invoices).

The product

To meet these principles, at Trucking Hub, we developed DocuSense™ as a modular pipeline for document processing. The figure below shows what the UI of our solution looks like.

The high-level document processing pipeline for DocuSense™, from ingestion to data output, is as follows.

DocuSense™ builds on a generalized document processing pipeline, adapted from successful patterns in financial document processing but optimized for logistics requirements.

Rate Confirmation Workflow with DocuSense™

To better understand how DocuSense™ operates in context, let’s walk through how a rate confirmation document flows through the system, from the perspective of our operations:

The pipeline processes documents through distinct stages:

1. Document Ingestion

The journey begins when a rate confirmation document is received. DocuSense™ can ingest documents from multiple sources. For example, an email listener can detect incoming emails with PDF attachments from brokers, or users can upload PDFs through a web dashboard.

Once received, the document file is stored securely (in an object storage or database), and a processing workflow is triggered.

2. Pre-processing

Before extracting text, DocuSense™ performs various pre-processing steps. If the document is a PDF, we determine whether it contains a text layer; if not (i.e., it’s essentially an image scan), we convert each page into high-resolution images for OCR.

We may perform image cleaning or augmentation to improve OCR results, for instance, by enhancing contrast or resolution if a scan is of low quality, as these enhancements can improve OCR accuracy.

3. OCR (Optical Character Recognition)

In this stage, the goal is to extract all text content from the document. After evaluating multiple options, we integrated a dual OCR approach:

• For digital PDF text extraction, we use UglyToad.PdfPig, an open-source .NET library specialized in reading text from PDFs. PDFPig allows us to extract text along with its position on the page, which can be useful for layout-aware parsing. It has no external dependencies and is optimized for performance, which makes it a great fit for our pipeline. We also experimented with Azure AI Document Intelligence, but it proved to be less flexible for us and had lower performance compared to performing a local OCR.

• For scanned images, faxes, or parts of documents that are images, we use Tesseract OCR via a .NET wrapper. Tesseract is a widely used open-source OCR engine recognized for its high accuracy in recognizing printed text. This combination, PdfPig for native PDF text and Tesseract for images, proved to be the fastest and most reliable solution in our tests. It significantly outperformed trying to use an LLM for raw text extraction, which, as noted, was too slow.

  By leveraging these OCR tools, we get exact text from the documents efficiently, forming the foundation for the next step.

4. AI Understanding (GenAI Model)

Once we have the raw text of the document (often just a blob of text or a list of lines, possibly out of order), the next challenge is to understand it and extract the structured fields we care about. This is where we incorporate GenAI.

We integrated an OpenAI GPT-4 model (via Azure OpenAI Service) into our pipeline. The raw text and layout information from OCR are fed into a carefully crafted prompt that asks the model to identify specific fields. We include sample formatting for the answer (such as JSON or XML) so that the output is structured.

Initially, we experimented with smaller models and even fine-tuned an open-source model for this task.

📈 Model evaluation

Our model selection process evaluated both open-source and commercial options across multiple dimensions:

GPT-4o emerged as our primary model due to its superior accuracy and acceptable speed. However, the real breakthrough came from prompt optimization.

We discovered that including example extractions in our prompts improved accuracy by 15%, while explicit instructions about common trucking terminology reduced errors in specialized fields by 30%.

We iteratively refined the prompt based on the model's outputs. For instance, if we noticed that the model sometimes confused the pickup and delivery addresses, we adjusted the prompt to clarify the expected format or added an example.

5. Post-processing

The raw output from the GenAI model (typically in JSON form with field values) is next fed into a post-processing module. This module applies business rules and sanity checks to further improve accuracy.

6. Integration and output

Finally, the extracted and processed data is delivered to where it’s needed. In our case, that could be an internal TMS, a database, or a system that triggers automated actions.

For example, once a rate confirmation’s details are extracted, we can automatically create a load entry in our TMS with all the pertinent information, send notifications to dispatchers or drivers, and queue the invoice generation.

7. Monitoring and feedback

Taking into account all these steps, we developed monitoring for key metrics, including processing time per document, extraction confidence scores, accuracy on test sets, and throughput. We also log model outputs and any manual corrections made by humans.

These logs form a feedback loop. By analyzing where the model made mistakes or needed assistance, we can determine whether to refine our prompts, add a new rule, or, in some cases, provide an example to the model for future reference.

This feedback loop has driven steady improvements in accuracy, from 82% at launch to 96% after three months. More importantly, we’ve reduced catastrophic failures (completely misread documents) from 5% to under 0.1%, building user trust in the system.

5. Implementation

The implementation leverages Azure AI Foundry and Azure OpenAI services to deliver enterprise-grade document processing. Rather than using higher-level abstractions, DocuSense™ integrates directly with the OpenAI .NET SDK for maximum control over model interactions, response handling, and error recovery.

Azure AI Foundry provides the foundational platform for model hosting, while Azure OpenAI Service delivers enterprise-grade access to GPT-4 with built-in compliance and data residency guarantees.

Direct OpenAI SDK Integration

DocuSense™ integrates directly with the OpenAI .NET SDK, rather than using higher-level abstractions, providing precise control over model interactions and response handling, which is essential for production reliability.

And the service registration looks like this:

This direct integration enables fine-tuned control over model parameters, structured response formatting, and comprehensive error handling that higher-level abstractions might obscure.

Structured response enforcement

The foundation of reliable AI extraction rests on eliminating response parsing ambiguity. DocuSense™ enforces JSON responses at the API level using OpenAI’s structured output feature.

An AI extraction operation is structured and deterministic. Each extraction request consists of:

• Messages: A conversation context with system instructions and user content

• Options: Model parameters that control response behavior and format

• Response processing: Structured parsing with error handling and token tracking

The SystemChatMessage contains the prompt template with few-shot examples and field definitions, while UserChatMessage contains only the raw document text. This separation enables prompt optimization without affecting the document processing pipeline.

Our model also includes a confidence score, which enables intelligent downstream processing:

• High confidence (90-100%): Auto-approve and process

• Medium confidence (70-89%): Flag for human review

• Low confidence (<70%): Requires manual intervention

External Prompt management

Prompt engineering drives extraction accuracy, but hard-coded prompts prevent rapid iteration. DocuSense™ externalizes prompt templates for hot-swapping without deployments.

This pattern reduced optimization cycles from days to minutes. When accuracy dropped for a new broker’s document format, we updated the prompt template with additional examples and saw improvements within hours, not release cycles.

The prompt includes few-shot examples, explicit field definitions, and trucking-specific terminology guidance. This engineering approach achieved 96% accuracy without requiring model fine-tuning, thereby maintaining flexibility across various document types while keeping costs under control.

Monitoring and error handling

Production AI systems require specialized error handling that accounts for unique failure modes, including token limits, rate limiting, model unavailability, and response parsing errors.

And also, we track performances in this way:

These metrics reveal that AI transformation typically takes 10-20x longer than text extraction, and that faster AI models may cost more or be less accurate

Lessons learned

Here are some important lessons learned from our work on the DocuSense™ solution:

1. Separate concerns. The two-stage pipeline (text extraction → AI transformation) allows independent optimization and testing of each stage.

2. Measure everything. Without metrics, you’re flying blind. Track not just success/failure, but processing times, token usage, and confidence scores.

3. Design for failure. AI services will fail. Network calls will timeout. Design your system to handle these gracefully with circuit breakers, retries, and fallbacks.

4. Abstract AI providers. An AI provider interface allows swapping between OpenAI, Azure, Google, or custom models without changing business logic.

5. Cache intelligently. AI calls are expensive. Cache responses for identical or similar documents, but be smart about cache invalidation.

6. Version prompts. Treat prompts as code. Version them, test them, and roll them back if needed.

7. Monitor costs continuously. AI token usage can spiral quickly. Implement cost tracking and alerts before going to production.

8. Build feedback loops. Track confidence scores and allow users to correct extractions. Use this data to improve your prompts or fine-tune models.

6. Results

After processing over 100,000 documents in production, DocuSense™ has delivered transformative results. Here are the most important ones:

• Major reduction in manual work. We’ve seen a roughly 2-fold reduction in manual document processing needs for rate confirmations. Tasks that used to require two full-time staff can now be handled by one (who mainly just reviews flagged items). Many documents go through completely automatically.

• Faster turnaround times. The average handling time for a rate confirmation (from reception to being ready in the system) has dropped by about 70%. What might have taken, say, 10-15 minutes or more between reading, interpreting, and typing into systems now takes just a couple of minutes or less with automation.

• High accuracy and reduced errors. Our automated extraction achieves an overall accuracy of around 90% in a fully automated process. Moreover, ~one-third of documents are processed with near-perfect accuracy (~99% field accuracy), requiring no corrections. For the remaining errors, they are usually minor (such as a formatting detail) and are caught in the review stage. Compared to previous manual error rates, this represents a significant improvement in data quality.

• Cost savings. By automating previously manual tasks, we are achieving notable cost savings. We estimate a 25-30% reduction in processing costs for these documents compared to the manual approach alone.

• Improved user experience. For our internal users (dispatchers and billing clerks), DocuSense™ has made their lives easier. Instead of juggling between an email, a PDF viewer, and a TMS screen to enter data, they either get the data automatically or have a single interface to verify it. The intuitive UI, featuring side-by-side comparison and alerts, significantly accelerates the verification process.

• Scalability. Over the months, DocuSense™ has seamlessly scaled to process over 100,000 documents and counting. When a new broker or document format is introduced, we haven’t had to write custom code; at most, we adjust the prompt or add a post-processing tweak. This agility validates our design goal of a flexible platform.

Overall, DocuSense™ has transformed the rate confirmation process from a manual bottleneck into a streamlined, largely automated pipeline. The combined power of OCR and GenAI has delivered both speed and accuracy, and the numbers reflect that success.

7. Conclusion

The development and deployment of Trucking Hub DocuSense™, our GenAI-powered document processing platform, have revolutionized how we handle critical operational documents in the trucking industry. By overcoming the challenges of manual data entry and rigid automation, we’ve achieved significant gains in efficiency, accuracy, and scalability.

This project illustrates a broader point: the combination of natural language understanding with domain-specific processing can automate complex tasks that were previously only solvable through human intuition. DocuSense™ doesn’t just read text; it interprets documents much like a human would, but at superhuman speed and consistency.

And by smartly integrating human-in-the-loop checks, we ensure that the system remains reliable and accountable, meeting the high accuracy our business requires.

The success of DocuSense™ has set a new benchmark internally, prompting us to explore other areas where AI can bring similar leaps in productivity. From invoices to bills of lading, the possibilities are vast.

More ways I can help you:

• 📚 The Ultimate .NET Bundle 2025 🆕. 500+ pages distilled from 30 real projects show you how to own modern C#, ASP.NET Core, patterns, and the whole .NET ecosystem. You also get 200+ interview Q&As, a C# cheat sheet, and bonus guides on middleware and best practices to improve your career and land new .NET roles. Join 1,000+ engineers.

• 📦 Premium Resume Package 🆕. Built from over 300 interviews, this system enables you to craft a clear, job-ready resume quickly and efficiently. You get ATS-friendly templates (summary, project-based, and more), a cover letter, AI prompts, and bonus guides on writing resumes and prepping LinkedIn. Join 500+ people.

• 📄 Resume Reality Check. Get a CTO-level teardown of your CV and LinkedIn profile. I flag what stands out, fix what drags, and show you how hiring managers judge you in 30 seconds. Join 100+ people.

• 📢 LinkedIn Content Creator Masterclass. I share the system that grew my tech following to over 100,000 in 6 months (now over 255,000), covering audience targeting, algorithm triggers, and a repeatable writing framework. Leave with a 90-day content plan that turns expertise into daily growth. Join 1,000+ creators.

• ✨ Join My Patreon Community and My Shop. Unlock every book, template, and future drop, plus early access, behind-the-scenes notes, and priority requests. Your support enables me to continue writing in-depth articles at no cost. Join 2,000+ insiders.

• 🤝 1:1 Coaching. Book a focused session to crush your biggest engineering or leadership roadblock. I’ll map next steps, share battle-tested playbooks, and hold you accountable. Join 100+ coachees.

Want to advertise in Tech World With Milan? 📰

If your company is interested in reaching an audience of founders, executives, and decision-makers, you may want to consider advertising with us.

Love Tech World With Milan Newsletter? Tell your friends and get rewards.

We are now close to 50k subscribers (thank you!). Share it with your friends by using the button below to get benefits (my books and resources).

Share Tech World With Milan Newsletter

Track your referrals here.