nuwandavek

Removed them! Sorry, never had so many people using the site at once before :)

Sorry! Never has so many people using the site at once before! Removed them :)

Yeah, I wonder how they even test interactions between different parts of the prompt (if at all). All the recent effort with skills seems to be the right direction as their complexity can be arbitrarily fractal.

(Author here) I’ve to complete part 3. Spoiler: HN is actually not getting meaner and is shockingly consistent!

There is so much scope with maps! All we need is a realtime-ish image model to tidy up the scene. (was looking into it during a recent side project - https://sf.isopolis.city/).

So exciting!

sorry! i debated this quite a bit, but the sv opening credits was too good to not include :(

more zoom enabled!

more zoom enabled!

yeah, there are a ton of issues wrt water. I've documented a few of them here: https://sf.isopolis.city/dev.html

Planning to fix in the next version!

Spurious lakes are an interesting issue I looked into a bit. 2 types of cases ended up becoming lakes: 1. "shadows" 2. flat green areas

I think a better data distribution should eliminate this. Also, my "water detector" was not too good and could be improved.

I wrote about a few of these things here: https://sf.isopolis.city/dev.html

ty!

very inspired by you!

glad you liked it!

I had to leave out a ton of details in the training process. But at every step, codex/cc built me a dev tool to navigate the complexity. That was such a unique side project experience.

yeah, there are a ton of issues especially around water. I've documented a bunch of them here: https://sf.isopolis.city/dev.html

I tried out a few ideas, but i think better training data around water will help a LOT.

oooof, I can actually allow more zoom (was just embarrassed at bad pixels)

haha ty!

hey thanks! i wrote it all up here: https://sf.isopolis.city/dev.html

woahhh, these are so beautiful!

(blogpost author here) I've noticed this too. My top guess for any such thing would be that this type of sub-agent routing is outside the training distribution. Its possible that this gets better overnight with a model update. The second reason is that sub-agents make it very hard to debug - was the issue with the router prompt or the agent prompt? Flat tools and loop make this a non-issue without loss of any real capability.

There may be other reasons to use ai sdk, but I'd highly recommend starting with a simple loop + port most relevant tools from Claude Code before using any framework.

Nice, do share a link, would love to check out your agent!

Oops, fixed it, thanks!

(blogpost author here) Haha, that's totally fair. I've read a whole bunch of posts comparing CC to other tools, or with a dump of the the architecture. This post was mainly for people who've used CC extensively, know for a fact that it is better and wonder how to ship such an experience in their own apps.

(blogpost author here) I actually found none of them useful. I think MCP is an incomplete idea. Tools and the system prompt cannot be so cleanly separated (at least not yet). Just slapping on tools hurts performance more than it helps.

I've now gone back to just using vanilla CC with a really really rich claude.md file.

(blogpost author here) You're right! I did make the distinction in an earlier draft, but decided to use "RAG" interchangeably with vector search, as it is popularly known today in code-gen systems. I'd probably go back to the previous version too.

But I do think there is a qualitative different between getting candidates and adding them to context before generating (retrieval augmented generation) vs the LLM searching for context till it is satisfied.

(author of the blogpost here) Yeah, you can extract a LOT of performance from the basics and don't have to do any complicated setup for ~99% of use cases. Keep the loop simple, have clear tools (it is ok if tools overlap in function). Clarity and simplicity >>> everything else.

Haha, the analogy is totally yours to use :) Nice, yeah, there is a lot of leverage in building agent-like hooks into current workflows. Even if the agents are pretty mid right now (they are for any complex use case that needs long horizon planning), it's a great place to be in time for the next generation models to drop!

Thanks! Not sure, I think the term has been in the ether for a while.

Yeah, I see that too. I think for the longest time there was no leverage in doing this sort of retrofitting (except for grammarly type of use cases). But with better intent capture (llms help here), we can actually fix up any existing gaps!

We love that feature too and use it quite a bit ourselves!

> Not quite sure if this should be a separate category?

We see ourselves at the intersection of generic browser-automation agents and generic coding agents. MinusX integrates deeply into jupyter/metabase (we had to do a lot of shenanigans to get the entire jupyter app context) and has more context than RPA agents do today. It is possible that eventually all these apps will converge, but we think MinusX will be more useful for anything data related than any of them for the foreseeable future.

To paraphrase geohot, we think that the path to advanced agents runs through specialized, useful intermediaries.

Yes! Both bring-your-own-keys and local models are on the roadmap. The ETA for both is ~1-2 weeks.

Haha, yes! We were doing the exact same thing. Also, there is so much context you can't capture with just table schema that you can if you integrate the extension deep into the tool. It also unlocks cross-app contexts (we're working on a way to import context from a doc to a metabase query, or from a sheet/dashboard to a jupyter notebook etc.

> Is there a way to select which model is being used? Not at the moment, but this is in our pipeline! We will enable this (and the ability to edit the prompts, etc.) very soon.

Do try it out and let me know what you think!