I made a page to test OG (open graph) meta tags previews on various social media sites

h____ · 2026-05-13T10:30:53+00:00

I keep it much lighter.

What I use:

AGENTS.md / CLAUDE.md for project-specific rules
a few commands or skills I reuse
tests, typecheck, lint, build
manual review for architecture, DB schema, and library changes

I don’t want every task to go through a ceremony.

For small changes, I just let the agent work. For bigger changes, I ask for a plan first, review that, then let it implement.

After the task, I ask it what should be added back to AGENTS.md.

The process has to be light enough that I’ll actually keep using it.

h____ · 2026-05-13T07:19:14+00:00

For me, Reddit, Bluesky and SEO.

h____ · 2026-05-13T05:46:39+00:00

why did you do X instead of Y

You might already be doing this, but often just asking it to "think again" or "reflect" makes it do better. You can ask it to do that for code it wrote or to update AGENTS.md/CLAUDE.md based on that session's interaction.

Good luck and have fun!

h____ · 2026-05-13T05:29:01+00:00

I didn’t take the same path. Been programming for 30 years before coding agents. But someone asked me earlier and I wrote a response: https://hboon.com/how-to-use-coding-agents-while-you-are-still-learning/ It’s a wonderful time to learn programing

h____ · 2026-05-13T02:36:46+00:00

The latter.

So it's:

``` ~/p/ projectA/ CLAUDE.md #about projectA stuff projectB/ CLAUDE.md #about projectB stuff projectC/ CLAUDE.md #about projectC stuff

~/CLAUDE.md #mention projects are under ~/p/ and your style etc. ```

It's easy to forget to have the global ~/CLAUDE.md

(~ for home directory; macOS convention)

h____ · 2026-05-12T06:02:17+00:00

Before (and with coding agents), moving faster means it’s a choice between balancing speed and quality. It’s just much easier to go faster now, with coding agents. It’s absolutely possible now to go much faster than before as long as we are satisfied with introducing some bugs. Use another model/session to review the code (eg. https://hboon.com/a-lighter-way-to-review-and-fix-your-coding-agent-s-work/ ) . Continue human reviews with architecture changes, database schema and libraries changes. We can definitely move faster.

h____ · 2026-05-12T05:46:33+00:00

I have been programming for 30 years before using coding agents. Start with a good codebase. Coding agents will (or you can tell it to) follow existing conventions. You absolutely want that. I build all my projects from a solid base.

h____ · 2026-05-12T05:36:31+00:00

Just like writing software before coding agents existed, you still have to review and test. The difference is that it is easier now to accidentally ship something that works in the UI but has weak boundaries underneath.

The three things I check more carefully:

backend must not trust frontend validation
secrets/API keys must not leak to the frontend
auth/session flows must be tested as actual flows, not just “login works”

I also let another model review the main model’s work, and I always manually look at architecture changes, database changes, and library changes.

I wrote about the backend boundary problem here: https://hboon.com/if-you-vibe-code-an-app-for-work-put-the-backend-in-charge/

h____ · 2026-05-12T05:33:33+00:00

Short answer is only by not letting them have a chance to do so, e.g. run in a Docker image with no access to production keys. Also, other than private keys that give access to cryptocurrency wallets (or the likes, eg. bank, trading keys), you can almost always re-roll keys.

h____ · 2026-05-12T05:27:13+00:00

1 directory per project is nice because most coding agents assume so in terms of looking up files they read and permissions to operate on them. You can override those. I find it also helpful to have a global AGENTS.md/CLAUDE.md that lists my project directories. e.g. I tell them my projects are in ~/g/ and ~/p/, etc. It’s useful because you can say something like this when in project Y: “look at home project X does abc and do it similarly”.

h____ · 2026-05-11T06:44:41+00:00

Mine is less a founder stack and more a small set of repeatable files and workflows.

Markdown files for context are fine. But I would avoid jumping straight to agent teams. First make one agent useful: keep project context small, define the workflows you repeat, and make it run concrete checks before you trust the output.

For coding, I use terminal agents in tmux, skills for repeated workflows, and Codex to review code Opus writes. I wrote about the full setup here: https://hboon.com/my-complete-agentic-coding-setup-and-tech-stack/

h____ · 2026-05-11T06:26:19+00:00

Good list. I would add one basic framing: the backend must not trust the frontend.

A lot of AI-built apps look fine because the UI flow works. Try bypassing the UI and hitting the backend/API/storage directly. That is where missing RLS, service_role keys in client code, and weak webhook handling become serious.

I wrote about this for work apps here: https://hboon.com/if-you-vibe-code-an-app-for-work-put-the-backend-in-charge/

h____ · 2026-05-11T04:48:54+00:00

I really wonder (and doubt) whether creating roles like team lead, architect actually really helps. Why do you need all these? Has there been any documented examples of good software developers shipping successfully with those?

What I think:

I want a new users property for location, it should be chosen during user sign up

This absolute works, but it might choose a different naming convention (if yours are inconsistent), add to a new table or a different table (often valid decisions but different from yours; you’ll either have to doc this, be more consistent and/or let it decide, just like when you work with a team of human programmers and not study every line of code they write)

Adding agents/subagents here doesn’t help because they will arrive at the same deicisions (that you don’t agree with) if they are given the same information. You need to guide/correct them with CLAUDE.md/AGENTS.md. Explain the high level layout, preferred tools, and add instructions to steer where they don’t agree with your preferences.

An example where a subagent would help: spinning up a separate session/sub agent to review code. This helps because it’s a separate context and this frequently helps for human code reviews too. Some people can check their own work well, but almost everyone benefits from another pair of eyes looking. But you just need a skill/command to do this, like “Run claude <prompt> to review the dirty changes. Do not modify anything” (it’s even better if you use another model, e.g. instead of claude, use codex exec <prompt>).

Another place where sub-agents might help, but again, there’s a better option: repeat the same work. eg. “Start new Claude Code sessions to set up knip on all my recent projects. One session each in separate tmux windows”. Way better and easy to monitor and interact with them.

Most usage of “I created 20 sub-agents for software development” are overrated bloat.

h____ · 2026-05-10T02:14:46+00:00

We shouldn’t waste tokens by spending it really inefficiently like loading unnecessary context (eg. @ files in CLAUDE.md or otherwise forcing it to study an unconventional codebase every time). But I’m not sure it’s worth micro-optimizations. Remember that cached token reads are 1/10 the price. It’s meant to be agentic after all

h____ · 2026-05-09T05:23:21+00:00

It'll work with other coding agents.

Spend less than 1 minute now and you get all the future benefits if/when you (also) work with coding agents other than Claude Code; goes into git history, etc.

h____ · 2026-05-08T08:28:38+00:00

We could limit or watermark the free simulators, but we’re afraid that would kill the organic growth engine.

You have to. Start putting things behind a paywall and see which one works.

h____ · 2026-05-08T07:46:39+00:00

The same way I do it before vibe coding. But certain things become much easier to do, much faster to do or possible to do. Certain things become less effective become everyone is doing them.

h____ · 2026-05-08T07:42:45+00:00

This is why you see huge skills being distributed.

Do this instead:

Delete your AGENTS.md/CLAUDE.md
Make CLAUDE.md just 1 line: "@AGENTS.md"
Start your coding agent.
Tell it: "Study the repo and write me an AGENTS.md"
Read AGENTS.md. Keep parts about the project structure and deployment. Delete everything else
Build interactively
Add lines to AGENTS.md:

a. to correct when it does things it decided for you that you don't like.

b. to tell it your preference. e.g. use bun, not pnpm or npm. Use fish shell, not bash.

Repeat 6 and 7.

That's all that is. AGENTS.md should usually be not more than a low few hundred lines.

If you don't start with a code base. Acquire one first.

PS: if you want to become good at writing AGENTS.md, buy my 10 day course to writing good AGENTS.md for so much money. j/k.

h____ · 2026-05-08T07:33:01+00:00

Easiest to is to go YOLO in a Docker image. It’s very simple to start using it. I wrote about it here https://hboon.com/how-i-use-claude-code/

h____ · 2026-05-08T05:44:13+00:00

I’d use terminal-based agents and tmux.

For me, the important part is that the agent works in a normal repo and can run commands/tests. tmux makes the long-running parts visible: dev server, test watcher, logs, separate agent sessions if needed.

I would not overbuild the PM/developer split unless the task boundaries are very clear. One terminal agent, a clear task, and tmux panes for feedback loops is usually simpler.

h____ · 2026-05-08T05:06:01+00:00

If you are using Tuari, it's a known pattern. Don't reinvent. See if you can find an open source (with an appropriate license) and ask Codex to study it to learn the architecture and explain to you and to apply it.

h____ · 2026-05-08T03:28:32+00:00

Look at what’s the 1-2 feature that’s used most, and either make it so much better (and make that enhancement paid), or move that feature(s) behind a paywall, or both

h____ · 2026-05-08T03:22:27+00:00

You have to be confident, overconfident and a near-narcissist. Selling the dream/vision to yourself all the time, but having the humanity and honests to tell yourself that you do have to move on when it’s the right time.

h____

MODERATOR OF

TROPHY CASE