When you hand a coding agent like Claude Code access to your production system, you are trusting it to understand your architecture. Sometimes it does. Sometimes it does not. The developer who spent weeks building a FastAPI, asyncpg, LangGraph, MQTT, and pgvector stack decided to make sure Claude Code could not break what he had built without tests failing first.

The approach was simple. Write tests that run fast enough to be part of every interaction with the codebase. Make them comprehensive enough to catch architectural violations. Run them after every significant change to verify the system still behaves as intended.

The Testing Stack That Runs in 0.4 Seconds

The test suite uses pytest with a focus on speed over coverage of every edge case. Tests that run slowly get ignored. Tests that run in under a second become part of the development rhythm. The 18-test suite runs in 0.4 seconds on the developer's machine, fast enough to run after every Claude Code action.

The tests cover architectural boundaries. When Claude Code proposes a change that violates the separation between layers, the tests catch it. When it suggests replacing an asyncpg query with a synchronous SQLAlchemy call that would block the event loop, the tests fail. When it proposes using MQTT QoS levels inappropriately for real-time sensor data, the tests catch that too.

Integration tests verify that the LangGraph workflow actually executes the expected state transitions. Unit tests verify individual component behavior. The combination creates a net that catches the most impactful errors without requiring a full regression suite.

Why LangGraph Specifically Needs Testing

LangGraph workflows define state machines with specific transitions. A developer defines nodes and edges, and the graph executes by following those edges based on state. When Claude Code modifies the graph definition, it can inadvertently change the transitions that are allowed.

If the graph is supposed to transition from a pending state to a processing state only through an explicit start action, a change that adds a shortcut edge bypassing that transition changes the system's behavior in ways that may not be obvious.

The tests verify that the graph's structure matches the documented behavior. Any change to the graph structure that would alter the allowed state transitions triggers a test failure.

MQTT and Real-Time Data Constraints

The IoT component of the stack handles real-time sensor data through MQTT. This protocol has specific semantics around message delivery guarantees. QoS 0 means at most once delivery. QoS 1 means at least once. QoS 2 means exactly once. Using the wrong QoS level for a given use case causes different failure modes.

For critical sensor readings that must not be lost, QoS 2 is appropriate. For high-frequency telemetry where occasional loss is acceptable, QoS 0 reduces overhead. A developer working with MQTT needs to understand these tradeoffs. So does an AI coding agent.

The tests verify that each MQTT topic uses an appropriate QoS level for its intended purpose. Claude Code, when asked to optimize the system, might suggest reducing QoS levels across the board to reduce latency. The tests catch this when applied to topics that require guaranteed delivery.

pgvector and Semantic Search Constraints

pgvector handles semantic search for the system. This extension to PostgreSQL stores embeddings and enables similarity search. The critical constraint is that embeddings must be generated consistently using the same model. If Claude Code modifies the embedding generation to use a different model, the similarity searches will return incorrect results.

The tests verify that the embedding model used for storage matches the model used for queries. Any change to the embedding pipeline triggers a test failure that prevents the system from accumulating embeddings generated by incompatible models.

The Cost of Not Testing

The developer who skipped the testing layer would have caught architectural violations only through manual review or runtime failures. With a complex system involving multiple specialized components, the surface area for errors grows with every addition.

AI coding agents amplify this risk. They move faster than human developers and may not fully understand the architectural implications of every change. Without automated tests enforcing boundaries, it is easy for an agent to make changes that seem reasonable in isolation but violate system-wide constraints.

The 0.4-second test suite is not a comprehensive solution to this problem. It is a safety net that catches the most expensive errors before they reach production. Running tests frequently enough to be useful requires speed. Building tests comprehensive enough to catch meaningful violations requires understanding the system deeply enough to know where violations are likely.

The test suite covers several categories of architectural violations. API contract tests verify that endpoints return responses matching documented schemas. Database constraint tests verify that migrations do not break existing data relationships. Message queue tests verify that MQTT topics follow naming conventions and QoS assignments.

When Claude Code proposes a change, the developer runs the test suite before accepting the changes. If tests pass, the changes are integrated. If tests fail, Claude Code receives feedback about which tests failed and why, and it proposes corrections. This loop continues until the test suite passes.

The approach is similar to Test-Driven Development but inverted in timing. TDD writes tests before code. This approach runs tests after AI-generated code. The effect is similar: code that violates the test contract does not get merged.

What This Means for AI Coding Workflows

The developer who built this system learned something about how AI coding agents operate. They move fast, they explore aggressively, and they do not always anticipate how changes in one part of a system affect other parts. The test suite enforces global constraints that individual node edits cannot be aware of.

For teams using AI coding agents in production environments, this kind of safety net becomes essential. The alternative is extensive code review before any AI-generated change reaches the codebase. The 0.4-second test suite provides a faster feedback loop without sacrificing quality.

The developer documented the approach on Dev.to, where it resonated with other developers working with AI coding agents in complex environments. The comments section revealed that many developers are encountering similar challenges and are looking for practical solutions beyond "review everything manually."

Sources

Sources: Dev.to

For more insights on AI agent development and testing strategies, visit XerAds Blog.