Lgvdp

@gymbroinvestor Me dejas con curiosidad, me cuentas algo mas por dm? Ya por entender un poco la complejidad jajaja

@dataphagus El caso es que son gastos o ingresos que no puedo automatizar con agentes, creo que sería muy difícil

Lo de los trimestres siendo autónomo es un absoluto coñazo. No solo porque pierdes una mañana de trabajo (como poco) para recopilar todas las facturas del trimestre... Sino porque empiezas el mes en negativo con un pago de 2.000 o 3.000€. Qué puta vergüenza.

@evrendom @NickPrijic @jyoti_mann1 @DamiDina Love it hahaha

@NickPrijic @jyoti_mann1 @DamiDina interesting feature idea for the open source we're building at rudel.ai

New: Meta has taken down its internal AI token leaderboard. It now displays a message that says: “It was meant to be a fun way for people to look at tokens, but due to data from the dashboard being shared externally, we’ve made the decision to shutter Claudeonomics for now.”

While i see the point, i think the post tackles a nonexistent issue in a way. I dont think any dev believes current models are the same as the ones we had last year, or that the future models wont improve per se. And I also do not think the model will swallow the harness (basically because a harness is trully every single aditional information the model has that does not come from it's training, give or take). If we want models to interact with the environment we will need harnesses for them. But besides this, which is more my opinion than a ground truth, most developers can't have an impact on the models, but they can certainly try and use them in ways where they get better results, and that's by tweaking the harness. Honnestly, i think it's also making people think a lot and understand model<>environment interaction, which is not trivial. I dont see any reason why it'd be doing more harm than good not gonna lie. Complexity is certainly a complex matter (forgive the redundancy), and harnesses are the way that currently enable us to handle it "for our models", plus it's super fun!

Maybe I'm missing something, but "harness engineering" might be doing more harm than good. I've read a couple of posts on harness engineering, filesystem memory, subagent architecture. All real, all important. I've learned a lot from them. But I keep coming back to this: the framing of Agent = Model + Harness undersells the actual engineering involved. And as far as I can tell, none of the major agent products work this way. Claude, ChatGPT, Devin. These are all systems. They handle authentication, multi-tenancy, deployment, observability, cost controls, state management across sessions and users, RBAC, resource isolation. The "harness" is a subset of the engineering involved in building these products. A better framing might be Agent = Model + System. This makes sense because you can't serve a raw API call to users. You need the system around it to turn the model into a product. You could argue Agent = Model + Harness + System, and that's fair. But at that point the harness is just a component of the system. Treat it as one. My concern is that when we center the conversation on harness engineering, we train developers to think about the 30% that touches the model and ignore the 70% that makes the thing actually work in the real world. When we look at the problem through the lens of the 30%, we end up with things like virtualized file systems which are solving problems that shouldn't exist in the first place. At best, the harness wraps the model. The system is the product. And there's a reason the consensus is that model progress will eventually swallow the harness. Because the harness is a thin layer. The system is not. The system is the product, and that's what developers should be focusing on. Another reason to take harness engineering with a grain of salt: it's shaped by coding agents. Coding agents are a very specific form factor which itself is evolving rapidly. Single user. Running in a terminal. Local filesystem. The patterns that emerge from this form factor are useful for this form factor. And I worry that generalizing them to broader agentic systems is damaging to the ecosystem as a whole. Here's what I mean. And notice a pattern: many of these are solutions to problems that shouldn't exist in the first place if you start with the right system design. 1. Filesystems for memory and storage Harness engineering recommends patterns like AGENTS.md files for memory. This works when one developer is running one agent on their laptop. It falls apart the moment you need a real product. There's a reason databases exist. Files don't support concurrent access. They don't support querying. They don't support access control. A filesystem as your memory layer is a single-user solution presented as architecture. And now I'm seeing people build "virtualized file systems" that wrap databases into filesystem-like structures to patch over these limitations. At that point, just expose the database. You get SQL as a first-class interface, proper access control, and durable storage without the abstraction gymnastics. And you know what, LLMs are even better at SQL than they are at cat and bash. 2. No multi-tenancy or RBAC How do 50 engineers on a team share an agent securely? How do you control which users can trigger which actions? That's multi-tenancy, authorization, and access control. No filesystem pattern solves this. You need real RBAC. 3. No resource isolation How do you stop one tenant's runaway agent from burning through your entire token budget? That's resource isolation. It lives at the system level. A harness has no concept of it. I hear people recommending sandboxes scoped to individual users and it makes 0 sense to me because your costs will eat you alive. Btw these problems aren't new. They're the same problems we've been solving in software engineering for decades. The instinct to create new terminology comes from a good place. "Harness engineering", "Scaffolding”, "Context engineering". People want to name the new discipline. But every time we mint a new term for a subset of systems engineering, I think we make it harder for developers to recognize that the patterns they need already exist and we shouldn't re-invent the wheel. All problems that harness engineering solves, you can solve with systems engineering. Maybe I'm wrong about this, but I'm just seeing harness engineering create more issues than it solves (virtualized file systems???) If we want developers to successfully build agentic products, we should encourage them to think in systems. The solutions already exist. We should use them. Again, maybe I'm missing something. I'll keep an open mind as I learn more. And maybe the answer is simply that harness engineering applies to coding agents and not to broader agentic products, which makes perfect sense. TLDR: Agent = Model + Harness undersells the real problem. Harness engineering is shaped by coding agents (single user, terminal, local filesystem) and ignores the 70% that makes agents work in production: multi-tenancy, RBAC, approval flows, audit logs, resource isolation, durable storage. These are systems engineering problems.

Si no lo teneis ya Juan, es super importante que en el CLAUDE.md (o en una rule.md) mas externo que tengas en tu ordenador (idealmente en el root de la instalacion, para que aplique a TODAS las sesiones) pongas explicitamente una instrucción indicando que SIEMPRE busque si la labor a realizar puede utilizar una de las skills disponibles, que no la lea, sino que la invoque. Si quieres probar con la que usamos nosotros abreme dm, por no saturar esto. Y por si quieres ver como mejora el uso de skills etc, puedes probar rudel.ai.

Uno de los temas que quiero investigar son los skills de Claude. Tenemos bastante documentado cómo se ha de hacer las cosas tanto en front y back pero a veces se lo salta. Quiero ver si hay algo con los skills que nos ayude

@garrytan @evrendom seems like rudel.ai is pointingnin the right direction

Decision traces are a big deal and now possible with 1M token context *sneak peek: one of my projects is launching soon and will be focused on decision traces in agentic engineering

@avilesrafa Data, speed and AI, the three things a business can't miss

@philip_off Said that way it sounds simple, but it's basically the difference between determinism and probabilism though hahaha

if you think about it programming didn't really change a lot. just went from "chanting the right incantations to make the computer do something" (coding) to "chanting the right incantations to get the computer to make the computer do something" (prompting)

@evrendom We gotchu

being a designer shipping code with codex has a bit of danger. i can ship UI changes. but the data engineering layer is a black box to me. one wrong merge and something breaks somewhere i'd never think to look. so I started building a living wiki of the codebase with codex, inside obsidian. a map of how the project is structured, what each piece does, what connects to what. now i - know which parts of the codebase i can touch no problemo - know which pr's need a real engineer before merging - know enough to ask better questions when i'm out of my depth dont expect codex to one shot it though, but expect that each just-in-time iteration adds to your mental model of the code. im not trying to become a data engineer, i just want to know enough so that i can fly where i'm good at. also i dont want to embarrass myself as the repo is open source lol (feel free to check it out github.com/obsessiondb/ru…)

If you are a block explorer, indexer, data platform, or similar working in Crypto, we can cut your analytics infrastructure costs by more than 25%, guaranteed. Reach out.

@0xSpaydh Absolutelly. I have 0 doubts better times will come man 🫂

@dataphagus Likewise ser, got a great deal of respect for you team and enjoyed working together. Sad we didn't get to ship the latest indexers and interfaces we were working on 🥲

Today, I made the incredibly difficult decision to transition Neutron to long term support. It is never easy to close a 4 year + chapter, and I wish we had been able to deliver more successful outcomes to all who bet on us as a team and project. Yet I'm tremendously proud of our team, our work, and our consistent drive to maintain our integrity and transparency, even in tough times. All in all, we shipped infrastructure that secured >$100M TVL, facilitated close to $2bn in trading volume, and never lost a user dollar. We pioneered a more integrated / opinionated approach to building blockchains and L1 ecosystems, which is now being validated by industry-defining projects such as Tempo and Hyperliquid. I am also tremendously grateful for all of the help and support we received throughout the journey - from our partners, backers and community - and for having the opportunity to work and learn alongside you each day for the last 4 years. For now, my priority is to return as much value as possible to all stakeholders: teammates, users, builders, and backers. To this effect, over the next few months, I'll continue to shepherd the remaining work to make Neutron safe and sustainable without our active involvement longer term. Thank you all for your time, and for believing in us.

@Ineslaram Depende del tipo de proyecto. Claude no es solo para programar al fin y al cabo. Pero para llevar a cabo un proyecto serio desde luego hay que tener nociones minimas.

Estoy construyendo mi primer proyecto con Claude desde 0. De momento veo un poco complicado que alguien que no sepa programar pueda hacerlo. Que pensáis ?

@ObsessionDB @rauchg Fuego 🔥

@rauchg It's ObsessionDB*. Thanks.

Obsession is the mother of invention

Part of what we are doing to understand what works and what does not work with AI agents is rudel.ai. We log every single session and check success rates, skill usage, etc. If you want to try it out it is completely free. It's certainly a work in progress, so we'd love to know what do you think it's missing, what is useful...

@alvaro__data God bless the new final multithread implementation lol

Millions of tick updates daily. A few thousand are active at any given time. We serve current state from a ClickHouse® ReplacingMergeTree table. 25MB batches, sub-second ingestion, live to traders. Here's what the production setup looks like:

@vchennai2 Did you enable the ENABLE_LSP_TOOL flag so it can use the ctrl+click simile to traverse the codebase?

I've switched back to cursor from Claude Code Claude code makes it far too easy to lose codebase context since you're only looking at diffs For an application that requires precision that starts becoming a problem real fast Curious if anyone found a good way around this