Every confirmed finding is fixed, small ones too
Every finding counts, whatever its severity. Every fix comes with a test that fails before and passes after, so the fix is proven and stays.
Quality and security agents
Our quality and security agents are our own tool. They check every build on a fixed route: QA, UX, security, pentest, SEO/AEO, a technical audit with Lighthouse and code review. Every confirmed finding is fixed with a test that fails before the fix and passes after it, and every bug stays as a permanent test.
Our own product
| Industry | Internal tools & platforms |
|---|---|
| Challenge | Accountability |
| Decision environment | Product evaluation |
| Complexity | High |
| Service | Platform |
Maybe you wonder why a website or platform from iwebforyou is not handed over "as it came out". The answer is here: every project goes through the same checks before it reaches you. The table shows what each agent looks at and when it runs. The text explains what this means for the client.
Agent | What it looks at | Runs |
|---|---|---|
SEO/AEO | Whether pages can be found and quoted by search engines and answer engines (websites) | Once |
Technical audit | Page quality measured with Lighthouse (websites) | Once |
Code review | The code of the framework in use, checked for correctness | Up to 2 rounds |
UX | How the pages work for a person | Once |
Security | The weak points of the application | Up to 3 rounds |
Pentest | A simulated attack, to see what a real attacker would do (platforms, or sites with a shop or bookings) | Up to 2 rounds |
QA | The whole application, used the way a customer would use it | Up to 2 rounds |
Quality and security agents What was the starting situation?
Our builds are produced by the Planner. Every feature already passes its own tests before it is accepted. But features must also work correctly all together. A page that works alone can break when another page is added. A form that is safe on its own can be reached from another place.
So after the build is approved, a second stage follows. It is kept separate from the first on purpose. The agents did not write the code, and their job is to examine it with a critical eye.
This stage gives the word "checked" its meaning in our work. Clients rarely see it, so we describe it here in detail.
Quality and security agents What was the problem?
Every check sees only what it was designed to look for. A security scan finds weak points, not a confusing form. A visual check judges the look, not an unprotected endpoint. A tester who knows the application well does not trip where a new visitor would. The full picture needs many different checks.
The second issue is what happens after a finding. A problem is fixed for good when the way it was found is recorded too. A finding with a test stays solved, because the test guards it from then on.
Quality and security agents What constraints shaped it?
Three constraints. The route must have a clear end, so every agent finishes its rounds and stops. Every finding is recorded and gets a decision before the build continues: it is either fixed or knowingly accepted, with a written reason. The work leaves no test data in the real content.
The CMS is a special case. Inside a site it is read-only. A finding in the CMS itself is recorded as such and fixed in its own repository, so the fix reaches all sites and not just one.
The limits are written in the code: 5 sessions per task, 3 repairs of the quality gate, 3 attempts per round. If an issue reaches a limit, it goes to the project owner for a decision, and the run carries on.
Quality and security agents What do we watch for in the checks?
The first point is what happens after the report. A long report is worth something only when every finding gets a decision. So no finding is left waiting with the label "needs checking". The notes about what an agent did not cover are read too, because they may be the most important line of the report.
The second point is loops. When one agent changes code and another starts again because of the change, the route needs a clear end. Fixed rounds make sure of that.
The third point is verification. When a scanner reports a "possible problem", the first step is to check whether the problem is real. Only then do we decide to fix it or reject it.
Quality and security agents What is the approach?
The route is the same in every project. Each agent runs once, in a fixed order and with a set number of rounds. The second round runs only if the first one fixed something. The numbered list gives the order, and the table above shows what each agent examines.
SEO/AEO and technical audit (Lighthouse), for websites.
Code review, with a second round only for the fixes of the first.
UX. Findings about looks become suggestions in a separate file and wait for the owner's approval, instead of being applied automatically.
Security in up to three rounds (a checklist, then an open search, then a refreshed checklist). Pentest in up to two rounds, for platforms or sites with a shop or bookings.
QA in two rounds over the whole application. A simple informational site gets light QA. A site with a shop or bookings gets intensive QA, which tries on purpose to break it.
The backlog becomes suggestions (documentation and refactoring, only as suggestions).
A final security check, and pentest where needed, once, on the changes of step 4. It fixes what it finds and then stops, even for Critical or High findings.
One full run of the quality gate, with e2e tests. In the steps in between, only the fast gate runs.
Reports.
Lighthouse, used in the technical audit, is an automatic open-source tool. It measures the quality of a page in performance, accessibility, SEO and best practices (see the Sources).
Quality and security agents What were the key decisions?
There are six key decisions. Every confirmed finding is fixed with a test, every bug becomes a permanent test, and every finding gets a decision. The coverage notes are read, the security checklist grows, and one ledger keeps the status. Each is explained below.
Every bug becomes a permanent test
A bug found by QA stays in a folder of regression tests. What was found once is checked from then on in every build.
Every finding gets a decision
The tool verifies every claim and decides: it fixes it, or rejects it with a written reason. Every finding is proven or disproven with evidence.
All the notes are read
The coverage notes of the agents are read, because the note about what an agent did not cover may be the most important line of its report.
The checklist grows from the findings
The checklist of the security agent grows each time a new kind of weakness is found. So the next project starts with the knowledge of the previous one.
One source of truth
A ledger records the status of every finding: fixed with a commit, rejected, accepted, passed to the owner, open or not verified.
Quality and security agents What outcome should be expected?
The result is a build with a trail that anyone can follow: what each agent examined, what it found, what changed and which test now protects it. For the client this means fewer unknowns on the day of delivery. It also means a record that supports the site's reliability and its long life.
No check can promise a build without a single flaw, and we do not claim that. We do not publish numbers of findings, because they would be selected and not neutral. What the method guarantees is clear: the route is fixed, findings are proven before they are fixed, and the tests stay.
To see where this stage fits in a project, read our process. For the security side on a real platform, see the AWS infrastructure for a healthcare platform, or start a project.
Quality and security agents Sources
Quality and security agents Frequently asked questions
Do the agents replace a check by a person?
No. The agents do the long, repetitive checking. A person decides what needs human judgment: design choices, content and priorities. The findings of the agents are verified and then either fixed or rejected with a reason.
What does "a test that fails before" mean?
For every real problem we write an automatic check that fails as long as the problem exists. Then we fix the problem, and the check passes. If the problem appears again, the check turns red again and we see it at once.
Is a pentest different from a security scan?
Yes. A scan looks for known weak points from a list. A pentest is a simulated attack: it tries to combine small weaknesses, as a real attacker would. We use both on platforms, and on sites with a shop or bookings.
Does every website go through all the checks?
The route adapts to the project. The SEO/AEO and Lighthouse checks apply to websites. Pentest applies to platforms or sites with a shop or bookings, and an informational site gets lighter QA. See what a typical site includes on the page about business websites.
Quality and security agents Related case studies
Planner: from specification to app
Planner is our own tool that turns detailed specifications into an application without supervision. For every feature the test is written first, the result is checked in the browser against the design, and a quality gate decides what moves on.
- Unclear structure
- Product evaluation
- High
AWS infrastructure for a healthcare SaaS platform
We built the AWS infrastructure of a US healthcare platform (SaaS) from scratch. The app runs on Elastic Beanstalk with Nginx.
- Trust and credibility
- Supervised
- High
Our own CMS for multilingual websites
Every website we build runs on our own CMS. It keeps the languages in step and converts images automatically.
- Unclear structure
- Product evaluation
- Intermediate
Next step: Quality and security agents
Start your project
Send a project request, or check your current website for free. We read every message ourselves.