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.

January 2026 marks a pivotal shift in the digital commerce landscape with Google’s launch of the Universal Commerce Protocol (UCP). We are moving from an era where humans browse websites to an era of “Agentic Commerce,” where AI agents (like Gemini, ChatGPT, or specialized bots) discover, negotiate, and purchase products on a user’s behalf. For development teams at Macronimous and our clients, this means the immediate challenge is mastering Universal Commerce Protocol implementation.

If you are a developer I recommend you to give a quick visit to the developers guidelines here.

Instead of building a visual frontend for human eyes, UCP requires us to build standardized API endpoints for AI interpretation. This blog breaks down what UCP is technically, how it impacts the major platforms we support, and the immediate action steps developers need to take.

The Problem UCP Solves: The “N x N” Complexity

Until now, if an AI assistant wanted to purchase a product from 10,000 different online stores, it would technically require 10,000 custom integrations to understand how each store’s cart, checkout, and inventory systems work. This is unscalable.

UCP acts as a standardized lingua franca. It is an open, RESTful API standard using JSON payloads that allows any e-commerce store to “speak” directly to any certified AI agent. It standardizes three core pillars of commerce:

1. Discovery: How an agent learns what a store sells and what UCP features it supports.
2. Capabilities Negotiation: How the agent asks real-time questions like, “Is SKU-123 in stock?” or “Can this be shipped to zip code 90210?”
3. Checkout Execution: A standardized session for securely completing the transaction without the user ever visiting the store’s domain.

The Developer Paradigm Shift

For developers used to building traditional Magento or WooCommerce sites, UCP requires a shift in mindset toward “Headless” and API-first architectures.

Key Technical Requirements:

• The Discovery Endpoint: You must implement a .well-known style endpoint. This is where your store declares its supported UCP capabilities (e.g., dev.ucp.shopping.checkout, dev.ucp.shopping.discount).
• State Management (The “Checkout Session”): The traditional “Cart” object, often tied to a user’s browser cookie, is replaced by a server-side “Checkout Session.” Your backend must be able to create, update, and finalize this session state via API calls from the AI agent.
• Security is Paramount:
  • Request Signing: Requests coming from agents (like Google) will be cryptographically signed. Your endpoints must verify these signatures to prevent spoofing.
  • OAuth 2.0: This is required for “Account Linking.” If a user wants the AI agent to use their existing store account and saved addresses, you must implement an OAuth flow to grant the agent permission.

Platform-Specific Impact Matrix

The effort required for Universal Commerce Protocol implementation varies significantly depending on the underlying architecture of the e-commerce platform. Below is a breakdown of how UCP affects the major platforms we support at Macronimous.

Action Plan for Developers and Technical Leads

First, you may have to explain this to your clients; while some forward-thinking merchants might already be aware of Agentic Commerce, others will need guidance on why this shift matters. To prepare both your clients and your internal teams for this shift, you need to execute a clear plan, but it is vital to communicate that this is a new integration layer, which implies there is a budget for this additional work. Depending on the platform and specific requirements, you can achieve this implementation either through custom code for bespoke architectures or by leveraging commercial and open-source plugins or extensions for a more streamlined, cost-effective rollout.

Phase 1: Immediate Prerequisites (Weeks 1-4)

1. Master the Spec: Lead developers must review the official UCP specification documentation (available at ucp.devor associated GitHub repos) to understand the required JSON structures.
2. Data Hygiene is Critical: UCP relies heavily on data feeds (like Google Merchant Center) to “match” user intent to products. Before writing code, ensure client product data is pristine. Missing GTINs, incorrect stock status, or vague descriptions will break the AI discovery process.
3. Security Infrastructure: Begin reviewing existing OAuth 2.0 implementations on custom platforms. A successful Universal Commerce Protocol implementation hinges on secure request signature verification, so plan the necessary middleware for Magento/PrestaShop now.

Phase 2: Pilot Implementation (Months 2-3)

1. The “Hello World” of UCP: On a staging environment for a flexible platform (ideally WooCommerce), attempt to implement just the Discovery Endpoint. Verify that an external tool can read your store’s capabilities.
2. Rethink the Cart: Start architecting how your chosen platform handles server-side cart sessions decoupled from browser cookies. This is often the hardest part of headless implementations.

Conclusion

UCP is not just another sales channel; it is the infrastructure for the next decade of commerce. By understanding the technical requirements now, Macronimous can help our clients transition from merely having a website to being fully accessible to the emerging economy of AI agents. The time to start preparing your architecture is today.

The post Preparing for Agentic Commerce Implementation: A Technical Guide to UCP for Developers first appeared on Macronimous Blog.

What does the future of software development in 2026 look like? Looking at the Stack Overflow survey data across 2020, 2023, and 2025, it’s clear we aren’t just seeing new tools—we are seeing a total re-calibration of how we define “productivity” and “trust.”

As a web agency owner who has navigated every tech shift since 1998, here is how I see the last five years of evolution:

2020: The “Flexible Foundation” Era

The industry was in reaction mode. Remote work shifted from a “perk” to a “mandate” (today, ~32% of devs are still fully remote). JavaScript was the undisputed king, and we were focused on building the “digital-first” world. Tools like Jira were the standard for keeping these new, distributed teams in sync. We were focused on connectivity.

2023: The “AI Honeymoon” Era

We entered the “Magic Phase.” Positive sentiment toward AI tools exceeded 70%. Developers rushed to integrate LLMs, and the focus shifted to sheer speed. Barriers to entry dropped, and we felt like we had superpowers. We were focused on acceleration.

2025: The “Cautious Transformation” Era

According to the 2025 data, the honeymoon is over. We have entered a mature, sober phase:

• High Usage, High Skepticism: AI usage is up to 84%, but favorable sentiment has dropped to 60%. The realization? AI is “frequently almost right,” leading to frustration for 66% of developers.
• The Python Surge: Python has jumped 7% in a single year (to 9%), officially becoming the “connective tissue” for the AI era.
• The Rise of the Architect: For the first time, “Architect” is a top-4 role. We aren’t just writing code anymore; we are designing systems that can withstand the chaos of AI agents and complex infrastructure.

My Perspective as an Agency owner:

 In 2020,We hired developers who could write code fast.

In 2023, We looked for developers who used AI to write code faster.

In 2025, We are looking for “Verifiers.”

Like it or not – With 46% of developers now distrusting AI accuracy, the most valuable person in the room is no longer just the coder—it’s the one who can debug the “almost right” logic that AI produces.

The Shift in Analogy:

• 2020: We were builders carrying bricks by hand.
• 2023: We got heavy machinery (AI) and moved at record speeds.
• 2025: We realized the machine sometimes places the bricks slightly crooked. Now, the most important person on the site isn’t the driver—it’s the inspector with the level and the blueprint.

Looking Ahead: 2026 and the “Orchestration Era”

As we look toward 2026 and beyond, my prediction is that the current friction of manual verification will become unsustainable. The industry will respond with a new wave of tooling focused not on generation, but on autonomous validation—think AI agents dedicated solely to security auditing, or automated testing suites designed specifically to catch “LLM hallucinations.” We will move rapidly from the current “Verification Era” into the “Orchestration Era.” In this new reality, the most valuable developers won’t just be checking the AI’s work; they will be defining the high-level business logic and managing the interplay between multiple specialized AI agents, finally elevating the human role from site inspector to master planner.

The post Future of Software Development: From Fast Builders to Master Verifiers first appeared on Macronimous Blog.

Upgrade Laravel Application

Stability can be deceptive in software development. If your Laravel application is running smoothly in production, the incentive to touch the codebase is usually low. However, the ecosystem around your application—specifically PHP versions, security patches, and Composer dependencies—is constantly evolving.

Staying on Laravel 8, 9, or even 10 might feel “stable,” but it introduces silent risks. You aren’t just missing out on features; you are accumulating technical debt. With Laravel 12 pushing the standard to PHP 8.2+, the gap between your current version and modern security standards is widening.

Here is a practical look at why upgrading to the latest stable version is a necessary maintenance step to keep your infrastructure healthy.

The Lifecycle Reality: Why Versions Matter

Laravel releases a major version annually to keep pace with backend technologies. Understanding the support lifecycle is critical for long-term planning.

Here is the current support status:

The Risk: If your application runs on Laravel 8 or below, you are operating without security patches. If you are on Laravel 9, you have a very short window before official support ends.

Key Technical Benefits of Upgrading

1. Security and Compliance (The Non-Negotiable)

Legacy frameworks often rely on older hashing algorithms and session handling methods that modern security standards have surpassed.

• The Impact: New releases patch specific vulnerabilities found in the framework core. Upgrading ensures your application meets current compliance requirements for data handling and payment processing.

2. Performance Optimization

Laravel continuously refactors its core to reduce overhead.

• Routing & Caching: Recent versions have significantly optimized the route registration and container resolution processes.
• PHP 8.2+ Support: Laravel 12 runs on PHP 8.2+. This version of PHP offers JIT compilation improvements and better memory management compared to PHP 7.4 or 8.0.
• Result: For high-traffic applications or API-heavy backends, this translates to lower latency and reduced server resource consumption.

3. Reducing Maintenance Costs (Technical Debt)

The longer you wait to upgrade, the harder it becomes. Skipping from Laravel 8 directly to 12 is a painful, complex migration that often requires rewriting large chunks of code due to “breaking changes” accumulated over four years.

• The Strategy: Incremental upgrades are predictable and low-risk. Delayed upgrades often turn into expensive “rescue projects.”

4. Developer Experience & Modern Tooling

Upgrading allows your development team to utilize modern architectural patterns, making the codebase easier to maintain.

• Laravel 12 Features: Includes cleaner API structures, improved job queue handling, and native support for modern frontend stacks (React/Vue).
• AuthKit: simplifies complex authentication flows like SSO and Passkeys, which are becoming standard user expectations.

When is an Upgrade Urgent?

You should prioritize this migration if:

• Hosting Compatibility: Your hosting provider is deprecating older PHP versions (many are dropping PHP 8.0 support).
• Dependency Hell: You cannot install new packages because they require a newer version of illuminate/support.
• New Feature Development: You are planning a sprint for new features. Building new code on top of a legacy framework is inefficient.

The Upgrade Strategy

We don’t recommend “blind upgrades.” At Macronimous, we treat upgrades as a structured engineering process:

1. Dependency Audit: We analyze composer.json to identify packages that have been abandoned or need replacement.
2. Phased Migration: We step through versions sequentially (e.g., v9 ? v10 ? v11) to isolate breaking changes.
3. Automated & Manual Testing: We run your test suite (Unit/Feature tests) and perform manual regression testing on critical flows.
4. Performance Benchmarking: We compare response times before and after deployment to ensure the upgrade delivered the expected speed gains.

Conclusion

Upgrading Laravel is not about chasing the “shiny new thing.” It is about infrastructure integrity. It ensures your application remains secure, fast, and compatible with the modern web.

At the outset, it may look like too much work—especially when your current site is running fine. But trust me, it is worth it.

If your application is running on a version older than Laravel 10, now is the time to plan your migration path.

Need a technical assessment of your current stack? Contact us to discuss a migration plan that minimizes downtime.

The post Upgrade Laravel Application: A Laravel 12 Migration Guide for Application Owners first appeared on Macronimous Blog.

Back in 2014, we wrote about 10 programming taboos you should break immediately. At that time, topics like version control, commenting code, and not skipping testing were the hot issues for developers.

Fast-forward to 2025 — many of those lessons still hold true. But the context has changed. Cloud-native development, DevOps culture, AI-assisted coding, and global security concerns have added new dimensions to what we consider “taboos.”

Let’s revisit the old list, see what still applies, and then look at the new taboos every developer should avoid today.

The Classic 10 (2014) — Still Relevant

Here’s a quick refresher of the original 10 taboos from 2014:

1. Not honing non-technical skills — soft skills, empathy, communication.
2. Not being judicious about coding — reinventing the wheel, ignoring templates/libraries.
3. Not keeping code understandable — bad naming, no comments, confusing flow.
4. Not using proven tools/techniques — poor error handling, empty catch blocks.
5. Poor version control — missing commits, bad commit messages, no sync.
6. Not keeping oneself updated — lack of training, slow to adopt new trends.
7. Inadequate testing — ignoring unit, mock, and integration tests.
8. Security lapses — input validation, SQL injection, XSS, CSRF.
9. Poor client communication — silence until delivery, reactive updates.
10. Cutting corners under deadlines — sacrificing quality for speed.

What Changed?

Still true: All 10 remain valid — they’re like “coding commandments.”
Changed in emphasis:

• Version control ? From SVN/Mercurial to Git/GitHub/GitLab.
• Testing ? Now expected as automated pipelines in CI/CD.
• Security ? Threats are wider (APIs, cloud misconfigs, supply chain attacks).
• Keeping updated ? Today this means DevOps, AI tools, and cloud-native design.

In other words: the principles haven’t aged — the tools and risks around them have.

The 5 New Programming Taboos of 2025

1. Ignoring Accessibility (the new “responsive design”)

In 2014, responsive design was the buzzword. By 2025, accessibility is no longer optional. Over 1.3 billion people worldwide live with some form of disability (WHO). Accessibility lawsuits have risen steadily — in the U.S. alone, over 4,600 ADA website lawsuits were filed in 2023. Poor accessibility means you alienate real users and risk legal challenges.

Taboo: Shipping a product that only “works on your machine” but leaves out users with screen readers, keyboard navigation, or color blindness.

2. Skipping Dependency Security

Most modern apps are built on hundreds of open-source packages. A single vulnerability can compromise the whole system. The 2021 Log4j vulnerability exposed millions of apps worldwide. Studies show 80–90% of modern codebases are made up of third-party components. Attackers increasingly target supply chains (npm, PyPI, Composer) rather than your core code.

Taboo: Not running automated security scans (Snyk, Dependabot, npm audit) or ignoring patch updates.

3. Overlooking CI/CD and Automation

In 2014, “inadequate testing” meant skipping unit tests. Today, the taboo is larger: not automating the entire flow. Teams that adopt CI/CD pipelines deploy 200x more frequently with far fewer failures (DORA State of DevOps report). Manual builds, deployments, and tests are now considered wasteful and risky.

Taboo: Relying on manual QA and deployment when tools like GitHub Actions, GitLab CI, Jenkins, or CircleCI can handle it safely and repeatedly.

4. Neglecting Observability

In the past, a few log files were enough. Not anymore. Today’s systems are distributed — microservices, cloud functions, APIs across regions. Without logs, metrics, and traces, debugging becomes a needle-in-haystack problem. Gartner reports that 70% of outages in cloud-native systems take longer to fix due to poor observability.

Taboo: Shipping code without proper logging, monitoring, or alerting (using tools like OpenTelemetry, Datadog, Sentry, Prometheus).

5. Blindly Trusting AI-Generated Code

In 2014, the closest thing we had to “AI help” was Stack Overflow. In 2025, AI assistants (GitHub Copilot, ChatGPT, Tabnine) write large chunks of code. A Stanford study found that developers using AI assistants wrote code faster, but introduced 40% more security vulnerabilities when unchecked. AI can hallucinate APIs, misuse libraries, or produce inefficient code.

Taboo: Treating AI as autopilot. The right approach is using AI as a pair programmer — review everything, add tests, and validate against business requirements.

Old vs New: How They Fit Together

The old list covered the foundations. The new list highlights modern realities that didn’t exist (or weren’t mainstream) in 2014.

Wrapping Up

When we first published 10 programming taboos you should break immediately, they felt like reminders to programmers of the “basics.” Ten years later, they still do. But the field has matured, and so have the mistakes.

The new taboos — accessibility, dependency security, automation, observability, and AI misuse — reflect the world we build software in today: cloud-native, AI-driven, and global.

The lesson is clear: Good coding isn’t just about syntax. It’s about responsibility — to your team, your clients, and your users.

The post From 2014 to 2025: Common Programming Mistakes That Still Matter — and 5 New Ones to Avoid first appeared on Macronimous Blog.

Update, October 2026: I first published this post in August 2025. It aged badly, and fast. About three weeks after it went up, the PHP Foundation, Symfony, and Anthropic’s MCP team announced an official PHP SDK, which made both packages I’d recommended the wrong place to start. Then in July 2026 the protocol itself changed shape. So I’ve thrown out the old version and written this one from scratch. (The URL is the same. Almost nothing else is.)

If you write PHP for a living and somebody has asked you to “make the app work with AI agents,” this is what I’d tell you over coffee.

What changed since the first version

Four things, and I’ll go through them in the order they hurt.

• There’s an official SDK now. It’s mcp/sdk, it grew out of Kyrian Obikwelu’s PHP-MCP project and the Symfony AI work, and the Symfony team leads maintenance. It covers servers and clients. It’s also still pre-1.0, and the README says “experimental” in plain words, so pin your version.
• Laravel ships its own package. laravel/mcp is first-party, documented alongside the framework, and comes with Artisan generators, a test API, and an MCP client.
• The protocol went stateless. The 2026-07-28 revision removed the opening handshake and the protocol-level session. More on this below, because for PHP it’s the big one.
• Authorization grew up. OAuth 2.1 is the mechanism the spec documents. A bearer token still works with plenty of clients, but “use an API token” (which is all I said last time) isn’t the whole answer anymore.

And one correction I owe you. The JSON example in the old post called a method named tool. There’s no such method. It’s tools/call, and it was tools/call back then too. Sorry about that.

What a PHP MCP server exposes

This part hasn’t changed, so I’ll keep it short. A server offers three kinds of things to an AI client.

Tools are functions the model can call: create a project, send an invoice, look up an order. Resources are read-only data the client can pull in as context, addressed by a URI. Prompts are reusable templates the server hands to the client.

Start with tools. In the servers we’ve built, tools did nearly all the useful work, and resources came a distant second. I’d leave prompts until a real user asks for one.

Why the stateless spec suits PHP

Until this summer, MCP over HTTP was a conversation. The client opened with an initialize handshake, the server handed back a session ID, and every later request had to carry that ID so the server could remember who it was talking to.

That’s fine in Node or Python, where one long-lived process sits in memory holding the session. It’s a nuisance in PHP, because PHP-FPM on an ordinary host gives you a fresh process for each request that remembers nothing, which meant you needed a session store (files on one server, Redis on several), and then you needed the load balancer to cooperate, and then somebody’s shared hosting plan killed the long-running stream the server wanted to keep open, and at that point a perfectly sane developer would ask why a remote procedure call needed all this furniture.

The 2026-07-28 revision removes the furniture. There’s no handshake and no protocol session. Each request carries its own protocol version and client details, any worker on any machine can answer it, and list results come with cache hints. Cloudflare, AWS, and the MCP maintainers all describe it the same way: MCP now scales like any other HTTP API.

What if your server really does need to remember something, like a cart or a half-finished import? The spec’s guidance is to return a handle from one tool and accept it as an argument on the next. In other words, a primary key. We’ve been doing that since PHP 3.

There’s a cost, and you should hear it from me before you hear it from a client. The new revision isn’t backward compatible. A server that only speaks 2026-07-28 may not work with an older client, and the reverse. So for a while you’ll be supporting both eras, and that’s a good reason to use an SDK instead of hand-rolling the JSON. (We hand-rolled once. I wrote up what happened in building a WordPress MCP server while the spec changed.)

What a tool call looks like on the wire

MCP messages are JSON-RPC 2.0, a small remote procedure call format where every message names a method and carries an ID. Here’s a client asking a server to run a tool.

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "create_project",
    "arguments": {
      "project_name": "New Website Launch",
      "due_date": "2026-12-31"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28"
    }
  }
}

I’ve trimmed the _meta block. The spec requires client info and client capabilities in there too, and your SDK fills them in. On HTTP, the client also sends MCP-Protocol-Version, Mcp-Method, and Mcp-Name headers, so a load balancer or firewall can route the call without opening the body. If you’ve ever fought a web application firewall over a JSON payload (I have, on our own host), you’ll like that.

The server answers like this.

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "resultType": "complete",
    "content": [
      { "type": "text", "text": "Created project 42: New Website Launch" }
    ],
    "structuredContent": { "project_id": 42, "name": "New Website Launch" },
    "isError": false
  }
}

Two details matter. structuredContent is the machine-readable result, and the text block is the fallback for clients that only read text. And when your business logic fails, say the due date is in the past, you return a normal result with isError set to true and a message the model can act on. Save real JSON-RPC errors for broken requests and unknown tools.

Build one in plain PHP with the official SDK

This works in any PHP project: plain PHP, CodeIgniter, Slim, a legacy app with no framework at all. The steps below build a local server that talks over STDIO (standard input and output, the way a desktop AI client starts a server as a child process).

Goal. A PHP file exposes one tool named create_project, and MCP Inspector can call it.

Before you start. You need Composer and Node.js installed. Check the PHP version the SDK requires on its Packagist page before you install.

Step 1: Install the SDK. Run this command in an empty project folder. Composer prints the installed version when it finishes.

composer require mcp/sdk

Step 2: Create the server file. Save this code as server.php in the same folder. The tool body is a stub, so replace it with a call to your own service class later.

<?php

require __DIR__ . '/vendor/autoload.php';

use Mcp\Server;
use Mcp\Server\Transport\StdioTransport;

class ProjectTools
{
    /**
     * Create a project and return its ID.
     */
    public function createProject(string $projectName, string $dueDate): array
    {
        // Call your existing service class here.
        return ['project_id' => 42, 'name' => $projectName, 'due_date' => $dueDate];
    }
}

$server = Server::builder()
    ->setServerInfo('Project Server', '1.0.0')
    ->addTool([ProjectTools::class, 'createProject'], 'create_project')
    ->build();

$server->run(new StdioTransport());

Step 3: Open the server in MCP Inspector. MCP Inspector is the official browser tool for testing a server by hand. Replace the path with the full path to your server.php.

npx @modelcontextprotocol/inspector php /Users/YOU/project-server/server.php

Check. The Inspector’s Tools tab lists create_project with two string inputs. You run it, and the result shows project_id 42.

If it fails. The usual cause is stray output. On STDIO, anything your script prints (a warning, a debug echo, a byte order mark) lands in the protocol stream and breaks it. Send logs to a file or to standard error.

Undo. Delete the project folder. Nothing else on your machine changed.

For a remote server you swap the transport for the SDK’s StreamableHttpTransport, which takes a PSR-7 request (the standard PHP interface for an HTTP message) and returns a response. The transports guide has the wiring. Read the protocol versions page while you’re there. As far as I can tell from the repository, support for the stateless revision has been landing release by release, so check what your installed version speaks before you promise a client anything.

Build one in Laravel with laravel/mcp

If the app is Laravel, don’t use the plain SDK. Use the first-party package. You get the container, validation, policies, and middleware you already know, and the tool class ends up looking like a small controller.

Goal. Your Laravel app serves an authenticated MCP endpoint at /mcp/projects with one tool that creates a project.

Before you start. The package needs PHP 8.2 or newer and Laravel 11, 12, or 13. The steps assume Sanctum (Laravel’s token authentication package) is already installed, and that you have a ProjectService class and a Project policy. Swap in your own names.

Step 1: Install the package.

composer require laravel/mcp

Step 2: Publish the routes file. This command creates routes/ai.php, where MCP servers are registered.

php artisan vendor:publish --tag=ai-routes

Step 3: Generate the server class. The file appears in app/Mcp/Servers.

php artisan make:mcp-server ProjectServer

Step 4: Generate the tool class. The file appears in app/Mcp/Tools.

php artisan make:mcp-tool CreateProjectTool

Step 5: Write the tool. Replace the generated tool with this code. Notice the order: authorize, validate, then call the service.

<?php

namespace App\Mcp\Tools;

use App\Models\Project;
use App\Services\ProjectService;
use Illuminate\Contracts\JsonSchema\JsonSchema;
use Laravel\Mcp\Request;
use Laravel\Mcp\Response;
use Laravel\Mcp\Server\Attributes\Description;
use Laravel\Mcp\Server\Tool;

#[Description('Creates a project for the signed-in user. Needs a name and a due date.')]
class CreateProjectTool extends Tool
{
    public function handle(Request $request, ProjectService $projects): Response
    {
        if (! $request->user()->can('create', Project::class)) {
            return Response::error('Permission denied.');
        }

        $validated = $request->validate([
            'project_name' => 'required|string|max:120',
            'due_date' => 'required|date|after:today',
        ]);

        $project = $projects->create($request->user(), $validated);

        return Response::structured([
            'project_id' => $project->id,
            'name' => $project->name,
        ]);
    }

    public function schema(JsonSchema $schema): array
    {
        return [
            'project_name' => $schema->string()
                ->description('The project name.')
                ->required(),
            'due_date' => $schema->string()
                ->description('The due date as YYYY-MM-DD.')
                ->required(),
        ];
    }
}

Step 6: Register the tool on the server. Open app/Mcp/Servers/ProjectServer.php and set the $tools property.

protected array $tools = [
    \App\Mcp\Tools\CreateProjectTool::class,
];

Step 7: Register the route. Put this code in routes/ai.php. The throttle:mcp middleware expects a rate limiter named mcp, so define one in your AppServiceProvider or remove that entry.

<?php

use App\Mcp\Servers\ProjectServer;
use Laravel\Mcp\Facades\Mcp;

Mcp::web('/mcp/projects', ProjectServer::class)
    ->middleware(['auth:sanctum', 'throttle:mcp']);

Step 8: Open the server in MCP Inspector. Add your Sanctum token as an Authorization: Bearer header when the Inspector asks for connection settings.

php artisan mcp:inspector mcp/projects

Check. The Inspector lists create-project (Laravel derives the name from the class). You call it with a past date, and the tool returns your validation message instead of creating anything.

If it fails. A 401 response means the token header is missing or the token is wrong. An empty tool list means Step 6 was skipped.

Undo. Remove the route from routes/ai.php. The endpoint stops existing on the next request.

One thing I’d do before any of this reaches production: write the validation messages for a machine reader. When validation fails, the model reads your error text and tries again, so “The due date must be a future date in YYYY-MM-DD format” gets you a correct retry and “Invalid input” gets you a loop. (Laravel’s type handling has its own traps here. We wrote about one in integers arriving as strings.)

MCP vs REST vs GraphQL

I get asked whether MCP replaces the REST API. No. They have different callers.

The row that matters is the second one. With REST, a programmer read your docs and decided which endpoint to hit. With MCP, a model reads your tool descriptions and decides on the spot. So the description is part of the interface, and a vague one is a bug.

Don’t write the logic twice, though. Your MCP tool and your REST controller should call the same service class. If your controllers are fat and the logic lives in them, fix that first. It’s the same advice I’d give for splitting a PHP app into services, and it pays off here for the same reason.

Security: what I’d lock down first

An MCP tool is a function on your production app that a language model can run. You are giving a caller that doesn’t understand consequences a button. You are trusting its client to ask a human first. You are assuming nobody slipped instructions into the text it just read. Treat every argument the way you’d treat a form field from a stranger.

The spec lists four things a server must do: validate inputs, enforce access control, rate limit, and sanitize outputs. Here’s how that turns into a pre-launch list.

• Every web MCP route sits behind authentication middleware. No public endpoints, not even for a demo.
• Each tool checks what this user may do, with a policy or gate, inside the tool. Being logged in isn’t permission.
• Each tool validates its arguments with real rules, not just the JSON schema.
• The route has a rate limiter. Models retry, and they retry quickly.
• Read-only tools are marked read-only, and destructive ones are marked destructive, so clients can ask for confirmation.
• Nothing destructive ships in version one. No delete tools, no bulk updates.
• Every tool call is logged with the user, the tool name, and the arguments.
• Tool output is trimmed to what the model needs. No password hashes, no internal IDs you wouldn’t put in an API response.

On authentication: Laravel’s own docs recommend OAuth through Passport, since that’s what the spec documents and what the widest range of clients support. They also say that if you’re already on Sanctum, stay there until a client forces the issue. I agree with that. Don’t bolt on an OAuth server for an internal tool three people use.

And keep a person in the loop for anything that writes. We run an MCP server on one of our own sites that lets an AI assistant edit pages. Every edit lands as a draft, and a human publishes it. That one rule has saved us more than once. It’s the same thinking behind controlled AI coding, and behind my standing worry that the code an AI wants to delete is load-bearing.

Where I’d wait

I’d build an internal MCP server today. I’d be slower about a public, customer-facing one, for two reasons.

Both PHP packages are pre-1.0. APIs will move. The examples in this post matched the documentation on the day I checked them (October 9, 2026), and I’d bet at least one is out of date within a year. Pin versions, and read the changelog before you run composer update.

The protocol also just had its biggest revision since launch. The maintainers added a formal deprecation policy alongside it, which is a good sign, but I’d let clients and SDKs settle for a few months before signing a contract that names a spec version.

If you’re not on Laravel: Symfony has symfony/mcp-bundle, Drupal has an mcp_server module, and API Platform and CakePHP have integrations built on the same official SDK. For WordPress, read the post I linked earlier. That’s about all I know that’s worth passing on. If you’ve shipped a PHP MCP server and something here is wrong, tell me in the comments and I’ll fix it with credit.

FAQ

The post PHP MCP Server: A PHP Developer’s Guide to the Model Context Protocol first appeared on Macronimous Blog.

This is an exciting time for developers, and for a tech-focused people like us at Macronimous.com, diving into new tools like Gemini CLI for Laraval development is definitely a natural fit. Here’s a detailed blog post for Laravel developers on how Gemini CLI can revolutionize their workflow.

Let’s break down what Gemini CLI is, why it matters for Laravel developers, what you might miss if you don’t explore it, and how to get started.

What is Google Gemini CLI?

At its core, the Gemini CLI is an open-source AI agent that allows you to interact with Google’s Gemini models directly from your terminal. Think of your command line as an AI-powered workspace. It’s designed to understand natural language prompts and leverage the advanced capabilities of Gemini 2.5 Pro (which boasts an impressive 1 million token context window in the free tier) to perform a wide range of tasks.

Key capabilities include:

• Code Understanding and Generation: Explain complex code snippets, draft new code, generate unit tests, suggest refactorings, and even help with migrating code.
• Debugging and Troubleshooting: Analyze error messages, pinpoint root causes, and suggest effective solutions for bugs.
• File and Project Management: Use natural language to navigate, summarize, and even modify files within your project structure.
• Command Execution: Translate plain English instructions into executable shell commands.
• Content Generation: Beyond code, it can assist with general content creation, problem-solving, and research, grounding prompts with real-time Google Search results.
• Extensibility: Being open-source (Apache 2.0 license), it supports Model Context Protocol (MCP) servers, allowing for custom tool integrations and extending its functionality.

Essentially, Gemini CLI aims to be a versatile assistant that streamlines your development workflow, making you more productive without leaving the familiar environment of your terminal.

Is it Required for Laravel Developers to Learn and Use Gemini CLI?

“Required” is a strong word in software development, as many paths lead to a successful outcome. However, for Laravel developers aiming for peak efficiency and modern development practices, Gemini CLI is becoming increasingly valuable and highly recommended, though not strictly mandatory.

Here’s why:

1. Complexity of Modern Laravel: Laravel applications, especially larger ones, can involve intricate logic, multiple packages, API integrations, and complex database interactions. Navigating and understanding these can be time-consuming.
2. Increased Productivity: AI tools are no longer a luxury; they are becoming productivity multipliers. Gemini CLI can automate repetitive tasks, provide instant answers, and generate boilerplate code, freeing up developers to focus on more complex, creative problem-solving.
3. Staying Competitive: As AI integration becomes more common, developers who can effectively leverage these tools will have a significant edge in terms of speed, quality, and adaptability.

While you can develop Laravel applications perfectly well without it, embracing such tools pushes you towards a more efficient and less error-prone future.

What Would Laravel Developers Miss if They Don’t Use Gemini CLI?

Choosing to forgo Gemini CLI means missing out on several significant advantages:

• Rapid Prototyping and Boilerplate Generation: Imagine instantly generating a Laravel Livewire component with basic CRUD operations, or a database migration script for a new feature, just by describing it in natural language. Without Gemini CLI, these are manual tasks.
• Accelerated Debugging: Instead of meticulously tracing stack traces, you could paste an error and get intelligent suggestions, potential fixes, and even context-aware code modifications. This drastically cuts down debugging time.
• Deep Codebase Understanding: For large or legacy Laravel projects, understanding how different services, controllers, models, and views interact can be daunting. Gemini CLI, with its large context window, can analyze your entire codebase and provide summaries, architectural overviews, or explain specific Laravel patterns used.
• Optimized Code & Best Practices: You might miss opportunities for AI-driven code reviews that suggest performance improvements, adherence to Laravel conventions, or security enhancements.
• Reduced Context Switching: Staying in your terminal for AI assistance, rather than switching to a browser or other applications, maintains your flow state and improves focus.
• Enhanced Learning: For junior developers, or when learning new Laravel features or packages, Gemini CLI can act as an interactive tutor, explaining concepts, providing examples, and answering questions in real-time.
• Automated Documentation: Generating doc blocks for your Laravel classes, methods, or even entire modules can be automated, ensuring your codebase remains well-documented.

In essence, you’d be missing out on a powerful assistant that can significantly reduce cognitive load and development cycles.

Why Gemini CLI is Not Necessary for Some Developers

Despite its immense benefits, Gemini CLI might not be a game-changer for everyone, or at least not immediately:

• Smaller Projects or Solo Developers (Initial Stages): For very small, simple Laravel projects or developers who prefer a strictly manual approach, the initial setup and learning curve might seem like overkill.
• Highly Specialized Workflows: Developers with deeply ingrained, highly optimized, and unique manual workflows might find adopting a new AI tool disruptive, especially if their existing setup is already extremely efficient for their specific niche.
• Reliance on Specific IDE Features: Modern IDEs like PhpStorm already offer powerful code completion, refactoring, and debugging tools. Developers who heavily rely on these integrated features might not feel the immediate need for a CLI-based AI.
• Bandwidth/Internet Dependency: While the free tier is generous, heavy reliance on any cloud-based AI tool means you’re dependent on an internet connection and Google’s service availability.
• Privacy Concerns (for some): While Google has robust privacy policies, some developers or organizations might have strict internal policies against sending proprietary code to external AI services, even if the data handling is secure.
• “Human in the Loop” Preference: Some developers simply prefer to understand and write every line of code themselves, meticulously, and might view AI generation as a shortcut that reduces their hands-on understanding.

For these developers, the traditional Laravel development workflow remains perfectly viable. However, the capabilities offered by Gemini CLI are rapidly becoming a standard expectation for developer productivity.

How to Start Using Gemini CLI for Laravel Development

If you’re a Laravel developer ready to harness the power of Gemini CLI, getting started is straightforward.

1. Prerequisites:

• Node.js (Version 18 or higher): Gemini CLI runs on Node.js. Ensure you have a recent version installed. You can check with node -v.
• Google Account: You’ll need a personal Google account for authentication. This grants you free-tier access with generous quotas (60 requests/minute and 1,000 requests/day for Gemini 2.5 Pro). For higher limits or specific models, you can use a Google AI Studio API key.

2. Installation:

Open your terminal and choose one of the following installation methods:

• Run Directly (npx): This is great for quick tests or if you don’t want a global installation.

Bash

npx https://github.com/google-gemini/gemini-cli

• Global Installation (Recommended for regular use): This installs gemini as a command accessible anywhere.

npm install -g @google/gemini-cli

3. First Run and Authentication:

After installation, simply type gemini in your terminal:

gemini

On the first run, you’ll be prompted to:

• Choose a color theme: Select your preferred look.
• Authenticate: Select “Login with Google” and follow the browser prompts to sign in with your Google account. This securely links your terminal to Gemini’s AI capabilities.

4. Start Prompting!

Once authenticated, you’ll see the gemini > prompt. Now you can start interacting!

Examples for Laravel Developers:

• Explain Laravel Code:

gemini > Explain this Laravel controller method: @app/Http/Controllers/UserController.php:store

(Use @ to reference files/folders. Gemini CLI will often auto-complete paths).

• Generate a Model & Migration:

gemini > Write a Laravel migration for a `products` table with columns: name (string, unique), description (text, nullable), price (decimal), stock (integer, default 0). Also, create a Product model with fillable properties.

• Debug a PHP Error:

gemini > I'm getting a `Target class [App\Services\PaymentService] does not exist.` error in my Laravel application. Here's my controller: @app/Http/Controllers/OrderController.php. What's wrong?

• Generate a Blade Component:

gemini > Create a simple Blade component for displaying a success alert message. It should accept a `$message` prop.

• Refactor Code:

gemini > Refactor this PHP code to use a more modern Laravel approach: @app/Helpers/OldHelper.php

• Summarize a Project Folder:

gemini > Give me a summary of the `app/Models` directory and the relationships between the models.

Tips for Effective Usage:

• Be Specific: The more context and detail you provide in your prompt, the better the output.
• Use @ for Context: Leverage the @ symbol to include specific files, directories, or even parts of files in your prompt’s context.
• Review and Refine: AI-generated code is a starting point, not always a final solution. Always review, test, and refine the output to fit your exact needs and project standards.
• Explore Commands: Type /help within the Gemini CLI to see a list of available commands and shortcuts.

Conclusion

Google Gemini CLI is a powerful addition to the developer ecosystem, offering Laravel developers an intelligent co-pilot directly in their terminal. While not strictly “required,” embracing such AI-powered tools can significantly boost productivity, enhance code quality, and make the development process more enjoyable. For a web and mobile development business like Macronimous.com, integrating tools like Gemini CLI can translate directly into faster delivery, higher quality, and a more competitive edge in the market.

Start experimenting today, and unlock a new dimension of efficiency in your Laravel development journey!

The post Google Gemini CLI for Laraval development: Your New AI Co-Pilot in PHP programming first appeared on Macronimous Blog.

FrankenPHP Officially Supported by The PHP Foundation: What It Means for Modern PHP Development

At Macronimous, we’ve been crafting robust web applications with PHP for over two decades. Our PHP teams are constantly exploring new horizons, embracing advancements like sophisticated frameworks such as Laravel and dynamic front-ends powered by modern JavaScript frameworks. We’re always seeking ways to enhance our deliverables, making our applications faster, more efficient, and a joy to build.

That’s why we’re particularly excited about the latest news in the PHP world, a development that promises to significantly impact the future of PHP development. If you’re a PHP learner eager to build high-performance applications and streamline your development process, pay close attention! This update is especially for you.

Exciting news just dropped in the PHP world! The innovative FrankenPHP project has officially received support from The PHP Foundation, with its source code now moving to the official PHP project’s GitHub organization. This isn’t just a technical footnote; it represents a significant advancement that promises to substantially improve how we build and deploy PHP applications.

If you’re a PHP developer, whether you’re hearing about FrankenPHP for the first time or wondering how this collaboration impacts your daily work, you’ve come to the right place. Let’s dive into what FrankenPHP is, why it matters, and how this official endorsement will supercharge our development community.

What Exactly Is FrankenPHP?

At its core, FrankenPHP is a modern, high-performance application server for PHP, built atop the powerful Caddy web server and primarily written in Go.

Forget the traditional Nginx + PHP-FPM or Apache + mod_php setups for a moment. FrankenPHP takes a different approach: it embeds the official PHP interpreter directly within the Caddy server. This tight integration is the secret sauce behind its capabilities.

Here’s a quick rundown of its powerful features:

• Blazing Fast Performance: This is a standout feature. FrankenPHP’s “worker mode” keeps your PHP application booted in memory across multiple requests. No more re-initializing your entire framework for every single page load! This can lead to significant speed improvements – think 3.5x faster in some benchmarks, and up to 80% reduction in response times for specific scenarios.
• Modern Web Standards Out-of-the-Box: Thanks to Caddy, FrankenPHP inherently supports cutting-edge web protocols like HTTP/2 and HTTP/3 for faster communication, and even automatic HTTPS via Let’s Encrypt or ZeroSSL. Yes, automatic SSL for free! It also offers “103 Early Hints” for quicker perceived page loads.
• Real-Time Capabilities: Ever wanted to easily add real-time features to your PHP app without a separate WebSocket server? FrankenPHP includes native support for the Mercure protocol, enabling real-time updates and push notifications directly from your PHP code.
• Remarkably Simpler Deployment: This is a highly desirable feature for many. FrankenPHP can compile your entire PHP application – interpreter, web server, extensions, and your code – into a single, standalone executable binary or a straightforward Docker image. Deploying becomes as simple as copying one file or running one container!
• Extensible and Compatible: While written in Go, it’s designed to be compatible with most existing PHP extensions. You can even extend your PHP apps with Go, C, and C++ if you need to!

So, What Does This Mean for You, the PHP Developer?

FrankenPHP isn’t just a fancy new piece of tech; it directly impacts your daily development and deployment workflow:

1. Goodbye Performance Bottlenecks: Imagine your Laravel or Symfony application responding almost instantaneously because it’s already “warm” in memory. This means a snappier user experience for your applications and higher throughput for your servers.
2. Deployment Has Become Simpler: The era of wrestling with complex web server configurations and PHP-FPM pools could be behind us. Building a single executable or Docker image that just runssimplifies CI/CD pipelines immensely, making deployments faster and less error-prone.
3. Modern Features Without the Headache: Want HTTP/3 or automatic SSL? FrankenPHP handles it. Need real-time updates? Mercure is built-in. You can focus on your application’s logic, not infrastructure configuration.
4. Enhanced Developer Experience (DX): Faster local development due to the worker mode means quicker feedback loops. And for command-line tools or self-contained microservices, a single binary simplifies distribution and execution.
5. Potential Cost Savings: More efficient execution means your applications can handle more traffic with fewer resources, potentially leading to lower hosting bills.

How Does Official PHP Foundation Support Elevate the Entire Community?

This collaboration is a massive win for the broader PHP ecosystem:

1. Trust and Mainstream Adoption: When The PHP Foundation officially backs a project, it signals reliability and future commitment. Companies and developers will feel more confident investing time and resources into adopting FrankenPHP, knowing it’s part of the language’s official roadmap.
2. Long-Term Stability and Evolution: With Foundation staff actively contributing, FrankenPHP is guaranteed consistent maintenance and development. This ensures it stays compatible with future PHP versions and continues to evolve with the needs of modern web development. No more worries about a promising project fizzling out!
3. Enhanced Reliability and Compatibility: Official integration means rigorous testing and alignment with core PHP advancements. This translates to fewer bugs, better performance, and seamless compatibility with the latest language features.
4. Increased Visibility and Learning: Being under the PHP project’s umbrella will significantly boost FrankenPHP’s profile. More developers will discover its benefits, accelerating its adoption and driving innovation across the community.
5. Fostering Community Contributions: Moving the codebase to the official PHP GitHub organization makes it easier for the wider community to get involved, contribute code, report issues, and suggest features. This collaborative environment will only make FrankenPHP stronger.
6. Modernizing the PHP Stack: FrankenPHP pushes the boundaries of how PHP applications are served. Its success will encourage the adoption of more efficient deployment strategies and advanced web features, solidifying PHP’s position as a cutting-edge language for modern web development.

The Future is Bright for PHP

The integration of FrankenPHP into The PHP Foundation marks a very important moment for PHP. It’s not just about a new tool; it’s about a renewed commitment to performance, simplicity, and modern capabilities within the PHP ecosystem.

If you haven’t already, now is the perfect time to explore FrankenPHP. Whether you’re building a new project or looking to optimize an existing one, this powerful application server, now with the official backing of The PHP Foundation, is poised to become an indispensable part of your modern PHP development toolkit.

The post FrankenPHP for Modern PHP Development – Now with the support of The PHP Foundation first appeared on Macronimous Blog.