This thing is obviously fully vibe coded... Click the "what's coming next" and under the healthcare section the marketing screenshot contains broken images... Like no one ever looked at this before deploying it?
I agree there is probably some impact on output quality when doing this (Claude seems to embedded key signals all over the writing, which is much or what makes it horrible to read). However this does work well as a "second pass" over technical docs or designs along the way
Seems like a lot of this knowledge was encoded into the blog post. I wonder if given this post and access to a planet scale instance to compare with, how close an agentic agent could get.
Meanwhile, I just setup codex for the first time (to try Astra) and it offered to load my Claude and Cursor conversations and claims to even do it in a way where it says in sync if you use both. The only reason to use Claude Code is the 20x usage of the 200$ plan is ridiculous value if you have the need for that volume.
I don't follow iphone products, but if it's anything like android this is because they tend to be the lower end models and are missing the features that people really want (mainly a better camera/lens setup). The top of the line models are ALWAYS the bigger phones and if your going for something budget, then you're better off with the Chinese brands for value.
We use mcp as a "gateway" for a customer facing cloud agent. It basically is just a tool registry and could have been built using open-api... but MCP is arguably more robust/aligned for context management and the agent frameworks and observability tools support it first class.
Wouldn't most opensource harnesses work with lmstudio? I assume it has an "openai" style chat API like every other model provider? What's special about it vs langchain deep agents or pi or pydantic-ai?
I would honestly consider one of these for the utility of a cheap, small electric truck, but not having 4wd is an absolute deal breaker for a truck in the mountain west.
I've always assumed there is some sort of "acclimation" period, maybe even related to the conditions you grew up in. I much would rather spend a time outside in -40c (with proper outerwear) than 40c. I'm relatively healthy but I feel like my body shuts down at anything above 36c
They didn't remove the bolts for "leave no trace" reasons. They removed them because the style they were put up was considered "poor climbing ethics". They felt it could go "free" and on gear.
This would have made the summit unobtainable to all but the strongest climbers in the world... Which would have upset many people who had traveled far and spent a lot of money to attempt the summit.
Alex Honnolds "climbing gold" podcast has like a 3 part series on this history if your interested to learn more.
I don't see any mention of "the market" anywhere in this thread. I'm just talking about the ability for a motivated user to solve real problems with these tools. Right now these solutions are available to software developers but over time it will become approachable to more users
These use cases will just be built as "open source" (openclawd) or even custom one off application in the future. I've been building apps to run the tedious parts of my life recently. Meal planning, personal finance, bills, tax organization... Why would I pay for services that will be enshiftified when I can build a app that does exactly what I want in an afternoon. Yes the code is shit and it wouldn't scale... But it doesn't need to
I made the switch from premier to resolve a few years ago and it feels like such a breath of fresh air. Being able to do the same with Lightroom would be amazing so can't wait to check this out. I've been using the free version and honestly never needed the pro features but I think I'll make the one time purchase today just to support a non-subscription based product of this caliber
Not sure I understand. If you generate a random string to use as a reference for something that the LLM interacts with... and the LLM cannot reliably recall the reference, then it's a problem that needs to be solved by simplify the random string.
The problem is really more getting the agent to reliable relay a UUID. For example, we were creating files for visualizations and having the agent reference them in there response with a custom <visualization file=UUID /> and found that it would often fail to accurately return a UUID from a tool response it was previously provided (running sonnet 4.6).
For this use case, our solution was just to use a slug for the filename, but we can control the uniqueness constraint on our backend.
Coding agents don't really need memory. Agent skills, rules, git history, documentation is all far more efficient, transparent and easier to manage. These memory frameworks only really makes sense if you are building a consumer facing agent with managed context and limited capabilities.
also I never had considered that breaking your up-time into a bunch of different components is just a strategy to make your SRE look better than it actually is. The combined up-time tells the real story (88%!). Thanks for the link
ya i was just doing the math on their chart for the git operations. I added up 14.93 hours combined hours, which puts them WAY lower than the reported 99.7 metric they show right next to it.
So based on their own reporting, the uptime number should be 99.31. Which means only like 6 additional hours and they'd fall below 99.0%
Most enterprises that need consultants are using Salesforce, SAP, Hubspot, Dynamics, etc. If a company has an engineering department to build and run internal software, they very rarely need a consultant. And if they don't, they are very unlikely to higher a consultant to build it custom. They'd want "out of the box" because they think (often incorrectly these days), it will be easier to maintain.
These days cursor feel more capable and reliable then Claude Code (at last for my workflow). For personal projects, I'm using cursor during planning and verification but run Claude code for just implementation to save $.