We have been shipping a lot of apps with agents lately: Claude Code on some projects, our developers on Kilocode and Codex on others. The developers adapted fast. The question that kept bothering me was our test engineers, and whether twenty years of testing discipline just became obsolete overnight. This post is my answer: it did not. It became more important, and it moved to a different place in the process. Along the way I will also answer the question that follows immediately after: if agents write the code, who reviews it, and does agent-reviewing-agent even make sense?

The safety net became the steering wheel

For twenty years, tests sat downstream of code. You wrote the feature, then you wrote tests to prove it worked, and everyone quietly accepted that half the time the tests came late or not at all. Tests were insurance. Skipping them was a debt, not a disaster.

Agentic coding flipped the direction of that arrow. When Claude Code, Cursor, or any autonomous agent writes and modifies code in a loop, the test suite is the only channel through which reality reaches the agent. The agent cannot see your product spec. It cannot sit in your standup. What it can do, thousands of times an hour, is run a test and read the result. That makes tests the primary steering mechanism, not the final checkpoint. Anthropic’s own Claude Code best practices put test-driven workflows at the center for exactly this reason: a red-to-green cycle gives the agent unambiguous feedback it can iterate against without a human in the loop.

Here is the position I will defend: in an agentic team, writing tests after the code is not a smaller version of testing. It is theater.

What happens when an agent codes without tests

The failure modes are predictable, and if you manage a web team using AI agents, you have already seen at least one of them.

• Hallucinated correctness. The agent reports “done, all working” for code it never executed against a real assertion. It is not lying. It has no ground truth to check against, so its confidence is a language pattern, not a verdict.
• Fix one, break three. Ask an agent to patch a Laravel endpoint and it will happily rewrite a shared helper, silently changing behavior in two other controllers. Without a regression suite, nobody notices until a client does.
• Spec drift. Over a long session, the agent’s idea of the feature slowly diverges from yours. Each individual change looks reasonable. The sum is a checkout flow that does something you never asked for.

There is a fourth failure mode that surprises people: unlike a human developer, an agent almost never says no. A senior developer will push back on a bad requirement. An agent builds whatever you describe, including the unwise version, and builds it convincingly. Tests are the mechanism that replaces the pushback you lost.

Test-driven prompting: write the contract, not the code

The practical shift for developers is that you stop typing assertions by hand and start defining behavior up front, in plain language or minimal test skeletons, then instruct the agent to write code that makes those tests pass. Kent Beck, who literally wrote the book on TDD, calls this discipline the difference between vibe coding and augmented coding: in one you only care that the behavior looks right, in the other you own the tests and the design while the agent does the typing.

The working sequence looks like this:

1. "Write failing tests for the coupon validation endpoint.
   Expected: 422 on expired codes, 200 with discount object on valid codes,
   409 when the coupon is already redeemed. No implementation yet."
2. "Run the tests. Confirm they all fail."
3. Commit the failing tests.
4. "Now implement until every test passes.
   Do not modify the tests."

Step 3 is not optional. Agents will sometimes edit a test to make it pass instead of fixing the implementation. Committing the failing tests first means any tampering shows up in the diff, and you can revert it in seconds. That one git commit is doing the supervision work a human reviewer used to do line by line.

For web teams, the same pattern applies at every layer: Pest or PHPUnit for the API, Vitest for React components, and Playwright for the end-to-end flows that actually pay the bills, like login, cart, and checkout. The agent can write and run all of them. Your job is deciding what they must assert.

Fix bugs backwards: regression test first, patch second

When a bug surfaces, the old reflex is to dive into the implementation. The agentic reflex should be different: prompt the agent to write a test that reproduces the bug, watch it fail, and only then allow the agent to generate the fix.

This ordering matters for two reasons. First, a reproducing test proves the agent understood the bug; a patch without one proves nothing. Second, that test stays in the suite forever, so the same agent (or the next one, or the junior developer six months from now) cannot reintroduce the bug without the pipeline going red. Every incident becomes a permanent constraint. Over a year, this is how a codebase touched by agents gets more stable instead of less. This is the same discipline we described in controlled AI coding, applied to defects instead of features.

Can an agent review agent code?

This is the question that sounds like a trap: if the agent wrote the code, having an agent review it feels like a developer testing his own work. Sometimes it is exactly that, and sometimes it is not. The difference is context, and it is worth being precise about.

An agent reviewing code inside the same session that wrote it is worthless. It carries the full memory of its own reasoning, so it re-approves its own assumptions, the same way you cannot proofread your own email five seconds after sending it. But a fresh agent session with no memory of the implementation is a genuinely different reviewer. It reads the diff cold, with no attachment to the decisions behind it, which is closer to a new team member reviewing a PR than to a developer grading himself. Anthropic recommends this writer/reviewer split as a standard pattern for the same reason.

So agent review is real, but it is narrow. A fresh agent catches logic errors, missed edge cases, and deviations from the test contract. What it cannot do is be accountable. Both agents still share the same training, the same blind spots, and the same inability to know your client, your compliance obligations, or your business. That is where the human stays, and not as a formality:

• Owning the behavior contract. A human decides what the tests must assert. Agents can propose edge cases; a person approves them.
• Reviewing the tests, not the volume. Nobody honestly reads 800 generated lines. A human reads the 60 lines of tests that govern them, plus a spot-check of anything touching money, auth, or data deletion.
• Architectural and product judgment. Whether this feature should exist, whether this dependency is acceptable, whether this shortcut will hurt in a year. No test suite encodes that.
• The merge. A human presses the button, and that name in the git history means something a bot’s cannot.

Put plainly: shipping unreviewed code was never acceptable, and agents do not change that. They change what review looks like. Test contract reviewed by a human, implementation reviewed by a fresh agent, judgment calls and the merge held by a human. That is not weaker than traditional code review. Done honestly, it is stricter, because the contract is explicit instead of living in a reviewer’s head.

What changes for the team lead

If you run a web team, the shift is bigger for you than for your developers. The summary:

The review change deserves emphasis. An agent can generate 800 lines of plausible React in a minute; no human reviews that honestly. What a human can review is the 60 lines of tests that define what those 800 lines must do. Review the contract, spot-check the implementation. Where the web development life cycle used to place QA as a phase, agentic teams place it as a gate: CI runs the full suite on every agent-generated commit, and the agent is simply not allowed to ship red. Budget-wise, the hours you used to spend on post-build QA move upstream into behavior definition. The total testing effort does not shrink. It moves to the front, where it is cheap.

A policy checklist worth adopting before your team’s next sprint:

• Every agent-built feature starts from tests the agent was given or asked to generate first, committed while still failing
• Agents are instructed never to modify existing tests; any test change requires a human commit
• No agent-generated PR merges with a red pipeline, no exceptions for “it works locally”
• Every production bug gets a reproducing regression test before its fix is accepted
• Critical user flows (auth, cart, checkout, payments) have end-to-end coverage the agent must keep green
• Reviewers read tests first and sign off on behavior, not line-by-line implementation

Your testers just got promoted

The uncomfortable conclusion for managers: the people on your team who are good at defining expected behavior, edge cases, and failure conditions just became your highest-leverage engineers. That skill used to be undervalued as “QA work.” It is now the interface through which your team controls its fastest developer, the agent. The developers who thrive in this model are the ones who can hold the whole behavior of a feature in their head and write it down precisely, which is also the skill we argued matters most in vibe coding for web developers and in writing clean code with AI.

So no, test cases did not die in the age of agentic coding. They stopped being paperwork and became the steering wheel. The teams that treat them that way will let agents run fast safely. The teams that skip them will discover that an agent with no constraints is just a very fast way to write next quarter’s incident report.

The post Testing in Agentic Coding: From Safety Net to Steering Wheel first appeared on Macronimous Blog.

The primary bottleneck in modern Magento headless builds isn’t the React frontend; it is GraphQL query latency. While Magento’s schema offers immense flexibility, the default implementation often triggers a cascade of database requests that kill mobile performance. To achieve the sub-second interactions expected by US and UK shoppers, we must move beyond the “out-of-the-box” setup and re-engineer the data orchestration layer.

The N+1 Problem: Why Your Mobile Storefront Feels Laggy

If your product listing pages (PLPs) take more than 500ms to respond, you are likely hitting the N+1 query trap. In a standard Magento resolver, fetching a list of 20 products can trigger 21 separate database queries—one for the collection and twenty for individual attributes like “special_price” or “stock_status.”

At Macronimous, we solve this by implementing PHP DataLoaders. By batching these requests, we ensure the backend executes a single, optimized SELECT statement with an IN clause, reducing SQL execution time by up to 70%.

Infrastructure Acceleration with the Vinyl Cache Project

Traditional GraphQL requests are sent via POST, making them invisible to standard edge caches. To solve this, we leverage The Vinyl Cache Project (formerly Varnish Cache) alongside GraphQL Persisted Queries.

• Query Hashing: We map complex GraphQL strings to short, unique hashes.
• GET-based Fetching: By sending these hashes via GET, we make the responses cacheable at the edge.
• Vinyl Cache 8.0+ Integration: We utilize Vinyl’s high-speed memory storage to serve JSON payloads in under 30ms, effectively offloading 90% of the traffic from your Adobe Commerce origin server.

Optimizing the Apollo Client for High-Latency Networks

Mobile-first commerce requires resilience. We don’t just optimize the server; we tune the Apollo Client in the React frontend to handle “jittery” 4G/5G connections:

• Field-Level Fragments: We use colocation to ensure the client only requests the exact data points needed for the immediate viewport.
• Bypassing Hydration Bottlenecks: We utilize useSuspenseQuery to ensure the UI remains interactive while data streams in, preventing the “blank screen” effect during peak traffic.

Technical FAQ: Headless Magento Engineering

Is your headless infrastructure scaling with your traffic? At Macronimous, we specialize in React Magento integration and high-concurrency API tuning. Consult with our senior architects to audit your GraphQL performance.

The post Headless Magento GraphQL Performance Optimization first appeared on Macronimous Blog.

Your Magento Store is Powerful. But is it Fast Enough?

At Macronimous, we’ve built and managed countless applications on PHP, with a special focus on Magento. We know its power. It’s a robust, scalable e-commerce engine that can handle complex catalogs and business logic like no other. But as we started our journey into modern frontend technologies like React, we realized something crucial.

The biggest hurdle for Magento stores today isn’t the backend—it’s the traditional frontend experience.

We’ve successfully guided clients in pairing a React frontend with their Magento backend. It’s a challenge, especially for large-scale stores, but the results are transformative. This post explains why this “headless” approach is the future for serious e-commerce, both for the business owner and the developer.

The “Old Way”: Why Traditional Magento Frontends Feel Clunky

Without getting too technical, a traditional Magento site operates on a simple cycle:

1. A customer clicks on a product, a category, or a filter.
2. Their browser sends a full request to your server.
3. Magento works hard to build the entire new page from scratch—header, footer, sidebars, everything.
4. It sends that complete HTML page back to the customer.

Think of it like a customer in a physical store having to ask a clerk to bring them a whole new printed catalog every time they want to look at a different item. It works, but it’s slow and interrupts the shopping flow.

This model was fine a decade ago, but today it leads to tangible business problems:

• Slow Page Loads: Every click involves a delay, causing shopper frustration.
• Poor User Experience: Applying multiple filters or navigating categories feels sluggish.
• Higher Cart Abandonment: A slow, clunky checkout process is a primary reason customers leave.
• Lower SEO Scores: Google’s Core Web Vitals penalize slow, unresponsive sites.

The “New Way”: Instant, App-Like Speed with a React Frontend

Now, imagine a different approach. Instead of a printed catalog, you hand your customer a super-fast digital tablet. The main application is loaded just once. When they want to see a new product, only that product’s information is instantly fetched and displayed on the screen. The rest of the tablet’s display (the header, the menu) remains untouched.

This is exactly how a React frontend works with Magento. This is often called “Headless Magento.”

Your powerful Magento backend remains in place, managing products, orders, and customers. It just sends raw data (JSON) to the frontend. The React application, which runs in the user’s browser, handles all the visuals.

The business benefits are immediate and significant:

• Blazing-Fast Speed: Navigating between pages, filtering products, and searching becomes nearly instantaneous.
• A Modern, App-Like Feel: The store feels smooth and responsive, like a native mobile application, which dramatically improves the customer’s perception of your brand.
• Higher Conversion Rates: A faster, more enjoyable experience directly reduces friction and leads to more completed purchases.
• Better SEO Performance: The speed and improved user experience metrics are exactly what Google wants to see, leading to better rankings.
• Unmatched Design Flexibility: You are no longer constrained by Magento’s theme structure. You can build a completely unique, branded customer experience from the ground up.

For Your Developers: Making the Mental Shift

For this to work, your development team needs to think differently. If they’re used to the old Magento way, they must shift their perspective from building “pages” to building a “state-driven application.”

Here’s the core of that mental shift:

• From Server Pages to a Client-Side App: They must stop thinking about the server building HTML pages. The new world is a JavaScript application that lives in the browser and just talks to the Magento API for data.
• From Request-Response to State Management: Instead of a full page reload to show new data, they will simply update a variable in the app (the “state”), and the UI will instantly react to that change. A click on a color swatch doesn’t reload the page; it updates the selectedColor state, and the product image and price instantly change.
• From Pages to Reusable Components: Their new job is to break the UI down into small, independent, and reusable “components”—a <ProductCard>, a <PriceDisplay>, a <FilterSidebar>. This makes development faster and more maintainable in the long run.

To summarize this new way of thinking, here is a direct comparison:

Magento vs. React: A Shift in Thinking

The Best of Both Worlds

Adopting a React frontend is not about replacing Magento. It’s about unleashing its power. You keep the robust, secure, and scalable e-commerce engine you trust while bolting on a world-class, lightning-fast customer interface.

It’s a significant upgrade, but one that is essential for competing in the modern digital marketplace. If you’re ready to transform your store’s performance and provide an experience your customers will love, this is the way forward.

The post Headless Magento with React – Your Magento Store is Powerful. But is it Fast Enough? first appeared on Macronimous Blog.