HN user

sprobertson

736 karma

Front/back/deep-end developer

https://github.com/spro/

Posts9
Comments462
View on HN

Pretty much everyone saying worktrees but I lean heavily on hot-reloading of both backend and frontend (to actually see what I'm doing) so it's too annoying to deal with dependencies and ports when things are isolated. Instead I keep everything on the main branch and just make sure to keep tasks pretty separate in scope, e.g. add this API route vs. fix this layout issue, so they don't step on each other. When I consider something done I have the agent commit what it worked on and start a new one.

Microgpt 5 months ago

Sure, but use the tool for the job IMO. GPTs are much more complex so should demonstrate a much more complex task.

Who's the designer? I assume the same as agents.cloudflare.com, finally something that looks creative and not based on purple gradients

Yeah good call, I missed that. I don't think there's a correct answer here, but it could be another step of the read or write. Either it would do another lookup of "my daughter" -> Name on read, or do a lookup on write if you already have a "my daughter is Name" memory. Whatever's less expensive in the long run. The graph memory someone else mentioned also seems like a good option there.

As a simplified example:

(memory) [2023-07-01] My daughter is 10

(memory) [2024-05-30] My daughter turned 11 today!

System prompt: Today is 2025-08-21

User prompt: How old is my daughter?

The vector DB does the work of fetching the daughter-age-related memories, your system decides (perhaps with another LLM) if the question needs time-based sorting or something else.

This in combination with making the tool call / json response itself also "batched" is a good pattern. Instead of returning a single `{english, foul}` object per record, pass in an array of records and have it return an array of `[{english, foul}]`. Adjust the inner batch size depending on your record size and spread the rest over the batched API.