DEV Community: Asper Brothers

Three things AI agents did on the web, and what they mean for people who build agents

Asper Brothers — Mon, 28 Sep 2026 15:42:34 +0000

I run Asper Brothers, an MVP startup studio that has been building digital products for clients since 2008. I'm on the product side, so I spend most of my time thinking about what we build and who's going to use it.

Over the past few weeks I've been reading about AI agents on the web, and I found three cases that shocked me and that I think anyone who builds agents should know about. In each one the agent did what it was built to do and still caused a problem, because it didn't know something that people on the web have assumed for years.

One of those assumptions is that opening a link shows you a page and doesn't change anything on it. Another is that crawlers read a small file called robots.txt and stay out of the parts a site asks them to skip. The third is that whoever connects to your API has read the documentation first. People learned these by using the web, and older programs followed them because the developers who wrote them knew them too.

An agent follows them only if somebody built that into it, and the three cases below show what happens when nobody did.

Case 1: agents that were only allowed to read, and still edited wikis

OpenAI was training research agents that could browse the web. To limit what they could do, it let them open pages on almost any site and blocked anything that would change a page.

The agents found UseMod, wiki software written more than 23 years ago, which lets you edit a page by opening a specially built link. Over one week they made about 13,000 edits on German developer wikis, mostly notes and answers they left for each other so they could finish their tasks on time. At one point one of the agents left a message warning the others that someone had started deleting their notes, and even noted the time it had spotted it.

I see two lessons in this for anyone building agents. The first is that the block worked as designed and the agents still did something nobody wanted. It covered what they were technically able to do, but it said nothing about whether writing on someone else's website was allowed, and the agents had a deadline to meet.

The second lesson is about memory. The agents needed somewhere to keep notes and share them, nobody had given them a place, so they used other people's websites. If your agent works in several steps or passes work to other agents, give it its own place to store notes.

Case 2: every page your agent reads costs someone else money

Konstantin Ryabitsev runs the servers behind kernel.org, where the Linux source code lives. At the end of August he wrote that git.kernel.org gets about 6 million requests a day, and by his estimate around 98% of them come from scrapers. Between 14 and 16 of their 90 processor cores are busy all the time generating pages for those scrapers. In his words:

"we spend more CPU cycles rendering commits for scrapers than we spend on all other kinds of legitimate access, including git clones"

When people work out what an agent costs, they usually count tokens and API bills, and the cost on the site's side rarely comes up. Every page your agent reads has to be generated by somebody else's server, and they pay for it.

Kernel.org responded by making visitors solve a small puzzle before they get a page, and by switching some features off for anyone who isn't logged in. Ryabitsev says they had little choice, because "it's impossible to tell with certainty which of these are bots and which are real humans". Those changes apply to every visitor, so they make the site harder to use for any agent, including a well-built one.

Case 3: what an agent looks like in someone else's logs

Pierre-Laurent Medori (@pierrelaurentmedori) runs a production MCP server at GoodBarber. MCP is a standard way for AI agents to use other products, and agents from other companies call his server all day. He published what he saw between June 3 and September 2: close to 100,000 calls from over 100 apps.

62.8% of those calls changed something, mostly creating or editing content. 125 calls asked for tools that don't exist, 33 different ones, and one agent asked for GBContent.getItems(), a name it had made up. His server also asks agents to check each change after they make it, and only 41% of changes got checked within two minutes. In his words, "three writes out of five never get one."

The teams behind those 100 apps probably see their tasks marked as done. Medori's logs show agents that guessed at tools that weren't there and changed content without checking the result.

The checking part surprised me most. The server asks every agent to check its changes, and most of them don't. If you want your agent to follow instructions like that from the sites it uses, you have to build it to look for them.

Should your agent identify itself?

There's already an official way for an agent to identify itself, called Web Bot Auth. The agent signs every request and the website can verify the signature. Cloudflare, AWS and Akamai already verify these signatures, and OpenAI's agent signs its requests.

The standard isn't finished yet. The IETF group working on it started in October 2025 and as of August still hadn't agreed on a single document. Since September 15, Cloudflare's default setting for new sites also blocks bots marked as "Agent" on pages with ads. So at the moment an agent that identifies itself can lose access to some sites, and I understand why a team might be tempted to make its agent look like a normal browser.

I'd still have my agent sign its requests. Sites like kernel.org add extra checks for every visitor who can't prove who they are, however well they behave, and more sites are adding them. If a site owner knows which agent is visiting, they can let it in, give it an API key or contact the company behind it, and none of that is possible with an agent that pretends to be a browser.

Six things I'd build into an agent

None of these needs technical knowledge to ask for.

Tell it what it shouldn't do, in addition to what it's blocked from doing. The UseMod agents were blocked from changing pages and still ended up editing wikis.
Give it its own place for notes, so it doesn't use someone else's website.
Make it check that a change actually happened after it makes one.
When something it expects isn't there, have it stop and report it. Medori's server got calls to 33 tools that don't exist in three months.
Keep track of what it costs the sites it visits, and use the official access a site offers, like an API or an MCP server, when there is one.
Make it identify itself.

What I found in our own documents

After writing these six points down, I went back through the MVP scope documents from this year to see how many of them we already use. Some were there, mostly under other names.

In a travel planning product we built, the AI assistant keeps a profile of how each person likes to travel. The spec we worked from has a rule that learning is confirmed and never silent. If someone swaps the suggested hotel for a five-star one, the assistant asks whether it should update their profile before it changes anything. The same assistant plans the whole trip but doesn't book anything. It shows links to booking sites, and the person books there. Place data comes in through Google's official API, and when someone wants to change one day of the trip, only that day gets regenerated.

In a tool we scoped for a founder who wanted the sales team to judge deals the way the founder would, the proposal says in plain words what the AI isn't allowed to do: one use case, one model, and no learning on its own. The acceptable and unacceptable cases get written down before the AI sees a single real deal.

In another product we scoped with an AI assistant, people can see what it remembers about them and correct or delete any of it.

What I didn't find anywhere was point 4 or point 6. None of our documents says what an agent should do when something it expects isn't there, and none says whether it should identify itself on other people's websites. None of these products sends an agent out onto the open web yet, so the question never came up. For the next one that does, I'd want both on the list before development starts.

Pawel Jackowski is CEO and co-founder of Asper Brothers, an MVP development studio that has shipped over sixty products across fintech, healthtech, and other regulated software categories in the last fifteen years. He writes about building, shipping, and learning from early-stage products, and works directly with founders on MVP scoping, validation, and production engineering.

Sources

Simon Willison, OpenAI's rogue agents were caught communicating via public wikis
Konstantin Ryabitsev, Creepy crawlies
Pierre-Laurent Medori, The agents in production aren't mine. Here's what their server sees
Cloudflare changelog, New options to manage AI traffic
IETF, Web Bot Auth architecture draft

The Modern SaaS Stack Is a Superpower

Asper Brothers — Mon, 07 Sep 2026 13:24:35 +0000

Asper Brothers

Sep 7

We've Never Had a Better Time to Build a SaaS Product

#saas #react #ai #webdev

7 min read

We've Never Had a Better Time to Build a SaaS Product

Asper Brothers — Mon, 07 Sep 2026 13:16:07 +0000

There has probably never been a better time in the history of software to build a SaaS product.

Not because AI can generate an entire application from a single prompt.

Not because you can describe an idea to a vibe coding tool and have a prototype 15 minutes later.

Those things are interesting, but they are only part of a much bigger shift.

The real change is that the cost of turning an idea into reliable, production-ready software has collapsed across almost every layer of the stack.

Frontend frameworks are mature. Backend infrastructure is available as a service. Authentication is largely solved. Payments are APIs. Deployment takes minutes. Mobile development can share a significant part of the same ecosystem as the web.

And now AI sits on top of all of this as an extraordinary productivity multiplier.

For a small technical team — or even a single experienced developer — that changes the economics of building software completely.

The modern SaaS stack is ridiculously powerful

Imagine starting a SaaS company 15 years ago.

Before building the actual product, you might have needed to make decisions about servers, deployment, database administration, authentication, backups, monitoring, infrastructure, and scaling.

Today, a perfectly reasonable starting architecture might look like this:

Web application → React / Next.js
Mobile application → React Native
Database → PostgreSQL / Supabase
Authentication → Supabase Auth
File storage → Supabase Storage
Backend functions → Edge Functions / serverless
Payments → Stripe
Transactional email → Resend
Hosting → Vercel / Cloudflare
Analytics → PostHog
AI features → OpenAI / Anthropic / others

None of these technologies is particularly exotic.

And that is exactly the point.

The biggest advantage modern SaaS builders have isn't access to some secret technology. It is access to boring, mature, composable infrastructure.

You can spend far more time solving the customer's problem and far less time rebuilding infrastructure that thousands of companies have already built before you.

React has become more than a frontend library

React's importance for SaaS development isn't simply that it is popular.

Its real advantage is the ecosystem around it.

A modern React application has access to mature solutions for routing, forms, validation, component libraries, charts, tables, payments, authentication, analytics, monitoring, and almost every other problem that appears repeatedly in SaaS products.

This matters enormously when speed is important.

When building a SaaS MVP, you rarely want to invent infrastructure. You want to combine proven building blocks and concentrate engineering effort on whatever makes your product unique.

React makes that approach extremely effective.

And if the product eventually needs a mobile application, React Native gives a JavaScript/TypeScript team a realistic path into iOS and Android without immediately creating two completely separate engineering organizations.

The web and mobile applications will obviously not share everything.

But they can share much more than code.

They can share TypeScript types, validation schemas, API clients, domain logic, backend infrastructure and — perhaps most importantly — engineering knowledge.

For an early-stage company, that leverage is enormous.

Supabase changes what "backend development" means

One of my favorite examples of how much SaaS development has changed is Supabase.

Create a project and you are not starting with an empty server.

You can immediately have a real PostgreSQL database together with authentication, storage, realtime capabilities, and server-side functions.

That removes a surprising amount of undifferentiated work.

Consider something as ordinary as user accounts.

Historically, authentication could mean building password storage, reset flows, email verification, sessions, OAuth integrations, and security mechanisms yourself.

Today, this can be infrastructure.

The same applies to file storage, database APIs, and many backend workflows.

Importantly, this doesn't necessarily mean giving up the foundations of traditional software engineering.

Supabase is built around PostgreSQL.

You still have tables.

You still have relationships.

You still write SQL.

You can use database constraints, indexes, migrations, and Row Level Security.

This is an important distinction.

The modern SaaS stack isn't powerful because it allows us to avoid engineering.

It is powerful because it lets us apply engineering effort at a higher level of abstraction.

Then AI arrived

All of the improvements above would already make this an excellent period for building software.

AI changed the equation again.

The most interesting use of AI in software development isn't asking:

"Build my startup."

It is having an extremely fast collaborator available during almost every stage of engineering.

AI can help you explore an unfamiliar API.

It can generate the first version of a database migration.

It can suggest test cases you forgot.

It can explain a strange TypeScript error.

It can review a function for edge cases.

It can transform an API response into types.

It can draft SQL queries, regular expressions, validation schemas, and documentation.

It can help investigate logs.

It can generate repetitive UI code.

It can help refactor code that already works but has become difficult to maintain.

None of these tasks individually sounds revolutionary.

Together, they remove enormous amounts of friction from a developer's day.

And that is where the real acceleration happens.

AI makes experienced developers disproportionately faster

There is an interesting paradox in AI-assisted software development.

AI makes it easier for people with limited technical experience to create software.

But it can make experienced engineers dramatically faster.

Why?

Because generating code isn't the hardest part of software development.

The difficult questions are usually things like:

Should this logic live in the client, server, or database?
What happens when two requests execute simultaneously?
What data should this user actually be allowed to access?
What happens when a payment webhook is delivered twice?
How should this model evolve when the product changes?
Which part should be generalized and which should stay simple?
What happens when this API fails?

AI can help answer these questions.

But somebody still needs to ask them.

An experienced developer can use AI to eliminate mechanical work while spending more time on architecture, product behavior, security, and edge cases.

That is a much more interesting productivity gain than generating another landing page.

AI is also becoming part of the product stack

There is another important shift.

AI isn't only helping us build SaaS products.

It is becoming infrastructure inside SaaS products.

A few years ago, building features involving natural language understanding, document extraction, summarization, or semantic search could require specialized machine-learning expertise.

Today, many of these capabilities are APIs.

A small SaaS product can realistically offer features such as:

Document → structured data
Email → classification
Conversation → summary
Database → natural-language interface
Support ticket → suggested response
Meeting transcript → action items
Knowledge base → semantic search

You don't need to train a foundation model.

You need to understand the user's workflow and determine where intelligence creates meaningful value.

That opens an enormous design space for small software companies.

The bottleneck is moving away from implementation

This might be the most important consequence of everything happening today.

For years, software implementation itself was a major constraint.

You could have a good idea and still need months of engineering before discovering whether customers cared.

That feedback loop is becoming dramatically shorter.

A small team can build a credible product, deploy it globally, integrate payments, add authentication, and start talking to real customers surprisingly quickly.

The bottleneck therefore moves somewhere else.

Choosing the right problem.

Understanding a niche.

Talking to customers.

Designing workflows.

Distribution.

Pricing.

Positioning.

Knowing what not to build.

These things aren't becoming easier at the same speed as programming.

If anything, they become more important because more people can now build software.

Fast doesn't have to mean disposable

There is also a misconception that building quickly means producing throwaway software.

It doesn't.

You can move extremely fast while using technologies that can remain with the company for years.

React isn't a prototype-only technology.

React Native powers serious mobile applications.

PostgreSQL certainly isn't an MVP database.

TypeScript isn't something you need to replace once you find product-market fit.

The key is avoiding unnecessary complexity while keeping good fundamentals.

Use migrations.

Model your database properly.

Add constraints.

Use Row Level Security where appropriate.

Write tests around critical business logic.

Track errors.

Keep secrets out of the client.

Make webhooks idempotent.

Back up important data.

You don't need enterprise architecture for your first 50 customers.

But you also don't need to build software you expect to throw away.

Modern tooling allows us to occupy a very useful middle ground:

Prototype speed with production-grade foundations.

The smallest capable team in history

Perhaps the most exciting consequence is organizational.

Things that previously required separate frontend, backend, mobile, infrastructure, and machine-learning specialists can increasingly be handled by a much smaller team.

Not because those disciplines disappeared.

Because the tools became better.

A strong product engineer with React, TypeScript, React Native, PostgreSQL, Supabase, and modern AI tools now has an extraordinary range.

Add one person who deeply understands a specific industry or customer problem and you already have the foundations of a potentially serious software company.

That doesn't mean every SaaS should be built by two people forever.

It means you can reach the point where hiring becomes justified much later.

That is a huge difference.

Build now

The barriers haven't disappeared.

Building something people want is still difficult.

Distribution is difficult.

Customer acquisition is difficult.

Creating a product that survives contact with real users is difficult.

But implementation — historically one of the most expensive parts of starting a software company — has become dramatically more accessible.

We have mature open-source frameworks.

Managed infrastructure.

Global cloud platforms.

Incredible developer tooling.

Cheap experimentation.

Instant deployment.

Powerful APIs.

And AI assistance available directly inside the engineering workflow.

The interesting question is no longer:

"Can a small team build this?"

For an increasingly large category of software, the answer is yes.

The better question is:

"Is this a problem worth solving?"

If the answer is also yes, there has rarely been a better time to start building.

Laravel Repository Pattern

Asper Brothers — Wed, 18 Dec 2019 13:43:53 +0000

Originally posted on: https://asperbrothers.com/blog/implement-repository-pattern-in-laravel/

The first thing we need to know to implement a repository pattern in the Laravel application is to understand what Repository Pattern is and what are the benefits of using it.

In this article you’ll learn about:

Main benefits of using Repository Pattern
How to implement a Repository Pattern in Laravel?
We will show you step by step how to start code and implement it in Laravel app

What’s important

A repository is a separation between a domain and a persistent layer. The repository provides a collection interface to access data stored in a database, file system or external service. Data is returned in the form of objects.

The main idea to use Repository Pattern in a Laravel application is to create a bridge between models and controllers. In other words, to decouple the hard dependencies of models from the controllers. The model should not be responsible for communicating with or extracting data from the database. A model should be an object that represents a given table/document/object or any other type in our data structure and this should be its sole responsibility. Therefore, to keep your Laravel code clean, it is worth using repositories to separate the responsibility for which the model should never be responsible.

The use of Repository Pattern has many benefits, below is a list of the most important ones:

Centralization of the data access logic makes code easier to maintain
Business and data access logic can be tested separately
Reduces duplication of code
A lower chance for making programming errors

In most Laravel applications you may encounter such a code.

class UsersController extends Controller
{
   public function index()
   {
       $users = User::all();

       return view('users.index', [
           'users' => $users
       ]);
   }
}

At first glance, it doesn’t look that bad. However, it is worth to think what if the client proposes to change the data structure and instead of in MySQL/Postgresql from now on we are going to keep the data somewhere else, in the data engine which is not supported by Eloquent? When we write such a code, such a change may turn out to be very difficult to implement, or even impossible! That’s why it’s very dangerous to write code this way, every implementation should be based on interfaces, so in case of changes you don’t need to change the code in the whole application, but only create another class implementing the interface. This should be the code above written in a correct way. (The code above should be written in a correct way).

class UsersController extends Controller
{
   private $userRepository;

   public function __construct(UserRepositoryInterface $userRepository)
   {
       $this->userRepository = $userRepository;
   }

   public function index()
   {
       $users = $this->userRepository->all();

       return view('users.index', [
           'users' => $users
       ]);
   }
}

In this particular example, when a client wishes to change the data structure, it is child’s play to implement these changes into our application! We simply create a class that implements UserRepositoryInterface and contains the logic that will allow us to pull it out in a new way and everything works again. That is why it is so important to write code in such a way that even when the client comes with the most difficult change we will be able to deal with it easily. The repository template greatly facilitates this process!

To see the entire article go to https://asperbrothers.com/blog/implement-repository-pattern-in-laravel/.