DEV Community: Benjamin Cane

Generating Code Faster Is Only Valuable If You Can Validate Every Change With Confidence

Benjamin Cane — Fri, 27 Mar 2026 00:00:00 +0000

Generating code faster is only valuable if you can validate every change with confidence.

Software engineering has never really been about writing code. Coding is often the easy part.

Testing is harder, and many teams struggle with it.

As tools make it easier to generate code quickly, that gap widens. If you can produce changes faster than you can validate them, you eventually create more code than you can safely operate.

Which begs the question: What does good testing actually look like?

🔍 What Good Looks Like

One of the biggest challenges I see is that teams struggle to understand what “good” testing means and never define it.

Pipelines are often built early in a project, when the team is small, and they rarely keep pace with the system and organization as they grow.

My starting principle is simple:

At pull request time, you should have strong confidence that the change will not break the service or platform being modified.
Within a day of merging, you should have strong confidence that the change hasn’t broken the full customer journey that the platform supports.

🔁 On Pull Request

For backend platforms, I like to see three levels of automated testing before merging.

Code Tests (Unit Tests)

This level is the foundation. Unit tests validate internal logic, error handling, and edge cases. Techniques such as fuzz testing and benchmarking also reveal issues early. As the test pyramid tells us, this is where the majority of testing and logic validation should take place.

Service-Level Functional Tests

Too many teams stop at unit tests for pull requests. Functional tests should also be run in CI for every pull request.

Services should be tested in isolation with functional tests. Dependencies can be mocked, but things like databases should ideally run for real (Dockerized).

This is where API contracts are validated and regressions can be identified without wondering whether the issue came from this change or another service.

Platform-Level Functional Tests

Testing a service alone isn’t enough. Changes can break upstream or downstream dependencies. Platform-level tests spin up the entire platform in CI and validate that services interact correctly.

These tests ensure the platform continues to work as a system.

For platforms with strict latency or resiliency requirements, I recommend introducing light stress tests at both the service and platform levels. These aren’t full performance tests, but they act as early indicators of performance regressions.

If these three layers pass, you should have high confidence in the change. But not complete confidence.

🌙 Nightly Testing

Some failures take time to appear.

Memory leaks, performance degradation, and cross-platform integration issues may not show up immediately.

That’s why I like to run a nightly build (or every few hours).

This environment runs end-to-end customer journey tests, performance tests, and chaos tests.

These are typically the same tests used during release validation, but running them continuously accelerates feedback. If something breaks, you learn about it early, before the pressure of a release.

🧠 Final Thoughts

There is no universal approach everyone can follow.

Different systems have different needs; mission-critical systems may focus heavily on correctness and resilience. Non-mission-critical systems may focus more on validating core functionality.

Your testing strategy depends heavily on architecture, dependencies, and operational constraints. But if your organization is increasing its ability to generate code quickly, your testing capabilities must evolve at the same pace.

AI-generated code becomes much easier to review when you already have high confidence in your testing.

When You Go to Production with gRPC, Make Sure You’ve Solved Load Distribution First

Benjamin Cane — Fri, 20 Mar 2026 00:00:00 +0000

When you go to production with gRPC, make sure you’ve solved load distribution first.

I was recently talking with another engineer who is rolling out gRPC into production. He asked what the biggest gotchas were.

My first answer: Load Distribution.

🚦 HTTP/1 vs. HTTP/2

Most teams first implement services using REST over HTTP/1 and then migrate to gRPC as they seek its performance benefits.

That shift introduces a subtle but important change in how traffic gets distributed across instances.

With HTTP/1, requests are generally tied closely to connections. A client opens a connection, sends a request, waits for the response, and then sends another (if connection re-use is enabled).

HTTP/2 (which underpins gRPC) works differently.

HTTP/2 multiplexes requests over persistent connections. A client can send many requests over the same connection without waiting for responses.

This is one of the reasons gRPC provides a performance boost, but it can create unexpected load distribution issues.

If your infrastructure isn’t built for an HTTP/2 world, you’ll quickly find traffic becoming unevenly distributed.

🏗️ Infrastructure Support

In an HTTP/1 world, load balancing at the connection (Layer 4) level often works well enough. But with HTTP/2, connections live much longer and carry far more concurrent traffic.

If your load balancer distributes traffic based only on connections, a busy client may hammer a single instance while others sit idle.

Unfortunately, much of the infrastructure still doesn’t fully support HTTP/2-aware load balancing.

Depending on your environment, your load balancers or ingress controllers may operate primarily at Layer 4. That works fine for HTTP/1, but once you introduce HTTP/2 via gRPC, the effectiveness changes significantly.

⚙️ Supporting gRPC

To get the most out of gRPC, the best approach is to use infrastructure that understands HTTP/2 and load-balances requests rather than just connections.

If that’s not possible, another option is client-side load balancing.

Many gRPC clients support opening a pool of connections and distributing requests across them. You still benefit from HTTP/2’s persistent connections, but you avoid concentrating all traffic on a single backend instance.

🧠 Final Thoughts

gRPC offers many advantages, including performance, strongly typed contracts, and efficient communication. But it also introduces different networking behavior.

If you’re rolling out gRPC into production, make sure your load balancing infrastructure is ready for an HTTP/2 world.

You may be building for availability, but are you building for resiliency?

Benjamin Cane — Fri, 13 Mar 2026 00:00:00 +0000

You may be building for availability, but are you building for resiliency? Many teams design for availability. Far fewer design for resiliency.

A concept that took me a while to really grasp is that building highly available systems and highly resilient systems is not the same thing.

The difference is how the system reacts to failure.

🚄 High Availability

When you build for high availability, the goal is simple: ensure there is always another path.

If something fails, traffic can be redirected somewhere else.

For example, a service might run across multiple availability zones or regions. If one fails, traffic is routed to another.

Detecting failures and redirecting traffic are core elements of building for high availability.

Availability is about rerouting traffic when something fails.

🚂 High Resiliency

Building for resiliency is different.

The solution to failure isn’t another path; it’s how the system handles the error.

When a dependency fails, the decision becomes:

Do we retry? Do we continue without that dependency? Do we degrade functionality? Do we stop processing altogether?

Resiliency is about defining what happens when things go wrong.

Sometimes you can continue processing. Sometimes you can defer work and fix it later.

Resiliency is absorbing failure instead of avoiding it.

🧩 A Simple Example

When you design systems with resiliency in mind, you tend to treat dependencies differently.

A simple example is configuration.

Many systems use distributed configuration services so that runtime behavior can change without redeployment.

But that configuration service then becomes a dependency. To avoid turning it into a hard dependency, many systems cache the configuration in memory.

When updates occur, the system fetches the new configuration and switches only after it’s fully loaded into memory.

If configuration refresh fails, the system continues operating with the last known configuration. Transient failures don’t bring the system down.

That’s resiliency.

🧠 Final Thoughts

When I talk about non-functional requirements, you’ll hear me say:

“Highly available and resilient systems”

I separate them intentionally because the approaches are different.

Availability ensures there is always another path. Resiliency ensures the system can continue operating when failures occur.

Availability routes around failure. Resiliency survives failure. You need both.

When your coding agent doesn’t understand your project, you’ll get junk

Benjamin Cane — Fri, 06 Mar 2026 00:00:00 +0000

When your coding agent doesn’t understand your project, you’ll get junk.

Junk in, junk out.

One of the best ways to get more from agentic coding tools is to give the agent context.

The more an agent understands your project, the better its work will be.

If you ask an agent to add a method to a class, it will. It might read the file. It might infer some structure. But it won’t understand the project's intent.

If you asked a human engineer to make the same change, they would have questions.

What is the purpose of this project? How is it used? What constraints exist?

If they skipped that step, you’d get exactly what you asked for, even if it was wrong.

That’s the same challenge many face with coding agents. A lack of context means it only does what it’s told — which isn’t always what you actually need.

But when it understands a project, it operates with far more clarity.

🧙‍♂️ My “Old School” Method

Before I start serious work with an agent, I have it learn the project.

Read the docs 📚 Review the codebase ⚙️ Understand the architecture 🏙️ Learn how to build, test, and run the project locally 👩‍🔧

I even ask the agent to summarize its understanding back to me.

This started as a saved prompt, turned into a slash command, and is now a skill.

This step is a huge productivity boost.

🤖 Agents Files (`AGENTS.md`)

Over the past year, an open standard for providing agents with structured context has emerged.

Instead of prompting the agent to rediscover your project every time, document that context once — and the agent will reference it going forward.

Most modern agents support an Agents.md file and reference it during each interaction.

💽 What Goes in an Agents File?

Think of the Agents file as onboarding documentation, but for an agent.

Project context:

Purpose
Architecture
Layout
CI/CD instructions

Team context:

Code style preferences
Testing philosophy (TDD or YOLO)
Tech stack constraints

Any tribal knowledge you’d expect a new team member to learn belongs in an Agents file.

👨‍💻 Personal Agent Files

Many tools also support a personal Agents file in your home directory.

That’s where your workflow preferences live. Are you a two-space tabs person? Do you want your agent to prefer table tests?

If you have preferences you want to apply to every project, but are unique to you, they go in the personal Agents file.

🧠 Final Thoughts

Using an Agents file dramatically improves agent quality.

Even then, I still use my “learn-this” slash command — sometimes that extra context makes a difference.

If you wouldn’t drop a new engineer into a project without context, don’t do it to your agents.

You can have 100% Code Coverage and still have ticking time bombs in your code. 💣

Benjamin Cane — Fri, 27 Feb 2026 00:00:00 +0000

You can have 100% Code Coverage and still have ticking time bombs in your code. 💣

I was listening to a team recently, and an engineer was discussing how a coding agent added additional tests to a project that already had 100% code coverage.

The conversation reminded me that coverage is directional and often mistaken for quality. Just because your coverage shows 100% doesn’t mean your software is fully tested.

👨‍🏫 Understanding How Coverage Is Measured

Code Coverage measures the percentage of executable lines that run during code tests. Executed doesn’t mean well-tested.

Just because every function runs doesn’t mean it’s free of logic errors or safe.

😃 Happy Path Testing

A common challenge teams face with testing is focusing too much on the happy path.

Suppose you have a function that accepts an array. In your tests, you always pass 5 elements — because that’s the expected usage. Coverage shows all branches executed. You’re good, right?

What happens if you pass 4 elements? Or 0?

If you never test fewer than 5, how do you know? You may say: “But wait, it’s only ever called with 5 elements.” That may be true, for now.

⚠️ Protecting Against Your Future Self

Code is rarely static; someone will come along and change things. That might be you, it might be someone else.

Eventually someone changes that function. Will they add tests for new edge cases? Maybe. Assume they won’t.

When you write tests, don’t just focus on how you know a function is going to be used; also include tests that misuse the function.

Rather than sending an array with 5 elements, send one with 4, 0, and send a nil value.

Rather than sending strings that match an expected pattern, send junk that doesn’t.

Does the function still behave correctly? Should it?

The more you test outside the happy path, the more resilient your code becomes — and the less likely it is to break later.

🧠 Final Thoughts

Code coverage is a guide, don’t let it give you false confidence. Test the happy path, and the unexpected ones. Validate function outputs against the input you provide.

100% Coverage is easy. Writing reliable code is not.

Getting More Out of Agentic Coding Tools

Benjamin Cane — Fri, 20 Feb 2026 00:00:00 +0000

Are you getting the most out of Agentic Coding Tools?

Software engineering is changing fast.

Agentic coding tools became widely available last year, and if you’re not using them today, you’re already behind. But many still struggle to move beyond the “fancy chat” experience.

Just like any tool in our engineering tool belts, knowing how to use it effectively matters.

🤖 Agents Are More Than A Better Chat

Last year, most were using tab-complete with a useful chat interface where you could ask questions, get suggestions, and maybe copy/paste into your code.

But agents can do much more than make suggestions — they can understand your codebase and act.

Instead of asking an agent:

“Can you suggest additional tests?”

Tell your agent:

“Create additional test cases, then run make tests and validate they pass.”

An agent can create tests, run them, inspect failures, adjust the implementation, and re-run the suite until it passes.

This isn’t about suggestions anymore; agents have more autonomy.

I think of coding agents as assistants working toward a shared goal. They do some work, you do some, and you iterate together.

🏆 Moving from Direction to Outcomes

A big mental shift is moving away from simple directions to defining an outcome with guidance & guardrails.

Agents don’t just perform a single task; they can execute multiple steps (and even parallelize them). You don’t need to spoon-feed each directive one by one.

Instead, define the outcome you want, along with guidance and guardrails.

The clearer you are on the outcomes, constraints, and context around what you are trying to do, the better the agent will perform.

📋 Examples: Real-world tasks I’ve asked Agents to handle

“Using the existing DB Driver X as a reference, create a set of table tests for driver Y. The tests should be structured similarly to the existing driver, surface any logic issues, concurrency issues, and act as a clear insurance against the defined interface.”

“Update CI workflows to Go 1.26.0, find and update any references to 1.25.6, then run tests to ensure everything still builds and passes”

I also use agents for mundane work like git commits and opening pull requests. They consistently produce better commit messages and PR descriptions than I would.

Agents don’t always get it exactly right, but with a bit of feedback and occasional adjustment, you can get a lot done quickly.

Avoid going down the rabbit hole of endless refinement, sometimes it’s better to reset with a clearer prompt.

👨‍🏫 Context is Key

If you want the best results from agents, you need to give them context.

Before I do serious work on a project, I have the agent:

Read the Docs 📚
Review the Architecture 🏙️
Understand the Project Structure 📐
Understand how to build, test, and run the application locally 👩‍🔧

The same steps that a human would take. Agents are no different.

(I’ll dive deeper into Agent files, skills, and effective ways to provide more context in a future post)

🧠 Final Thoughts

Engineers are doing amazing things with agents, and new capabilities are being added daily. But you don’t need to be at the bleeding edge to get more out of them (I certainly am not).

Don’t worry about the hype. Understand what these tools can do, making small adjustments in how you use them can drastically change what you get back.

Why is Infrastructure-as-Code so important? Hint: It's correctness

Benjamin Cane — Fri, 13 Feb 2026 00:00:00 +0000

Why is Infrastructure-as-Code so important? Hint: It's correctness.

I’ve worked on many systems in my career, and one thing that I’ve noticed is that those that leverage infrastructure-as-code tend to be more stable than those that don’t.

🤔 But wait, isn’t everyone using IaC these days?

You may be thinking, "Why am I talking about IaC in 2026? Isn’t this just the de facto standard at this point?"

My hope is yes, everyone does this, but I’m sure many don’t invest the time into it.

I’m not here to tell you to use IaC; I’m here to tell you why it’s important, and it’s not necessarily about the speed of deployment.

🏎️ Fast is great, but it’s not the biggest benefit

A very clear and correct reason people leverage IaC is the speed of infrastructure provisioning.

It’s much faster to provision infrastructure with IaC; it takes less time, enabling you to scale faster, and it lets you do cool things like ephemeral environments.

But the biggest benefit of IaC, in my mind, is correctness.

⚠️ IaC reduces human error

Humans make mistakes. When you ask humans to click the same buttons in the same sequence every time, you’ll get mixed results.

Steps get missed — especially when time passes or people rely on memory instead of process.

Documentation helps, but there are those of us who think, “I’ve done this a million times, I don’t need instructions.”

This attitude is the same reason one of my kid’s desks wobbles and the other one doesn’t…

IaC is a contract. Once defined, every environment is created from the same source of truth.

✅ Consistency is essential to production stability

The consistency of IaC is what brings production stability.

When your performance testing environment matches production, your tests become more accurate.

If one service has a larger memory footprint in testing than it does in production, you might find yourself surprised by out-of-memory errors, especially if heap sizes are configured based on your test environment and not your production environment (because, of course, they would be the same, right?).

When I come across platforms that use IaC, I see fewer mistakes and fewer incorrect assumptions. And production tends to be more stable, at least with respect to infrastructure and capacity-related issues.

🧠 Final Thoughts

So, to answer the question, why is IaC so important? It’s not the speed of provisioning; it’s the correctness of the environments.

In production systems, correctness beats speed every time.

Optimizing the team’s workflow can be more impactful than building business features

Benjamin Cane — Fri, 06 Feb 2026 00:00:00 +0000

Optimizing the team’s workflow can be more impactful than building business features. It defies logic, but it’s true.

I work with and talk to a lot of engineers, and to explain my point, I’ll describe two engineers on the same team.

💪 Engineer 1

The first engineer churns out a lot of code and user stories. They’re focused, consistently finishing on time, and often doing more than they’re assigned.

When it comes to shipping business features, this person does a great job.

But this person is also more than happy to let their build run for 3 hours.

🦾 Engineer 2

The second engineer completes their assigned user stories, but when they encounter inefficiencies, they spend time fixing them. Sometimes it’s improving the build pipeline, fixing flaky tests, making code more maintainable, etc.

While this engineer may finish fewer user stories because they are distracted by these “side quests,” they make a bigger impact.

🏋️ Enabling Others

While avoiding the 10x engineer trope, Engineer 2 has a bigger impact by resolving issues affecting the whole team.

A slow pipeline slows everyone’s work.

Open a single change, then wait 3 hours. A test fails—wait another 3 hours. Feedback comes in—wait 3 more.

Broken workflows turn simple changes into long, inefficient endeavors.

So fixing these not just for themselves but for everyone means the whole team can ship code faster.

📈 Invest in Workflows

Investing time in optimizing your workflow and the team’s workflow usually pays dividends.

Sometimes it’s hard to quantify, but the smallest optimizations can be huge.

Someone on the team who gets frustrated with inefficiencies and decides to fix them is incredibly valuable.

👩‍🔧 Do you take ownership of your codebase?

If you want to make a greater impact, look at how you work.

When you fix a bug, do you search the codebase for the same bug elsewhere?

When your build pipeline is slow, or you have flaky tests, do you fix them or live with them, complaining while nothing changes?

I follow an architecture principle I call The Law of Collective Amnesia

Benjamin Cane — Fri, 30 Jan 2026 00:00:00 +0000

I follow an architecture principle I call The Law of Collective Amnesia.

Over time, everyone (including yourself) forgets the original intention of the system's design as new requirements emerge.

This law applies at all levels, from system design to microservices, or even libraries.

🧬 Systems Evolve (and Intent Fades)

When building new platforms/services/whatever, we create a system design that follows a structure.

Different components have distinct responsibilities; they interact clearly with the rest of the system, and there is a plan.

But as time progresses, new people may not understand the original intentions of the design.

As new requirements come in, the pressure to deliver may push you or others down a path that doesn't align with the original plan.

When the architecture’s intent is understood, additions can be beneficial. When it’s forgotten, they start to feel duct-taped on.

Duct-taped solutions turn into technical debt or operational/management complexity that starts to weigh the system down.

📠 How Good Systems Become Legacy Nightmares

We've all seen the legacy platform that feels brittle, does too much, and is daunting to refactor.

It didn't start that way.

At the time, it was probably a great design, but over time, new features and capabilities turned it into Frankenstein's monster.

👮 How to Defend Architecture from Collective Amnesia

While it may not be possible to prevent the system from devolving forever, you can reduce the need for duct tape solutions by designing for change.

📜 Roles and Responsibilities

An important—but not always effective—step is to document and define the roles and responsibilities of components within the system.

When a system is broken down into components with distinct roles and responsibilities, it becomes easier for people to make informed decisions about where new capabilities should reside.

The documentation “should” influence how change is implemented.

But it relies on people following that documentation, which is the fundamental flaw.

🚧 Architectural Guardrails: Make the Right Path the Easy Path

When I say "architectural guardrails," you probably think of review boards and ADRs. These processes are essential, but they don't always work as a prevention.

Instead, I mean designing the system so that the correct placement of functionality is the path of least resistance.

🔏 Contracts as Constraints, Not Convenience

In general, I feel like back-end APIs should provide as much data as possible, and it should be up to the clients to use what's relevant.

But sometimes contracts can be used to enforce design behaviors.

Systems can't act unless they receive the data required to act.

🚪 Control Ingress and Egress to Control Evolution

Ensuring that only specific systems serve as entry and exit points helps direct future design decisions.

It's often easier to add a new endpoint than to add a new platform that serves as an entry point.

Knowing this can allow you to put in place processing at those entry and exit points that ensure future capabilities follow specific patterns.

🧩 Design for Change, Not Today’s Requirements

When you are first building a system, it's easy to want to make it quickly based on the requirements in front of you.

But when you know a platform will evolve, it's beneficial to take time and implement interfaces that make the system more modular.

Within a microservice, this can be how you structure the application, how you create packages that can be extended even though you don't need them day one.

At a platform level, it could be the decision between monolith and microservices. If you know there will be a rapid change, it may make sense to leverage microservices. If you know there won't be a fast change, start with a monolith.

🧠 Final Thoughts: Assume Intent Will Be Forgotten

The above examples are just a subset of the ways you can enforce a design that aligns with your intentions.

The key lesson: don't build a plan that relies on people to follow your intentions. They won't.

You have to assume the next person won't design systems the way you do, they won't understand the reasons behind your design, and they'll be under pressure to deliver.

Performance testing without a target is like running a race with no finish line

Benjamin Cane — Fri, 23 Jan 2026 00:00:00 +0000

Performance testing without a target is like running a race with no finish line.

Did you win or did you stop early?

I previously shared my thoughts on benchmark and endurance tests, but before ever running a test, a target must be defined.

🎯 Why Set Targets?

Without a target, how do you know what good looks like?

I've often come across teams that have incorporated performance testing into their releases (which is excellent). But they had no targets defined.

No production baseline.

No service-level objectives from the business.

_How did they know whether the system was meeting expectations?_They didn't.

In some cases, after targets were defined, the system was performing as needed.

In others, it clearly wasn't, and the team had no idea until targets were defined and compared with production.

🏆 Defining Targets

It's easier to define targets for existing systems (and modernization projects) than for a brand-new system.

Existing platforms have production numbers you can reference, user expectations, and service-level objectives that can be translated into performance targets.

New systems rarely have much to baseline from.

For a brand-new system, I like to work with the product/business team and understand their goals.

- 📈 What is the expected growth? Slow and steady, or fast and unpredictable?

- 🚨 What is the criticality of the platform? If it fails to respond, is it a problem or an inconvenience?

- 🌟 What unique constraints or features of the platform might influence performance requirements?

Once defined, targets should not be treated as static.

As traffic starts, you can adjust targets accordingly. Maybe it's higher, perhaps it's lower.

🪫 Leave Some Buffer

Once a target is agreed upon, I like to add a bit of buffer.

If the requirement is 100ms, I’ll target closer to 75ms, or lower, depending on the system and its purpose.

_Why?_Adding capacity or tuning the system takes time.

Things change, sometimes in unexpected ways.

Sometimes unexpected changes can be handled by automatic/manual scaling, but not always.

It's important to give yourself a bit of buffer to respond to those changes.

🧠 Final Thoughts

I've talked a lot about setting targets and their importance. But one of the most important aspects of having targets is monitoring and measuring production.

Having visibility in production helps validate that your targets are realistic.

Maybe they are too high, and you have wasted infrastructure reserved.

Perhaps they are too low, and you won't be able to survive the next traffic spike.

Traffic changes over time, and application performance naturally drifts as new capabilities are added.

Clear visibility into traffic and latency patterns is essential for anyone operating mission-critical, large-scale systems.

But also a foundational practice for most platforms.

Do you have performance targets for your platform? Is it grounded in production measurements? Should you?

Many teams think performance testing means throwing traffic at a system until it breaks.

Benjamin Cane — Fri, 16 Jan 2026 00:00:00 +0000

Many teams think performance testing means throwing traffic at a system until it breaks. That approach is fine, but it misses how systems are actually stressed in the real world.

The approach I’ve found most effective is to split performance testing into two distinct categories:

🏋️‍♀️ Benchmark testing
🚣‍♀️ Endurance testing

Both stress the system, but they answer different questions.

🏋️‍♀️ Benchmark Testing:

Benchmark tests are where most teams start: increasing load until the system fails.

Failure might mean:

⏱️ Latency SLAs are exceeded
⚠️ Error rates cross acceptable thresholds

Sometimes failure is measured by when the system stops responding entirely. This is known as breakpoint testing.

Even when SLAs are the target, I recommend running breakpoint tests after thresholds are exceeded.

Knowing how the system breaks under load is useful when dealing with the uncertainties of production.

🚣‍♀️ Endurance Testing:

Endurance tests answer a different question:

Can the system sustain high load over time?

Running at high but realistic levels (often near production max) over extended periods exposes different problems:

🪣 Queues, file systems, and databases slowly fill
🧹 Garbage collection and thread pools behave differently
🧵 Memory or thread leaks become visible

These issues rarely show up in short spikes of traffic. If you only run benchmarks, you’ll discover them for the first time in production.

⌛️ Testing Thoroughly vs Deployment Speed:

Benchmarks run fast; Endurance testing takes time.

A 24-hour endurance test can slow down releases, especially when you want to release the same service multiple times a day.

It's a trade-off between the system's criticality and the need for rapid deployments.

How tolerant is the system to minor performance regressions?

If performance truly matters, slowing releases down to run endurance tests might be the right call.

🧠 Final Thoughts:

Effective performance testing isn’t just about surviving spikes.

Spikes matter, but so does answering:

📈 Can the system withstand peak load for extended periods?
🔎 If not, how does it fail, and why?

All too often, I see the system's capacity become the breaking point during unexpected traffic patterns.

While an application might handle spikes, the overall platform often can't sustain them. That's where endurance tests deliver their real value.

Pre-populating caches is a “bolt-on” cache-optimization I've used successfully in many systems. It works, but it adds complexity

Benjamin Cane — Fri, 09 Jan 2026 00:00:00 +0000

Pre-populating caches is a “bolt-on” cache-optimization I've used successfully in many systems.

It works, but it adds complexity , which is why most teams avoid it.

📖 Context

For context, in this post, I’m talking about scenarios where one system requires data from another system, I.E., the _source of record (SOR)._The data is needed frequently, and the decision to cache has already been made.

A good traditional approach is the cache-aside pattern, which maintains a local cache of data.

That cache is populated organically by checking for records as needed, finding that the data is not cached, fetching it from the SOR, and storing the result.

A pro of this approach is that the cache is transient. If it's dropped, it's ok because you can always go back to the SOR, albeit with a performance penalty.

But slow is better than broken.

🤔 Why?

Calls to the SOR are problematic for low-latency or random-access workloads.

When 9 out of 10 requests all want the same data, you’ll have infrequent cache misses. But when 9 out of 10 requests all require different data, you’ll have more cache misses, which reduces the effectiveness of caching.

Pre-populating caches is a way to avoid those cache misses by trading off latency for complexity.

⚙️ How?

Caveat: I use pre-population purely as a bolt-on optimization, not a core dependency.

Typically, I keep the cache-aside path as the primary mechanism. If anything goes wrong (and it will), there is always the option to go to the SOR for data (slow > broken).

A key decision is whether to pull the data or listen for it.

I prefer the SOR publishes updates as they occur, but platform constraints or circumstances may require you to pull the data.

Pub/sub works great when the SOR publishes, but other options exist as well (webhooks, files) with their own trade-offs.

Use whatever makes sense for your environment.

⚠️ Why Not?

Implementing pre-populating a cache can be easier said than done, as a lot can go wrong.

What happens if you lose a message or two?

What happens when you’re rebuilding the cache (errors or new instances)?How do you repopulate?

The cache-aside will cover any dropped messages, but implementing republish mechanisms is complicated.

You can’t rely solely on deltas; at some point, you'll need to republish the entire dataset.

Building all of these systems is complicated; there's more to monitor, patch, and manage.

If the latency hit and traffic volume to the SOR are not a concern, then that complexity is not worth it.

🧠 Final Thoughts

Pre-populating caches can be a significant performance win , but it can also be an operational overhead.

If your data is primarily static (changing infrequently), the overhead can be worthwhile.

If your data changes frequently, stick with cache-aside (and aggressive TTLs), or no cache at all.

DEV Community: Benjamin Cane

Generating Code Faster Is Only Valuable If You Can Validate Every Change With Confidence

🔍 What Good Looks Like

🔁 On Pull Request

Code Tests (Unit Tests)

Service-Level Functional Tests

Platform-Level Functional Tests

🌙 Nightly Testing

🧠 Final Thoughts

When You Go to Production with gRPC, Make Sure You’ve Solved Load Distribution First

🚦 HTTP/1 vs. HTTP/2

🏗️ Infrastructure Support

⚙️ Supporting gRPC

🧠 Final Thoughts

You may be building for availability, but are you building for resiliency?

🚄 High Availability

🚂 High Resiliency

🧩 A Simple Example

🧠 Final Thoughts

When your coding agent doesn’t understand your project, you’ll get junk

🧙‍♂️ My “Old School” Method

🤖 Agents Files (AGENTS.md)

💽 What Goes in an Agents File?

👨‍💻 Personal Agent Files

🧠 Final Thoughts

You can have 100% Code Coverage and still have ticking time bombs in your code. 💣

👨‍🏫 Understanding How Coverage Is Measured

😃 Happy Path Testing

⚠️ Protecting Against Your Future Self

🧠 Final Thoughts

Getting More Out of Agentic Coding Tools

🤖 Agents Are More Than A Better Chat

🏆 Moving from Direction to Outcomes

📋 Examples: Real-world tasks I’ve asked Agents to handle

👨‍🏫 Context is Key

🧠 Final Thoughts

Why is Infrastructure-as-Code so important? Hint: It's correctness

🤔 But wait, isn’t everyone using IaC these days?

🏎️ Fast is great, but it’s not the biggest benefit

⚠️ IaC reduces human error

✅ Consistency is essential to production stability

🧠 Final Thoughts

Optimizing the team’s workflow can be more impactful than building business features

💪 Engineer 1

🦾 Engineer 2

🏋️ Enabling Others

📈 Invest in Workflows

👩‍🔧 Do you take ownership of your codebase?

I follow an architecture principle I call The Law of Collective Amnesia

🧬 Systems Evolve (and Intent Fades)

📠 How Good Systems Become Legacy Nightmares

👮 How to Defend Architecture from Collective Amnesia

📜 Roles and Responsibilities

🚧 Architectural Guardrails: Make the Right Path the Easy Path

🔏 Contracts as Constraints, Not Convenience

🚪 Control Ingress and Egress to Control Evolution

🧩 Design for Change, Not Today’s Requirements

🧠 Final Thoughts: Assume Intent Will Be Forgotten

Performance testing without a target is like running a race with no finish line

🎯 Why Set Targets?

🏆 Defining Targets

🪫 Leave Some Buffer

🧠 Final Thoughts

Many teams think performance testing means throwing traffic at a system until it breaks.

🏋️‍♀️ Benchmark Testing:

🚣‍♀️ Endurance Testing:

⌛️ Testing Thoroughly vs Deployment Speed:

🧠 Final Thoughts:

Pre-populating caches is a “bolt-on” cache-optimization I've used successfully in many systems. It works, but it adds complexity

📖 Context

🤔 Why?

⚙️ How?

⚠️ Why Not?

🧠 Final Thoughts

🤖 Agents Files (`AGENTS.md`)