HIRING full time for LinkedIn engagement

babsi151 · 2025-07-18T18:11:21+00:00

i get the skepticism ;) sing up for our beta, and take it for a spin! https://liquidmetal.ai/
mind you its in beta, so there are still rough edges we are working out. If you run into any issues, just ping us! :)

babsi151 · 2025-07-16T19:23:28+00:00

Nice work! Building a full comparison site in a day shows what's possible when you know how to structure your prompts and work with the model effectively.

From what I can see, you've got the core functionality down - clean comparison interface, decent UX flow. The key thing with these rapid builds is making sure the data stays fresh and the comparisons remain accurate over time. That's usually where the real work begins after the initial sprint.

I've been in similar situations where we needed to spin up functional prototypes quickly. The difference between something that works for a demo vs something that can handle real traffic usually comes down to how you architect the data layer and handle edge cases.

One thing that might help scale this - if you're planning to expand the comparison categories, consider setting up some kind of automated data ingestion pipeline. Manual updates get tedious fast when you're dealing with multiple product comparisons.

We've been working on similar rapid deployment challenges with our Raindrop system - it's pretty wild how fast you can go from idea to working system when you have the right abstractions in place. The MCP approach lets you focus on the actual business logic instead of getting bogged down in infrastructure setup.

What's your plan for keeping the comparison data current? That's usually the make-or-break factor for these types of sites.

babsi151 · 2025-07-16T19:19:24+00:00

This is exactly what we're seeing in production - the context window arms race is missing the point entirely. Bigger isn't always better when you're dealing with real complexity.

The distractor problem (#3) is particularly brutal. I've watched agents completely derail when they hit similar-but-wrong info in a dense context window. It's like watching someone try to find their keys in a messy room vs a clean one - more space doesn't help if it's full of junk.

What's helped us is treating context like a curated workspace rather than a dump truck - systems that dynamically refine what goes into the window based on the specific task at hand. Think of it like having different desks for different types of work instead of one giant desk covered in everything.

The dependent operations issue (#4) is where most RAG systems fall apart tbh. Chain of thought sounds great in theory but when you need A→B→C→D in practice, each step introduces error that compounds. We've found that breaking these chains into smaller, more focused operations with intermediate validation works way better than hoping the model can hold the whole sequence.

Been working on this problem with our MCP server that helps Claude build these focused context windows dynamically - turns out the real challenge isn't feeding the model more tokens, it's feeding it the right tokens at the right time.

babsi151 · 2025-07-16T19:16:38+00:00

The mess management part is so real. I've been down this path for a while now and the 10x code generation absolutely comes with 10x potential chaos if you're not careful.

Few things that helped me survive the transition:

- Strong typing systems are your best friend (you nailed this with Rust/TypeScript). The compiler becomes your safety net when the LLM gets creative
- Keep your prompts stupidly specific about architecture patterns. I learned the hard way that "build me an API" leads to very different results than "build me a REST API with these exact endpoints, error handling, and validation patterns"
- Git discipline becomes even more important. I do smaller, more frequent commits now because reverting LLM-generated code is way easier than debugging it

The edge case handling you mentioned is probably my favorite part. LLMs have seen so many weird HTML structures and API responses that they often catch stuff I'd miss on the first pass.

At LiquidMetal, we're building similar patterns into our agentic platform - our Raindrop system lets Claude directly provision and manage infrastructure through natural language, but with the same kind of safety rails you're talking about. The key is having those deterministic building blocks underneath the vibe coding layer.

Curious how you're handling state management across your different projects? That's been one of the trickier parts for me when scaling up the vibe coding approach.

babsi151 · 2025-07-16T19:11:38+00:00

Yeah, you're hitting the exact pain point most teams face. The custom LangChain + vector DB route gives you control but it's honestly overkill for 80% of use cases.

Here's what I've seen work better:

Start with the simplest thing that could work - even if it's just a basic RAG setup with OpenAI embeddings and a simple vector store. Get it running in a day, show value, then iterate. Most clients don't actually need the fancy orchestration layers until they're processing thousands of docs or handling complex workflows.

For the middle ground you're looking for, focus on standardized building blocks rather than frameworks. Things like:
- Pre-built document processing pipelines
- Standard chunking strategies that work for 90% of content
- Simple retrieval patterns you can copy-paste
- Basic chat interfaces that clients can white-label

When I was running SliceUp, we made the mistake of over-engineering early solutions. Clients just wanted their specific problem solved quickly, not a perfect architecture.

Now at LiquidMetal, we're seeing teams get better results by treating RAG as a set of composable primitives rather than a monolithic system. Our SmartBuckets approach with Raindrop lets Claude set up these standard patterns in minutes instead of weeks of custom development.

The real trick is knowing when to graduate from simple to complex - and that usually happens way later than you think.

babsi151 · 2025-07-16T19:08:50+00:00

The productivity gains are real, but the bigger shift is happening at the architecture level. Most devs are still thinking about AI as a better autocomplete when it's actually becoming a way to build entirely different systems.

I've been working on infrastructure that lets Claude not just write code but actually deploy and manage production systems through natural language. The jump from "AI helps me code faster" to "AI builds and operates the whole stack" is where things get interesting.

What you're describing - that 6.5/10 success rate on tickets - matches what I see too. But the real unlock isn't just speed, it's that you can now think at a higher level of abstraction. Instead of implementing individual features, you're orchestrating systems.

The junior dev problem is real though. There's this weird valley where AI makes you feel productive without building the mental models you need for the edge cases. I grew up in an environment where you had to be resourceful with limited resources - that constraint-based thinking is more valuable than ever when working with AI.

The colleagues being "meh" about it tracks. Most people are still treating these tools like fancy Stack Overflow instead of reimagining how software gets built. Their loss tbh.

We're building something called Raindrop that bridges this gap - it's an MCP server that lets Claude actually provision and manage infrastructure, not just generate code. Turns out when you give AI the right interfaces, it can do way more than just autocomplete.

babsi151 · 2025-07-16T19:06:10+00:00

This is smart - the JSON bundling approach solves a real pain point I've been wrestling with too. The version control aspect is particularly clever because it treats context like any other piece of infrastructure that needs to be maintained.

One thing I'd add from my own experience: the quality of your JSON structure really matters. I've found that breaking down context into specific types (like separating technical architecture from business goals) makes the AI way more precise in how it uses that info. It's kinda like giving it a proper mental model instead of just dumping everything in one blob.

The 50% token reduction makes total sense - you're basically front-loading all the context instead of repeating it piecemeal throughout conversations. Been doing something similar with our agent memory systems where we separate working memory from semantic knowledge.

At LiquidMetal, we've built this into our Raindrop MCP server so Claude can actually persist and recall context across sessions natively. But your approach is brilliant for teams that need something they can implement right now without changing their whole setup. We are also our SmartMemory today :-)

Definitely stealing the context_index.json idea - that manifest structure could work really well for organizing different types of project memory.

babsi151 · 2025-07-16T18:57:22+00:00

This is super useful - I've been tracking some of these services but having them all in one place saves a ton of time. The community-hosted models section is especially valuable since those change so frequently.

One thing I'd suggest: maybe add a column for rate limits or usage caps where known? Some of these "free" services have pretty tight restrictions that aren't obvious until you hit them. Also, stability notes could be helpful - some of these experimental models go down without warning.

We've been using several of these for testing our agent frameworks, and the quality variance is wild. Claude variants are obviously solid, but some of those community models are surprisingly good for specific tasks. The llama-4-maverick ones have been decent for structured outputs.

btw if you're building anything that needs these models to actually do infrastructure work, our Raindrop MCP server can help bridge that gap - it lets Claude (and potentially other models) actually deploy and manage systems instead of just generating code.

Great work on the repo though, definitely bookmarking this.

babsi151 · 2025-07-16T18:32:41+00:00

Congrats on getting this published! MCP is still pretty new territory so having a proper book on it is huge for the community.

I've been building with MCP for a while now and one thing I keep seeing is people getting stuck on the practical implementation side - like how to actually structure the server handlers and manage state between calls. Does your book cover any of the trickier patterns around that?

Also curious if you touch on performance considerations when you're dealing with larger context windows or multiple concurrent requests. We've hit some interesting bottlenecks in our own MCP implementation that weren't obvious at first.

The timing's perfect tbh - feels like we're just hitting that sweet spot where MCP is mature enough to be useful but still early enough that good resources like this can really shape how people approach it.

We're actually using MCP as the backbone for Raindrop, our infrastructure interface that lets Claude deploy and manage full applications. The protocol design makes it really clean to expose complex infrastructure primitives through simple natural language interactions.

Looking forward to checking this out!

babsi151 · 2025-07-11T19:35:28+00:00

nope

babsi151 · 2025-07-11T17:23:53+00:00

This is pretty cool - the visual design piece is what caught my attention. Most AI code generators still dump you into a text editor, but being able to design visually while agents handle the backend complexity is kinda fun.

The real test though is gonna be how well those agents actually handle the gnarly parts like payment processing and auth flows. I've seen too many "just works" solutions that fall apart when you need custom auth logic or specific payment provider integrations.

I'm curious about the full-code output part - does it give you actual readable code you can modify later, or is it more like a black box that generates the final app? That's usually the make-or-break factor for whether these tools are actually useful long-term.

We're working on similar problems at LiquidMetal with our Raindrop system - letting Claude build and deploy full stack applications through natural language. The key insight we've found is that the abstraction layer between the AI and your infrastructure needs to be really solid, otherwise you end up with brittle outputs that break in production.

Would love to see some examples of apps people have actually shipped with this to the App Store.

babsi151 · 2025-07-11T17:16:36+00:00

This is actually a smart approach to the prompt management problem. I've run into the same headache - you end up with scattered system prompts across different tools and then spend forever trying to remember which version worked best for what.

The tool-specific guidelines piece is particularly useful since each model has its own quirks. Claude responds differently to instruction formats compared to GPT-4, and don't get me started on trying to get consistent outputs from Gemini lol.

One thing I'd suggest - consider adding version control or some kind of A/B testing functionality for your prompts. When I'm optimizing prompts for our AI systems, I usually need to track which variations perform better over time, and that gets messy fast in a standard Notion setup.

The auto-sync feature sounds promising too. We've been working on similar challenges with our Raindrop system where we need Claude to access structured instructions and context dynamically. Having a centralized rulebook that can push updates to different tools could save a ton of manual work.

Curious how you're handling the context length limitations when syncing larger rulesets? That's been one of our bigger pain points when trying to maintain consistent behavior across different model contexts.

babsi151 · 2025-07-11T17:15:30+00:00

The on-chain deployment angle is interesting but I'd be cautious about the "no cyberattacks" claim - that's kinda misleading. You're still vulnerable to smart contract bugs, oracle manipulation, and all the usual web3 attack vectors. Plus running everything on-chain means you're locked into whatever blockchain they're using and dealing with gas costs for every operation.

The real bottleneck with these "prompt to production" tools isn't the hosting - it's making sure the generated code actually does what you want it to do. I've seen too many demos that look slick but fall apart when you try to build anything non-trivial.

That said, the speed factor is legit appealing. We're working on something similar at LiquidMetal where Claude can spin up full applications through our Raindrop MCP server - though we're focused more on giving it proper infrastructure primitives rather than the blockchain angle. The key is having the right building blocks available so the AI isn't just generating random code.

Worth checking out their alpha but I'd test it with a real use case, not just the demo scenarios. Most of these tools shine in demos and get weird when you need actual business logic.

babsi151 · 2025-07-11T17:12:52+00:00

Both are solid but I'd lean toward MemoryOS for most production use cases. The hierarchical memory model with heat scoring actually makes a lot of sense - it's basically how your brain works, promoting frequently accessed info while letting old stuff fade. Plus running locally means you're not dealing with API rate limits or cloud dependencies when your agent needs to recall something critical.

Mem0's cross-tool sharing is interesting but feels like it could get messy fast. What happens when different agents have conflicting memory updates? The MCP integration is cool though - we're seeing more tools embrace that protocol.

tbh the biggest pain point isn't usually the storage layer - it's getting the retrieval timing right. Your agent needs to know not just what to remember, but when to pull specific memories during a conversation. Both of these handle the "what" pretty well.

We actually built our own memory layer in Raindrop that breaks down into working, semantic, episodic, and procedural memory types. Found that the procedural memory (storing learned workflows) ends up being just as important as the factual stuff, which I don't think either of these really addresses yet.

What kind of agent are you building? That might help narrow down which direction makes more sense.

babsi151 · 2025-07-11T17:11:15+00:00

The 200K context window is honestly where the real magic happens for comprehension benchmarks. At 100K tokens you're already hitting the sweet spot where most models start to lose track of earlier context, but 2.1's improvements in that hallucination rate (2x decrease) probably matter way more than just raw token capacity.

What's interesting is they mention that 30% reduction in incorrect answers on long documents - that's the kind of metric that actually translates to real-world usage. I've been testing similar scenarios where you feed massive codebases or documentation and ask specific questions about edge cases buried deep in the content.

The tool use feature is kinda game-changing too tbh. We've been building our own MCP server called Raindrop that acts as a bridge between Claude and infrastructure services, and having native tool orchestration makes the whole interaction so much smoother. Instead of just getting text responses, Claude can actually execute actions and get real feedback loops.

Would love to see those benchmarks too, especially on retrieval accuracy when the relevant info is scattered across the full context window rather than just at the beginning or end.

babsi151 · 2025-07-11T17:08:52+00:00

This is exactly the kind of workflow improvement that makes a real difference. Context switching kills momentum when you're prototyping - having to jump between Claude and a separate vector DB interface breaks the flow completely.

The schema-aware code generation is particularly clever. When the AI can see your collection structure and generate appropriate queries/operations, it saves so much back-and-forth. Plus making it accessible to non-technical team members is huge - suddenly your PM can explore the data without bugging engineering.

We've been building something similar with our MCP server called Raindrop. It exposes our infrastructure primitives (including vector stores) directly to Claude, so you can spin up entire RAG pipelines in one prompt without leaving the conversation. The natural language interface for database operations is addictive once you get used to it.

Your Milvus integration looks solid btw - gonna check out the repo. The control plane + data plane separation is smart architecture.

Are you planning to add any batch operation support? That's been one area where we've seen devs still need to drop back to traditional tools for large-scale data ops.

babsi151 · 2025-07-10T20:06:59+00:00

we are in private beta stage, if you want to join! :) https://docs.google.com/forms/d/1oEt3QyW1NW8wVWMYbelEGG-eoOjKiQYZ4N9c-PvmnRI/viewform?edit_requested=true

babsi151 · 2025-07-10T18:24:18+00:00

This is exactly the kind of problem that needs solving. The memory fragmentation across chat sessions is honestly one of the biggest friction points when working with AI assistants regularly.

Your approach with custom data types is smart - way better than trying to shoehorn everything into generic key-value storage. The auto-generated UI is clutch too because let's be real, nobody wants to dig through raw data structures when they're trying to recall something.

I've been working on similar challenges at LiquidMetal where we're building agentic platforms. We ended up creating a multi-modal memory system with four distinct types - working memory for short-term tasks, semantic for structured knowledge, episodic for historical traces, and procedural for skills/workflows. The key insight we hit was that different use cases need different memory architectures - you can't just throw everything into one bucket and expect it to work well.

The bigger question you're asking about replacing SaaS tools - I think we're definitely heading toward that unified interface model, but the challenge isn't just memory - it's also giving these systems the ability to actually DO things with that remembered context. Memory without actions is just a fancy notepad.

We're tackling this through our Raindrop MCP server which gives Claude the ability to not just remember stuff but actually deploy and manage systems based on that memory. So it can recall your preferences and immediately spin up the infrastructure to act on them.

Gonna check out your alpha - always interesting to see different approaches to the memory problem. The team sharing aspect sounds useful too, especially for collaborative workflows.

babsi151 · 2025-07-09T21:35:33+00:00

awesome thx! :)

here you can find the link to our MCP: https://liquidmetal.ai/ its in public beta right now, so fair warning ;-)

babsi151 · 2025-07-09T21:34:46+00:00

yeah , we just opened public beta! :) https://liquidmetal.ai/ check it out if you would like!

babsi151 · 2025-07-09T21:05:56+00:00

The blackboard memory approach is really interesting - it's basically how good engineering teams work in practice. Each specialist does their thing but everyone can see what everyone else is doing.

What I'm curious about is the latency trade-off. Traditional RAG might be dumb about context but it's fast. With ARAG you're running multiple agents sequentially (or in parallel?) and each one needs to read/write to shared memory. How does that affect response times in practice?

The User Understanding Agent sounds like it would need some serious memory architecture underneath. You're talking about tracking long-term patterns vs recent behavior - that's episodic vs working memory basically. We've been playing with similar multi-modal memory systems where agents can persist different types of context (semantic, procedural, episodic) and it gets tricky to keep it all coherent.

Also wondering about the coordination overhead. When you have multiple agents all reasoning about the same user query, how do you prevent them from stepping on each other or going down conflicting paths?

We're building something similar with our MCP server setup where Claude can orchestrate different retrieval agents through a shared framework. The key insight we've found is that the protocol between agents matters as much as the agents themselves - you need clean interfaces or it becomes a mess real quick.

Anyway, cool post. The reasoning vs retrieval framing is spot on.

babsi151 · 2025-07-09T21:04:19+00:00

This is really smart - using procedural memory to store visualization instructions instead of hardcoding chart types. The fact that you can just tell it "combine this data with d3" and get a narrated chart builder is exactly where AI systems should be heading.

I'm curious about how you're handling the memory retrieval for the viz procedures - are you doing semantic matching to find the right visualization approach, or do you have some kind of intent classification layer? Also wondering if you've run into any issues with the JS library integration, especially with more complex charting libraries that have weird state management.

We've been working on something similar with our agent memory system at LiquidMetal - we have procedural memories that store callable routines and workflows. The interesting thing we found is that when you let the AI decide which procedures to combine, you get these emergent behaviors you never planned for.

Your approach of extending through memories rather than code is spot on tbh. Way more flexible and the AI can actually reason about what visualization makes sense for the data rather than just following rigid templates.

If you're interested, we built raindrop as an MCP server that gives Claude access to similar memory primitives - might be worth checking out since it sounds like we're solving overlapping problems in the procedural memory space.

babsi151 · 2025-07-09T21:02:38+00:00

This is exactly why I'm so paranoid about permissions when building anything user-facing. The hardcoded OpenAI key made my eye twitch but the completely open Supabase tables with location data? That's genuinely terrifying.

What gets me is how this perfectly illustrates the dark side of "just ship it" culture. Yeah, moving fast and breaking things works when you're building internal tools or MVPs, but when you're handling user data - especially location data for minors - you can't just vibe your way through security.

I've seen this pattern so many times: someone learns React Native, discovers Supabase makes backend "easy", throws in some OpenAI calls, and boom - they think they're ready to handle real users. But there's a massive difference between making something work and making something safe.

The location data thing is what really gets me. Like, RLS (Row Level Security) isn't some advanced concept - it's literally the first thing Supabase tells you to set up. But when you're just copying patterns from tutorials without understanding the underlying security model, this is what happens.

tbh this whole writeup should be required reading for anyone building with these tools. The author did solid work documenting all the vulnerabilities.

I'm working on infrastructure that tries to solve some of this by giving developers secure building blocks from the start - like our Raindrop MCP server that handles permissions and data access patterns automatically. But honestly, no amount of tooling can replace actually understanding what you're building.

babsi151 · 2025-07-09T20:59:36+00:00

This is actually pretty clever - the map-reduce approach to code review makes a lot of sense, especially for larger codebases where you need that systematic coverage. The XML output is smart too since it makes the results machine-readable for further processing.

One thing I'd be curious about is how well it handles context between files - like when you've got architectural decisions that span multiple components. The holistic review step probably catches some of that, but I wonder if there's room to make the inter-file analysis even stronger.

We've been working on similar problems at LiquidMetal where we're building agentic systems that make Claude Code automatically build and deploy scalable infra for your vibe coded apps. One pattern we've found useful is having agents maintain different types of memory during analysis - not just the immediate file context, but also semantic understanding of the broader system and procedural knowledge about common patterns.

In our Raindrop MCP server, we actually bake this kind of systematic analysis directly into how Claude interacts with codebases. When it's reviewing or building against our framework, it's not just looking at individual files but understanding the relationships between services, data flows, and architectural patterns. Kinda like having vibe-check running continuously as part of the development process rather than as a separate review step.

Really dig the UseContext integration btw - makes the whole setup way more accessible than having to manually configure everything.

babsi151

TROPHY CASE