Sarj AI Blog

How Do You Test a Phone Call?

Mohammed Alshamrani — Sun, 13 Sep 2026 00:00:00 GMT

You make one. Every hour.

Testing a web app is a solved problem. Render the page, click the button, assert the thing. Testing a voice agent, though, is a different story. One call passes through STT, an LLM, TTS, and a real telecom network, live, in sequence. Any link in that chain can quietly break, and the product becomes an awkward silence on a phone line.

Unit tests don’t catch a carrier misbehaving in the middle of the night. Status pages don’t either; every dependency can be “up” while calls are broken end to end.

So we built Canary!

Coal miners kept canaries to notice bad air before it noticed them. Ours makes phone calls. Every hour, a robot caller dials our production stack, over real phone lines, and checks that everything works the way a real caller would experience it.

We didn’t start by “covering everything”. We started from our clients instead. The first canaries were built around real client flows, the same journeys their callers take every day. If those work, the platform works. From there, Canary grew to cover the platform’s most vital paths. And it doesn’t just check that a call happened: it checks the whole journey, that the agent spoke, the conversation went where it should, and the data landed where it was supposed to, right down to the record in a client’s CRM.

The same machinery scales up, too. Because Canary already knows how to be a caller, it can just as easily be many callers at once. That turns the pipeline into our load-testing rig: waves of concurrent calls against the platform, so we find any capacity limits in a drill we run, not on the day a client launches a big campaign.

And when something breaks, we don’t find out from a client. Canary alerts us and someone gets paged before anyone else notices.

Voice AI demos are easy. What our clients get, though, is the guarantee that the call actually gets answered, correctly, at 4am on a Friday. Canary is how we know. It sings every hour, and the whole point is that nobody thinks about it until it stops.

Kudos to Kidus: How My Mornings Plan Themselves

Fatma Moanes — Sun, 16 Aug 2026 00:00:00 GMT

One day I was talking to my colleague Kidus. He’s a brilliant engineer, and we share so many common traits and ideas. We both love planning. He was sharing his screen explaining something, and I saw an app with tasks inside, so I asked him about it. He said: “Oh, that’s Super Productivity!” It turned out to be the app’s name, not a description. Then he showed me his magical workflow that blew my mind with how powerful yet simple it was!

Kidus felt the pain of asking yourself every morning: “ok, what do I need to do today? What should I start with? Am I blocking anyone? Any messages I must respond to ASAP?”, then spending at least 30 minutes finding out what you need to do today.

So he smartly wrote a Claude “kickoff” skill that fetches data from Linear, Slack, GitHub, Google Calendar and Gmail. It compiles everything and dumps it into the SP app. Every morning he just asks Claude to “kickoff” and waits for the magic to happen.

Of course I asked to use it, and ever since then I’ve been building on top of it and using it every day. I tailored it for myself: for the different hats I’m wearing, for my priorities, for the people I’m leading. It has been a “super productivity” booster for me!

So Kudos to Kidus!

Coming up next, I’m gonna show you how my AI keeps my pull requests moving: it chases my reviewers, reviews my own code before anyone else sees it, fixes linting CI errors, and leaves me only the decisions!

The Blessings of working at Sarj

Fatma Moanes — Sun, 16 Aug 2026 00:00:00 GMT

I joined Sarj as the third engineer ever. We were six people: the CEO, the CTO, one salesperson, and three engineers. I was the third.

Ever since I joined Sarj, the one thing I’ve always admired about them is how they listen to feedback and ideas. After all, what makes a person feel good about themselves at work? It’s their impact. You can never have a positive impact on someone if they never listen to you… if they are not even willing to listen to you. Sarj has been not just listening to me, but encouraging me to speak more and more. I have seen most of my suggestions and feedback get applied, and have seen the positive impact of it up until this moment. Which makes me really proud.

What completes it is the culture. How we all communicate with each other… the human aspect of it.

You spend at least a third of your life at work, it ought to be fun. A simple “how was your weekend” each Sunday morning can do magic! We are humans, not machines, and this is how we should treat each other.

For the last couple of months, the closest person to my heart has been fighting cancer. What was the team’s reaction to the news? I have seen so much genuine care, love and support from the team, and I’m eternally grateful for that. You might think it’s the normal reaction, but it’s not what I used to see. Nobody is obliged to constantly follow up and ask a colleague about her health every now and then.

The company = the team. Although we come from 10 different countries, we all speak the same language; we have similar values.

We believe that proactively engaging with the team, being humble, equally respecting everyone, and holding yourself accountable for your actions, all while being flexible, is what really makes you a Sarj-ian, and what sets you up for success. And of course… to love what you are doing, and have fun while doing it!

Coming up next, I’m gonna talk about how my career developed at Sarj!

Vim-Fu

Nasr Maswood — Mon, 10 Aug 2026 19:00:00 GMT

I used to take ferocious pride in my Vim skills. I knew all the hot keys, tricks and tips. I wrote macros, memorized register mappings and even dabbled in Vim script. My Vim-Fu was strong.

Nowadays, my Vim skills have mostly atrophied. I rarely open a text editor and my .vimrc is outdated and sad. Times have changed. Nobody writes code by hand anymore. Instead we practically will it into existence with AI.

Claude! (or more honestly Codex, we are a Codex household now) build me an Arabic Voice AI platform!

While this has made producing software much faster, it has made reading and reviewing software a nightmare. Good code review is careful, methodical and thoughtful. No one has (or should have!) the patience to carefully review thousands of lines of AI generated code each day.

To help solve this problem we developed the Standards linting tool. The tool is three years of code reviews (as well as most of my software career’s learnings) compressed into 100+ deterministic linting rules. The linter runs as part of our pre-commit process. Whenever an AI agent writes a line of code and tries to commit, the linter analyzes the code and automatically flags violations. The fixes are then made by the agent without the developer having to think about it.

Some of these rules are simple syntactic idioms. For example, in rule SARJ109 we enforce uuidv7 and prohibit uuidv4 as uuidv7 has desirable performance benefits. However, other rules like SARJ023 encapsulate more complicated / judgment based concepts like the stepdown rule. (For reference the stepdown rule is a concept that promotes more readable code by mandating that public functions appear first in a source file.) New rules are constantly being created and pre-existing rules grow and expand over time.

My hope is that the tool will allow us to write high quality / correct code while not losing the speed benefits that AI gives us. I don’t know what the future of coding will look like. However, I am certain that guardrails, linters, verification layers, etc. will be more important than ever.