DEV Community: Chisom Chima

What Are AI Agents and How Are They Changing Software Development?

Chisom Chima — Mon, 27 Apr 2026 15:05:42 +0000

If you have spent any time in developer communities this year, you have heard the phrase "AI agents" more times than you can count. It gets thrown around in product announcements, conference talks, LinkedIn posts, and job descriptions. Most of the time it sounds impressive and stays vague.

This post is going to make it concrete. Not because the buzzword matters, but because what it describes is genuinely changing the way software gets built, and understanding it will help you use these tools more effectively whether you are a junior developer or a seasoned engineer.

Start Here: What an AI Agent Actually Is

Most people's first experience with AI in software development is a tool like GitHub Copilot or Claude in a chat window. You write a prompt, you get a response, you copy what you need and move on. The AI reacts to one input at a time and then stops. That is not an agent. That is just a very good autocomplete.

An AI agent is different in one fundamental way: it can take a sequence of actions over time to accomplish a goal, not just respond to a single prompt.

Here is a simple analogy. Imagine you hire a new intern. You can use them in two ways.

The first way: every time you need something done, you walk over to their desk, describe the exact task, watch them do it, and walk away. They do exactly what you asked, nothing more.

The second way: you give them a goal, something like "research our three biggest competitors and put together a comparison doc by Friday," and they figure out the steps themselves. They search the web, read product pages, take notes, organize information, ask you a clarifying question when they hit something ambiguous, and come back with the finished work.

The first version is a regular AI assistant. The second version is closer to an agent.

The technical definition most researchers use: an agent is a system that perceives its environment, makes decisions, takes actions, and updates its behavior based on the results of those actions, in a loop, until the goal is achieved or the task is complete.

The Four Things That Make Something an Agent

There are four capabilities that separate an agent from a regular AI model. Understanding these individually makes the whole concept much clearer.

1. A Goal, Not Just a Prompt

A regular AI interaction is one round: input in, output out. An agent works toward a goal across multiple steps. The goal might be "fix the failing tests in this repository" or "find all the API endpoints that are not covered by contract tests and write the missing ones."

The goal is bigger than any single prompt, and the agent has to break it down into smaller actions on its own.

2. Tools

To accomplish goals in the real world, agents need to be able to do things, not just produce text. Tools are how they do this.

A tool is anything an agent can call to interact with the outside world. Common examples include a web search tool to find information, a code execution tool to run code and see the output, a file system tool to read and write files, an API calling tool to interact with external services, and a browser tool to navigate websites and click things.

When an agent has access to tools, it can take actions that have real effects. It is not just generating text. It is executing code, reading files, searching the web, and modifying things based on what it finds.

3. Memory

An agent needs to keep track of what it has done and what it has learned as it works through a task. This is what allows it to build on previous steps rather than starting fresh with every action.

There are different kinds of memory in agent systems. Short-term memory is the conversation history, essentially everything that has happened in the current session. Long-term memory might involve writing notes to a file or database that can be retrieved later. Some agent systems maintain a scratchpad where they work through intermediate reasoning before taking an action.

Without memory, an agent would repeat itself, contradict its previous actions, or lose track of where it is in a multi-step task.

4. Feedback Loops

This is what makes agents genuinely different from one-shot AI responses. After taking an action, an agent observes what happened and uses that observation to decide what to do next.

Run a test suite and three tests fail. Read the failure output. Identify which files need to be changed. Make the changes. Run the tests again. Observe the result. Continue.

This loop of action, observation, and adjustment is what allows agents to handle tasks that cannot be solved in a single step.

A Concrete Example: An Agent Fixing a Bug

Abstract explanations only go so far. Here is what an agent actually does when given a task like "fix the broken tests in this repo."

Step 1: The agent reads the task and decides its first action is to understand the current state. It runs the test suite.

Action: run_tests()
Result: 3 tests failing
  - test_user_authentication (auth.test.js)
  - test_checkout_flow (checkout.test.js)
  - test_order_creation (orders.test.js)

Step 2: The agent reads the failure output for the first test and inspects the relevant source file.

Action: read_file("auth.test.js")
Action: read_file("auth.js")
Observation: The test expects a field called "userId" in the JWT payload,
             but the auth module now returns "user_id" (snake_case).
             This is a naming inconsistency introduced in a recent refactor.

Step 3: The agent decides how to fix it. Rather than changing the test, which describes the intended behavior, it updates the source code to match.

Action: edit_file("auth.js", change "user_id" to "userId" in JWT payload)

Step 4: It re-runs just the affected test to confirm the fix worked.

Action: run_tests("auth.test.js")
Result: 1 test passing

Step 5: It moves to the next failing test and repeats the process.

This loop continues until all tests pass or the agent hits something it cannot resolve on its own, at which point a well-designed agent system surfaces the problem to a human with enough context to make a decision.

What just happened here would have taken a human developer 15 to 20 minutes. The agent did it in seconds, without being told exactly what the problem was or how to fix it.

Multi-Agent Systems: When One Is Not Enough

Individual agents are useful. Multiple agents working together are where things get genuinely powerful, and where a lot of the current industry excitement is focused.

The idea is straightforward: instead of one agent trying to do everything, you have several specialized agents, each responsible for a specific part of a workflow.

Think about how a software team is organized. You have developers who write code, reviewers who check it, QA engineers who test it, and ops engineers who deploy it. Each role has specialized knowledge and a specific responsibility. Multi-agent systems work the same way.

Here is an example architecture for an automated code review pipeline:

New Pull Request Created
        |
        v
[Summarizer Agent]
Reads the diff and writes a plain-English summary
of what changed and why
        |
        v
[Security Agent]
Checks for common vulnerabilities: SQL injection,
unvalidated inputs, hardcoded secrets
        |
        v
[Test Coverage Agent]
Identifies new code paths that lack test coverage
and suggests test cases
        |
        v
[Style Agent]
Flags deviations from the team's coding conventions
        |
        v
[Coordinator Agent]
Assembles all findings into a structured review comment
and posts it on the pull request

No single agent in this pipeline knows how to do everything. But together, they produce a code review that would take a senior engineer 30 to 45 minutes, in about 90 seconds.

Teams using multi-agent setups in their CI pipelines are already reporting measurably fewer bugs reaching production and significantly faster review cycles. This is not a theoretical benefit. People are seeing it in practice right now.

How This Is Already Changing Software Development

This is not a future prediction. It is happening now, and developers who are paying attention are already adapting.

Testing is the most immediate impact area. Agents can generate test cases for new code, run them, identify gaps in coverage, and write additional tests, all without a human specifying what to test. For teams that historically undertest because testing is tedious, this removes the biggest friction point.

Code review is getting faster and more consistent. Human reviewers are good at catching logic bugs and architectural problems. They tend to be inconsistent and slow at checking style, security patterns, and coverage. Agents are better at the systematic, rule-based checking and are available instantly. The best setups use both, and they complement each other well.

Boilerplate and scaffolding are disappearing as manual tasks. Setting up a new API endpoint used to mean writing a route, a controller, a service, a repository, a DTO, a test file, and a migration, often copying the same structure from elsewhere in the codebase. An agent can do all of that from a single description: "add an endpoint to create a new order, following the same patterns as the existing checkout endpoint."

Documentation is finally getting written. Nobody genuinely enjoys writing documentation. Agents will do it without complaining, keep it in sync with code changes, and generate it in whatever format your team needs.

What Agents Cannot Do Yet

It is worth being honest about the limitations because the hype often obscures them.

Agents struggle with ambiguity. When a task is underspecified or the requirements are contradictory, an agent will often make a confident choice that turns out to be wrong. A human developer would ask a clarifying question. Getting agents to know when to stop and ask for help rather than plowing ahead incorrectly is still an active area of research.

They also struggle with tasks that require deep contextual understanding of a codebase. An agent can read files and understand patterns locally, but reasoning about why an architectural decision was made three years ago, or understanding unwritten team conventions, is much harder. This is improving with longer context windows, but it is still a real limitation.

There is also the issue of compounding errors. In a multi-step task, a wrong decision early on can propagate and cause cascading problems further down the line. Humans catch this through intuition and experience. Agents need to be explicitly designed to validate their intermediate outputs and backtrack when something looks wrong.

The practical takeaway: agents work best on well-defined tasks with clear success criteria that can be verified automatically. "Make the tests pass" is a great agent task. "Make this codebase more maintainable" is not, at least not yet.

How to Actually Start Using Agents Today

You do not need to build anything from scratch to start benefiting from this shift.

Claude Code is one of the most capable agentic coding tools available right now. Give it a task in natural language, something like "refactor this module to use async/await" or "write integration tests for this API" or "find all places where we're not handling errors and add proper error boundaries," and it works through the steps on its own. It reads your codebase, makes edits, runs tests, and iterates until things are working.

GitHub Copilot's agent mode, now available in VS Code, can take multi-step coding tasks and execute them with access to your full project context.

LangChain and LlamaIndex are open-source frameworks for teams that want to build their own agent pipelines. They give you the building blocks, including tool definitions, memory management, and agent orchestration, without having to implement everything from scratch.

For teams rather than individuals: start by identifying one workflow that is repetitive, has clear success criteria, and is currently taking up meaningful engineering time. Code review consistency, test generation for new endpoints, and release notes generation are all good starting points. Pick one, add an agent to it, measure the time savings, and expand from there.

The Bigger Shift

There is a version of this conversation that frames AI agents as a threat to developers' jobs. That framing is not useful and also not accurate, at least not for the foreseeable future.

What is accurate is that the shape of a developer's job is changing. Tasks that required a human because they were technically complex, things like writing boilerplate, running test suites, checking style, and generating scaffolding, are becoming automated. The tasks that require genuine judgment, like understanding tradeoffs, making architectural decisions, communicating with stakeholders, and deciding what to build in the first place, remain firmly in human hands.

If you spend most of your time on the first category, agents are going to change your workflow significantly. If you spend most of your time on the second category, they are going to make you faster at the parts that were previously slowing you down.

The developers who will benefit most are the ones who learn to direct agents effectively. They understand what tasks to delegate, how to specify them clearly, how to verify the output, and when to step in and course-correct. That is less like being replaced by a tool and more like getting a capable junior colleague who never sleeps, never gets bored, and works best with clear direction.

Software development has always been about solving problems with whatever tools are available. Agents are a genuinely new kind of tool, with different strengths and different failure modes than anything that came before. Understanding them clearly, rather than through the lens of pure hype or reflexive skepticism, is what lets you actually use them well.

That is what separates the developers who feel overwhelmed by what is happening right now from the ones who are genuinely excited about it.

Observability vs Monitoring

Chisom Chima — Mon, 27 Apr 2026 14:59:20 +0000

Here is a situation that has probably happened to you at some point.

A user submits a support ticket saying the app is "slow." You check your dashboards. CPU looks fine. Memory looks fine. Error rate is zero. Everything is green. But the user is right, something is wrong. You just cannot see what it is.

So you start guessing. Maybe it's the database. Maybe it's a third-party API. Maybe it's that new endpoint that shipped last week. You add some console.log statements, redeploy, wait for it to happen again, and hope the logs tell you something useful.

That is what life looks like without observability. And honestly, it is the reality for most engineering teams, even the ones that think they have "good monitoring."

The Word Everyone Gets Wrong

Monitoring and observability get used as synonyms all the time, even by experienced engineers who should know better. They are related, but they describe fundamentally different things, and mixing them up leads to blind spots that cost you hours of painful debugging.

The clearest way to think about it:

Monitoring tells you that something is wrong.

Observability tells you why.

Monitoring is about watching predefined metrics like CPU usage, memory, request counts, and error rates, then alerting you when one of them crosses a threshold you set in advance. It works great for problems you already know about and thought to measure ahead of time.

Observability is about the ability to understand the internal state of a system just by looking at the data it produces. It handles the problems you did not predict and never wrote an alert for. The ones that only appear on Tuesdays at 3pm for users in a specific region making a very specific sequence of requests.

The key word in that definition is ability. Observability is not a tool you install. It is a property your system either has or does not have, and building it requires intentional decisions at every layer of your stack.

Why Monitoring Alone Is Not Enough

Imagine your house has a single smoke detector in the hallway. If there is a fire, it goes off. Great, that is monitoring. You know something is wrong.

Now imagine the fire is in the kitchen. Or in the basement. Or it is not actually a fire but a slow gas leak that has not ignited yet. The smoke detector cannot help you understand any of that. It only knows one thing: smoke threshold crossed, yes or no.

Most monitoring setups work exactly like this. They answer binary questions about things you already anticipated.

The problem with modern software is that most of the interesting failures are not binary and were not anticipated. A service call that normally takes 80 milliseconds starts taking 800 milliseconds for about 3% of requests. No error is thrown. No threshold is breached. Users just notice the app feels sluggish on certain actions, and they start quietly switching to a competitor.

Traditional monitoring has nothing to say about this. Observability does.

The Three Pillars (And What They Actually Mean)

You will hear observability described through three data types: logs, metrics, and traces. Most articles just list them and move on. I want to actually explain what each one does and why you need all three working together.

Logs

Logs are the oldest and most familiar tool. They are records of things that happened, written to a file or a stream as your application runs.

2026-04-18T14:22:31Z INFO  User 8821 requested /orders/summary
2026-04-18T14:22:31Z INFO  Fetching orders from database
2026-04-18T14:22:32Z WARN  Database query took 943ms (threshold: 500ms)
2026-04-18T14:22:32Z INFO  Returned 12 orders to user 8821

Good logs tell you what happened, in what order, and with enough context to reconstruct the sequence of events. Bad logs tell you almost nothing useful, things like Error occurred or Request failed with no indication of which request, which user, or what the actual error was.

The problem with logs alone is that they become overwhelming fast. A service handling a few thousand requests per second might produce millions of log lines per hour. Finding the one that explains your bug feels like searching for a specific sentence in a library with no catalogue system.

Metrics

Metrics are numerical measurements collected over time. Unlike logs, which capture individual events, metrics are aggregated. They answer questions like:

What is the average response time over the last five minutes?
How many requests per second are hitting this endpoint?
What percentage of database connections are currently in use?
How many items are sitting in a queue waiting to be processed? Metrics are excellent for spotting trends and triggering alerts. They are also cheap to store because a single number replaces thousands of individual log lines. The tradeoff is that aggregation destroys detail. If your average response time is 200ms but your 99th percentile sits at 4 seconds, the average makes everything look fine while a real slice of your users are having a genuinely terrible experience.

Traces

Traces are the pillar that most teams skip entirely, and they are often the most valuable one for debugging anything in a distributed system.

A trace follows a single request as it travels through your entire system: from the browser, through your API gateway, into Service A, which calls Service B, which queries the database, which calls an external payment API, and eventually returns a response to the user.

Each step in that journey is called a span. The trace is the collection of all spans for one request, tied together with a shared identifier called a trace ID.

Here is what a trace might look like for a checkout request:

Trace ID: a3f8b21c

[0ms]     API Gateway          received POST /checkout
[2ms]     Auth Service         validated JWT token         (2ms)
[4ms]     Cart Service         fetched cart for user 8821  (18ms)
[22ms]    Inventory Service    checked stock availability  (340ms)  <- slow
[362ms]   Payment Service      charged card               (89ms)
[451ms]   Order Service        created order record       (12ms)
[463ms]   API Gateway          returned 200 OK

In one view, you can see the Inventory Service took 340 milliseconds, which is where nearly all the latency for this request lived. Without distributed tracing, you would have to correlate timestamps across four separate log files to figure that out, assuming the relevant logs even existed in the first place.

A Real Debugging Scenario

Say you get a Slack alert at 9am: "P95 checkout latency spiked to 4 seconds, normally 600ms." You have about two minutes before your on-call phone starts ringing.

With only monitoring:
You know something is wrong. You open your dashboards. CPU fine, memory fine, error rate zero. You start guessing which service is the culprit and dig through logs hoping something jumps out. Twenty minutes later, maybe you find it.

With full observability:

First, you open your tracing tool and filter for slow checkout requests from the last fifteen minutes. You immediately see that every slow trace shares one thing in common: the Inventory Service span is taking 2-3 seconds instead of the usual 50ms.

Then you click into one of those slow traces and look at the logs attached to that specific span. You see: Inventory cache MISS - falling back to database query.

Next, you check your metrics dashboard for the Inventory Service cache hit rate. It dropped from 94% to 11% at 8:51am, right when the latency started climbing.

Finally, you check what changed at 8:51am. A deployment went out. Someone updated the cache key format, which silently invalidated every cached item in one shot.

Total time from alert to root cause: four minutes. That is what observability actually looks like when it is set up properly.

The Difference in One Sentence

Monitoring answers a question you already thought to ask. Observability lets you ask questions you had not imagined yet.

This distinction matters more than ever because modern systems are not monoliths anymore. A single user action might touch ten services, three databases, two message queues, and a couple of third-party APIs. When something goes wrong in that web of interactions, you cannot possibly have written an alert for every failure mode in advance. You need the ability to explore and investigate freely.

Structured Logging: The Underrated Starting Point

Before reaching for a fancy observability platform, the most impactful thing most teams can do is improve their logs by making them structured.

Unstructured log:

User 8821 checkout failed after 3.2s

Structured log (JSON):

{
  "timestamp": "2026-04-18T09:14:22Z",
  "level": "error",
  "event": "checkout_failed",
  "user_id": 8821,
  "duration_ms": 3200,
  "trace_id": "a3f8b21c",
  "failed_service": "inventory",
  "error_code": "CACHE_MISS_TIMEOUT"
}

The structured version is searchable, filterable, and joinable with other records. You can ask your logging system to show you all checkout failures in the last hour where failed_service is inventory. With unstructured logs, you are doing regex searches and crossing your fingers.

Most modern logging libraries support structured output out of the box. Turning it on is usually a single configuration change.

Tools Worth Knowing About

You do not need to build any of this from scratch. The ecosystem has matured a lot in the last few years.

For metrics, Prometheus is the open-source standard. It scrapes numeric measurements from your services and stores them as time-series data. Pair it with Grafana to build dashboards and set alerts, and you have a solid foundation that thousands of companies run in production today.

For distributed tracing, OpenTelemetry is the project that matters most right now. It is an open standard with vendor-neutral instrumentation libraries that you add to your services to emit traces, metrics, and logs in a consistent format. Once you instrument your services with OpenTelemetry, you can send that data to whichever backend you prefer. Jaeger is open source and great for getting started. Tempo from Grafana integrates cleanly with the rest of that stack. Managed services like Honeycomb or Datadog are solid options if you want less operational overhead.

For logs, Loki from Grafana is a lightweight option that plays nicely with the rest of that ecosystem. If you are already running the ELK stack (Elasticsearch, Logstash, Kibana), that works well too, though it is heavier to maintain long-term.

The full Grafana stack, meaning Prometheus, Loki, Tempo, and Grafana together, gives you all three pillars in a single unified interface and is entirely free to self-host. For most teams just getting started, this is the most practical path forward.

When Monitoring Is Actually the Right Tool

This is worth being clear about: monitoring is not obsolete. It is still the right tool for predictable, well-understood failure modes.

Is the service up or down? Monitoring. Set an alert and move on.

Is database storage above 85%? Monitoring. Simple threshold, simple alert.

Is the TLS certificate expiring in the next seven days? Monitoring. Done.

Observability earns its added complexity when you have distributed systems, when failure modes are unpredictable, and when the cost of long debugging sessions is high. A solo developer building a side project probably does not need distributed tracing. An engineering team running twenty microservices and handling millions of users almost certainly does.

The Mindset Shift

The deeper change that observability asks for is not really technical at its core. It is about how you think about your systems.

With a monitoring mindset, you assume you know what can go wrong and you write alerts for it. You are reactive to events you already predicted.

With an observability mindset, you accept that you cannot predict everything. So instead, you invest in making your system explorable. When something unexpected happens, you have enough data to reason about it from the outside, without needing to reproduce it locally or add new instrumentation after the fact and wait for the bug to resurface.

This shift sometimes gets described as moving from handling known unknowns to handling unknown unknowns. Monitoring covers what you know you do not know. Observability covers what you had no idea you did not know.

Production systems fail in genuinely creative ways. The more complex your architecture, the more creative those failures get. Knowing a server is down is easy. Understanding why 3% of users experience five-second delays on a Tuesday afternoon after making a specific sequence of requests that nobody thought to test together requires observability.

You do not have to build it all at once. Start with structured logs. Add metrics with Prometheus. Instrument one or two critical paths with OpenTelemetry traces. Each layer gives you more signal, and more signal means shorter debugging sessions and faster fixes.

That is the whole point. Not the dashboards, not the tools. The shorter debugging sessions.

Contract Testing Explained for Beginners

Chisom Chima — Mon, 20 Apr 2026 06:39:51 +0000

Let me paint a scene that will feel familiar if you've worked on any project with more than one moving part.

It's a Friday afternoon. You and the backend team have been building a new feature for two weeks. Everything passes locally. The QA environment looks clean. You ship to production feeling good about it.

Then your phone buzzes. The frontend is broken. Users are seeing blank screens where their profile data should be. You dig in, and after twenty minutes of confusion, you find it: the backend team renamed a field in the API response. Just one field. name became fullName. That's it. That's the whole incident.

Nobody made a mistake, exactly. There was no test that caught it. There was no agreement written down anywhere that said "this field must always be called name." And that missing agreement is exactly what contract testing is designed to create.

What Contract Testing Actually Is

Contract testing is about formalizing the agreement between two systems so that both sides can be held accountable to it automatically.

Those two systems are usually a consumer (something that requests data) and a provider (something that serves it). In the most common setup, the consumer is a frontend application, a mobile app, or another microservice, and the provider is a backend API.

The "contract" itself is just a documented expectation. The consumer says: if I call this endpoint with these parameters, I expect a response that looks like this. That expectation gets saved as a file. Then the provider runs its own tests against that file to confirm it actually delivers what was promised.

If the provider ever changes something that breaks the contract, the test fails before anything gets deployed. The problem surfaces in the build pipeline, not in production at 5pm on a Friday.

Why Integration Tests Alone Are Not Enough

The instinct most teams have is to write integration tests. Spin up the frontend, spin up the backend, spin up the database, run some end-to-end scenarios, and call it covered.

This works, until it doesn't. Integration tests have a reliability problem. They depend on the entire environment being healthy at once. A database that takes three seconds too long to boot, a port conflict, a misconfigured environment variable, and suddenly your test fails for a reason that has nothing to do with your code. You re-run it, it passes, and you move on without learning anything.

The failure rate on integration tests in active CI pipelines can be surprisingly high, and most of those failures are what engineers call "flaky": intermittent failures caused by timing, environment, or infrastructure rather than actual bugs.

Integration tests also run slowly. A full suite on a non-trivial application can take fifteen minutes or more. That delay accumulates across a team and across a week.

Contract testing sidesteps most of this. Each side tests independently. The consumer runs its contract tests against a mock. The provider runs contract verification against the saved contract file. Neither side needs the other to be running. Neither test takes more than a few seconds. And when something fails, it fails for a clear, reproducible reason.

A Concrete Example, Step by Step

Take a simple scenario. You are building a user profile page. The frontend makes this request:

GET /users/42

The backend responds with:

{
  "id": 42,
  "name": "Priya Kapoor",
  "email": "priya@example.com",
  "role": "admin"
}

The frontend developer writes a contract that captures exactly what they depend on. Not every field just the ones they actually use:

{
  "consumer": "profile-frontend",
  "provider": "user-api",
  "interactions": [
    {
      "description": "a request for a user by ID",
      "request": {
        "method": "GET",
        "path": "/users/42"
      },
      "response": {
        "status": 200,
        "body": {
          "id": 42,
          "name": "Priya Kapoor",
          "email": "priya@example.com"
        }
      }
    }
  ]
}

Notice the contract does not include role. The frontend does not use it, so it does not care about it. This is intentional. Contracts should only capture what the consumer actually depends on, nothing more.

This contract file gets committed to a shared repository or uploaded to a broker tool like Pact Broker.

Now the backend team runs their verification step. Their test loads the contract, replays the request against their actual running API, and checks whether the response matches. If it does, all is well. If a backend developer has renamed name to fullName, changed the status code, or restructured the response body, the verification step catches it immediately.

The backend cannot merge that change without either fixing the API to match the contract, or explicitly renegotiating the contract with the frontend team.

What Happens When a Contract Breaks

Here is where the real power shows up.

Suppose the backend team decides to refactor the user model. They want to split the name into firstName and lastName for internationalization reasons. Perfectly reasonable. But this is a breaking change.

Without contract testing, this change might get merged, deployed, and discovered by users or caught in a manual QA session if you are lucky.

With contract testing, the backend verification step fails the moment the contract no longer matches:

$ pact verify

Verifying a pact between profile-frontend and user-api

  a request for a user by ID
    returns a response which
      has status code 200 (OK)
      has a matching body (FAILED)

Failures:

  1) profile-frontend - a request for a user by ID
     Diff
     Key "name" is missing from the response body.
     Unexpected key "firstName" found in the response body.
     Unexpected key "lastName" found in the response body.

1 interaction, 1 failure

The CI pipeline blocks the merge. The backend developer sees exactly which contract is failing and knows they need to coordinate with the frontend team before proceeding.

The conversation that would have happened after an incident now happens before any code ships.

Consumer-Driven vs Provider-Driven Contracts

There are two flavors of contract testing worth knowing about.

Consumer-driven contracts are the more common approach. The consumer team writes the contract based on what they need. This is the model described above, and it is what tools like Pact are built around. It works well because it centers the contract on actual usage rather than theoretical API documentation that may drift from reality.

Provider-driven contracts go the other direction. The API team publishes a specification (often an OpenAPI spec) and consumers write tests that verify their usage matches that spec. This approach is useful when you have a public API with many consumers and cannot collect individual contracts from all of them.

Most teams working on internal microservices or frontend-backend pairs use the consumer-driven model because it is more precise about what any given consumer actually needs.

Contract Testing vs Integration Testing: When to Use Each

These are not competing approaches. They serve different purposes.

	Integration Testing	Contract Testing
Speed	Slow (minutes)	Fast (seconds)
Reliability	Flaky	Stable
Requires full system?	Yes	No
Catches breaking API changes?	Sometimes	Always
Best for	End-to-end user flows	Service-to-service agreements

Integration testing is still valuable for verifying complete user flows: log in, create a resource, update it, delete it. These tests confirm that the system behaves correctly as a whole for scenarios that matter to users. You want some of them. You do not want to rely on them exclusively.

A healthy testing strategy looks like this:

Many unit tests — verify logic inside individual services
A good number of contract tests — verify the handshakes between services
Few integration or end-to-end tests — verify critical user flows

The pyramid shape holds: many at the bottom, few at the top.

The Setup in Practice

If you want to try this on a real project, Pact is the most widely used tool and supports JavaScript, Python, Java, Go, Ruby, and several other languages.

The basic flow with Pact looks like this:

The consumer writes interaction tests using the Pact DSL
Running those tests generates a .json contract file
That file gets published to a Pact Broker instance (you can self-host or use the managed PactFlow service)
The provider pulls the contract from the broker and runs verification as part of its own test suite
Both sides report results back to the broker, which tracks whether the current consumer and provider versions are compatible

This compatibility check is called "can I deploy", and it is what CI pipelines query before allowing a release. If the check passes, you ship. If it fails, you have a conversation.

Here is what a simple Pact consumer test looks like in JavaScript:

const { PactV3, MatchersV3 } = require('@pact-foundation/pact');
const { like } = MatchersV3;

const provider = new PactV3({
  consumer: 'profile-frontend',
  provider: 'user-api',
});

describe('User API contract', () => {
  it('returns user data by ID', async () => {
    await provider
      .given('user 42 exists')
      .uponReceiving('a request for a user by ID')
      .withRequest({ method: 'GET', path: '/users/42' })
      .willRespondWith({
        status: 200,
        body: {
          id: like(42),
          name: like('Priya Kapoor'),
          email: like('priya@example.com'),
        },
      })
      .executeTest(async (mockServer) => {
        const response = await fetch(`${mockServer.url}/users/42`);
        const user = await response.json();
        expect(user.name).toBeDefined();
        expect(user.email).toBeDefined();
      });
  });
});

When this test runs, Pact spins up a local mock server, verifies your frontend code interacts with it correctly, and generates the contract file automatically. No real backend required.

Who Should Care About This

If you are working on any system where more than one codebase communicates over a network, contract testing is worth understanding. That includes frontend teams, backend teams, and anyone building or consuming microservices.

The pattern is especially valuable in organizations where frontend and backend teams work somewhat independently and deploy on their own schedules. The contract creates a stable interface that both sides can build against, reducing the need for constant coordination and the risk of surprises at deployment time.

If you have ever found yourself waiting for the backend to be "ready" before you could test your frontend code, or discovered a breaking API change only after deploying, contract testing is solving exactly that problem.

Final Thoughts

The mental shift contract testing asks for is small but meaningful. Instead of asking "does the whole system work?", it asks "does each service honor its commitments to the services that depend on it?"

Answer that question consistently, and the whole system tends to take care of itself. No more Friday afternoon incidents. No more "it works on our side."

If this was helpful, feel free to follow along.

Design Patterns You’ll Actually Use: A No-Nonsense Guide

Chisom Chima — Wed, 07 Jan 2026 07:17:10 +0000

We have all been there. You start a project with the best intentions, but three months later, the codebase looks like a bowl of spaghetti. Changing one variable breaks five unrelated files, and "fixing" a bug feels like playing a dangerous game of Jenga.

This is exactly why design patterns exist. They aren't just academic theories meant to make you sound smart in interviews. They are battle-tested strategies for keeping your code clean and your sanity intact.

Here are the four patterns that every JavaScript developer should actually know.

The Singleton (The "Only One" Rule)

The Singleton is one of the simplest patterns to understand but also one of the most debated. The goal is simple: ensure a class has exactly one instance and provides a global point of access to it.

Think of a Database Connection or a Theme Manager. You don't want five different objects trying to manage your dark mode settings at the same time.

class ThemeManager {
  constructor() {
    if (ThemeManager.instance) {
      return ThemeManager.instance;
    }

    this.theme = 'light';
    ThemeManager.instance = this;
  }

  toggleTheme() {
    this.theme = this.theme === 'light' ? 'dark' : 'light';
    console.log(`Theme is now ${this.theme}`);
  }
}

// Even if we try to create a new one, we get the same instance
const managerA = new ThemeManager();
const managerB = new ThemeManager();

console.log(managerA === managerB); // true

Pro Tip: Be careful with Singletons. They are essentially "global state," which can make testing a bit harder if you aren't careful. Use them only when you truly need a single source of truth.

The Factory Pattern (The Object Creator)

In a big app, you often need to create different types of objects based on a specific condition. Instead of cluttering your main logic with a dozen if/else or switch statements, you use a Factory.

Imagine you are building a notification system that handles Email, SMS, and Push notifications.

class Email {
  send(msg) { console.log(`Sending Email: ${msg}`); }
}

class SMS {
  send(msg) { console.log(`Sending SMS: ${msg}`); }
}

class NotificationFactory {
  createNotification(type) {
    switch(type) {
      case 'email': return new Email();
      case 'sms': return new SMS();
      default: return null;
    }
  }
}

const factory = new NotificationFactory();
const service = factory.createNotification('email');
service.send('Hello World!');

This keeps your code "decoupled." The main part of your app doesn't need to know how an Email object is built; it just asks the factory for a notification service and goes to work.

The Observer Pattern (The Subscriber)

If you have ever used addEventListener in JavaScript, you have already used a version of the Observer pattern. It is all about "don't call me, I'll call you."

One object (the Subject) keeps a list of other objects (Observers) that want to know when something happens. When the state changes, the Subject broadcasts a message to everyone on the list.

class Store {
  constructor() {
    this.subscribers = [];
  }

  subscribe(fn) {
    this.subscribers.push(fn);
  }

  unsubscribe(fn) {
    this.subscribers = this.subscribers.filter(item => item !== fn);
  }

  broadcast(data) {
    this.subscribers.forEach(fn => fn(data));
  }
}

const myStore = new Store();

const logger = (data) => console.log(`Log: ${data}`);
const uiUpdater = (data) => console.log(`Updating UI with: ${data}`);

myStore.subscribe(logger);
myStore.subscribe(uiUpdater);

// When something happens, everyone gets the update
myStore.broadcast('New product added!');

This is the backbone of state management libraries like Redux or the reactivity systems in Vue and React.

The Strategy Pattern (The Plugin Approach)

The Strategy pattern is a lifesaver when you have a specific task (like calculating a price) but there are multiple ways to do it. Instead of one massive function with a hundred arguments, you create separate "strategies."

Let’s look at a payment processing example:

// Different strategies
const paypal = (amount) => amount * 1.05; // 5% fee
const creditCard = (amount) => amount + 2; // Flat $2 fee
const crypto = (amount) => amount * 0.98; // 2% discount

class Order {
  constructor(amount) {
    this.amount = amount;
  }

  process(strategy) {
    return strategy(this.amount);
  }
}

const myOrder = new Order(100);
console.log(myOrder.process(paypal)); // 105
console.log(myOrder.process(crypto)); // 98

The beauty here is that you can add a new payment method (like Apple Pay) just by writing a new small function. You don't have to touch the Order class at all.

The Reality Check: Don't Over-Engineer

Here is the most important advice I can give you: Don't use a pattern just to use a pattern.

I have seen developers turn a 10-line file into a 200-line "Pattern Masterpiece" that no one can read. If a simple if statement works and it's readable, stick with the if statement.

Patterns are tools for your belt. Use them when the code starts feeling heavy or hard to maintain.

What’s your favorite pattern?
Do you use these in your daily workflow, or do you think they add too much boilerplate? Let’s talk about it in the comments.