German Velasco

Don’t niche down. Position yourself.

2026-09-03T00:00:00+00:00

I’ve always heard it said, “Niche down!”

But that never felt right to me.

I mean, sure, niching down means you can be a bigger fish in a smaller pond, and maybe that leads to a better customer fit and more sales. But what you actually want is the better fit with customers, regardless of whether or not that’s in a smaller pond.

So, instead of niching down, position yourself.

What you are trying to capture is a place in the mind of the customer (positioning), not a small pond to swim in (niching down).

(Of course, in the process of positioning yourself, you might niche down. But if that happens, that’s a side effect! It’s not the aim.)

What is positioning?

The first thing to understand is that your position isn’t yours. It exists in the mind of the customer. The second thing to understand is that in your customer’s mind, there is only ever one number one.

When I say “Kleenex”, you think tissue. It’s become almost synonymous because they own the position.

I imagine it’s the same in whatever space your product or service is trying to fit in: there are already players there, and unless it’s a new market, there’s already a leader.

So, if you want prospective customers to even think of you, you have to ask yourself: what makes you unique and better than what’s already out there?

Is your product faster than the competition’s?
Is it easier to use?
Is it higher quality?
Do you have a different way of solving a problem?
Something else?

Positioning is about finding how you are the best at something in a given market, and telling prospective customers that.

Then, your customers will understand at a glance what your product or service does, and how it can help them.

The beautiful thing is that once you find your position, you can also re-position the competition! If your product is fast, theirs becomes the slow one. If yours is easy to use, theirs is the complex one.

Diverge then converge with LLMs

2026-08-03T00:00:00+00:00

One of the patterns I’ve found particularly helpful with LLMs is the diverge-then-converge pattern.

Diverge & Converge

Since LLMs are neural networks, when we give agents slightly different prompts, we make their “thinking” travel through different neural pathways (at least, that’s how I think of it).

That makes LLMs really helpful at suggesting different solutions to a problem.

Slightly different starting points lead to different outcomes

But LLMs are also really good at summarizing, organizing, and synthesizing vast amounts of information.

When we put those two abilities together, we get an amazing tool to help us solve problems.

Here are three examples where I use the diverge-then-converge pattern.

Code Review

I have a code review skill that first diverges by having an orchestrator agent spin up three sub-agents to review code. Each sub-agent has a specific focus:

Correctness
Security
Simplicity

If there are UI changes, I add a fourth sub-agent that compares the resulting design with what was requested.

But rather than read those “raw” results immediately, I have the orchestrator agent categorize the results into important, nice-to-haves, and nits in an HTML file that I can review.

Bug Fixes

I know some people have created loops for fixing bugs: issue comes into error tracker -> robot picks it up -> fixes it -> opens PR -> merges PR.

In my experience, that works for simple errors.

But when I try that for more complex errors, that loop leads to shallow fixes: the agent will solve the obvious, terminal problem (“let me add a not is_nil(arg) clause”) rather than fixing the root cause (“we shouldn’t allow these values to be nil”).

And yet, the majority of the time, I want the root-cause fix. That’s why I like to have a diverge-then-converge pattern with the agents.

Just as with code review, I have an orchestrator agent spin up sub-agents to look for a fix with different aims.

Simple fix (sometimes not is_nil(arg) is all that’s needed)
Thorough fix (often suggests multi-step changes, closer to root cause fix)
Creative fix (helpful to catch system design flaws. Sometimes this is the root issue)

Then, I have the orchestrator agent summarize and synthesize the suggested fixes, so I can decide which course of action we should take. Often, it ends up being a combination of two of the three approaches.

Design Variants

I stole this idea from Tomasz Tomczyk when we were pairing on his workflow. He had a design skill that would create three alternative designs for a given page based on three different companies’ styles (e.g. GitHub, Stripe, Figma).

In my case, I have the orchestrator agent spin up three sub-agents to create the same design in three different ways:

Minimal (trying to capture only the essentials)
Bold (a more opinionated design)
Unexpected (rethinks the approach)

Once the agents are done, they output the designs in HTML so I can review them. Sometimes, there’s a clear winner, and we move on. But the benefit of having three different approaches is that I can choose parts of each that might work together.

And that’s when I tell the agent to combine the pieces that I like into a final design. The orchestrator agent then goes and creates a new design with all of my preferences.

Are plan files the new 10k-line PRs?

2026-07-07T00:00:00+00:00

Many people’s new way of working with LLMs is to start with an idea, have the LLM create a spec (review and approve that), then have the LLM generate a very detailed plan.

At that point, people have two options:

They either spend a lot of time reviewing the plan, ask for changes, and finally approve it. Warning: this may take hours.
Or they skim the plan, but it’s too long, so they YOLO it and say “LGTM 👍”.

And that made me realize that plans are the new 10k-line PRs.

Back before the days of LLMs, we used to say that the number of comments a PR received was inversely related to the number of lines it had.

If the PR had 10 lines, it’d get 11 comments.
If the PR had 10k lines, it’d get one comment: “LGTM 👍”.

The problem wasn’t that we were lazy.

The problem was that to understand 10k lines of code requires many, many hours of review. We’d have to transform that 2D text into a 3D mental model in our heads. We’d have to carefully consider how the new vast amounts of code fit into the existing system. We’d have to consider high-level architecture and low-level details.

Because of that, even if we spent 3 hours reviewing the PR, submitting comments, reviewing changes, and doing that 2 to 3 times until everything looked good (a process that I always found demoralizing for the reviewer and author alike), the results were still worse than if the author had split the work at the beginning into smaller slices.

So, the joke went that we would just give the 10k-line PR a thumbs up. 👍

Now, as an industry, we’re trying to figure out if we can stop reviewing code. To do that, I see some people turning to the big-plan-upfront strategy to try and specify the desired behavior ahead of time. After all, if we can do that, we can let the latest models run independently for hours!

But that suffers from the exact same problems we had when we tried to review 10k-line PRs: we have to transform the plan’s text into a 3D mental model in our heads. We have to carefully consider how the new vast amounts of code the model might generate will fit into the existing system. We have to consider high-level architecture and low-level details. And because of that, the implementation will be worse than if we split the work into smaller slices and work iteratively.

Thinner slices. More iteration.

For years, software development best practices encouraged a more iterative approach.

We were always trying to capture a small slice – a user story or maybe even just a use case – not a full-fledged specification. We would then build that and reevaluate. In the process, we’d discover some pitfalls or improvements we hadn’t foreseen at first.

Then we’d iterate.

And so, solutions would, to some degree, evolve from the kernel of the initial idea, the realities of what was already present in the codebase, and the new insights we gained with each iteration.

And I think that’s still how we can work.

My preferred flow (at least currently) is to plan the work in full-stack slices. Once I’ve split up my work into a slice, I then work on one or two use cases (sometimes in Gherkin) with the LLM. We then talk about architecture and agree on what the call stack should look like. Perhaps we do some ideation on UI or UX as well.

It’s only once we’ve agreed on all of that, that I let the LLM go. We have a plan of action, but it’s not the plan. It’s not a huge document sitting in my /plans directory. It’s encompassed by the use cases we agreed upon.

And once that’s done, we have a shippable unit of work. We can stop and evaluate what has been done and whether anything needs correction. That helps evolve the design. Then, I repeat the same cycle with the next chunk of work.

But isn’t that slow?

Not any slower than the big-plan-upfront approach. Instead of spending five hours with my eyes bleeding while I read and change the 10k-line plan, I spend that time iterating and evolving the design with the LLM.

It’s a far more engaging and enjoyable experience, and I think it creates better, more maintainable software.

Reflections on creating ExCrap without looking at the code

2026-06-25T00:00:00+00:00

I recently published ExCrap, an Elixir library for calculating Change Risk Anti-Patterns scores – or as they’re commonly called CRAP scores.

From the README:

CRAP combines function-level cyclomatic complexity with function-level coverage to highlight code that is risky to change because it is both complex and under-tested.

Because the library is small (it basically exposes a single mix crap task), and the idea concrete enough, it made for a perfect experiment: creating the library without looking at the code.

Why the experiment?

There’s so much talk about software factories, but I keep asking myself: can we really verify the code the agents write without looking at it? So, I wanted to treat the library’s code as a black box to force my brain to think of new verification strategies.

That’s what this post is about.

In it, I share a few things I tried while creating the library (some good, some bad), and I end with some reflections.

Here’s an outline if you want to skip around:

Initial research with the three big brains
The first few phases with superpowers
How do I verify this is working?
External verification
Internal code health
Final reflections

Initial research with the three big brains

The initial research itself was interesting. I could have done it myself and given the agents a good prompt or context. But that’s not what I did.

A little while ago, I attended a workshop on building software factories that two old colleagues of mine were starting. In the first session, we talked about bringing an idea and using the “three big brains” for research: GPT, Gemini, and Claude.

So, I used all three models to do deep research on a core idea:

I want to create an Elixir library that calculates C.R.A.P. scores (combining test coverage and cyclomatic complexity). The library should be able to be executed with mix to be run locally and in CI environments. And it should have the ability to give me a score. If the score is beyond a certain level, we should be able to fail CI (same as is possible with tools like Credo).

That resulted in three research files that I committed to the repo, which other agents then used as an index of information.

Those files served as the foundation of the library. For example, that’s where the agents who did the initial implementation got the knowledge for what CRAP metrics were and how to calculate them.

After that, the rest of the application was built using GPT 5.5 and OpenCode (in case that matters to you).

The first few phases with superpowers

Once I had the research in place, I started implementing the application in full-stack slices. At the time, I was using superpowers, so some of my prompts automatically triggered its brainstorming, writing-plans, and other skills.

I originally committed some of the artifacts, though I have since removed them from the repo. But if you’d like a sample, you can still find a few of them in the commit history like this plan.

To be honest, planning is the part I liked the least.

LLMs have made me hate markdown. I still love markdown for writing, but reading markdown created by an LLM just makes my eyes bleed. (I now prefer HTML files as output.)

I also prefer a more interactive flow than a giant upfront spec/plan. So, my feature work today is more interactive, where the agent and I define some Gherkin, talk about module/function architecture, and then I let the agent do a slice of work.

But I digress. For the initial implementation, I created plans, and if I’m honest, I probably only skimmed them. So, the agents were guiding the roadmap, and I was mostly flying blind.

How do I verify this is working?

With all software, I think we need two types of verification:

The first is about whether or not the product we’re creating is what we desired. This one is external to the black box, and therefore, visible to us. In web apps, you could think of this as the UI you can click around. With ExCrap, it’s mostly about running the mix crap task.
The second is whether or not the codebase is healthy and evolving well. That one is internal to the black box, and therefore, invisible to us.

So, for us to fully verify our software product, we need to inspect the output (visible) and we need sensors and signals to give us information about what’s happening inside the black box.

🧭 External verification

Since the library boils down to that single command, I could easily verify its output manually. I ran mix crap over and over to make sure the library could calculate CRAP metrics for itself.

That also allowed me to improve the format of the output.

For example, I wanted mix crap’s output to be terse by default and verbose only if we passed a --verbose flag (the LLM’s original output was really verbose). I wanted it to have colors: red on failure, green on success (the LLM’s original output had no colors).

But dog-fooding only gave me one data point. The “users” of mix crap would be other Elixir projects. Would it work in those?

Manually testing external libraries

As a first pass, I cloned some open source repos (like Phoenix and Ecto), added ex_crap as a dependency, and ran mix crap on those libraries.

That immediately flagged issues with ExCrap – it couldn’t even read the Elixir files in those projects correctly. All I got was an {:error, :invalid_source} error.

Unfortunately, the error didn’t even have a stacktrace (it just failed to read the file), so there was no way of knowing what construct in those codebases ExCrap was treating as invalid.

So, I did what anyone leaning on agents will do: I grabbed the error and fed it back to the agent.

The agent had guesses at what might be causing the issue. But after a couple of rounds of me running mix crap on libraries and feeding the errors back to the agent, it was clear we wouldn’t really solve the problem that way.

But I had learned one thing: the errors were coming from ExCrap’s cyclomatic complexity calculation. It seems that ExCrap only accounted for some Elixir constructs, and when it found a file that had constructs it hadn’t accounted for, it just returned {:error, :invalid_source}.

So, I needed a way to test more combinations of Elixir constructs to make sure the library could parse them. That’s when I reached for property-based tests.

Property-based testing

I thought this would be a great opportunity to use property-based tests. I needed many, varied combinations of inputs that should always satisfy a simple property: the files should parse without error.

But once again, not being able to look at the code meant it was hard to know how to best write those properties. The best I could do was to have the agent generate the tests.

That helped, but there were two problems:

I didn’t really know what we were testing with those property-based tests. I could read the test descriptions with --trace, but even then, I wasn’t really sure what those tests were actually testing. I only knew what the test description claimed to be testing.
The second, bigger problem, was that even after creating the property-based tests, and fixing the issues those caught, running mix crap on many open-source libraries would still fail.

That’s when I finally got the idea on how to close the loop.

Leaning even more into the search & gather methodology

What I really wanted to do was to somehow automate what I was already doing manually (running mix crap on a bunch of open source libraries), and to do it directly in the ex_crap library.

Bringing all the libraries into the ex_crap project seemed like a bad idea, but perhaps I could do something simpler and achieve the same result. Maybe I could grab pieces of open source libraries and create sample modules that could serve as fixtures for tests.

So, just as with the research at the start of the project, I sent some agents to search and gather.

In this case, I tasked an agent to send subagents to find sample Elixir open source repositories (I didn’t specify which). I told it to get a broad set of concepts to cover all Elixir constructs. I then asked it to consolidate those findings and generate sample Elixir modules that would compile and stand alone (i.e. have no dependencies). Those would be the sample modules that I could use as fixtures.

The agent did a pretty good job of that.

It created a series of sample modules, organized them into separate directories based on what they’re meant to capture, and created tests that run those fixtures.

Here’s the directory structure from the samples README:

elixir_samples/
├── 01_basic_modules/
├── 02_typespecs/
├── 03_structs_protocols/
├── 04_behaviours/
├── 05_macros/
├── 06_pattern_matching/
├── 07_genserver/
├── 08_supervisors_otp/
├── 09_protocols/
├── 10_advanced/
└── _raw_originals/

(A huge thank you to the original libraries the agent used as good examples.)

With those files as our fixtures, the agent wrote some tests that surfaced the same {:error, :invalid_source} error, and it fixed the issues. After that, I could get CRAP scores for all the libraries I was testing!

🏥 Internal code health

Throughout the process, I also kept trying to improve the internal verification mechanisms of the library.

First, with all the code I created, I used the superpowers TDD skill. That meant that most of the code that was created had tests. But I couldn’t read or write those tests myself.

So, I needed to figure out what would make for good sensors that would tell me about the code, including the tests themselves!

The first thing I did was to take a quick glance at what the tests claim to be testing by running mix test --trace.

Here’s a small sample:

ExCrap.ScoreTest [test/ex_crap/score_test.exs]
  * test score/2 returns complexity squared plus complexity for 0 percent coverage (1.1ms) [L#9]
  * test score/2 returns complexity unchanged for 100 percent coverage (0.00ms) [L#5]
  * test score/2 preserves fractional scores for intermediate coverage (0.00ms) [L#13]
  * test score/2 rejects invalid complexity (0.00ms) [L#17]
  * test score/2 rejects invalid coverage (0.00ms) [L#22]
  * test score/2 rejects fractional coverage outside the valid range (0.00ms) [L#28]

ExCrap.ElixirSamplesTest [test/ex_crap/elixir_samples_test.exs]
  * test canonical sample fixtures discovers only canonical samples (2.4ms) [L#39]
  * test canonical sample fixtures canonical samples live with test fixtures (0.01ms) [L#35]
  * test canonical sample fixtures all canonical samples analyze successfully (14.7ms) [L#45]
  * test canonical sample fixtures canonical sample aggregate complexity summaries remain stable (7.8ms) [L#57]

# ... more tests ...

Finished in 1.1 seconds (0.4s async, 0.6s sync)
22 properties, 197 tests, 0 failures

That was okay, but it immediately raised the question: are those tests actually testing anything?

I remember a while ago, I had an agent write a test like this (not in this library, but in a different project):

test "pretend to test something" do
  if Application.get_env(:foo, :bar) do
    assert true
  end
end

# in the config
config :foo, bar: false

In other words, the test would always run, do nothing, but show as passing in the output. Just by reading the test description, it seemed like the test was testing something useful. But the code in question was never exercised.

To try to counter that type of scenario, I used two other tools: code coverage and mutation testing.

Code coverage

In Elixir, we get test coverage out of the box with ExUnit with mix test --cover.

Here are the current results for the ex_crap library:

Generating cover results ...

| Percentage | Module                         |
|------------|--------------------------------|
|     83.78% | ExCrap.Coverage                |
|     88.46% | Mix.Tasks.Crap                 |
|     90.00% | ExCrap.Mix.BoundarySpec        |
|     90.74% | ExCrap.Complexity              |
|     96.30% | ExCrap                         |
|     97.18% | ExCrap.Report                  |
|    100.00% | ExCrap.Mix                     |
|    100.00% | ExCrap.Scanner                 |
|    100.00% | ExCrap.Score                   |
|    100.00% | Mix.Tasks.Boundary.Spec.Accept |
|    100.00% | Mix.Tasks.Boundary.Spec.Check  |
|------------|--------------------------------|
|     92.09% | Total                          |

With that, I can at least see that the 197 tests and 22 property-based tests are covering ~92% of the code. So at least as a whole, the tests are exercising a large part of the codebase.

Are they good tests? Do they only test behavior and not implementation? That, I don’t know. For now, it’s the black box’s domain.

Mutation testing

The next, more exciting tool I wanted to try in this project was mutation testing.

The idea behind mutation testing is that we change some of the code (e.g. swap an and for an or), and run the tests. If they still pass, it means our tests are not actually testing that code path.

After some brief research, I decided to try muex.

Muex gave me what I was looking for. Over the course of building the library, I ran my trusty mix mutate and mix mutate.fast aliases frequently and found mutants that survived. So, I fed those back into the agent to improve the tests.

I did run into a lot of false positives, but that might have been a somewhat unique scenario related to Boundary. Muex would remove a use Boundary declaration and say the mutation had survived. But use Boundary is probably one of a few use macros that don’t break your code if you remove them. Nevertheless, it created a lot of noise. So, in the end, I had to trim what types of mutators the library was looking for.

If you’re curious, these are the two mutation aliases I currently have:

mutate:
    "muex --mutators arithmetic,boolean,comparison,conditional,function_call,literal,return_value",
"mutate.fast":
    "muex --mutators arithmetic,boolean,comparison,conditional,function_call,literal,return_value --optimize-level aggressive --max-per-function 5"

Using Boundary for module architecture

It’s still unclear if, in a future where the code is a black box, we’ll care about the architecture of the code. Maybe we’ll just let the agents design it as they see fit. But for now, I wanted to have some control over how modules depend on one another.

And for that, I used Boundary.

Boundary lets us specify some modules as boundaries and declare their dependencies and exports. When those boundaries are violated, it throws a warning. It’s the perfect sensor for module interdependencies.

And it comes with a great mix boundary.spec task. This is the current output for ExCrap:

ExCrap
  exports:
  deps:

ExCrap.Complexity
  exports:
  deps:

ExCrap.Coverage
  exports:
  deps:

ExCrap.Mix
  exports:
  deps: ExCrap

ExCrap.Report
  exports:
  deps: ExCrap.Score

ExCrap.Scanner
  exports:
  deps: ExCrap.Complexity

ExCrap.Score
  exports:
  deps:

When I first introduced Boundary into the project, I had already built most of the functionality. The spec it produced showed that we had some undesired coupling. So, I had the agents modify the code to reduce the number of exports and deps to what you see above.

Enforcing boundaries

But here was another problem. In the course of adding a new feature, an agent could easily violate a boundary, get a warning, and then “fix” it by changing the boundary definition — warning gone! But that obviously removes the usefulness of the signal.

To prevent that, I created two additional mix tasks to enforce that the boundary definitions aren’t changed without human approval:

The boundary.spec.check task compares the output of mix boundary.spec against output that was previously approved and saved. If the spec differs, then it means the agent has changed the boundaries without approval.
To approve a new boundary spec, a human needs to run an interactive mix boundary.spec.accept task.

Of course, an agent can just go ahead and edit the text file that contains the spec’s source of truth. And no amount of ~~COMMANDS~~ suggestions in the AGENTS.md file will stop a determined agent. So, the workflow is far from perfect, but for now, I’m comfortable with it since module architecture is not mission-critical.

CRAP scores

Another signal I used to try to keep code healthy was CRAP scores (that’s why I created the library).

I’ve always found Credo’s cyclomatic complexity check a little annoying because it’ll flag any case statement that has many branches, even if each branch is simple. And case statements are very common in Elixir.

So, before learning about CRAP scores, I was reluctant to treat cyclomatic complexity as a signal that the agent could use to correct itself.

But since CRAP scores combine cyclomatic complexity with test coverage, I actually like the metric a lot more. If a function has good test coverage for all the potential branches in a case statement, the score goes down a lot (technically, a fully covered function’s score is equal to the original cyclomatic complexity score, but CRAP’s default threshold score of 30 is a lot more forgiving than Credo’s 9).

So throughout the creation of the library, I ran mix crap (or my other trusty alias mix test.crap) to see that everything was green.

When I wanted more details, I ran mix crap --verbose. And if I wanted to see what modules were getting too close to the threshold, I ran mix crap with a lower --max-score flag (e.g. mix crap --max-score 20).

Adding more static checks

Last but not least, I also reached for static analysis tools in my quest to keep the black box healthy. For ExCrap, I added Credo, Quokka, and Sobelow, though I added them pretty late in the process.

Since it was late in the game, Credo and Quokka (which automatically runs on mix format) didn’t find any glaring issues (that I could tell). Sobelow, on the other hand, caught a few things. The overall majority were minor (which I ignored), but it caught a String.to_atom call that I was very glad to fix.

After all was said and done, I added all three to my precommit alias that is the core of my fast checks:

    "test.crap": [
        "test --cover --export-coverage default",
        "test.coverage",
        "crap"
    ],
    precommit: [
        "format",
        "test.crap",
        "boundary.spec.check",
        "credo --strict",
        "sobelow --skip"
    ],

Final reflections

So, having now published the library, how do I feel about the project?

I have to say, I still feel unsettled. It is very strange to have a project under my name that I’m not entirely sure I understand.

Before I published the library, I opened the black box and looked inside. I wanted to make sure I wasn’t shipping malware to people in the Elixir community. I didn’t change anything because nothing stood out as malicious or bad, and I wanted to keep the experiment somewhat “pure” until I wrote about it.

And that’s one part of the experiment I’m taking with me: I just couldn’t verify (or shake the feeling) that I wasn’t shipping something bad to other Elixir folks without peeking inside the box. So, for me, at least for now, I want to be able to see inside the box.

So, what was inside the box?

The code isn’t at all how I would’ve written it. That’s not to say it’s necessarily bad. I actually think a lot of it looks interesting. But I didn’t spend hours and hours understanding it and internalizing it, so it looks foreign to me.

Aside from that, the library is small and simple enough that I’m happy to publish it, not in the least because I want to use it in my own projects.

Meta lessons about working with LLMs

I want to leave you with two (meta) lessons learned.

The first is something I’ve come to realize about working with LLMs (which, honestly, should’ve already been apparent as a software developer). It is best to do things manually first. Discover the rough edges. Fine-tune the flow. Once you’ve done that, and the action starts feeling repetitive, then automate it (or hand it to an agent).

The second lesson is that you sometimes have to lean more into how LLMs work. It was surprising to me at first (though in hindsight it shouldn’t have been) that the best solution to my failing-to-parse-files issue was to go get more data, refine it, and use it for my tests. That’s something that might’ve been too expensive (or annoying) to do without agents. But with agents, it was a nice way to provide the data we needed.

Thank you for reading and going on this journey with me. In this wild west of AI, I encourage you to experiment more, and then share what you learn!

Why dead code feels hard to delete

2026-06-19T00:00:00+00:00

It’s always surprising when people don’t want to delete dead code because they think they might need it in the future or because they worked so hard on it.

Recently, I had one of those conversations with a colleague. I was trying to convince him that we should delete unused code, and that made me think: why is it that we sometimes feel reluctant to delete dead code?

I think there are a couple of mental models that can help us understand why: the sunk cost fallacy and the loss aversion principle.

Sunk cost fallacy

Code isn’t free. Yes, today LLMs make it cheaper to write code (or at least some type of code). But shipping good features requires planning, coordination, research, and even the coding itself requires us to make many decisions about how to fit it into the existing system. That’s expensive.

But if it’s so expensive, how could we just throw it away?

Because the cost is what we call a sunk cost:

a sunk cost is a sum paid in the past that should no longer be relevant to decisions about the future

As humans, we tend to think that a thing (in this case, code) is valuable because it was costly to create. Especially if we incurred the cost. So, we end up keeping the thing, even if it makes it more costly going forward (that’s why it’s a fallacy).

In reality, we should want to avoid future costs, regardless of what happened in the past. That’s what we should optimize for. Dead code just makes it harder for us to reason about the codebase, and it makes it more costly to introduce new code. That’s why we should remove it.

So rationally, we should remove it. But it still feels bad sometimes. Why is that?

Loss aversion principle

I think the loss aversion principle can help us understand the feeling:

loss aversion is a cognitive bias in which the same situation is perceived as worse if it is framed as a loss, rather than a gain

So, if something seems like a loss, it feels worse. For example, we feel worse if someone gives us $100 and later takes it away than if we had never received the $100 in the first place. In both cases, we end up in the same place, but getting it taken away feels worse. (If you don’t believe me, promise your kid ice cream and then renege on the promise.)

I think the same is true of code.

If I were to tell you that I could add 10k lines of unused code in your codebase instantaneously and completely free, would you accept that?

Of course not!

Why would you want dead code that will make things more difficult for your team in the future? Who cares that it’s free to add today?

But if you think about it, that’s exactly the same thing we’re doing when we keep dead code. We just inverted the scenario.

We feel bad losing the code. But when we’re in our right mind, we wouldn’t accept useless code just because it was free.

A maxim to remember

That’s why I have a maxim:

Code is a liability

Remember that. Code is a liability. It’s not free to create or maintain. The less of it you have, the better. We only need as much of it as is required to serve our customers. Not a tab or space more.

Draw the rest of the ___ owl (software factory edition)

2026-06-12T00:00:00+00:00

My guess is that most software development teams in the world are at a point where we are drawing the two circles (Don’t quote me on that. I don’t have data to back that up). Those are all the teams where developers use LLMs daily.

Some may only use them as assistants (e.g. asking them questions). But others no longer open their editors much, if at all. They mostly interact with the LLMs through a CLI tool like OpenCode, Claude Code, or Codex, and have the LLM write all the code, even if that means just fixing a typo.

Still, I consider all of that to be on the “draw some circles” side.

But then you hear about teams that might be getting closer to buiding software factories, like the team described in Simon Willison’s blog post titled “How StrongDM’s AI team build serious software without even looking at the code”.

And that’s the “just draw the rest of the ___ owl”.

There’s a monumental gap there. And that’s the gap I’m trying to understand.

How can we trust the code without looking at it? (And does that change as models get better?)
How can we verify that the code is doing what we want it to do?
How can we verify that the code is not doing what we don’t want it to do? (e.g. secretly phoning home)
How can we make sure we’re building software that will be able to change over time? (We don’t want software that calcifies past the first few versions, where a change breaks a seemingly unrelated piece of code elsewhere)
How can we make sure the LLMs aren’t writing code that is slowly and silently decaying until a final day of reckoning? (We don’t want to be like the turkeys that are happy and well fed for 364 days of the year, only to be butchered on Thanksgiving Day)

How do we draw the rest of the owl?

If we’re going to treat the code the LLMs write as a black box that we never read, then all we can know about it is the inputs we provide, the outputs it creates, and the signals we get from what Birgitta Böckeler’s blog post calls “sensors”.

This is how I envision one factory line (in our larger software factory):

Context is not king

The inputs are the prompts and any context we provide the LLMs. Those matter. But I’m not convinced more context is what gets us to software factories.

Some people argue that if we can just provide a full specification, the LLMs will build it right. I disagree. I’m not convinced a 30-page tome that we create in “plan” mode is really how we get software factories. A better plan doesn’t help us know if the LLM has built the right thing, especially as more features are added over time.

No, if we’re going to build software factories, I think it all comes down to verification.

We need to make sure that the software we’re building behaves like we want it to, while also making sure the codebase can change over time without decaying.

Sadly, I see some people reverting to doing a lot of manual testing (e.g. they test their changes via some UI and say, “looks good”). Manual testing is fine, but it suffers from the problems it’s always suffered: it’s slow and expensive (and therefore cannot cover all possible scenarios), and it’s not easily repeatable (so it’s easy to miss regressions). That’s why automated testing is so much better — it’s fast, cheap to run, deterministic, and repeatable.

So, if we cannot verify the behavior by just clicking around the app, what do we do?

As someone who’s been practicing TDD/BDD for over a decade, my first inclination was to treat tests as a verification tool. After all, automated tests should verify the behavior of our application.

But if the LLMs are the ones writing the tests inside the black box, how can we verify the verifying mechanism?

We need more sensors

This is where I think we need to make the most progress. If it is indeed possible to create good software factories, we need more information about what’s happening inside the black box.

Remember, we want signals that help us answer questions like these:

Is the application behavior correct?
Are the automated tests the LLMs write actually covering the code they created?
Is the code architecture evolving well?
What’s the health of the code? Is it decaying?
Is the code performing unwanted side effects?

So far, my preferred flow includes writing Gherkin scenarios that act as an invariant the LLMs cannot break. I couple that with code coverage to make sure the tests are exercising new and existing code paths. And I’ve started using mutation testing to ensure those LLM-generated tests aren’t fake.

For high-level architecture, I’ve been relying on DDD-style bounded contexts by checking module boundaries with libraries like Boundary for Elixir. That architecture should not change without human approval.

I’m also interested in exploring things like TLA+ to see if we can have a more formal specification of the runtime temporal logic. But I haven’t gone far in that direction yet.

For code decay, I’m using static analysis tools (like Credo for Elixir) to help measure things like cyclomatic complexity, and I recently built ExCrap to to perform CRAP analysis.

For security, I’m using libraries like Sobelow and other LLMs to perform adversarial reviews. (Actually, I use adversarial LLMs for all of the above.)

But I’m still working on drawing that owl (it still looks like two circles to me). So, I think we need more (and better) sensors and signals. And then, ideally, we can feed the signals back to the LLM so the signals also serve as self-corrective mechanisms.

Oh, and hey, if we end up not wanting a software factory after all, all these sensors can help us humans build better software anyway!

Stop writing code by hand (and feel the friction)

2026-06-09T00:00:00+00:00

I know LLMs are a contentious topic. I’m not here to hype them or try to make you use one if you’re morally opposed to them. That’s not what this post is about.

But if you’re using LLMs in your day-to-day workflow, and you’re only using them as assistants that you ask questions of (like a glorified Google in your terminal or IDE), or if you call on them like a genie, only when you think they’re fit for the task (e.g. “change variable x to be y”), then this post is for you.

I think the best next step you can take is to close your editor or IDE and stop writing code by hand.

Why?

Not because writing code by hand is bad or slow. Or because we need to burn more tokens to make some weird flex. Not even because the CEO of your company mandates it.

I think you should stop writing code by hand because working with LLMs opens up a new way of working. And the best way to learn how to work in that new way is to stop writing code by hand. It’s only then that you’ll discover all the friction.

Having the LLM write the code doesn’t mean that you can’t look at what it creates (that’s another topic for another day). And very importantly, it doesn’t mean you have to accept what it writes in the way it writes it.

That discrepancy between what you want and what it does – that’s the friction I want you to feel.

But don’t revert to writing code by hand! If you dislike what the LLM writes, stop, take a minute, and try to think, “how could I have gotten it to do what I wanted in the first place?” Then, try again.

Maybe the LLM is producing too much output (find a way to work in thinner slices), or maybe it’s deviating from a standard you have in your codebase (find a way to automatically enforce that standard), or maybe it’s writing tests in a particular flavor you don’t like (then you realize the LLM is just copying the style from another file, and your codebase is inconsistent. Make it consistent).

Whatever the case, that feeling of frustration that the LLM isn’t doing what you want is good (in this case). It’s your spider-sense telling you that using the LLM in its raw form is not good enough for what you want. You have to learn how to use the new tool and its ecosystem.

Maybe you need some new “skills” or planning tools or something else. Whatever the case, the simple action of not writing code by hand and feeling the friction is opening an entirely new way of working.

But remember (and this is important too) that whenever you’re learning something new, you might go a bit slower at first. Remember that (especially if you’re a very senior engineer), because it might have been a long time since you last struggled so much with a new tool.

You probably already have your setup tuned perfectly to behave just the way you want it. And now, well, now you have a machine that everyone says will speed you up, but it’s simply slowing you down. Give it time. Work on removing that friction.

Daily writing retrospective

2026-06-02T00:00:00+00:00

Back in April, I decided to write daily for my newsletter. Up to that point, my newsletter was mostly a delivery mechanism for my blog. But I wanted to change that. I wanted to write more.

This is what I said in my first post:

It’s been a while since I’ve written in my newsletter (hope you’re still here!)

In this age of AI, I find that I want to write more (not less) in my own voice. To me, writing is thinking, and I have a lot of thoughts rolling in my brain that I want to clarify and solidify – so what better way to do that than to write?

But I have to dust some cobwebs.

Well, I love Martin Fowler’s “if it hurts, do it more often” aphorism. I frequently say it in programming or business circles. Why shouldn’t it apply to writing as well?

So, I’m going to try to write daily (for 30 days) and see if it sticks. At least for week days (weekends might be tough). If that’s not interesting to you, you can always unsubscribe. But before you do so, give me a chance!

I hope that what I write is useful to you.

More than anything, I’d love to also hear from you.

If I write something that interests you or sparks something in your mind, I’d love to hear it. Maybe this can become more of a conversation than me screaming into the void.

Well… that’s it. Hope you enjoy the ride with me.

Best,

German

In my typical retrospective format, I’ll ask:

What went well?
What went wrong?
What could we improve?

What went well?

First, the wins.

I wrote a lot more!

I wrote 29 posts in a span of ~40 days. I missed some days. But for the most part, writing daily – and publishing daily – was a tremendous forcing function.

Nothing like a good deadline to force yourself to just ship.

It wasn’t easy. I had to make time for writing (typically at 5am), since I didn’t have time otherwise. And it took about an hour to write each short post. But I loved being able to ship daily, even when I wasn’t fully satisfied with what I wrote. (Don’t let perfect be the enemy of good, right?)

I published blog posts

Out of that daily writing, I also created three blog posts:

It helped me think

In my first post I said “to me writing is thinking”. And boy did it get me thinking.

Because I had to write daily, I was constantly thinking of what I would write the next day, jotting down some ideas and notes, and it did help me work through some of the “thoughts” I had in my head (the ones I mentioned in my first post).

It helped me connect with readers

One of the coolest things was when a reader responded to a post. I love connecting with others over ideas. And a few people responded to some of my posts excitedly agreeing, asking questions, or offering their perspective.

It was honestly one of the best surprises about writing daily. Before I started, I didn’t know what to expect: either utter silence or perhaps outrage (those are the fears in our heads). Instead, people were interested and excited.

To those of you who wrote back, thank you!

Because I connected with readers, and because I have now made my newsletter into a vehicle that is more than just delivering blog posts, I feel comfortable writing there.

That may not seem big, but it’s a huge win for me.

Before this exercise, I felt like my newsletter had an implicit agreement that it was purely a delivery mechanism for blog posts. After 29 posts, I think the people who only wanted it for that reason have unsubscribed. :)

So, overall, I’m very glad I did it. But I want to make some changes. So, on to the what went wrong section.

What went wrong?

It’s costly

I loved the forcing function of writing daily. But the reality is that it is hard to always wake up at 5am and write.

Sleep is very important to me. Due to previous health issues, I try to prioritize sleep as much as possible, and my kids are also grateful when I’m not grumpy and tired. And though I wish I didn’t need as much sleep as I do, I think making sure I sleep well is the right trade-off.

I also have a bad habit of wanting to do too many things. So, as I was writing daily, I was also exploring new AI workflows, recording a couple of remote pairing sessions (which I’m still editing), and trying to get more information on how other teams are using AI. Oh, and I also had to do my regular consulting job. That’s a lot to fit into a single week.

So, even though I love writing daily, there are days when it is more important that I get an extra hour of sleep or that I edit a video.

I forgot to decouple deployments from releasing

Another huge problem was that by writing daily, I meant publishing daily.

In software, I always encourage teams to decouple deployments from releasing software to customers. We tend to use feature flags for that. That way, you can deploy whenever you want – ideally continuously. But you only release a feature when it’s ready.

Well, if I’d done that with writing, I could have written daily but only published when I felt ready. In that case, I might have felt differently about some of my posts.

Which brings me to the next point.

Some ideas need more space and time

Publishing daily meant I couldn’t fully work out some of the thornier ideas in my head.

Some writing just doesn’t fit into a single day – or into a single email, for that matter. Many thoughts are just complicated, and I feel like I have to untangle them before I can write about them.

I mean, that’s part of the beauty of writing: it forces you to work out those complicated topics until you can explain them simply. But because I had to publish something every day, I just couldn’t spend the time I needed on the thornier ideas.

So, publishing daily sometimes forced me to write about a simpler idea at the cost of refining a thornier one.

Posts are siloed

This is a good and a bad thing.

Because posts are not available in the general internet (unlike a blog post is), I felt more okay with publishing things that I wouldn’t have otherwise. I don’t mean that the posts were bad, but there’s an internal pressure when I publish a blog post that I have to make sure it’s really good because some unknown masses will read it.

In reality, for all I know, more people actually read the newsletter posts than my blog posts. But because the blog posts are “out there”, I feel that pressure. And that pressure can lead to not writing. So, the siloing can be a good thing.

But it’s definitely sad that they’re siloed.

I want to write to communicate with others. And I love blogs because to me they are part of the beautiful fabric of the internet. People sharing learnings, lessons, and ideas without gatekeeping. So, I’m a little sad that I have things written that live in emails and cannot be easily shared.

What could we improve?

Having said all that, I hope to make some tweaks.

I won’t continue to put the must-publish-daily pressure on myself. I wish I didn’t have to remove that (I like the forcing function), but I have to prioritize other things right now.

But that doesn’t mean I’ll stop writing!

On the contrary, I hope to continue to write more. I’ll still make 5am my writing time. It works most days. I just might not be able to hit it daily.

And I will continue writing in my newsletter. But I hope to publish a lot more to my blog as well. In a way, I would love it if I could write daily on my blog. That’s a bit wild, but I think it’s the ideal.

And I also hope to make my newsletter more of a 2-way channel.

I want to continue connecting directly with readers of the newsletter. That was one of my favorite parts of writing daily, so I’m really hoping I continue doing that.

Write to me or send me your blog!

Finally, some parting thoughts.

First, if you’re reading this, thanks for reading! Thank you for giving me some of your precious time.

Second, I encourage you to write more! (Make sure you write, not the robots!)

If you’d like a reader, send me an email and send me your blog. I love discovering new blogs to read.

Thinking about the extremes to break out of local maxima

2026-05-22T00:00:00+00:00

Thinking about the extremes is a powerful tool to help refine our intuition, unearth second-order effects, discover novel ways of doing things, and generally find alternate solutions to problems when we’re stuck.

Think of it like this: you’re a person trying to climb a hill.

One way to do that is to take a step in any direction. If you discover that the next step is higher than your previous one, great! You’re making progress.

You repeat that process over and over again, taking one step at a time. Each time, you check if you’re higher than before. If you are, you’re going uphill!

That’s marginal improvement, and it’s typically good. After only a finite number of steps, you’ll reach the top of the hill.

But once you’re at the top, any step you take will be a step downhill. You’ve reached a maximum.

How can you reach higher places? You can’t use the same “one small step” mentality. You actually need to change your approach.

And that’s where thinking about extremes can be helpful.

It’s only by thinking, “how can I climb Mount Everest?” that you realize you might need to get on a plane and fly to Nepal.

I think the same is true in business and software development. You can often get very far by making the next marginal improvement. One step at a time is good! You might even reach some heights. But at some point, you’ll likely get stuck in a local maximum. And it’s at that point that thinking about the extremes can help.

Consider this example. If you’re only trying to grow your revenue by 3% this year, you’ll probably focus on marginal improvements. But if you start thinking about how you can double or triple your revenue this year, you’ll come up with some wild, new ideas because you have to. There’s no other way to reach that goal.

Or think about query optimization in software development. You might try to optimize the query as much as possible. But at some point, you can’t make it any faster (you’ve hit a local minimum). If you think about the extreme you might ask, what if we could avoid making the database call altogether? You might discover a way to support the feature without that query or a different way to get the same information.

Steady progress is good and important. But every once in a while, you get stuck. That’s a good time to start thinking about the extremes.

Pair-programming is a cheat code

2026-05-01T00:00:00+00:00

I had that written on my office whiteboard for a while last year.

I had just finished working with a client for over a year where the whole team pair-programmed full-time (we also did a lot of mobbing).

I was then starting work with a new client, and I wanted to remind myself to push for pair-programming as much as possible because it is a cheat code for developers AND for businesses.

Here are some of “cheats” pair-programming gives you.

Pair-programming increases decision speed

I think this is one of the most underrated benefits of pair-programming.

When we’re building software, there are countless decisions we have to make. Those decisions take time. And frequently, they take coordination across teams. That’s really costly.

And those decisions tend to have ramifications that compound.

It’s typically cheaper for a business to change course early in the feature-development lifecycle. So, you want to arrive at the right decision as early as possible. With pair-programming, you have two people with full context able to bounce ideas off each other, challenge assumptions, and refine solutions quickly.

Compare that to finishing your feature, opening a pull-request, and waiting a few hours (or days) for someone to then question a piece of work. You go back and forth on alternatives (what you would’ve done with a pair at the moment you were coding that thing), and finally, you have to rewrite large pieces of the code because the decision made early informed the design of the whole feature.

Code-review is done in real-time with full context

It’s sad that most companies have a culture of doing code-review through pull-requests. GitHub has been a huge influence in that. And it’s a great model for low-trust environments (where PR author and reviewer don’t know each other). There’s high friction, and that’s a good thing.

But your company should be a high-trust environment. You know your team. You sync with them daily! So, to do code-review in the same slow, async way we do with open-source code seems suboptimal.

And when you’re reviewing a pull-request, you’re often missing context for the work that’s being done, decisions made along the way, and sometimes why the team is even building a given feature. So, as the reviewer, you have to either gain a lot of context to review the code well, or your review is worse than it would be if you had all that context.

Well, do you know who has all that context? The pair. And the pair can review the code as they write it.

That doesn’t mean others can’t look at the code. If you’re working on something gnarly that you want more eyes on, you can always tap another pair and ask them to do a review on a call. All of a sudden you have 4 people (2 pairs) reviewing the code while it’s being written. Very effective and efficient.

Knowledge transfer happens naturally

In programming, we’re always talking about the bus factor or domain knowledge silos. We don’t want a single developer to “own” a piece of code, and if they leave the company, get sick, or get hit by a bus, nobody else knows how to touch it.

(Also, note that they’re likely the only person who can review PRs related to that area of the codebase. Makes that PR problem even worse!)

So, teams tend to need to put a lot of effort into artifacts (documentation, videos, etc.) that can share that knowledge with other developers in case that bus really comes.

But documentation is costly and at best a proxy. Usually, it’s out of date and incomplete.

The code is the source of truth and the full specification of what our application currently does. So, it would be nice if we could rely on that. Of course, it takes time for people to gain knowledge of a particular domain in the codebase.

That’s where switching pairs frequently helps tremendously.

If you frequently switch who you pair with, that siloed context is immediately spread out across the team. The more you switch pairs, the more the context spreads. You don’t have to do anything special (other than rotate pairs).

Pair-programming is the best way to teach junior developers

And since sharing context is so easy with pair-programming, it’s also one of the best ways to teach junior developers. I’ve seen junior developers get good at an alarmingly fast pace. And they’ll ask the best questions, questions that frankly make you (the senior developer) better at your craft.

Pair-programming helps developers learn better ways to work and solve problems

The previous point leads to this one.

When you’re pair-programming, people have insight into how you work, not just the final code in a pull-request. That is phenomenal for two reasons:

a) Others learn from things you do. Things they didn’t even know were possible! It opens minds to whole new categories.
b) You learn from questions your pair asks! It’s amazing how a simple question can lead you to realize you haven’t re-evaluated the best way to solve a problem in many years.

(And note that we’re all switching between (a) and (b) all the time. I learn from you and you learn from me. And we both ask questions of each other.)

Is it still useful in an AI world?

Yes, yes it is!

Programming with AI is changing rapidly. How can your team learn to use these new tools as fast as possible?

I think there’s no better way to do that (and to develop best practices) than to pair a lot and rotate pairs frequently.

Think about it the other way. The more you silo information by not pairing, the slower the spread of knowledge and good practices. So, pair-programming is even more (not less) useful in this world full of LLMs.

Give it a try

There are more reasons why pair-programming is a cheat code, but hopefully those are good enough to give you a taste of the value it can bring to your team.

If your team doesn’t do pair-programming, I encourage you to give it a real try. Read a little about how to do it well (and there are ways to do it well and ways to do it poorly). And stick with it. It’s a skill that needs to be learned, so don’t expect to be immediately proficient at it.