DEV Community: erico964-blip

Can AI Agents Actually Use Your Website? I Built a Tool to Find Out

erico964-blip — Mon, 05 Oct 2026 20:21:34 +0000

AI agents are getting better at using websites, but there is still a basic question that is surprisingly difficult to answer:

Can an AI agent actually use your website?

I built Agentic Web Check to test that question in a real browser.

The idea is deliberately simple: instead of only checking whether a website has the right HTML, metadata, accessibility signals, or AI-facing interfaces, the tool actually opens the site in Chromium and tries to use it.

It has three main parts:

deterministic checks of what an agent can perceive and interact with
real browser tasks such as finding contact information, privacy policies, or help pages
programmatic verification of whether each task actually succeeded

The last part is the one I care about most.

The agent does not get to say “done” and receive a PASS.

A task ends as PASS, FAIL, BLOCKED, or INCONCLUSIVE based on assertions against the resulting browser state.

There is also a separate safety layer that looks for things such as hidden instructions aimed at AI systems, unsafe forms, authentication boundaries, downloads, and consequential actions without appropriate safeguards.

One of the controlled fixtures gave an interesting result: it scored 81 on the perception checks, but all three browser tasks ended BLOCKED because its consent banner did not expose a properly named close control.

That is a deliberately broken fixture, not a claim about the wider web. But it illustrates the distinction I wanted to measure: a page can look reasonably good to a static audit while still being difficult for an agent to operate.

The project is still very early.

It is currently v0.1.0, Chromium-focused, does not perform a full site crawl, and I have not published a public benchmark. Some thresholds are documented defaults rather than empirically validated constants.

The goal is to make those limitations visible and improve the methodology through real use rather than hiding them behind a single “AI readiness” score.

The project is open source:

https://github.com/ericovirgy/agentic-web-check

I would be particularly interested in feedback from people working on browser agents, Playwright, accessibility, WebMCP, or agentic web tooling.

What would you measure differently?

🚀 Never Write a README.md from Scratch Again — Meet readmeai

erico964-blip — Wed, 01 Jul 2026 07:12:13 +0000

Every developer has been there. You finally finish that side project, push it to GitHub, open the repo and the README.md is just # project-name . You tell yourself you'll fix it tomorrow. Tomorrow becomes next week. The repo quietly gathers dust.
The excuse is always the same: writing a good README is harder than it looks. You need a hero description, install instructions, usage examples, badges, a contributing guide, a license section and you have to make it not look like a templated ghost wrote it. It's not technical work; it's polishing work. And polishing work is the first thing that gets pushed aside when the next idea hits.
That's exactly why I built readmeai. It's a small Python CLI that scans your project structure, reads your key config files ( pyproject.toml , package.json , Cargo.toml , go.mod , Dockerfile , …) and asks an LLM to generate a complete, badge-laden README.md ready to commit. One command, about ten seconds, and your repo stops looking orphaned. Local-first if you want it (Ollama works out of the box), zero heavy dependencies ( requests is the only one), MIT-licensed, on PyPI today.

Suggested section headers for the rest of the article:

Quickstart in 90 Seconds
How It Works (Under the Hood)
Picking a Provider: OpenCode vs OpenAI vs Ollama
Interactive Mode: Preview Before You Commit
Supported Project Types & Config Files
Customising the Output
Roadmap & Contributing
Closing Thoughts

How I Built an AI-Powered Conventional Commit Generator in Python

erico964-blip — Tue, 30 Jun 2026 20:59:59 +0000

I shipped my first Python CLI to PyPI this week. Here's what I learned building **gitpulse** — a tool that reads your staged git diff and generates Conventional Commit messages using AI.

## The Problem

Every developer has lazy commits in their history:
`git commit -m "fix"`
`git commit -m "update"`
`git commit -m "stuff"`

Clean commit histories matter — for changelogs, code reviews, and your future self trying to understand why you changed that line 6 months ago. But writing `feat(auth): add JWT token validation with refresh support` for every single commit is mental overhead nobody needs.

## The Solution

gitpulse reads your staged diff and generates the message for you:

`pip install gitpulse-commit`
`git add src/auth.py`
`git-pulse`
`# → feat(auth): add JWT token validation`

You confirm, edit, or abort. One key. Done.

## What I Learned

### 1. PyPI packaging is simpler than it looks

`pyproject.toml` + `python -m build` + `twine upload` is all you need. No `setup.py`, no `setup.cfg`. The hardest part was finding an available package name (hint: check PyPI before you start coding).

### 2. ABC + factory pattern for pluggable providers

The core `AIClient` is abstract. Each provider (OpenCode, OpenAI, Ollama) implements `generate(diff) -> str`. The factory function just does `return OpenAIClient(...)` based on a string. Adding a new provider is ~20 lines of code.

### 3. Prompt engineering is API design

The system prompt is the most important file in the project. It enforces:
- Conventional Commits format (`type(scope): description`)
- 72-character max
- No markdown, no explanations, no fluff
- Imperative mood, no period at end

If the AI ignores any of these, the CLI still strips markdown and truncates — defense in depth.

### 4. Git hooks are easy but fragile

`git-pulse init` writes a prepare-commit-msg hook. It works great, but detecting an existing hook without breaking it required a sentinel marker (`## GITPULSE_HOOK_V0.1`) rather than just searching for a comment string.

### 5. GitHub Actions CI/CD is a superpower

yaml
on:
push:
tags:
- 'v*'


Now `git tag v0.2.0 && git push --tags` automatically publishes to PyPI. Zero manual steps.

## The Code

7 modules, ~300 lines of Python:
- `cli.py` — argparse with subcommands
- `ai_client.py` — ABC + 3 providers
- `git_ops.py` — subprocess wrappers
- `hook.py` — git hook installer
- `config.py` — env var getters
- `prompts.py` — the system prompt
- `__init__.py` — version

Only dependency: `requests`. Python 3.8+. MIT license.

## Try It

`pip install gitpulse-commit`

GitHub: [erico964-blip/gitpulse](https://github.com/erico964-blip/gitpulse)
PyPI: [gitpulse-commit](https://pypi.org/project/gitpulse-commit/)

Built this over a weekend. Feedback welcome — especially on the prompt design and hook workflow!