• Base44 has launched an AI agent that can make and receive phone calls
• It aims to eliminate hold times and speed up research
• Just describe your goal, give context, and let it do the work for you

Waiting on hold may become a thing of the past thanks to Base44’s new voice AI agent. Launched earlier this month, Superagent can now make and receive phone calls on behalf of the user, with countless potential applications.

According to a press release shared with TechRadar Pro, Base44’s Superagent can take on everyday tasks that would otherwise require people to spend time on hold or leave them navigating frustrating phone systems.

How Base 44’s Superagent works

Users start by giving Superagent a goal and providing relevant context on how that goal should be achieved. The AI agent can then proactively contact businesses or customers, asking relevant questions, collecting crucial information, and even navigating supported phone menus. Once the job is complete, the agent will then report back to the user with a summary of what has been done and which outcomes have been achieved.

Some helpful use cases include:

• Improve time management by booking or rescheduling important appointments
• Speed up research by calling vendors to request quotes for comparison
• Increase call success by retrying unanswered calls on a predefined schedule
• Receive and manage calls from trusted contacts

A shifting approach to AI

The launch highlights an ongoing shift in consumer AI, with tools moving from generative AI that simply answers questions to agentic AI that undertakes real-world actions based on requests made by the user.

But the question remains: will humans be happy to interact with AI if it means limiting wait times and more efficient calls?

You no longer need knowledge of advanced coding languages to build apps. AI has torn down the barriers to coding, making it as simple as describing what you want in plain English.

Or at least, it can appear that way.

But coding isn't just about writing syntax. It's about systems architecture, understanding how people will really use a platform, and ensuring the right measures are in place to limit vulnerabilities.

I spoke with Gabriela Moreira, CEO of Quint, about how people using AI tools to write code can better understand the associated risks and put in place early checks and processes to limit unmaintainable code and catastrophic bugs.

Can AI be trusted to write production-ready code without human oversight? If not, what makes AI-generated bugs distinct from human error?

Oversight is definitely needed, because AI exists to serve humans, and therefore humans need to tell AI what to do and evaluate its results.

Now, which type of evaluation is the most adequate? You can read its code line by line or ship to production and monitor for problems, to talk about two extremes. Both of these are already techniques used to oversee code that might contain human error.

The main differences that AI brings to the table are the amount of potentially wrong code that gets produced and the cognitive disconnection of any human to the elements of what gets produced. Code review and monitoring are both harder at this load scale and cognitive disconnection.

Which core business systems are most vulnerable to AI coding flaws?

The ones that are harder to test, like concurrent and distributed systems, or any system with a high level of non-determinism where there are too many paths to consider.

AI is a generation tool, which is only as good as our ability to decide if a generated solution is correct or not. If I have good tests, or some other kind of verification harness I trust, I can accept AI solutions with less risk. If a system is hard to test or verify, there might be too many blind spots where flaws can sneak in.

What are the hidden operational and security risks of deploying AI-generated code without formal verification?

Perhaps the best way to think about risk in 2026 is by considering the asymmetry: defenders must protect all parts of their code, while attackers may only find one vulnerability to cause huge damage.

AI companies are already taking this asymmetry into account when they decided to give a model like Mythos only to companies in a program to secure themselves, before they land in the hands of potential attackers.

Formal verification is probably the strongest tool we know that can fight this asymmetry, but there are still many challenges in the area that make it infeasible to verify all the code surface, and vulnerabilities can still be found in unverified components. There’s no magical solution, and combining different strategies is the wisest thing to do.

Why is catching a design-level bug early in the process so important?

The answer to this question before AI wrote the code was quite different: because rewriting code is very expensive and error-prone if you catch the bug after months of development instead. I don’t think this is a strong argument anymore.

So, the new answer is: you are way more likely to find this problem in the scope of a design you can still reason about than after AI writes thousands of lines of code with the bug hiding in one of them.

You could maybe notice the problem as you typed the code, thinking “wait, we didn’t consider this scenario!” But this is less likely to happen if AI wrote the code for you, so more careful design is important.

Developers are used to reasoning about possibilities and bugs while compiling and executing different versions of code, so I’m extremely concerned about the design process involving mostly markdown files that cannot be compiled or executed, or interacted with in any way other than reading.

What simple checks, tools, and safety nets can dev teams put in place to verify AI code before it hits production?

First of all, tests! But tests that actually help with trust, not just any AI-generated test that makes some arbitrary assertions and has to be updated all the time.

I like to think about tests in terms of which behaviors they are exercising and which kinds of regressions they are preventing. If controlling the quality of tests becomes a challenge, formal models can help by either being a generator of scenarios to test or by validating that existing tests enforce interesting behavior.

Additionally, mutation testing is very helpful in measuring the quality of tests by how many different regressions they could catch.

What level of human oversight do you recommend to balance development speed with code quality and reliability?

This depends so much on context and risks. The best I can recommend is to do whatever allows you to ship with enough confidence and to feel enabled to make software changes without fear of breaking what is already working.

The worst scenario is always to get hacked or leak other people’s data. The second worst is to get to a state where there are a lot of things wrong with the software, but whatever you try to fix results in breaking things even more, so it gets stuck in a bad state.

I think it’s quite easy for AI-generated code to end up in this state. Interestingly, I think the way to escape it is very similar to how we handled legacy code that became too hard to maintain: first add enough tests to be confident your oversight is enough, and then change it.

Vibe coding makes developing an app as simple as describing your idea. With barriers collapsed, it is easy to assume that app monetization is dead.

Stan Marchand disagrees. As CEO of Paris-based app publisher Rocapine, he has proved that vibe-coded apps can still generate real revenue – but only if builders focus on the 20% of app development that moves beyond the code and into human craft.

I spoke with Stan to unpack what separates a buyable product from an empty gimmick in 2026.

Vibe coding has made it easier than ever to build apps, but are these apps actually generating revenue?

A few are, but most aren't, and most often it's because people assume building a functioning app is the hard part. It isn't anymore.

Vibe coding has collapsed the cost of building an app to almost nothing. But 80% of the work can now be automated, and more than ever it's the remaining 20% left to humans that decides whether an app makes money: finding a value proposition that genuinely resonates, crafting a product with human taste, and telling its story efficiently.

The apps generating real revenue got those three things right. The flood of apps that look finished but never find a market got none of them. Building is now the easy part. The scarce skills are insight, taste, and distribution.

When assessing a vibe-coded MVP, which metrics and signals do you look for to separate a "buyable" app from a gimmick?

The code itself is not worth much.

What is worth something is whether the product resonates with real people. That is shown by asking two questions:

• Is it marketable? Can you reach users at a cost the business can support, or is the market already saturated by giants pushing the same promise?
• Will people pay? Once they've installed it, do they convert and stick? The KPIs that capture this are cost per install, conversion to paid, and early retention.

Put these questions together: that's ROAS- how much it costs to acquire a user versus how much that user is worth.

A rough prototype with a low cost per install and users who pay is a real business. A polished app with beautiful code and no one converting is a gimmick.

How does that evaluation process differ when assessing vibe-coded apps compared to traditional human-built apps?

Less than you'd think.

Nobody writes code by hand anymore, so "vibe-coded" versus "human-built" is becoming a distinction without a difference.

What changes is where we spend our time. With vibe-coded apps, the code is cheap to rebuild, so we care less about its quality and more about whether the concept has proven resonance.

The risk isn't messy code, it's a product that exists because it was easy to make rather than because anyone needed it. AI gives everyone the same 80%. We evaluate the 20% the builder added: the insight, the craft, the taste.

AI-generated code can be messy. What steps must vibe coders take to ensure their app is legally compliant and structurally sound enough to pass due diligence?

Three things:

• Know your stack: which tools generated what, under which licenses, and whether any third-party code or assets carry restrictions. Undocumented AI code isn't a dealbreaker; undocumentable code is.
• Clean data practices from day one: privacy policy, user consent, App Store and Play compliance, and analytics you can actually export.
• Make your metrics verifiable: revenue through the stores, retention cohorts, acquisition costs. We've walked away from partnerships not because the code was AI-generated, but because nothing could be checked.

How should an app creator think about deciding whether a full acquisition, a publishing deal, or a revenue-share model is right for them?

Ask yourself what you actually want.

If you want the cash and to move on to the next idea, a full acquisition is clean. If you believe in the app and want to stay in the game, a publishing or revenue-share deal lets you keep upside while a partner brings what a solo builder rarely has: monetisation expertise, growth marketing budget, the infrastructure to scale.

The good news is that these paths aren't mutually exclusive. Unchaind, which we co-developed from scratch with a studio in Singapore under a publishing model, reached $1M ARR 16 days after launch. We ended up acquiring it later, once the developer wanted to move on to a new project.

Start with the model that fits where you are today; the exit can come when it makes sense for both sides.

What other tips would you give keen vibe coders who are looking to build and sell vibe-coded apps?

Build for a niche you understand deeply, ship in weeks, and put a price on it immediately. Free users tell you nothing about resonance.

Then fight AI slop relentlessly: the generic wording, the template design patterns, the onboarding everyone recognises. Users spot it instantly, and it kills trust. Invest your time in the 20% that makes your product yours; the rest is a commodity.

And when you talk to a publisher, bring your cohort data, not your feature list.