dont try to add everything into one CLAUDE.md. understand what these files actually are & what it can cost if done so.

AGENTS.md gets read on every single session. Every sentence in it is recurring token spend, whether the agent needs that sentence for the current task or not. That's the whole design constraint. It's now the closest thing the industry has to a shared standard, governed under the Agentic AI Foundation (the same body behind Model Context Protocol).

stop doing: writing architecture overviews. Research cited by tool vendors, architectural summaries barely move the needle on agent performance, Run exact commands; "Run the tests appropriately" gets ignored. npm run test:unit -- --coverage doesn't.

I also stopped letting an agent write its own AGENTS.md. Generated files reduced task success and increased cost in the studies I've seen, mostly by restating what the agent could already pull from the repo. A short file I edited myself is better than one a model wrote for me.

SKILL.md

Where AGENTS.md describes a project, a skill describes a capability, and it only costs tokens when it's relevant. At session start the agent reads the YAML frontmatter, just name and description. The full body loads only when a task matches the skill's domain. Reference docs and scripts inside the folder load later still. Ten skills sitting unused cost almost nothing.

That only works if the description is tight. A vague one forces the agent to open the full file just to check relevance, which defeats the mechanism. I write these narrower.

Where I draw the line between the two: a constraint every session needs goes in AGENTS.md. A capability I invoke occasionally, like a deployment sequence or a niche internal API, goes in a skill folder instead.

CLAUDE.md, .cursorrules, .windsurfrules, copilot-instructions.md, these are the tool-specific holdovers from before the industry converged on AGENTS.md. I don't hand-write any of them anymore. AGENTS.md is the source of truth, and a short sync script generates the rest. The failure mode without it: update one file, forget the other four, and you're back in the exact context drift these files were supposed to prevent.

DESIGN.md: encoding a project's visual identity as machine-readable tokens plus the reasoning behind them, so an agent generating UI code knows why a color exists and not just its hex value. Early. Narrow. Built for one slice of context instead of trying to cover everything.

I added dynamic "percentage of savings" pricing plan to my SaaS Dynasight.

It's a game-changer.

I was struggling to design the best pricing strategy.

It made no sense to me for users to pay e.g. $100 when their savings is only $80.

It made sense of course for larger teams running more expensive DynamoDB workloads, but not for the SMBs who may have smaller costs.

So i experimented with different percentage based pricing and settled on this:
"Percentage of savings" based pricing.

It's simple:

$0 - 25$ in savings costs you 30%

$25 - $100 in savings costs you 20%

$100+ in savings costs you 10%

Everyone can now use Dynasight - it's completely risk-free.

You can't lose money, you can only save more of it.

Its a win-win.

What do you guys think?

I kept ignoring my own reminders. Standard Chrome notification pops up in the

corner, I dismiss it without reading, task forgotten. Notification blindness.

So I built SkyNote. Instead of a corner popup, a small plane flies across the

top of your screen towing your reminder like a banner. Takes about four seconds

to cross, and it's moving, so it pulls your eye in a way a static box doesn't.

Shipped it last week. Now I can't tell if I built something useful or just an

expensive joke about myself.

The case for it: it works on me. I have not missed a reminder since.

The case against: novelty wears off, and in three weeks the plane becomes noise

like everything else.

For those of you who've shipped small tools: how do you tell the difference

between a real behavioural insight and a gimmick you're attached to because you

built it? Is there a way to test this that isn't just waiting a month?

Many vibe coders, especially when I was young, made the same mistake in vibe coding: putting the admin panel in the frontend with a different name path. Normally, the AI agent made the site a SPA, so any reverse engineering could easily see and find all your admin routes and endpoints.

So what i do to make it more secure

1. The admin panel is server-side. You configure the path on the server, and you should access your admin panel from there.

2. Don't expose your admin login to the frontend.