DEV Community: Aaron Lumsden

Vizra Evals and Pest's Evals Plugin: When You Want Which

Aaron Lumsden — Thu, 27 Aug 2026 12:00:00 +0000

If you are testing AI agents in Laravel, there are now two packages with "evals" in the description, and the obvious question is whether you need both.

Short answer: probably not, and which one depends on a single question. Do you need to know whether your agent is good now, or whether it is worse than it was last month?

This is a genuine comparison rather than a sales pitch. I wrote one of them, and there is a section below telling you when to use the other one on its own.

Start with what they share

Vizra Evals is built on Pest. Not alongside it, not as an alternative to it. Your evals are Pest tests, they live in your test suite, and they run through the Pest binary.

Both packages also use the same activation contract:

./vendor/bin/pest             # evals skipped
./vendor/bin/pest --evals     # evals run against the real model

The --evals flag and the PEST_EVALS environment variable mean the same thing to both. That is deliberate. You can have both installed in one suite and neither will fight the other for the flag.

So this is not a migration decision. Nothing has to be torn out.

What Pest's evals plugin does

pestphp/pest-plugin-evals scores agent output inside an expectation. You point it at an agent, give it a prompt, and assert on the response:

expect(CapitalCityAgent::class)
    ->prompt('What is the capital of Japan?')
    ->toBeCorrect(expected: 'Tokyo');

It has a genuinely broad set of expectations. Deterministic ones that cost nothing: toContain(), toMatch(), toBe(), toBeJson(), toHaveToolCalls() and toFollowTrajectory(), which checks tools were called in a given order. Then scored ones that call a model: toBeCorrect(), toBeRelevant(), toBeSafe(), toBeSimilar() for semantic similarity via embeddings, toSatisfy() for plain-English criteria, and toPassScorer() for your own.

Scorers return 0.0 to 1.0 against a configurable threshold. toBeCorrect() is more nuanced than a boolean: an exact match scores 1.0, approximately equal 0.9, a superset of the expected answer 0.8, a subset 0.6, and a contradiction 0.0.

It handles nondeterminism too. repeat() runs the same prompt several times and asserts every expectation against all of the samples, so a test only passes when the agent is consistent. That is the right instinct and a lot of eval tooling misses it.

prompt() also takes a plain closure, not just an agent class, so you can score anything that returns a string.

This is a well-built plugin. If you have read this far expecting me to find fault with it, that is not where this is going.

What Vizra Evals adds

One thing, and everything else follows from it: it keeps the runs.

Every sample, every score, every judge's reasoning, every tool call, every token cost, written to your own database. That turns a passing test into a data point rather than an event.

Once runs are persisted, three things become possible that are not possible from a single assertion.

A baseline. Your first passing run becomes the reference. Everything after it is measured against that rather than against a fixed threshold you guessed at.

Row-level regression detection. Rows are joined across runs by a hash of their content, so the framework knows that "What is your refund policy?" in today's run is the same row as in last month's. When that specific row drops, the build fails and names it:

Eval [pest: answers support questions from documented policy] score 61.7%,
pass rate 33.3% across 6 samples.
Gate failed: 2 rows regressed against the reference run (allowed: 0).
  ↓ regressed: "What is your refund policy?" 96.7% → 51.7%
  ↓ regressed: "Can I return it?" 93.3% → 55.0%

Not "the suite scored 61.7%". Which two inputs got worse, and by how much. That difference matters most in a pull request, where the useful question is never "is this good" but "is this worse than what we had".

History you can look at. A second package, vizra/evals-ui, mounts a dashboard route inside your own app: score trends per suite, any sample's assertions and judge reasoning one click deep, two runs side by side. It reads the same database your evals already write to.

The eval itself looks like this:

it('answers support questions from documented policy', function () {
    expect(SupportBot::class)->toPassEval(fn ($eval) => $eval
        ->dataset(base_path('evals/support.jsonl'))
        ->samples(3)
        ->assert(fn ($a, $row) => $a
            ->notEmpty()->gate()
            ->contains($row->expected())
            ->costBelow(0.02))
        ->judge('Answers using only documented store policy.', min: 7)
        ->gate(minScore: 0.8, maxRegressions: 0)
    );
});

Note maxRegressions: 0. That parameter cannot exist without stored history, and it is the whole argument for this package in one keyword.

When you want Pest's plugin on its own

Plenty of the time. Genuinely.

You have a handful of agents and a handful of checks. If what you need is "this classifier returns valid JSON" or "this agent never recommends a competitor", that is an expectation, and adding a database and a dashboard to it buys you nothing.

You want zero extra infrastructure. Vizra needs a migration. Pest's plugin needs nothing. If you are evaluating in a package rather than an application, or in something with no database at all, that is close to decisive.

You are exploring rather than shipping. Working out whether the prompt is any good in the first place is a different activity from defending it over time. Expectations are the faster loop.

Your agent's quality genuinely does not drift. Some don't. A structured extraction task with a pinned model and a stable prompt can sit still for a year. If nothing changes, there is nothing to compare.

You don't have a baseline worth defending yet. Baselines are only useful once you have a version you are happy with. On week one you are still finding it.

In all of those, the honest recommendation is to use Pest's plugin and stop reading.

When the baseline starts to matter

The switch tends to flip at a specific moment, and it is usually a question someone asks you.

"Did the answers get worse after we changed the model?"

With expectations alone, the answer is a shrug, or a threshold that either failed or didn't. You cannot compare against a number you never wrote down.

Concretely, the baseline earns its keep when:

More than one person changes the prompts. You want the reviewer to see which rows moved, not to take someone's word that it seems fine.
You are changing retrieval. Swapping an embedding model, changing chunk size, adding a reranker. These shift quality in ways that look fine on the three examples you happen to test and quietly get worse on the fiftieth.
You need to explain a regression weeks later. "It got worse sometime in the last month" is a very different investigation from "it got worse on the 14th, on these two rows, and here is what the judge said about each".
Cost is creeping. Per-sample cost is recorded, so you can see it climb rather than discover it on an invoice.
Something is at stake. Regulated work, customer-facing answers, anything where "we think it's fine" is not an acceptable answer to an auditor.

Running both

There is no conflict. A reasonable setup uses Pest's expectations for quick assertions during development, and Vizra evals for the suites you want to defend over time. Both respond to --evals, so one command runs everything.

The docs cover running them side by side if you want the detail.

The summary

	Pest evals plugin	Vizra Evals
Question it answers	Is this agent good?	Is it worse than last month?
Sampling	repeat()	samples()
Scored assertions	Correct, relevant, safe, similar, custom	Judge with criteria and dimensions
Tool call assertions	Yes	Yes
Results persisted	No	Yes, your database
Baseline comparison	No	Yes, per row
Dashboard	No	Optional, self-hosted
Infrastructure	None	A migration
Activation	--evals	--evals

If you are starting today, start with Pest's plugin. It is less to install and it answers the first question you will have.

Come back to this when someone asks whether the answers got worse, and you realise you have no way to know.

If you want to see what kept history looks like before installing anything, there is a live demo with six weeks of runs behind it.

How to Test AI Agents in Laravel (Beyond Fakes)

Aaron Lumsden — Tue, 25 Aug 2026 13:42:33 +0000

Your test suite is green. All twelve AI tests pass, none of them touch a provider, and the whole run takes 200ms. Then someone tightens a system prompt on Tuesday, and three weeks later a customer forwards you a support reply that confidently invented a refund policy you do not have.

Every test still passed. They were never testing for that.

This post is about the gap: what fakes are genuinely good at, what they structurally cannot tell you, and how to test the part they leave out.

Fakes are good, and you should use them

The Laravel AI SDK ships a faking layer that works like every other test double in the framework. You define responses up front and assert the right prompts went out:

use Laravel\Ai\Facades\Ai;

Ai::fakeAgent(SupportBot::class, ['We offer a 30 day return window.']);

$this->post('/chat', ['message' => 'Can I return this?'])
    ->assertOk();

Ai::assertAgentWasPrompted(SupportBot::class, fn ($prompt) =>
    str_contains($prompt->text(), 'return')
);

There is a good Laravel News tutorial on this, and it is worth your time. preventStrayPrompts() in particular is the sort of thing you want on from day one. It fails the test if a code path calls a model you did not expect, which is how you find the accidental LLM call inside a loop before your bill does.

What fakes give you is fast, free, deterministic tests of your code. Does the route authenticate. Does the tool get called with the right arguments. Does the job get queued. Does the response get persisted. Every one of those is your logic, and every one of those should be tested with fakes, in CI, on every commit.

What a fake cannot tell you

A fake returns the answer you wrote. That is the entire point of it, and it is also the boundary.

When you assert that SupportBot returned "We offer a 30 day return window", you are asserting that you typed that string into the test. The model was never consulted. So the test passes identically whether the real agent is excellent, mediocre, or has been quietly degraded by a prompt change three commits ago.

Two different questions, and it is worth being blunt about which is which:

Does my code work? Fakes. Fast, free, deterministic, run on every commit.
Is the answer any good? Fakes cannot help. Nothing in a normal test suite can.

Most teams test the first and assume the second. It holds right up until it doesn't, and the way you find out is a customer.

Why you cannot just write a normal test for it

The obvious next thought is to skip the fake and call the real model. That breaks immediately, for a reason that is easy to state and easy to underestimate.

The same input produces a different answer every time.

Ask an agent the same question five times and you get five phrasings, sometimes five different levels of correctness. So assertEquals is useless, and assertStringContainsString is a coin flip you have dressed up as a verdict. It passes or fails depending on which roll you happened to run in CI.

Worse, a single run tells you nothing about the distribution. An agent that gets it right 95% of the time and one that gets it right 55% of the time both look identical if you sample them once and get lucky. The thing you actually care about is the shape of the answers, not one of them.

That is what an eval is: run each input several times, score every response, and look at the distribution rather than a single sample.

Writing one

Vizra Evals is an MIT-licensed package that does this as Pest tests. Install it as a dev dependency:

composer require vizra/evals --dev
php artisan migrate

An eval looks like a test, because it is one:

use App\Agents\SupportBot;

it('answers support questions from documented policy', function () {
    expect(SupportBot::class)->toPassEval(fn ($eval) => $eval
        ->dataset(base_path('evals/support.jsonl'))
        ->samples(3)
        ->assert(fn ($a, $row) => $a
            ->notEmpty()->gate()
            ->contains($row->expected())
            ->costBelow(0.02))
        ->judge('Answers using only documented store policy.', min: 7)
        ->gate(minScore: 0.8, maxRegressions: 0)
    );
});

The dataset is one JSON object per line:

{"input": "What is your refund policy?", "expected": "30 days"}
{"input": "Can I return a sale item?", "expected": "not eligible"}

And crucially, this does not run in your normal suite:

./vendor/bin/pest             # evals skipped, zero tokens, zero cost
./vendor/bin/pest --evals     # evals run against the real model

That separation matters more than it looks. Evals cost real money and take real time. A test suite that quietly spends $4 every time a junior runs pest is a test suite people stop running.

Three details worth understanding

samples(3). Every row runs three times. This is the whole premise. One sample proves nothing about a nondeterministic system, and three is the smallest number that gives you a mean and a sense of spread. Push it higher for rows you care about most.

->gate(). If notEmpty() fails, everything after it is skipped for that sample, including the judge. A response that came back empty is already broken; sending it to another model to be scored is spending tokens to confirm what you know. Order your cheap deterministic checks first and gate them.

judge(...) is for the things you cannot assert with string matching. "Did it stay within documented policy" is not a substring check. A judge is a second model scoring the first, returning a structured {score, reasoning} rather than prose you have to parse.

The judge needs its own scepticism

LLM-as-judge is the part people adopt fastest and check least. Three things to know before you trust a number it produced.

It grades its own family leniently. Point the judge at a different model family than the agent under test. It is the cheapest correctness win available and it takes one argument.

It rewards length. Longer answers score higher whether or not they are better. If concision matters to you, say so in the criteria, or you are quietly training your agent toward waffle.

An uncalibrated judge is an opinion with a number attached. Label fifty examples by hand, run the judge over them, and measure agreement:

php artisan evals:calibrate storage/labelled.jsonl --criteria="Correctness"

If it disagrees with you 30% of the time, its scores are not data. You will make decisions on those numbers for months, so it is worth an afternoon to find out whether they mean anything.

The part that actually catches regressions

Everything above scores today's run. On its own that is a report card, and a report card with no previous term is close to useless. You have no idea whether 71% is good.

The point is comparison. Your first passing run becomes the suite's baseline. Rows are joined across runs by a hash of their content, so the framework knows that "What is your refund policy?" in today's run is the same row as in last month's. When a specific row drops, the build fails and names it:

Eval [pest: answers support questions from documented policy] score 61.7%,
pass rate 33.3% across 6 samples.
Gate failed: 2 rows regressed against the reference run (allowed: 0).
  ↓ regressed: "What is your refund policy?" 96.7% → 51.7%
  ↓ regressed: "Can I return it?" 93.3% → 55.0%

Not "a test failed". Which inputs got worse, and by how much. That is the output you want in a pull request comment when someone has rewritten a prompt.

Where Pest's own evals plugin fits

Pest ships an evals plugin, and it does the scoring well: toBeCorrect(), toBeRelevant(), toBeSafe(), toSatisfy(), toHaveToolCalls(), toFollowTrajectory(), and repeat() to sample the same prompt several times. If what you need is to assert an agent is behaving right now, that is genuinely all you need, and you should use it.

Vizra Evals sits on top of that rather than against it. The difference is what happens after the run finishes. Every sample is persisted, rows are joined across runs by content hash, and a baseline lets the build fail when one specific row drops. Pest scores a run. This keeps them and compares them.

The two share the same --evals flag and PEST_EVALS environment variable, so both can live in one suite without fighting over the flag. The docs cover running them together.

So which do you use

Both, for different jobs, on different schedules.

	Fakes	Evals
Question answered	Does my code work?	Is the answer still good?
Cost	Zero	Real tokens
Speed	Milliseconds	Minutes
When	Every commit	Before a release, nightly, or when a prompt changes
Catches	Broken wiring, wrong tool, missing auth	Quality drift, regressions, cost creep

Fakes belong in your normal suite and should run constantly. Evals belong on a slower loop: a nightly job, a pre-release gate, or a CI workflow triggered when anything under app/Agents or your prompt files changes.

If you only take one thing from this: the tests you have prove your plumbing works. They were never designed to tell you whether the thing coming out of the pipe is any good, and no amount of adding more of them will change that.

Where to start

Pick your most important agent. Write down ten inputs where you know what a good answer looks like. Real ones, from support tickets or logs, not invented ones. That file is your first dataset, and it is genuinely the hardest part of the whole exercise. Everything after it is mechanical.

If you want to see what the output looks like before installing anything, there is a live demo with real history behind it. The quickstart takes about five minutes, and the source is on GitHub.

Why I Built an AI Agent Framework for Laravel (And Why PHP Deserves AI Too) 🚀

Aaron Lumsden — Thu, 14 Aug 2025 11:05:38 +0000

Update, August 2026: Vizra ADK is retired. v0.0.48 is the final release and there will be no further updates. Laravel shipped an official AI SDK that does this job better than my package did, so I stopped. Use laravel/ai to build agents. I now work on Vizra Evals, which tests them. It is not a replacement for the ADK: the ADK built agents, Evals tests them. This post is left up as history.

For over a decade, I've been building with Laravel. It's been my go-to framework for everything from simple APIs to complex SaaS platforms. But lately, I've felt like a kid with my face pressed against the candy store window, watching the Python developers have all the AI fun.

Every time I wanted to build an AI agent, I'd have to context-switch to Python. LangChain, AutoGPT, CrewAI – they're all amazing, but they're not PHP. They're not Laravel. And that constant switching between ecosystems was killing my productivity.

So I did what any reasonable developer would do after one too many late nights wrestling with Python virtual environments... I built my own AI agent framework for Laravel. 😅

Meet Vizra ADK – the AI Agent Development Kit that brings true agentic capabilities home to Laravel.

The Problem That Kept Me Up at Night 🌙

Picture this: You're building a Laravel app that needs an intelligent customer support agent. In the Python world, you'd spin up a separate service, set up API endpoints, manage different dependency managers, deployment pipelines, and pray that your PHP app and Python agent play nicely together.

But what if your agent could just... be Laravel? What if it could use Eloquent models directly? Queue jobs? Fire events? What if building an AI agent was as simple as extending a base class?

That's the itch I needed to scratch.

The "Aha!" Moment 💡

The breakthrough came when I realized that AI agents don't need to be complicated. At their core, they're just:

A persona (instructions and behavior)
Tools (things they can do)
Memory (context and history)
A brain (the LLM)

That's it. And Laravel already has amazing patterns for all of these!

Your First Agent in Under 5 Minutes ⚡

With Vizra ADK, you can have a working AI agent in literally three commands:

composer require vizra/vizra-adk
php artisan vizra:install
php artisan vizra:make:agent CustomerSupportAgent

Now let's look at what an actual agent looks like:

<?php

namespace App\Agents;

use Vizra\VizraADK\Agents\BaseLlmAgent;

class CustomerSupportAgent extends BaseLlmAgent
{
    protected string $name = 'customer_support';

    protected string $description = 'Helps customers with their inquiries';

    protected string $instructions = 'You are a friendly customer support assistant.
        Always be helpful and provide accurate information.';

    protected string $model = 'gpt-4o';

    protected array $tools = [
        OrderLookupTool::class,
        RefundProcessorTool::class,
    ];
}

That's it. That's a fully functional AI agent. No registration needed – Vizra ADK auto-discovers your agents. You can start using it immediately:

$response = CustomerSupportAgent::run('I need help with order #12345')
    ->forUser($user)
    ->go();

Or chat with it via the command line:

php artisan vizra:chat customer_support

Vizra also has a bneautiful chat UI built in that you can use to chat with your agent.

The Secret Sauce: Tools That Feel Like Laravel 🛠️

This is where things get really exciting. In Python frameworks, giving your agent access to your database or business logic often means building complex bridges. With Vizra ADK, your tools can directly use Eloquent:

<?php

namespace App\Tools;

use Vizra\VizraADK\Contracts\ToolInterface;
use Vizra\VizraADK\System\AgentContext;
use App\Models\Order;

class OrderLookupTool implements ToolInterface
{
    public function definition(): array
    {
        return [
            'name' => 'order_lookup',
            'description' => 'Look up order information by order ID',
            'parameters' => [
                'type' => 'object',
                'properties' => [
                    'order_id' => [
                        'type' => 'string',
                        'description' => 'The order ID to look up',
                    ],
                ],
                'required' => ['order_id'],
            ],
        ];
    }

    public function execute(array $arguments, AgentContext $context): string
    {
        // Just use Eloquent like you always do!
        $order = Order::find($arguments['order_id']);

        if (!$order) {
            return json_encode(['error' => 'Order not found']);
        }

        // Your agent now has access to your actual business logic
        $order->load(['items', 'customer', 'shipping']);

        return json_encode([
            'order_id' => $order->id,
            'status' => $order->status,
            'total' => $order->total,
            'customer' => $order->customer->name,
            'items' => $order->items->map(fn($item) => [
                'name' => $item->product->name,
                'quantity' => $item->quantity,
                'price' => $item->price,
            ]),
        ]);
    }
}

Your existing Laravel code IS the agent's toolkit. No API layers. No serialization headaches. Just PHP. 🎉

Memory That Persists (Because Context Matters) 🧠

One of the coolest features is how Vizra ADK handles memory and context. Every conversation is automatically persisted, and agents can maintain state across interactions:

// The agent remembers previous conversations
$response = PersonalShoppingAssistantAgent::run('Find me a gift for my mom')
    ->forUser($user)
    ->withSession($sessionId)
    ->withContext([
        'budget' => 200,
        'occasion' => 'birthday',
    ])
    ->go();

// Later in the conversation...
$response = PersonalShoppingAssistantAgent::run('She loves gardening')
    ->forUser($user)
    ->withSession($sessionId)  // Same session = continued context
    ->go();
// The agent remembers the budget, occasion, AND now knows about gardening!

The AgentContext class manages all of this elegantly, passing state between your agent and its tools:

class CartManagerTool implements ToolInterface
{
    public function execute(array $arguments, AgentContext $context): string
    {
        // Get current cart from context
        $cart = $context->getState('cart', []);
        $budget = $context->getState('budget');

        // Add item to cart
        $cart[] = [
            'id' => uniqid('item_'),
            'name' => $arguments['item_name'],
            'price' => $arguments['item_price'],
        ];

        // Update context state
        $context->setState('cart', $cart);
        $context->setState('total_spent', array_sum(array_column($cart, 'price')));

        return json_encode([
            'success' => true,
            'cart_total' => $context->getState('total_spent'),
            'remaining_budget' => $budget - $context->getState('total_spent'),
        ]);
    }
}

Multi-Model Support (Because Vendor Lock-in Sucks) 🔄

Thanks to the amazing Prism PHP library, Vizra ADK works with all major LLM providers out of the box:

// Use OpenAI
protected string $model = 'gpt-4o';

// Or Claude
protected string $model = 'claude-3-opus';

// Or Gemini
protected string $model = 'gemini-2.0-flash';

// Or local Ollama
protected string $model = 'llama3:latest';

Switch providers with just an environment variable. Your code doesn't change. I learned this lesson the hard way with payment gateways years ago – never again! 😂

The Laravel Advantage 🏆

Here's what makes Vizra ADK special for Laravel developers:

1. Eloquent Integration

Your agents can directly query your database, update models, and leverage all your existing scopes and relationships.

2. Queue Integration

Long-running agent tasks? Just queue them:

CustomerSupportAgent::run($message)
    ->forUser($user)
    ->async()
    ->onQueue('agents')
    ->go();

3. Event System

Agents fire Laravel events at key points:

Event::listen(AgentExecutionFinished::class, function ($event) {
    Log::info('Agent completed', [
        'agent' => $event->agent,
        'duration' => $event->duration,
        'tokens_used' => $event->tokensUsed,
    ]);
});

4. Artisan Commands

Everything is accessible via Artisan:

php artisan vizra:agents          # List all discovered agents
php artisan vizra:chat agent_name # Interactive chat
php artisan vizra:trace abc-123   # Debug execution traces
php artisan vizra:dashboard       # Web UI for testing

5. Evaluation Framework

Test your agents at scale with the built-in evaluation system:

php artisan vizra:make:eval CustomerSupportEval

Then define your test cases in CSV and run automated evaluations:

class CustomerSupportEvaluation extends BaseEvaluation
{
    public string $csvPath = 'app/Evaluations/data/customer_support_tests.csv';

    public function evaluateRow(array $csvRowData, string $llmResponse): array
    {
        // Validate the agent's response
        $this->assertResponseContains($llmResponse, 'help');
        $this->assertResponseHasPositiveSentiment($llmResponse);

        // Or use LLM-as-Judge for subjective evaluation
        $this->judge($llmResponse)
            ->using(QualityJudgeAgent::class)
            ->expectMinimumScore(7.0);

        return parent::evaluateRow($csvRowData, $llmResponse);
    }
}

Real-World Example: Multi-Agent Workflows 🔄

Where Vizra ADK really shines is when you need multiple agents working together:

use Vizra\VizraADK\Facades\Workflow;

// Sequential workflow - each agent processes results from the previous
$workflow = Workflow::sequential()
    ->then(ValidateOrderAgent::class)      // Checks inventory, pricing
    ->then(PaymentProcessingAgent::class)  // Handles payment
    ->then(FulfillmentAgent::class)        // Creates shipping labels
    ->then(NotificationAgent::class);       // Emails customer

// Execute the entire workflow
$result = $workflow->execute($orderData, $context);

// Or use parallel execution for independent tasks
$notifications = Workflow::parallel([
    EmailAgent::class,
    SmsAgent::class,
    SlackAgent::class
])->waitForAll()->execute($message, $context);

Each agent can access the results from previous agents, creating complex, intelligent workflows that would be a nightmare to orchestrate across language boundaries.

The Debug Experience That Doesn't Suck 🐛

I spent weeks debugging AI agents with just print statements before building proper tracing into Vizra ADK:

php artisan vizra:trace abc-123-xyz

This shows you:

Every LLM call with prompts and responses
Tool executions with inputs and outputs
Token usage and costs
Execution timing for performance optimization
Memory updates and context changes

Or use the built-in web dashboard:

php artisan vizra:dashboard

Now you get a beautiful Livewire-powered interface where you can chat with your agents, see real-time traces, and monitor performance. Finding bottlenecks went from 2 hours to 2 minutes. 🎯

Early Success & Community Response 💙

Since launching Vizra ADK:

65 downloads in the first week
49 stars on GitHub
Amazing feedback from the Laravel community
Several production deployments already!

But what excites me most is seeing what people are building:

A legal document analyzer that uses existing Laravel permissions
A code review bot that integrates with existing CI/CD pipelines
An intelligent inventory manager that predicts stock needs
A customer service bot that actually understands context

What's Next? 🚀

I'm actively working on:

Cloud platform for managed evaluations and monitoring

Join Me on This Journey 🤝

Look, I get it. "Another framework" might make you roll your eyes. But if you're a Laravel developer who's been watching the AI revolution from the sidelines, or struggling with Python integration, give Vizra ADK a try.

It's MIT licensed, fully open source, and built by someone who's been in the Laravel trenches for over a decade. I built this because I needed it, and I'm betting you do too.

composer require vizra/vizra-adk
php artisan vizra:install
# Join me on this journey

GitHub: https://github.com/vizra-ai/vizra-adk

Documentation: https://vizra.ai/docs

X: @aaronlumsden

Let's show the world that PHP deserves a seat at the AI table. Because Laravel developers shouldn't have to learn Python just to build intelligent applications.

We already have the best web framework. Now we have AI agents to match. 🚀

What are you building with AI? Have you felt the PHP/Python divide? I'd love to hear your thoughts in the comments!

Video courses to improve your web development skills

Aaron Lumsden — Sat, 27 Apr 2019 09:58:41 +0000

Hey there I've created a new website where any one can learn web development for free. I'd love to hear your thoughts & feedback on it.

Courses include Laravel, Vue.js, JavaScript, React.js, Angular.js, Node.js, Python and PHP. Let me know what you think? 👍

https://codevideos.co/