DEV Community: Charalambos Emmanouilidis

When Agile Is Not Enough: Developing Software at Agent Speed

Charalambos Emmanouilidis — Mon, 07 Sep 2026 10:41:29 +0000

Agentic Development, Part 1

How do you develop software when agents write the code? Not someday. Now.

Within a few weeks, my solo open-source project had more than 100 open issues. At the same time, an AI agent team was producing pull requests faster than I could properly review them.

I had automated implementation, but not delivery. I had increased the capacity of the wrong part of the system.

That was when I realized that agentic development is not simply faster Agile. It changes the bottleneck on which the whole development process has to be built.

Agile solved a different problem

Waterfall-shaped development made change slow and expensive. Releases were planned months ahead. Features felt carved in stone, and feedback or bug-fix loops often came late in the release.

Scrum, Kanban, and the broader Agile movement addressed exactly those pain points. They shortened planning horizons, reduced batch sizes, and made it possible to react while development was still in progress. That was a necessary step, and software development is better for it.

But these methods still grew around human teams working at human speed.

Coding is not the whole of software development, but implementation used to consume a large part of its time and capacity. A team could only implement so much during a sprint. Planning, implementation, review, and acceptance operated at roughly compatible speeds.

Agents break that capacity model.

A human can now send several agents into the same codebase, or orchestrate a specialized team that plans, implements, tests, reviews, and reworks an issue. Execution can happen in parallel and continue as long as work is available.

Work that previously filled a sprint can now be completed in hours. A sprint backlog can become outdated while a human is still reviewing the first results. The cadence no longer controls execution. Completed work arrives as a continuous stream.

Human attention does not scale with it.

The result is not just a shorter sprint. It is a different production system. Implementation becomes cheap and elastic, while intent, judgment, review, and responsibility remain scarce.

Scrum does not scale to that situation. It was not designed for it.

The system I built

To be clear, most of my experience so far has been solo plus AI, not a larger engineering team. It is not representative of every organization. It is, however, a real system I use to develop real software.

I built a tool for orchestrating AI agents around a workflow like this:

Human commits an issue → agent team implements it, opens a pull request, reviews and reworks the result → human approves the merge

The individual steps run through different agents, LLMs, and models. Each role has specialized rules and prompts for its domain.

The setup worked. Then the speed blew up in my face.

More output did not mean more delivery

Features and issues were implemented so quickly that I could no longer keep up with reviewing the code and pull requests properly.

Adding another agent did not solve this. It made the queue larger.

The human became the bottleneck.

More agent throughput did not produce more delivery. It produced more inventory waiting for human judgment.

The same thing happened before implementation even started.

I used an LLM-agent to discuss ideas, plan features, break work down, and identify follow-up tasks. While the agent team was implementing one issue, it could discover several more and file them immediately. Creating an issue was cheap, so almost every reasonable observation became one.

After a few weeks, the project had more than 100 open issues.

Each issue looked useful on its own. Together, they were no longer a plan I could oversee. The backlog had become exhaust from planning and implementation.

An issue may be cheap to create, but it is not free to own. Someone still has to understand it, compare it with everything else, decide whether it matters, keep its context current, and eventually accept or reject the result.

Agents had made both sides of the problem faster: producing software and producing demand for more software. The human capacity between them had not changed.

Why shorter cycles are not the answer

Scrum can reduce the amount committed to a sprint. Kanban can limit work in progress. Both are useful ideas, and I still use parts of them.

But limiting a column on a board does not answer the new questions:

May an agent turn a discovery into committed work?
What must be known before an agent is allowed to start?
How do we prevent an agent from expanding the scope while it works?
What evidence must it produce before a human review begins?
How much autonomy can it have without also giving it authority?
Which capacity controls the flow: agent execution or human validation?

In a human team, many of these answers are implicit. Developers carry context between conversations. They recognize uncertainty, ask questions, and remain accountable for their decisions.

An agent can turn an unclear request into convincing code without ever resolving the ambiguity behind it.

The danger is not that an agent cannot finish a vague issue. The danger is that it can.

If we change the roles, capacity model, commitment rules, handoffs, and acceptance process to handle that, we are no longer just making Scrum faster. We are building a different operating model.

A working method for agentic development

I started with one simple correction: remembering work and committing to work must be separate actions.

From there, the following rules emerged.

1. Anyone may capture. Only a human may commit.

An idea, defect, risk, or improvement may be captured at any time. It does not matter whether a human or an agent found it.

A capture records:

what was observed,
where it was found,
why it might matter,
and enough context to evaluate it later.

It is not yet an implementation issue. It has no milestone, estimate, or detailed specification. It may later be merged with another capture, rewritten, discarded, or simply expire.

This matters because an agent must be allowed to notice things without gaining the authority to expand the product.

Commitment is different. A human explicitly pulls a capture into committed work. By doing that, the human is not only asking an agent to implement something. The human is allocating the attention required to specify, review, and accept it.

Agents may propose work. They may not commit it themselves.

2. Committed work needs an executable specification.

Once work is committed, it needs enough information for an agent to finish it and for a human to review the result against it.

The specification should contain at least:

the intended outcome and why it matters,
the relevant context,
scope and explicit non-goals,
technical and product constraints,
acceptance criteria,
the required tests or other evidence,
and any known risks.

An LLM can help create that specification. It can ask questions, find missing cases, and propose acceptance criteria. The human still decides when the specification reflects the intended work.

“Improve error handling” is not executable. It does not say which failure, which behavior should change, or how anyone can prove that the issue is complete.

Agents are fast enough that unresolved ambiguity becomes code almost immediately. Preparation therefore matters more, not less.

3. Execution is limited by validation capacity.

The important question is no longer how many issues the agents can execute in parallel. The question is how many completed changes a human can understand and evaluate without losing control of the system.

I therefore limit committed work according to downstream review capacity. An agent should not start another issue merely because an execution slot is available. It should start when there is also a realistic path through review and acceptance.

This can leave agents idle while technically more work could be produced. That is intentional.

An idle agent is cheaper than a pull request that nobody can properly review.

4. Discoveries do not expand active scope.

Agents regularly find adjacent problems while working: missing validation, a weak abstraction, outdated documentation, another feature that would fit well.

These discoveries return to capture. They do not automatically become issues, and they do not extend the current task unless they block its acceptance criteria or require an explicit human decision.

This keeps one useful implementation from turning into five unplanned ones.

5. The result must arrive with evidence.

A pull request is not ready for human review just because the code compiles and another agent has approved it.

The handoff should explain:

what changed and why,
how the result satisfies each acceptance criterion,
which tests and checks were run,
which relevant decisions the agents made,
what risks or uncertainties remain,
and where human judgment is specifically required.

Agent reviews are useful quality gates. They can find mistakes, compare the implementation with repository rules, and request rework before a human sees the result. But an agent reviewing another agent does not create human accountability.

At least in my current workflow, final merge authority remains with the human.

The goal is not to keep up with the agents

My first instinct was to make reviewing faster so I could keep the agents busy. That was the wrong goal.

The method has to prevent the system from producing more committed change than the responsible humans can absorb. Otherwise, the queue grows, context is lost, reviews become superficial, and “approved” slowly stops meaning understood.

The scarce resource is no longer typing code. It is making clear decisions and validating their consequences.

I have been using this approach for only a few weeks. On this project, it works better than the Scrum-shaped workflow I used before. That is all I will claim. It is a field report, not proof of a universal method.

The team case will also be different. Review capacity can be distributed across several people. Product, architecture, security, and domain decisions may have different owners. But adding agents will create the same underlying imbalance whenever execution capacity grows faster than human judgment.

From Waterfall to Agile to Agentic

Waterfall organized software development around phases and a long-term plan.

Agile organized human teams around short feedback loops and their capacity to implement change.

The next step has to organize autonomous execution around human intent, bounded authority, and verifiable outcomes.

I call that broader step Agentic Development.

Some Agile principles will survive inside it, just as planning survived the move away from Waterfall. But Agile will no longer be the operating model. It will become part of the inheritance.

Agentic Development is not Agile with a faster coder added to the team. It starts from a different constraint: agents can produce almost continuously, while humans remain responsible for deciding what should exist and whether the result is acceptable.

That requires a new method.

This is my current attempt.

If your team used Scrum or Kanban before coding agents became part of the delivery process, I would like to know what happened. Which bottleneck appeared first? What did you keep, and what did you have to replace?

Docker works; until it doesn't. Why I started using Nix for dev environments

Charalambos Emmanouilidis — Fri, 20 Mar 2026 18:03:51 +0000

It's Monday morning. A new engineer joins the team. By Thursday, they're still fighting their dev environment. The Dockerfile the previous engineer wrote pulls from ubuntu:22.04, runs apt-get install without pinned versions, and "works on the CI runner." On the new engineer's M2 Mac it builds fine but the binary crashes at runtime because they're running a different glibc. You've seen this. We all have.

The thing is: Docker was supposed to fix this. It didn't. It just moved the problem. Not in production -- in development environments.

The Problem with Dev Environments

Dev environments fail in predictable ways:

Dependency drift: your local toolchain diverges from CI over weeks. Nobody notices until a build breaks in production but passes locally.
Version manager sprawl: nvm, pyenv, rbenv, sdkman -- one per language, none of them talk to each other, all of them break on OS upgrades.
Platform gaps: macOS developers running Linux containers via a VM, dealing with volume mount performance issues and file permission mismatches.
Onboarding friction: a README.md with fifteen manual steps that's six months out of date.

The underlying issue is that most tooling in this space solves isolation but not reproducibility. Those are different problems.

What Docker Actually Solves Well

Docker is genuinely good at a few things:

Runtime isolation: your service runs in a predictable Linux environment regardless of the host OS.
Distribution: package a runtime with its dependencies, ship it anywhere. This is Docker's strongest use case.
Standardized CI/CD: every major CI platform speaks Docker natively. The ecosystem around it is massive.
Service dependencies: spinning up Postgres, Redis, and Kafka locally with docker compose up is a legitimately good workflow.

For running services, Docker is the right tool. It's the dev environment use case where things get complicated.

Where Docker Hits Its Limits

The Dockerfile model is procedural, not declarative:

FROM ubuntu:22.04
RUN apt-get update && apt-get install -y \
    cmake \
    ninja-build \
    gcc \
    python3

This fetches whatever happens to be current at build time. You're not building a stable environment. You're replaying a moving target -- without even knowing what changed -- and taking a dependency on the state of the internet that day. Build the same Dockerfile six months later: different packages, different behavior, zero indication anything changed.

The usual response is to pin the image digest:

FROM ubuntu:22.04@sha256:58b87898c82e...
RUN apt-get update && apt-get install -y cmake ninja-build gcc python3

Better -- but the packages inside still drift. You've pinned the base layer, not the build. And now you own the update cycle manually. So even "best practices" don't fully solve the problem.

More practically:

macOS and Windows performance: Docker on macOS runs inside a Linux VM. On Windows, you're going through WSL2 -- and while WSL2 is functional, cross-filesystem I/O (your code lives on the Windows side, the build runs on the Linux side) kills performance. Large C++ or Go builds inside a container on either platform are noticeably slower than native Linux.
DevContainers + Kubernetes: if your team runs DevContainers against a remote Kubernetes cluster, you've already hit the wall. VSCode remote development, build performance, port forwarding, image rebuild cycles -- it adds friction at every layer.
Build caching is fragile: Docker layer cache depends on instruction order and content. It breaks in non-obvious ways and is hard to share across machines without a registry.
DinD is a mess: if your CI or dev workflow needs Docker inside Docker, you're fighting containerd, socket mounts, and privilege escalation from day one.

Snapshot vs. Derivation

This is the core difference.

A Docker image is a snapshot. A Nix build is a derivation.

A snapshot tells you what existed. A derivation tells you how to get there.

That difference matters when things break -- because with a snapshot you can restore, but you can't reason. With a derivation you can reproduce, audit, and understand exactly what changed and why.

How Nix Approaches the Problem

Nix takes a different angle. Instead of "here's a script that builds an environment," it asks: given a precise description of inputs, what are the outputs?

Every package in Nix is identified by a cryptographic hash of its inputs -- source code, dependencies, build flags, compiler version. If the inputs are identical, the output is identical. Always. This is what reproducible builds actually means. And because the entire build graph is explicit, cross-compilation becomes a first-class concern: you can target ARM from an x86 machine without custom Docker images or fragile toolchain scripts.

For dev environments, nix develop gives you a shell with an exact toolchain:

# flake.nix
{
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.05";

  outputs = { self, nixpkgs }:
    let
      forAllSystems = nixpkgs.lib.genAttrs [
        "x86_64-linux"
        "aarch64-linux"
        "aarch64-darwin"  # M1/M2 Mac
      ];
    in {
      devShells = forAllSystems (system:
        let pkgs = nixpkgs.legacyPackages.${system};
        in {
          default = pkgs.mkShell {
            packages = [
              pkgs.cmake
              pkgs.ninja
              pkgs.gcc13
              pkgs.python311
            ];
            shellHook = ''
              echo "toolchain: $(cmake --version | head -1)"
            '';
          };
        }
      );
    };
}

flake.lock pins the exact nixpkgs revision. A colleague on macOS, a CI runner on Linux, and you on your laptop all get the exact same cmake binary -- same source, same build flags, same hash. Not "the same version" -- the same build. That includes clang-format: it ships with clang-tools and is pinned alongside everything else. No separate install, no "which version did you format with?" conversations.

No global installs. No version managers. nix develop drops you into the environment, exit leaves it. Your system stays clean.

Combine with direnv and it gets even better. Add a .envrc with a single line:

use flake

Now cd into the project directory and the environment activates automatically. Leave the directory, it's gone. No manual nix develop, no global state, no version managers fighting each other. Your shell just has the right tools when you need them.

The same principle applies to your C++ library dependencies. Anything you'd normally pull in via CMake's FetchContent can go into the devShell instead:

# The FetchContent approach: version string lives in CMakeLists.txt,
# downloads happen at configure time, requires internet access on every fresh build
include(FetchContent)
FetchContent_Declare(fmt
  GIT_REPOSITORY https://github.com/fmtlib/fmt
  GIT_TAG        10.2.1
)
FetchContent_MakeAvailable(fmt)

With Nix, you add the library to packages like any other tool:

packages = [
  pkgs.cmake
  pkgs.ninja
  pkgs.gcc13
  pkgs.fmt  # fmt -- same pin, same hash, same binary everywhere
];

And in CMakeLists.txt you use standard system package discovery:

find_package(fmt REQUIRED)
target_link_libraries(myapp PRIVATE fmt::fmt)

The library is already in the Nix store when CMake runs -- no build-time downloads, no internet access required. The version is pinned in flake.lock alongside gcc and cmake. One lock file. One place to update. No version strings scattered across CMakeLists.txt files.

Full example (including fmt dependency): github.com/charemma/blog/tree/main/nix/devshell-cmake

Key Differences

	Docker	Nix
Reproducibility	Image digest is reproducible; Dockerfile build is not	Content-addressed; build graph is fully deterministic
Dev environment	Container with volume mounts	Native shell, no overhead
macOS / Windows	VM overhead, slow volume mounts, WSL2 I/O issues	Native, no VM
CI integration	Native, widely supported	Requires setup; but identical to local
Learning curve	Low-medium	High
Partial adoption	All-or-nothing per container	Per-project devShell, gradual
Binary caching	Registry-based	Nix substituters (cachix, self-hosted)
Package availability	Anything you can `apt-get`	nixpkgs is large but has gaps

Where Nix is Stronger

Toolchain-heavy projects: C++, embedded, cross-compilation. When your build depends on a specific GCC version, exact sysroot, and a custom linker script, Nix handles this cleanly. Cross-compilation is where Nix really shines. You declare host and target -- Nix handles the rest. Docker can technically do it too, but cross-compilation setups in containers are notoriously fragile.

Cross-platform consistency: the same devShell works on macOS and Linux. No "but it works in the container" conversations.

CI parity: the gap between local and CI closes because they run the same command against the same environment:

# locally
nix develop
cmake --build .

# GitHub Actions
- name: Build
  run: nix develop --command cmake --build .

No "install dependencies" step in CI that diverges from what you ran locally. Same flake, same lock file, same result.

Incremental adoption: you don't need to Nix-ify your entire infrastructure (though once you've been running NixOS for a while, you'll want to). A flake.nix in a repo gives everyone a consistent dev environment without touching your deployment pipeline.

Where Nix Falls Short

This section matters more than the strengths.

The learning curve is real. Nix the language is functional, lazy, and unlike anything most engineers have written. Error messages are often cryptic. The mental model takes weeks to build, not hours.

Documentation is fragmented. The official docs are improving but still incomplete in places. A lot of knowledge lives in GitHub issues, forum posts, and other people's flakes. You will spend time reading source code.

Flakes are "experimental." Pragmatically, everyone uses them and they're stable enough. But the official experimental label is real friction in corporate environments where "experimental" means "not approved."

Cold builds are slow. On a cache miss, Nix builds from source. For packages with heavy build times (LLVM, Qt, anything Rust-based) this can be painful. Cachix or a self-hosted binary cache solves this, but it's infrastructure you need to set up.

Some tooling doesn't play well. JetBrains IDEs, some commercial SDKs, proprietary build tools -- Nix support is incomplete or requires workarounds. If your stack is heavily JetBrains-based, expect friction.

Hard to justify organizationally. "We're switching to a functional package manager written in a language nobody knows" is a tough pitch to a team already stretched thin.

The reproducibility story is weaker for JavaScript and Python projects. Nix pins the interpreter -- Node 20, Python 3.11 -- but your actual application dependencies still live in package-lock.json or poetry.lock. Those lock files already solve the version pinning problem for the packages that matter most. If you're already committing them, Nix adds little beyond what .nvmrc or pyenv already gives you. The full reproducibility story that makes Nix compelling for C++ and embedded -- where the entire relevant stack lives in nixpkgs -- doesn't translate cleanly to ecosystems with their own mature package managers.

When to Use Which

Reach for Docker when:

You need runtime isolation for services (this is Docker's home turf)
Your CI/CD is Kubernetes-native and you're building images anyway
The team has no appetite for learning new tooling
You need to distribute a pre-built environment to non-engineers

Reach for Nix when:

You have a complex toolchain where exact versions matter (C++, embedded, cross-compilation -- and if you're building an embedded OS, Nix can replace Yocto entirely. But that's a story for another post.)
You've been burned enough times by local/CI divergence
macOS or Windows developers on the team are tired of Docker Desktop / WSL2 performance
You want onboarding to be nix develop and nothing else

The common pattern that actually works:
Use Nix for the dev environment (the toolchain, the build tools, the local shell) and Docker for runtime (building and running the actual service images). They're not competing -- they solve different layers of the same problem.

Conclusion

Docker solved distribution. It didn't solve reproducibility -- it just moved the non-determinism from your local machine to a Dockerfile that nobody updates.

Nix solves reproducibility. It doesn't replace Docker for what Docker is actually good at.

The question isn't "Docker or Nix." It's: where is your actual pain? If your team is fighting with environment drift, onboarding friction, or local/CI divergence -- that's a reproducibility problem and Nix addresses it directly. If you need consistent runtime packaging for services running in Kubernetes, that's Docker's job and it's good at it.

Use boring tools for boring problems. Reach for Nix when the boring tools have stopped working.

The mental shift

Docker teaches you to think in environments.

Nix forces you to think in inputs and outputs.

Once you see that difference, it's hard to unsee it.

If you're dealing with similar problems, I'd be curious how you're solving them -- drop a comment below.
It's Monday morning. A new engineer joins the team. By Thursday, they're still fighting their dev environment. The Dockerfile the previous engineer wrote pulls from ubuntu:22.04, runs apt-get install without pinned versions, and "works on the CI runner." On the new engineer's M2 Mac it builds fine but the binary crashes at runtime because they're running a different glibc. You've seen this. We all have.

The thing is: Docker was supposed to fix this. It didn't. It just moved the problem. Not in production -- in development environments.

The Problem with Dev Environments

Dev environments fail in predictable ways:

Dependency drift: your local toolchain diverges from CI over weeks. Nobody notices until a build breaks in production but passes locally.
Version manager sprawl: nvm, pyenv, rbenv, sdkman -- one per language, none of them talk to each other, all of them break on OS upgrades.
Platform gaps: macOS developers running Linux containers via a VM, dealing with volume mount performance issues and file permission mismatches.
Onboarding friction: a README.md with fifteen manual steps that's six months out of date.

The underlying issue is that most tooling in this space solves isolation but not reproducibility. Those are different problems.