Coding agents changed the equation. Not because they replaced the thinking, but because they introduced idle time in the middle of it. When you ask Claude Code to implement a feature, you don’t sit there watching it write files and run tests. You could, but it would be a waste. The agent might run autonomously for hours, and during that window you have a choice: do something else with your hands, or do something else with another agent.

Ethan Swan recently argued that context switching between multiple AI sessions is becoming a core engineering skill, that it’s “about to become table stakes.” Addy Osmani takes a more cautious view, sticking to one coding agent at a time and treating the AI as a pair programmer that needs constant direction. I’ve landed somewhere between the two. Running agents in parallel is genuinely productive, but there’s a ceiling, and it’s lower than I’d expect.

How I work with agents

I typically run at most two main agents in parallel. Main meaning agents working on substantial features, not quick chores. Each gets its own git worktree so they don’t step on each other’s files, and I keep the primary repository checkout free for my own manual work. I wrote a small git-worktree-init script that scaffolds two worktrees ({repo}-1 and {repo}-2) inside a .worktrees/ directory at the repo root, each on its own branch. A global .gitignore keeps those directories out of version control.

In my iTerm2 setup, the first two tabs are Claude Code sessions and the rest are mine. To keep track of what each agent is doing at a glance, I use Claude Code hooks to color each tab based on the agent’s state. Adding even one more agent beyond two noticeably increases the cognitive load for me. Not linearly, but in a way that feels closer to what managers describe when they talk about the cost of each additional direct report.

Delegating the main development work to agents doesn’t mean I stop writing code. I still enjoy it, and there are things I want to learn by doing rather than delegating. What changes is that I get to choose. I can pick up a small technical task on the side, design future systems, review more PRs, or I can step back entirely and spend that time on things that usually get squeezed out: reading technical material, studying a new tool, thinking about architecture. The agents handle the bulk of the implementation and I get space for the higher level work.

The key to making this work for me, and to not spending the whole day babysitting, is front-loading the planning. I use Claude Code’s Plan Mode extensively before letting an agent start writing code. My Claude Code settings default to plan mode so every session starts with planning, not coding. A good plan means I can trust the agent to run autonomously for a long stretch, which is what buys me time to focus on other things. I also ask agents to split their work into minimal, individually deployable commits, each one safe to ship on its own. This aligns well with how we work at Mergify, where every commit is pushed as its own PR using mergify stack and deployed independently.

Planning often starts before I even open Claude Code. I use Linear for issue tracking, and with the Linear MCP server connected, I can tell an agent “write a plan to tackle MRGFY-1234” and it pulls in the issue context, understands the scope, and proposes an implementation strategy. Linear also supports delegating issues directly to coding agents, which closes the loop even further.

On our codebase, we’ve invested in making the agent as autonomous as possible. We documented conventions, testing commands, and dangerous patterns to avoid. We’ve also written custom skills that the agent can invoke to run database migrations safely, query production data, migrating between test frameworks, etc. The Claude Code permissions are tuned to pre-approve safe operations (git add, git commit, grep, mergify, etc.) while still requiring confirmation for git push. The result is that the agent can write code, run tests, generate SQL migrations, compare SQL optimisations, build OpenAPI schemas, and push a stack of commits, all without asking me anything.

What changes downstream

Once the agent finishes, it pushes its work and I get a set of PRs to review. I review them on GitHub alongside my colleagues, and alongside other automated reviewers like GitHub Copilot code review. When reviewers leave comments, I can point Claude Code at the PR and ask it to address all open threads. We wrote a small internal skill to streamline that step.

This workflow produces more PRs than a traditional one, which has shifted where the bottleneck sits. Review throughput has become a real constraint. We’re still figuring out the right approach. One thing we’ve tried at Mergify is a “low-impact” label that reviewers can apply to acknowledge that a PR is safe enough to merge with a single approval rather than the usual two. It’s a small process change, but it reflects a broader tension: agent-assisted development generates more incremental, well-scoped changes, and the review process hasn’t fully adapted to that cadence yet. We’ll keep iterating on this.

To stay on top of the review load, I asked Claude Code to build two GitHub CLI extensions: gh-reviews, which lists open PRs requesting my review directly in the terminal, and gh-reviews-dashboard, which generates an HTML dashboard with CI status, reviewer avatars, and keyboard navigation.

I don’t think this way of working is for everyone, or for every task, and it’ll probably still change a lot in the future. Some problems still reward, maybe even require, sustained single-threaded focus. But for the kind of feature work and maintenance that makes up the bulk of a product engineer’s week, learning to manage agents in parallel has been a meaningful shift for me. The skill isn’t prompting anymore. It’s more orchestrating.

Before joining Mergify, I spent a few years working primarily in Go. Backend services, APIs, systems where performance and correctness mattered. At Mergify, Python was the language in production.

This post is a reflection on developer experience after six months of real-world Python usage, seen through the lens of someone shaped by Go. I’m focusing on web apps, tooling, testing, and shipping code.

Shipping Speed: Python Is Relentlessly Fast

The first thing that surprised me was how fast you can build things in Python.

Spinning up an API, wiring a service, gluing components together: it all feels immediate. There’s very little friction between “I have an idea” and “it’s running locally.” In Go, I spent more time upfront designing types, interfaces, and data flows before seeing anything work.

Python flips that order. You build first, shape later.

This makes experimentation cheap. You try things you might not bother with in a more rigid environment. But it also sets the tone for everything that follows: Python optimizes for velocity, not enforcement.

Go optimizes for correctness from the start. You pay the cost early, but you rarely wonder later what a piece of code is supposed to do.

Typing: Go Still Lives in My Head

If there’s one thing Go permanently changed in how I write code, it’s typing. Not typing as a safety net, but typing as a design tool.

Writing Go for years trained me to think carefully about what objects exist in the system, how they’re named, what data flows between layers, and where responsibilities start and stop. That mindset carried over directly to Python.

Python’s typing is optional, porous, and negotiable. Even with strict settings and an army of linters, you can always fall back to typing.Any. In practice, you sometimes do, especially at boundaries:

import typing

def make_sql_statement() -> sqlalchemy.Select[tuple[typing.Any, ...]]:
    ...

This starts as a pragmatic choice and slowly spreads. Dictionaries become the norm. Shapes are implicit. The compiler stops being a design partner and becomes a suggestion engine.

The most painful part is external libraries. Many popular Python libraries are poorly typed, or not typed at all. Combined with sparse documentation, this often leads to reverse-engineering: reading source code, stepping through functions, or adding print statements just to understand what’s going on.

In Go, you fight the compiler. In Python, you sometimes fight reality.

Python doesn’t prevent bad modeling. It just makes it easier to postpone it.

If you bring Go’s discipline with you, Python’s flexibility is powerful. If you don’t, things get fuzzy fast.

Writing Code: Faster in Python, Easier in Go

One sentence kept coming back to me over these six months:

It’s faster to write Python, but it’s easier to write Go.

Python has more concepts, more magic, more ways to express the same idea. Decorators, context managers, dynamic attributes, metaclasses, magic methods. There’s a lot going on.

Go keeps the surface area intentionally small. Fewer concepts, fewer surprises, fewer ways to do the same thing.

This shows up when mapping data between layers. In Go, if you want clean separation between an API layer and a domain layer, you write explicit mapping code:

func NewUser(model UserModel) User {
    return User{
        ID:    model.ID,
        Name:  model.Name,
        Email: model.Email,
    }
}

It’s verbose. It feels like boilerplate. You even end up writing a bunch of tests just to make sure all your fields are properly passed from one type to another. But it’s explicit and quite easy to reason about.

In Python, the same thing might look like:

@dataclasses.dataclass
class User:
    id: str
    name: str
    email: str

user = User(**model)

That conciseness is fantastic. But it hides assumptions. If the shape changes, you’ll find out later. Often in tests, sometimes in production.

Python feels liberating; Go feels grounding.

Tooling Philosophy: Centralized vs Community-Driven

One of the bigger cultural shifts for me was tooling.

Go’s tooling philosophy is clear: most things come with the language. You install Go, install the official IDE extension, and you’re productive. Formatting, testing, linting all work out of the box.

Python’s tooling is community-driven. That’s both its strength and its weakness.

On one hand, you get incredible innovation: FastAPI, pytest, uv, poetry, mypy, ruff. On the other hand, you spend real time understanding the stack. FastAPI is built on Starlette, which relies on… wait, where does this error come from?

There’s also no single standard. It’s easy for your IDE setup to drift from your CI setup. If you’re using pytest with uv, poe, multiple linters, and custom scripts, you have to work to ensure your local feedback matches reality.

In Go, IDE ≈ CI by default. In Python, this gap is shrinking, but it’s still noticeable.

Testing: Weird at First, Then Powerful

Testing is where Python won me over.

At first, it felt uncomfortable. You don’t get all the same IDE features you’re used to in Go. Fewer guarantees, fewer compile-time signals. But once properly configured, pytest is powerful.

I spent several months working on a pytest plugin, which forced me to dig into its internals. The framework follows a Unix-like philosophy: small hooks, clear inputs and outputs, composability everywhere.

That’s why the ecosystem is so strong. You get plugins for parallel execution, coverage, test splitting, selective execution, and flaky test handling.

The one thing I still miss is Go’s table-driven tests:

tests := map[string]struct{
    input, want string
}{
    "test case 1": {input: "foo", want: "bar"},
    "test case 2": {input: "baz", want: "qux"},
}
for name, tt := range tests {
    t.Run(name, func(t *testing.T) {
        ...
    })
}

I know a lot of people don’t like this method. But I think it forces you to think about (1.) dependencies, (2.) inputs, and (3.) outputs. They’re explicit, readable, and fully typed. Pytest’s parametrization is powerful, but you lose typing quickly with layered fixtures and indirect dependencies.

Still, for large test suites, Python’s testing ecosystem is world-class.

Concurrency: I Don’t Miss Goroutines As Much As I Thought

I expected to miss goroutines more than I do.

Coming from Go, goroutines feel like a requirement for any modern language. Lightweight concurrency, simple syntax, powerful primitives.

In practice, with a proper queue system and worker model, things work fine. Workers are easier to debug, easier to observe, probably more robust, and easier to reason about than implicit concurrency everywhere. Less magic, more explicit flow.

Deployment: Go Still Wins

Deployment is the one area where Python can’t compete.

A Go service compiled into a single static binary, shipped with a multi-stage Dockerfile ending in FROM scratch, is hard to beat. Python images are heavier. They’re acceptable for web apps, but never elegant.

What Changed How I Code

Python didn’t replace Go in my head. I think Go made me a better Python engineer. It taught me to care about boundaries, naming, and data flow, even when the language doesn’t force me to.

Python rewards speed. Go enforces a kind of discipline.

One thing I didn’t cover here is Python’s reach beyond web apps. LLMs, data science, R&D: Python is everywhere. That adoption brings a massive community, and that community is genuinely helpful. Go’s community is great too, but Python’s sheer size means more libraries, more answers, and more people who’ve hit the same problems you have.

After six months, I’m convinced the best results come from combining both: moving fast, but acting as if the compiler were watching, even when it isn’t.

Should I go for a run, a hike, climbing? Should I continue this task, start this project, take a break?

I have to keep in mind that simply having these options is a form of wealth. Being able to overthink these decisions is an incredibly precious thing.

So, yes, decision fatigue is real, and we shouldn’t ignore it. We should probably even try to reduce the number of decisions we have to make to the bare minimum to be able to stay focused on what matters.

But don’t get me wrong, having no options is also very real, and certainly a bigger problem.

Sometimes, remembering that outside my head there is a concrete world waiting for me to take opportunities without thinking too much is actually pretty nice.

I thought a lot about this after watching this video by Josh Romero.

I know a blog isn’t exactly an innovative project. It might even sound boring in the age of AI-generated everything. But I like it. Blogging feels personal. Which by the way is kind of strange, right? Writing personal things online? It’s maybe a bit of nostalgia.

This idea has been sitting in my head for a while, but it never felt like the right thing to do. Probably because, every time I thought about it, I went straight into developer mode:

Which tools should I use? What stack? What about the design, the hosting, the automation?

Basically, everything except the fact that I just wanted to write.

So, a few weeks ago, I decided to build something very minimal. A simple website, made with very boring tech. No fancy frameworks, no endless dependencies.

I knew I wanted to keep control of the underlying code (which is available here) so I didn’t want to use platforms like Medium or Substack for now. Plus, I have no business goals here. I just want a space to share thoughts, even if they don’t make sense to anyone but me.

I already had a small website hosted on GitHub Pages, so I started digging around and noticed they natively support Jekyll as a static site generator. I opened the Jekyll documentation. It’s short, well-written, and straight to the point. It just felt right even if it’s Ruby (I know, I know). It lets me keep control without needing an army of frameworks and build tools, but it still provides enough structure to write without touching raw HTML all the time.

The project was up and running in… what, maybe four hours? All these years of hesitation, and that was it.

First, I installed Jekyll locally. Just make sure to install the latest version of Ruby, not the one bundled with MacOS.

Then, the only slightly tricky part was integrating Tailwind CSS. To do that, I installed and configured a PostCSS gem called jekyll-postcss-v2. The configuration is straightforward:

// postcss.config.js
module.exports = {
  plugins: {
    "@tailwindcss/postcss": {},
  },
};

I also needed to add this plugin to my Jekyll configuration file:

# _config.yml
plugins:
  - jekyll-postcss

postcss:
  cache: false # Use Tailwind CSS JIT engine instead.

The next step was to install Tailwind CSS and create its configuration file:

// tailwind.config.js
module.exports = {
  content: ["./**/*.html"],
  plugins: [],
  theme: {},
};

I can now import the library in my main CSS file with:

@import "tailwindcss";

h1 {
  /* Utility classes and the @apply keywords are available. */
  @apply text-xl;
}

The last step was to automate everything with GitHub Actions. I used the official template and just added the steps required to install pnpm dependencies:

jobs:
  build:
    steps:
      # ...

      # https://github.com/marketplace/actions/setup-pnpm#use-cache-to-reduce-installation-time
      - uses: pnpm/action-setup@v4
        name: Install pnpm
        with:
          run_install: false

      - name: Install Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: "pnpm"

      - name: Install dependencies
        run: pnpm install

      - name: Build with Jekyll
        # Outputs to the './_site' directory by default.
        run: bundle exec jekyll build --baseurl "$"
        env:
          JEKYLL_ENV: production

      - name: Upload artifact
        # Automatically uploads an artifact from the './_site' directory by default.
        uses: actions/upload-pages-artifact@v3

And voilà! The website now looks more like a web reader and I like that. It’s simple, quiet, and kind of mine. This article is written on something really not that cool. But hey, who knows? Maybe I’ll write something nice someday!

Other times, I need to experiment first. I try things, adjust the design, maybe even build the feature completely before worrying about tests. And that’s when writing them suddenly feels like climbing uphill. My brain is still in “feature mode”, focused on what the code does, not how it behaves under different inputs.

When I write tests after building something, I have to rewind my own mental model — break down what I just finished, recall the critical paths, and figure out where to poke it. It’s doable, but it always takes me a few deep breaths to switch gears.

A Small Trick That Helps Me Pause

Lately, I’ve been using a really simple method that helps me make that mental switch. Whenever I’m about to write tests I start by writing down three things:

1. Dependencies
2. Inputs
3. Outputs

That’s it. Just three bullet points, often scribbled in a comment.

It sounds almost too basic, and it is, but writing these down forces me to re-clarify what matters. It’s not about writing formal specs, but about thinking long enough to see the shape of what I’m testing again.

An Example

Here’s how it looks in practice. I’ve been working on a pytest plugin that automatically detects new tests. To test that behavior, I first write out:

1. Dependencies
    - `pytester`, to execute the plugin and simulate test runs
    - A web server, since the plugin needs to call an API to check which tests are new

2. Inputs
    - The list of existing tests (what the system already knows)
    - The test suite to run (what’s new in this run)

3. Outputs
    - The list of newly detected tests

From that tiny list, I can immediately see the shape of a minimal test case:

# 1. Dependencies
pytester = ...
server = ...

# 2. Inputs
existing_tests = ["test_login", "test_signup"]
suite = ["test_login", "test_signup", "test_logout"]

# 3. Outputs
expected_new_tests = ["test_logout"]

Writing this down usually takes less than a minute. But it clears my head because I stop thinking about the whole plugin and just focus on one behavior at a time. Without it, I tend to copy-paste old tests and tweak them until they work, which feels more like guesswork than testing.

I’ll often feed this list into an LLM to generate test cases (it tends to write edge cases I wouldn’t have thought of). With that additional context, the AI doesn’t have to guess what the code does and can focus instead on what I want to verify. That’s especially helpful for code like this, where the logic lives inside a broader framework (pytest, in this case).

Why It Works for Me

This isn’t a grand testing philosophy. It’s more of a small mental reset or a way to think, slow down, and get back into “testing mode” after building something. The list reminds me that every test is just a combination of what I depend on, what I change, and what I expect.

It’s simple, maybe too simple, but it keeps me from getting stuck staring at an empty test file. And that’s good enough for me.

Automatic suggestions often feel like a coworker who talks too much. Suddenly you’re juggling a stream of half-relevant context that you didn’t ask for. Sometimes useful, sure, but also distracting.

So I turned it off.

Writing Without Interruptions

With inline suggestions disabled, coding feels more intentional. I get the old craftsmanship vibe: I type what I mean, not what the AI nudges me toward. At first, that felt liberating.

But the honeymoon ends quickly. You start to realize how much friction comes from repetitive tasks. Without Copilot filling in obvious loops or boilerplate, you feel slower, even a bit reduced. Efficiency takes a hit.

Using Copilot as a Copilot

That’s when I shifted how I think about AI. Instead of treating Copilot like a partner constantly typing on my keyboard, I use it like an actual copilot: someone I ask for help when I want it.

I’ve noticed a pattern. Each coding problem has thousands of possible solutions. The mistake I used to make was assuming Copilot would “skip” the design phase for me. It doesn’t. If I start coding too soon, it happily glues together snippets and good ideas around a bad structure. The result looks smart but feels wrong.

By writing first and asking questions later, I use AI more to challenge my ideas before I commit to code. I started adding this kind of line to my prompts:

Tell me if you need more information. Ask me questions.

The good thing is that, depending on the model you choose, it will not blindly try to ask questions. For example, I used this method to find a way to fix an issue in a pytest plugin. I added a bit of context, the stacktrace, and ended the prompt with:

Can you find how to fix this issue? I also want to cover this case in the tests of the plugin. How can I do that? Tell me if you need more information.

In that specific case, the plan was clear and Copilot never asked for more information.

That small tweak changed the interaction completely. Instead of being flooded with code, I get alternatives, nudges, and clarifications. It feels like talking to a colleague instead of handing them my keyboard.

Where It Still Shines

Even with inline suggestions off, I use Copilot heavily as an agent for:

• Repetitive, well-defined tasks — where I don’t need creativity, just output.
• Tests and test cases — Copilot is great at proposing edge cases I didn’t think of.

In these scenarios, I treat Copilot like a junior engineer: it does the grunt work, I review.

My Takeaway

I’m biased: I actually enjoy writing code. I like the structure, the choices, even the aesthetics. I want my code to carry my “fingerprint”. Copilot doesn’t take that away, but inline suggestions blur it too much for me.

That said, I’m not dogmatic. Sometimes I’ll flip suggestions back on, or I’ll experiment with a bigger delay before they pop up. The point is to keep control of the workflow — not let an algorithm steer my design.

For me, AI is best when it’s a partner that asks good questions and proposes alternatives. It should help me think better, not just type faster.