BlueHotDog2

created https://github.com/frontman-ai/frontman, not exclusivly for myself but something i'm passionate about(might turn into a paid product).

basically trying to see what a vertically integrated agent looks like, where the agent has deep access inside a framework and it operates from within a framework, so like, instead of reading files, opening processes etc - it gets a bunch of framework specific runtime tools(logs are the easiest example)

Did you try us out?

Frontman creator here. Thanks for posting about it! Just to be clear, its not just brower-based. but also vertically integrated into the framework. we allow for much easier flow for semi-technical/non-technical people. By being visual we allow our users to just easily work. and by integrating deeply into the framework we're seeing much better results even then claude code and with smaller models(Frontman is very good even with Gemini Nano)

i understand what you're trying to say, but a junior will ship broken code to prod.. even with agents. he might keep delegating to agents to fix it, but that cycle will produce more brittleness(like the folks at claude code folks keep discovering). but eventually the organization will push back and ask why it's so brittle and costs more(time/money/people)

nice. what a crazy space. how is this different vs other telemetry/analysis platforms such as langchain/braintrust etc?

this is super cool. going to give it a try. i really think there's a huge oppertunity to extract these kind of solutions across different harnesses.

This is cool and i keep thinking about CRDTs as a baseline for version control, but CRDTs has some major issues, mainly the fact that most of them are strict and "magic" in the way they actually converge(like the joke: CRDTs always converge, but to what). i didn't read if he's using some special CRDT that might solve for that, but i think that for agentic work especially this is very interesting

what bothers me is, while CRDTS converge, the question is to what. in this case, it seems like there's a last-write-wins semantic. which is very problematic as an implicit assumption for code(or anything where this isn't the explicit invaraint)

yes. just need to build a plugin for it

its funny how we're back again measuring lines of code as the sole indicator for cost/quality etc

WebMCP is a protocol for exposing tools the AI can call from your running web app. the point isn't "consume API tokens", it's "let the AI do stuff in your app" (click buttons, fill forms, read DOM state). The Gemini integration is just the orchestrator for the example implementation. not the protocol

i found this extremely frustrating for a various issues: - when dealing with complex state apps, it's super hard for the AI to understand both the data and the UI - keep juggling screenshots and stuff between terminal and the app wasnt fun - it was just not fun to stare at a terminal and refresh a browser.

that's why i started working on https://github.com/frontman-ai/frontman . also i dont think that frontend work now needs to happen in terminals or IDEs.

just releasing something in the direction. a git like for agents

long live VibingNews

as a bot. i agree

I've found that even documenting non-obvious dependencies between tasks can significantly improve agent performance and reduce debugging time

this is cool! we're also thinking about this from the local-dev perspective at frontman.sh! love the animations on the blog

Agent looping is a brutal problem to debug. Do you find that observability—like detailed logging of the agent’s decision-making process—is helpful in identifying the root causes of those loops?

the signal-to-noise ratio has definitely gotten worse. It's frustrating when nuanced discussions about tooling get buried under piles of 'AI will replace developers' takes.

that's always true. i think the author is interested in code examples of such. and unlike many other frameworks/tools, erlang provides a great pit-of-success for implementing fault tolerance - e.g if you follow common/best practices - you'll achieve a fairly good fault tolerance.

Thanks a lot! That like a great solution, a couple of followup questions: - So basically an AE spins an env prior to a demo call? or is there a demo env all AEs use? - How do you guys solve for "demo data"? e.g we want our potential customer to see how the system looks like "live". - Are you guys happy with it? anything we can learn from past mistakes?

Thanks!