Mert

Coding with agents definitely gives you more power. With a couple of sentences in natural language, you can create something that would take weeks. Yet I feel there is a fundamental flaw in this process: you need to wait too long for a result. Agents give you superpowers, but they destroy flow state.

Before we start with agents, I must confess that I freak out when there is too much delay between me typing a key and a letter appearing in the editor. That’s the kind of thing that distracts me, even if it’s only milliseconds. I remember trying a lot of markdown editors a couple of years ago and rejecting them one by one because the character I typed was not there immediately. It was that distracting.

I also use a Vim plugin in my IDE because it allows me to make small changes very fast: appending text at the beginning or end of the line (I, A), removing multiple lines with a single command (d + 11 + ↓), or selecting and substituting a block of text. And then there’s the killer feature: the dot shortcut (.), which repeats the last edit action.

Tab is the new dot

But to be honest, I use Vim’s dot less often now. Cursor guesses your intent, suggests the location of the next change, and you just press tab. It moves the cursor there, you press tab a second time, and the change is applied. You don’t need an internal monologue about which sequence of operations to repeat with a dot, and you don’t need to navigate to that line. Everything just happens, immediately.

I wish I could have something similar with agent-assisted coding.

Typically, when you code by hand, you want to keep the time between change and validation short. Compilation should be real time, with hot reload in the running app. Tests should run fast. Programming is the art of minimizing feedback loops.

If you don’t optimize it and you make a change, you need to wait a couple of minutes for test results. You get distracted. You’re either idle, browsing social media, or starting another task. When the tests eventually finish, you need to recall the context, which takes time and effort. That effort accumulates and makes you tired.

The multi-agent context-switching hell

When an agent is doing a coding task, it usually takes a couple of minutes. Enough to get distracted. Worse, it feels easy to trigger another agent.

Agent thoughts displayed by Cursor or Claude feel like progress, but they’re just a spinner with better PR. You can stare at them, sure, but it seems like a waste of time.

You end up spinning another agent while waiting for the current one. First, you need to think about what you want to achieve and then type an informative prompt, maybe reformulating it a couple of times because the first version seems ambiguous. Then you press enter and check the status of the current sessions. Once you find the one that ended, you need to recall what the project was and what the agent was actually doing. Yet another context switch.

You have multiple tasks running in parallel and multiple contexts, and you switch over and over. It’s draining. You feel overwhelmed, your context evaporates, and your performance collapses.

This is me managing a dozen agent sessions at the same time. Stranger Things, Netflix

The ideal world?

Fast local feedback loops like hot reload, instant tests, and Cursor Tab provide superpowers while preserving deep work. In contrast, slow agent loops offer similar benefits, but at the cost of cognitive overload.

In an ideal world, I type my intent in a more convenient way than verbose natural language, maybe with some lightweight meta-language that strips out the fluff, maybe with a non-invasive brain-computer interface.

Then the result appears immediately. The app I’m working on is refreshed automatically and I can see a nice diff, such as the one presented by Cursor. Possibly I can even browse alternate versions and pick the one that fits best. Then I review, point out issues, and ask for improvements.

I can iterate fast in the same window, focusing on a single project and staying deeply focused on the task I want to achieve. That would be faster and less draining than managing multiple agents at the same time.

We are not there yet, but I believe we’ll reach that point. Maybe fast agents will win over autonomous ones, and we’ll regain flow state.

Originally posted at www.dzikowski.online.

Print receipts directly to any ESC/POS thermal printer from your web-based POS system — no SDK, no cloud, no hassle.

The Problem

Browsers can’t talk to thermal printers. Bluetooth SDKs are buggy. Cloud printing is slow.

The Solution

POSBridge – a free Android app that acts as a bridge between your PHP web app and USB/Bluetooth/Network thermal printers.

⚡ How Direct Thermal Printing Works

PHP → Encode → Custom URL → Android → POSBridge → Printer

This method uses Android deep linking to pass print data.

🧾 PHP ESC/POS Receipt Example

Use this optimized PHP code:

<?php 

$data = "[C]<font size='big'><b>POSBRIDGE STORE</b></font>n".
"[C]Calicut, Keralan".
"[C]Tel: +1 9605884551n".
"[L]n".
"[C]--------------------------------n".
"[C]<b>INVOICE</b>n".
"[C]--------------------------------n".
"[L]Order No : 045n".
"[L]Date     : 19-03-2026n".
"[L]n".

"[L]<b>Item</b>            [R]<b>Price</b>n".
"[C]--------------------------------n".

"[L]Beautiful Shirt     [R]$9.99n".
"[L]  Size: Sn".
"[L]n".

"[L]Awesome Hat         [R]$24.99n".
"[L]  Size: 57/58n".
"[L]n".
"[C]--------------------------------n".
"[R]Subtotal           $34.98n".
"[R]Tax (5%)           $1.75n".
"[C]--------------------------------n".
"[R]<b>TOTAL</b>       <b>$36.73</b>n".
"[C]================================n".
"[L]n".
"[L]<b>Customer</b>n".
"[L]Arshid KVn".
"[L]Calicut, Keralan".
"[L]Ph: +1-9605884551n".
"[L]n".
"[C]<qrcode size='25'>https://phpbolt.com</qrcode>n".
"[L]n".
"[C]Thank you for your purchase!n".
"[C]Visit againn";

// Compress print data
$compressed = gzencode($data, 9);

// Encode for URL (important for Android intent)
$encoded = rtrim(strtr(base64_encode($compressed), '+/', '-_'), '=');

// Trigger print via deep link
echo "<a href='pos-bridge://print?print-data=".$encoded."'>Print Receipt</a>";

Quick Start

1. Install – POSBridge on Google Play

2. Connect – Pair your thermal printer (USB/Bluetooth)

3. Copy – Use the PHP code above

4. Print – Click the link from any Android browser

When writing immediate mode (egui) applications it comes to me quickly that nigh all logic computations should be done off the UI thread. There are many ways to approach it, however as a fan of event-based systems sooner or later I implement some kind of event handling. The pattern is almost the same with minor differences and looks like this:

#[derive(Clone)] pub struct ProcessorConfig { pub id: String }
#[derive(Clone)] pub struct TaskResult { pub success: bool }
pub struct State { pub active_tasks: Vec<u32> }

#[derive(Clone)]
pub enum Event {
  ProcessorStart { config: ProcessorConfig },
  ProcessorStop,
  LongRunningTask { id: u32 },
  LongRunningTaskComplete { task_result: TaskResult },
}

struct EventHandler {
  state: Arc<RwLock<State>>,
  tx: tokio::mpsc::Sender<Event>,
}

impl EventHandler {
  fn handle(&self, event: Event, event_queue: &mut VecDeque<Event>) {
    use Event::*;
    match event {
      ProcessorStart { .. } => self.process_processor_start(event, event_queue),
      ProcessorStop => self.process_processor_stop(event, event_queue),
      LongRunningTask { .. } => self.process_long_running_task(event, event_queue),
      LongRunningTaskComplete { .. } => self.process_long_running_task_complete(event, event_queue),
    }
  }

  fn process_processor_start(&self, event: Event, _event_queue: &mut VecDeque<Event>) {
    let Event::ProcessorStart { config } = event else {
      return;
    };
    println!("Starting processor with config: {}", config.id);
    // ...
  }

  fn process_processor_stop(&self, event: Event, _event_queue: &mut VecDeque<Event>) {
    let Event::ProcessorStop = event else {
      return;
    };
    println!("Stopping processor...");
    // ...
  }

  fn process_long_running_task(&self, event: Event, _event_queue: &mut VecDeque<Event>) {
    let Event::LongRunningTask { id } = event else {
      return;
    };

    println!("Starting task {}", id);
    if let Ok(mut state) = self.state.write() {
      state.active_tasks.push(id);
    }
  }

  fn process_long_running_task_complete(&self, event: Event, _event_queue: &mut VecDeque<Event>) {
    let Event::LongRunningTaskComplete { task_result } = event else {
      return;
    };

    println!("Task completed. Success: {}", task_result.success);
    if let Ok(mut state) = self.state.write() {
      state.active_tasks.clear(); 
    }
  }

…

Design rationale

Code above has some design decisions that were developed over the years and it has specific needs “baked in” as a result. E.g.:

1. Serialization/deserialization and clone for Event is very important. I want to save stream to be able to: recreate the state, re-run event, create an event log etc. Starting with serialization and clone requirement makes sure that all events have adequate shape.

2. Arc<RwLock<State>> allows to defer processing to background threads and make a callback with state modification. It also keeps Sender<Event> for interacting with event system.

3. &mut VecDeque<Event> is an event pushback, it works with following loop pattern:

   loop {
       let first = rx.recv().await?;
       queue.push_back(first);

       while let Ok(ev) = rx.try_recv() { 
           queue.push_back(ev); 
       }

       while let Some(ev) = queue.pop_front() {
           self.handle(ev, &mut queue).await;
       }
   }

Doing self.tx.clone().send(...) in the same thread could end up deadlocking receiver and the whole application. To avoid deadlock same-thread processor can send event directly to queue instead. Another feature coming from the pattern is also an in-place event transformations. For example it allows for upgrading events without changing processing order (by event_queue.push_front during processing logic).

I’ll note that in example I didn’t use Envelope pattern – even though in final code I do. In a nutshell: Envelope replaces Event with a wrapper-like structure, i.e. Envelope { event: Event, ...}. Extra data can be included in envelope, a data that doesn’t impact on processing but provides useful information. Such data can be, for example, a tracing::Span (for telemetry it is almost required) or (in distributed systems) origin system, timestamps, correlation etc. Envelopes should be processed in a same way by processors and they add to boilerplate. EventEnvelope processor could like like this:

#[tracing::instrument(skip_all, parent: &envelope.span)]
fn process_some_task(&self, envelope: EventEnvelope, event_queue: &mut VecDeque<EventEnvelope>) {
  CustomCounter::count_origin(envelope.origin);
  let Event::SomeTask { value } = envelope.event else { return ; };

  // ...
}

A Perfect World

After implementing same thing thrice I was ready to make a macro for it. I love macros, even though I understand that they shadow the code and add to complexity. This is the same code as the initial example, but in proc-macro version.

#[derive(Clone)] pub struct ProcessorConfig { pub id: String }
#[derive(Clone)] pub struct TaskResult { pub success: bool }
pub struct State { pub active_tasks: Vec<u32> }

struct EventHandler {
    state: Arc<RwLock<State>>,
    tx: tokio::mpsc::Sender<Event>,
}

#[event_macros::event_processor]
impl EventHandler {
    #[handler(ProcessorStart)]
    fn process_processor_start(&self, config: ProcessorConfig) {
        println!("Starting processor with config: {}", config.id);
        // ...
    }

    #[handler(ProcessorStop)]
    fn process_processor_stop(&self) {
        println!("Stopping processor...");
        // ...
    }

    #[handler(LongRunningTask)]
    fn process_long_running_task(&self, id: u32) {
        println!("Starting task {}", id);
        if let Ok(mut state) = self.state.write() {
            state.active_tasks.push(id);
        }
    }

    #[handler(LongRunningTaskComplete)]
    fn process_long_running_task_complete(&self, task_result: TaskResult) {
        println!("Task completed. Success: {}", task_result.success);
        if let Ok(mut state) = self.state.write() {
            state.active_tasks.clear(); 
        }
    }
}

I really, really like it. Transformed code from that example is the same as the initial code.

What transformations are doing?

On the top there’s:

#[event_macros::event_processor]
impl EventHandler {
  // ...
}

That’s an actual entry point in the macro, it gathers all the information needed and from that it outputs:

• Full pub enum Event { ... } definition
• run(&self, event: Event, event_queue: &mut VecDeque<Event>) implementation (listen, add to queue, handle from queue)
• impl Debug for Event (for debugging purpose it’s helpful to know the name of current event)
• transformed fn process_ ... functions

Visualized, this is how transformation happen:

Why proc-macro at all

If I’d try hard enough I could (probably) achieve similar result with macro_rules! macro. And I tried!

There is however one thing that I really hate when working with such macros: rust-analyzer and rust-fmt giving up on everything. I don’t get inspection, I don’t get completion, I don’t get formatting. For simple macros that’s fine – I can live with a couple non-completed arguments. Yet, with event-driven architecture, the core logic actually lives in handlers, so I didn’t want to be deprived of these helpers.

When switching to proc-macros an interesting part is that processor functions are perfectly valid ones! rust-analyzer sees input and output types. I also do some magic (that I don’t like but hey…): when EventEnvelope or VecDeque<EventEnvelope> is in function inputs I forward the variable name to body processing, i.e.

#[handler(WithEnvelope)]
fn process_with_envelope(&self, my_envelope: EventEnvelope) { ... }

becomes:

fn process_with_envelope(&self, env: EventEnvelope, event_queue: &mut VecDeque<EventEnvelope>) {
  let my_envelope = env;
  // ... rest of the code
}

Production code

You can see implementation of (macroized) code at one of my open source projects.

There are however, some notable differences.

• As I mentioned before: I’m using EventEnvelope and tracing for telemetry, so the actual code is slightly more complex:

  fn process_my_event(
    &self,
    env: EventEnvelope,
    queue: &mut ::std::collections::VecDeque<EventEnvelope>,
  ) {
    let Event::MyEvent { item, value } = env.event else {
        unreachable!();
    };
    {
        println!("Hello from MyEvent");
    }
  }

• handle and run functions are asynchronous (because my spawned processor is asynchronous one)

…implementation?

It’s here. I won’t go into implementation itself, but I need to say that TODAY it’s easier than it was some time ago.

LLMs are quite capable in generating proc-macro code given simple instructions, and once I grasped the main concept it was actually quite easy (especially using proc-macro, proc-macro2 and syn crates). In case you wonder, the most important pieces are:

• proc-macro is the only crate that can produce proc-macros and it must produce proc_macro::TokenStream as output

• proc-macro2 provides many utilities, but outputs proc_macro2::TokenStream – incompatible, but easily convertible to and from proc_macro::TokenStream

• syn is creating structs of actual code – things like FnItem or Variant for enums, you can construct them by hand

• syn is using proc-macro2 for utilities

• code pieces can be generated using quote! (or quote_spanned! if you want to hint user of what is actual source of errors)

• parse_quote! can be used to fill in syn structs, e.g.

  method.sig = parse_quote! { fn some_func(a: u32, b: u32) -> u32 };

Once I internalized, used some help from LLMs implementation was quite smooth.

At the end of the day

…I’m really happy with the result. Adding new Events was a chore, usually required at least for places to put the code in:

• call site
• Event enum
• handle function
• boilerplate heavy processor_ function

After the change it became only 2, much simplified and deprived of boiler plate.

I considered packing this into a crate (because I KNOW this pattern is good and reusable) but I have some doubts about it.

I don’t know if there’s any audience: would I use such crate? No idea. Maybe they exist. It’s also opinionated – using tracing and serde for serialization. Also it raw crates Event and EventEnvelope in the current namespace, which might be conflicting. Then I require async processing run to dispatch events to handle.

So maybe someday, but if anyone stumbles upon it, the proc-macro implementation is only 300 lines of code (excluding tests) and is pretty straightforward to modify. Maybe it’s enough?

We can build software faster than ever now.

With AI-assisted development, scaffolding features, generating components, writing utilities, and even shaping entire flows can happen in a fraction of the time it used to take. That speed is exciting. It lowers the barrier to turning ideas into working products. It helps solo developers move faster. It helps teams prototype more aggressively. It helps side projects become real products. But it also introduces a new kind of risk: we can create code much faster than we can truly understand, review, and sustain over time.

In many projects, especially frontend projects, architectural problems do not appear all at once. They accumulate quietly. A component grows beyond its original responsibility. A shared UI element ends up living in the wrong place. A folder structure starts to drift. Warning signals become scattered. Complexity spreads across the workspace in ways that are easy to miss when all attention is focused on shipping the next feature.

That is the problem space that led me to build Modulens.

The source code and npm package links are available below.

Why I started this project

I kept coming back to the same thought: we already have tools that help us write code faster, but we do not always have equally strong tools to help us see the structural health of a project as it evolves.

When a codebase is still small, many things feel manageable. You can open a few files, navigate by memory, and reason about the whole system in your head. But once a project grows, that changes. The cost of understanding structure increases. Large components become normal. Risky patterns hide inside otherwise “working” code. The project may still compile, the UI may still render, and features may still ship, but maintainability starts to slip.

That is where I felt there was room for a tool focused on visibility.

Modulens is a brand of architecture, structure, and quality analysis tools for frontend workspaces. Right now, the Angular package is the first available implementation, while the broader repository is designed to support more frameworks over time.

What Modulens is

Modulens for Angular is a CLI tool that analyzes Angular workspaces and generates architecture, structure, and quality reports. Its goal is not to replace code review, static analysis, or team judgment. Its goal is to make certain signals more visible: large components, architectural risks, warning hotspots, and areas that may need refactoring.

That distinction matters to me.

I did not want to build a tool that simply says “this is wrong.” I wanted to build something that helps answer questions like:

• Where is complexity accumulating?
• Which parts of this workspace deserve attention first?
• Which components may be carrying too much responsibility?
• Where might maintainability start becoming expensive?
• What deserves investigation before it turns into a larger problem?

In other words, Modulens is meant to support architectural awareness.

Why Angular was the first step

I started with Angular because Angular projects often have a strong sense of structure, and that makes structural drift especially interesting. When the architecture is healthy, Angular workspaces can feel very clear and scalable. But when boundaries start to blur, the project can gradually become harder to reason about.

You might still have a working application, but the internal shape of the codebase may be telling a different story.

That makes Angular a good place to start for a tool like this. There is a lot of value in surfacing structural signals early, before teams normalize complexity just because the project continues to function.

The long-term idea is broader than Angular. The Modulens repository itself is intended as a multi-framework foundation, with Angular available today and future packages for other ecosystems being part of the vision.

How Modulens works today

The current Angular package is intentionally simple to start using.

You can install it globally and run modulens scan, or use it as a one-off command with npx @modulens/angular scan. It can scan the current working directory or a specific Angular workspace path.

npm install -g @modulens/angular
modulens scan
or:

npx @modulens/angular scan

his simplicity was important to me. I wanted the first run experience to be straightforward: point the tool at a workspace and get something useful back quickly.

By default, Modulens writes an HTML report under .modulens/reports/, opens it in the browser after a successful run, and also saves a JSON snapshot under .modulens/snapshots/ from the same analysis run. That means even when HTML is the main experience, the structured machine-readable result is still preserved.

The output philosophy: human-readable first, automation-ready too

One of the design decisions I care about most is the combination of HTML output for people and JSON output for systems.

The default HTML report is there because architecture and maintainability are often easier to understand visually. You want to scan patterns. You want summaries. You want to identify where to look first. You want something that feels explorable, not just a raw dump of data.

At the same time, structured JSON matters because modern workflows are increasingly automated. Teams may want to archive results, inspect them in scripts, use them in CI, or compare outputs over time. Modulens supports JSON output through –format json, lets you control output paths with -o / –output, supports –no-open for HTML generation without opening a browser, and even allows JSON to be written to stdout with –output -. HTML, intentionally, is not supported on stdout.

That split reflects how I think developer tools should behave: they should be useful both in a local developer workflow and in a more automated environment.

What the report is trying to reveal

The real value of a tool like this is not the scan itself. It is the questions the scan helps you ask.

A healthy project is not necessarily a project with zero warnings. A healthy project is one where important signals are visible, understandable, and actionable.

That is why Modulens is focused on surfacing things like:

• large components
• architectural risk signals
• warning hotspots
• areas that may need refactoring
• overall structure and quality patterns across the workspace

On the HTML side, the report includes an Overview section with an executive summary and Priority focus, specifically to make the first reading experience more useful. Instead of throwing the user directly into raw details, the idea is to first answer: What is the scale of what I’m looking at? What looks important? Where should I start?

That framing matters because analysis tools can easily become noisy if they do not guide attention.

Building for real workflows, not just demos

A lot of tools look good in isolated examples but feel harder to trust in day-to-day development. I wanted Modulens to move in the opposite direction.

That means caring about practical details:

• sensible default output behavior
• support for explicit file output paths
• support for JSON pipelines
• browser opening behavior that can be disabled
• a saved workspace snapshot from each successful run
• a public JSON shape with a top-level schemaVersion for compatibility awareness

The schemaVersion detail is especially important. If people want to build automation or downstream tooling on top of Modulens output, they need a stable contract mindset. The README explicitly distinguishes schemaVersion from toolVersion, which helps clarify how consumers should think about parsing compatibility versus tool release history.

That may sound like a small implementation detail, but for tooling, small details often shape trust.

The bigger motivation behind Modulens

I think developer tooling is entering a new phase.

For a long time, many tools focused primarily on syntax correctness, lint rules, formatting, and build pipelines. Those are still important. But the way we write software is changing. AI can help generate more code, more quickly, and with that comes a new pressure point: structural oversight.

The challenge is no longer only “can we produce code?”
It is increasingly “can we understand the system we are producing?”

That is the motivation behind Modulens.

I am interested in tools that help developers reason about software at a higher level:

• structure
• boundaries
• responsibility distribution
• maintainability trends
• architectural signals that are easy to miss when velocity is high

I do not think the answer is more noise. I think the answer is better visibility.

Why this is still an early project
Modulens is still early, and I think that is worth saying clearly.

I would rather publish a useful tool early, let real developers try it, and improve it through actual feedback than wait for some imaginary “perfect” version. Early tools have rough edges. They also have an advantage: they can evolve in direct conversation with the people who might use them.

That is how I want this project to grow.

The current release is focused on Angular workspaces, but the broader idea is intentionally larger. The repository is already framed as a foundation for a family of frontend workspace analysis tools, with Angular available first and React, Vue, and Flutter part of the broader direction I want to explore over time.

Who I think Modulens is for

I think Modulens can be useful for several kinds of developers:

Solo developers who are shipping quickly and want another layer of visibility before complexity gets away from them.

Frontend teams who want a faster way to inspect structural risk and identify where architectural attention is needed.

Tech leads and reviewers who want a higher-level view of maintainability signals across a workspace.

Developers experimenting with AI-assisted workflows who want speed without losing visibility into what the codebase is becoming.

If any of that sounds familiar, then Modulens is built with that kind of workflow in mind.

Try it

I recently released Modulens 0.2.0, and this is still just the beginning.

If you work with Angular and the problem of hidden architectural drift sounds familiar, I’d love for you to try it, inspect the output, and tell me what feels useful, what feels noisy, and what you would want a tool like this to detect next.

npx @modulens/angular scan

The package is available on npm, and the project is open on GitHub. The Angular package is currently the active entry point, and the repository positions Modulens as a growing set of frontend architecture, structure, and quality analysis tools.

If the future of software development is faster, then I think the future of tooling should also help us stay clearer about what we are building.

That is the idea behind Modulens.

GitHub: https://github.com/sinanyilmaz0/Modulens
Npm: https://www.npmjs.com/package/@modulens/angular

Every AI agent developer knows this pain:

You run your agent. It works. You run it again. It doesn’t. You have no idea why. You check the logs — there are no logs. You check the cost — $4.20 for a single run. You cry.

I got tired of this, so I built AgentProbe — an open-source testing framework for AI agents. Think pytest, but for LLM-powered agents.

What it does

Record — Capture every LLM call, tool call, and decision your agent makes.

Test — Run 35+ built-in assertions: cost limits, quality checks, safety validation, PII detection.

Replay — Swap models and compare results. “What happens if I switch from GPT-4o to Claude?”

Fuzz — 55 prompt injection attacks built-in. Find vulnerabilities before your users do.

The features nobody asked for (but everyone loves)

Agent Roast — Run agentprobe roast and get a brutally honest (and funny) analysis of your agent:

“Your agent spends money like a drunk sailor at a token store. Cost grade: D”

X-Ray Mode — Visualize exactly how your agent thinks, step by step, with costs per step.

Cost Calculator — Find out what your agent REALLY costs per month. Spoiler: more than you think.

Health Check — Get a 0-100 health score across 5 dimensions: reliability, speed, cost, security, quality.

Injection Playground — 55 built-in prompt injection attacks across 5 categories. Test your agent’s defenses.

Quick start

Install:

pip install agentprobe

Record your agent:

agentprobe record my_agent.py

Run tests:

agentprobe test

Get roasted:

agentprobe roast my_agent.py –level savage

What I learned building this

1. AI agents are black boxes by default. Nobody builds logging into their agents. When something breaks, you’re guessing.

2. Cost is the silent killer. Most developers have no idea what their agents cost per run. I’ve seen agents that cost $5 per query because of redundant LLM calls.

3. Security is an afterthought. Most agents are vulnerable to basic prompt injection. A simple “ignore previous instructions” breaks 60% of agents I’ve tested.

4. Testing AI is different from testing code. You can’t just assert output == expected. You need statistical assertions — “quality above 80% over 100 runs.”

What’s next

• VS Code extension
• Web3/crypto agent testing
• More framework integrations

The repo is open source (MIT): github.com/tomerhakak/agentprobe

Would love feedback from anyone building agents. What’s the hardest part of testing for you?