ohans

Lib author here. Like most teams, we ship fast, and increasingly the important thing for us is making sure the overall system is healthy. Working code isn't enough.

So, before reading the code diff on PRs, we can judge from visually rich architecture and data flow diagrams. This helps us keep a clear mental model of how every part of the system is evolving.

We built a new renderer to support some of the rich visualisations, and curious if it's helpful for others

Broken X link on the site footer FYI

Love the name! Now back to reading the docs to get a better sense of how this works :)

Author here.

The consensus, in order of how much they write about it mostly: architecture and repo layout, how to test, build commands, dos-and-don'ts, PR etiquette, and code style.

The surprise was tone, and the lack of non-technical constraints.

90% write in must/always/never, and there are 784 explicit "don't" bullets, most of them oddly specific.

It's almost like you can tell exactly which mistake an agent made in each repo.

Some are hilarious: "Do not claim that an interrupted or timed-out test passed" takes the gold for me.

The shortest is 35 words, one rule from Neovim.

> AI Disclosure: If AI was used in any way for a commit, add an AI-assisted: <tool name> trailer to the commit message. If the user commits manually, remind them to add it.

The most popular headings by far were: testing, commands, project overview, and architecture

There's a lot more interesting deets like the average length, nextjs' "Do NOT add "Generated with Claude Code" ..."

Is your AGENTS.md very different to these?

Hilarious on not trying to be different, and congrats on the launch. I've seen too many of these it has lost its charm for me, sadly

What I've found to work is just to bring the review cycle locally, e.g., implement with Claude and review with Codex (with my guardrails set) in the terminal. Something like Herdr works well; I use Coldtea

That being said, the reason I think cloud AI review companies (that review on PRs) work is that at a large org you need a way to ensure that the review indeed happens. And you can't blindly trust that the dev did this locally.

We're a small team, so shifting left works. Just review locally. If you're a large org, that's a different problem space

Being a smaller team, our process is a lot simpler, but the "ephemeral test env" is the one bit that's helped us move faster and more confidently

Since it allows us to automate regression testing with visual QA agents that test the app like a real user (mostly through Coldtea, which we build)

P.S: Been meaning to have calls recorded/transcribe. How do your agents retrieve the vast info in these transcripts? By that I mean is it effective?

Author here.

AI agents have dominated Twitter/X the past few days: Claude Code, Remotion, Cursor, etc. But most developers are running these locally. Terminal agents on your machine.

That's useful, but it's a different game when you're building AI apps for users. The moment your agent needs to actually execute something e.g., run a Python script, process a PDF, generate files, you're suddenly building sandboxing infrastructure, managing VMs, handling file storage.

It's a massive distraction from your actual product. We built Bluebag to solve this for Vercel AI SDK users. Two lines of code, and your agent gets access to Skills that execute in managed sandboxes.

No Docker orchestration. No K8s. Dependencies, file handling, signed download URLs, all handled.

The post walks through some of the architecture (progressive skill loading, auto-provisioned VMs, multi-tenant isolation) and shows concrete integration examples.

Happy to answer questions about the approach or trade-offs we made.

Cheers

TIL: you could add a ".diff" to a PR URL. Thanks!

As for PR reviews, assuming you've got linting and static analysis out the way, you'd need to enter a sufficiently reasonable prompt to truly catch problems or surface reviews that match your standard and not generic AI comments.

My company uses some automatic AI PR review bots, and they annoy me more than they help. Lots of useless comments

This was a brilliant write up, and loved the interactivity.

I do think "logs are broken" is a bit overstated. The real problem is unstructured events + weak conventions + poor correlation.

Brilliant write up regardless

Hey HN, can't help but think this is where AI development will be heading in 2026, with the biggest reasons being deterministic outputs + the cost savings that come from progressive disclosure as opposed to tools/MCPs

As always, curious to hear your thoughts

Yes!! The runtimes are ephemeral VMs/containers with no network access (exposed)

On OS, the core of the solution is not currently open source; it’s still changing a lot, and I don’t want to publish an API or SDK surface that I’ll immediately have to update.

But I plan to open-source the CLI package and SDKs shortly

Hi HN,

When Anthropic published their Skills system (https://www.anthropic.com/news/skills), the idea clicked for me immediately: take a general-purpose agent and turn it into a specialized one with procedural knowledge that no model can fully memorize.

In my own projects I wasn’t using Claude (most of my workloads were on Gemini 2.5 Flash, mostly cos it was affordable and got the job done), but I still wanted that architecture: a way to define Skills once and use them with whatever LLM made sense for a given use case.

So over the past few weeks I put together a solution that does roughly that. Right now it supports:

- Bundling metadata, instructions, reference files, and optional scripts into a Skill - Running scripts in Python or JS runtimes (with automatic package installation) - A simple files API so the LLM can create files, reference them, mint temporary download links, and let me upload docs for analysis - A CLI to manage skills locally (push/pull), a Typescript SDK and a web app to manage API keys, PATs, playground etc.

There’s a playground at http://www.bluebag.ai/playground with example Skills (mostly adapted from Anthropic’s public Skills repo at https://github.com/anthropics/skills). On the right-hand side you can see how different models progressively load files and metadata, so you can inspect how selection and loading behave across models.

There are still some open questions I’m thinking about, especially around VM reuse and isolation at scale, and how to handle large Skill libraries over time (cold starts with very large package sets and 15+ Skills are slow).

But it’s been useful enough in my own work that I wanted to share it and get feedback. I’d be interested in:

- obvious failure modes I’m missing - prior art I should be looking at (e.g., agent frameworks)

Happy to answer any questions or dig into implementation details if that’s useful.

Cheers

OK, got it! Cool. I had wild ideas, but this makes sense.

QQ: on clicking the articles, I expected to get redirected to the original article, but I stayed on your site.

Is what I see a summarisation of the original article?

Are the original authors happy with you? :)

What does "runs itself" mean in this context?

No qualms! Thanks for sharing :)

Really cool! I reckon a nice UI would be a good addition

Looks good! You could push to npm so that running it could be as easy as:

npx webclone URL (no repo cloning required)

Also, FYI, when running the example code

node webclone.js https://www.example.com/

It fails (at least for me) until I either install yt-dlp or ignore videos via:

node webclone.js https://www.example.com/

For just $10? The pricing begins at $45. Except you mean when broken down monthly?

Congrats on the launch!

I see, thanks. New to HN. I suppose I'll repost it later next week since I can't delete/edit the existing post.

Thanks!

dammit, just updated the link. Thanks!

You make some solid points!

> I don't know what you mean by "true alternative to Amazon SES.

e.g., the GMail API is restrictive (https://support.google.com/a/answer/166852?hl=en) for bulk sends. That's not the intended use case.

> Google partners with Sendgrid as well for customers who need that kind of solution.

Do you mean via the marketplace integration?

> I could ask why Amazon doesn't offer a true alternative to GMail and Outlook.

That's fair. I reckon different models like you mentioned

That's certainly a possibility! However, with 300 billion emails sent a day and assuming 10% of those are transactional / marketing, I assume there's a play for a pay-as-you-go solution. SES holds a monopoly in that space now.

nitpick: the tooltip (triggered by the question mark icon) does not work on mobile - at least on my iPhone (both chrome & safari)

May be worth taking a look at.

Good stuff otherwise! Cheers on the launch

No qualms! Congrats on the launch again

> Despite how crucial it is, it's hard to find a service that has all the features you need for a successful product.

> That's why we built Stack.

I’m not convinced this is a strong USP. One could make a decent argument “Stack” doesn’t have “all” the features (yet) - I’ve seen the roadmap.

Firebase, Superbase etc. arguably have more features.

In a nutshell, I think it might be better to have that paragraph really drive home the USP of the product e.g., open source accountability, fairer pricing model etc.

Those are strong tells, instead of the “all the features” narrative. That’s a hard battle to win :)

Regardless, awesome work! And congrats on the launch

“…I realized that a quiet life isn’t a passive life…”

The importance of finding such balance makes all the difference.

Beautiful writing.

No qualms re: removing registration. I understand! Thanks for the examples, gonna take a look!

While I haven't given it a deep look, a free trial without CC details would have been nice! Regardless, building such a rich (Notion style) text editor isn't trivial. So, cheers to that.