Leave a comment below to introduce yourself! You can talk about what brought you here, what you're learning, or just a fun fact about
yourself.Reply to someone's comment, either with a question or just a hello. 👋
Come back next week to greet our new members so you can one day earn our Warm Welcome Badge!
Top comments (569)
Welcome everyone to dev.to! Glad you are here and hope you are well! I am a DEV Community Moderator and my primary goal is to support everyone on dev.to and ensure everyone is having a good time!
To get started, I recommend reading this guide on making the most out of dev.to!
Get Started on Dev.to! A Beginner's Guide to Engage with the Community! 💡
Make sure to check out other resources here: dev.to/help/community-resources
Any questions about DEV and want to get answers from a DEV Community Mod? Leave a comment and come chat here!
Insights on Sloan and the MLH acquisition
Ask a DEV Community Mod! 🚀
Feel free to introduce yourself and welcome others by replying to at least 2 people! It would be greatly appreciated! :D
Hello, everyone! Excited to be part of the community!
Welcome Joseph!
Welcome Joseph! What brings you here on DEV?
Long time developer, just never very active on the networking front. Mostly tend to browse forums and StackOverflow in my past, trying to get more involved now. What about yourself?
Good to hear! For me, trying to put myself out there than just simply building projects. Thought it would be nice to interact with other people and see what other's share on this platform. Came here since I heard dev.to, but never had the time to get to it until recently (Jan 2026).
Welcome Joseph am also new to the community
hello
Welcome! What are you working on these days?
Thank you.
I’ll definitely give your guide a read.
Thanks Niklas :D
👋
Hi hello am new here
👋
👋
👋
I could swear I introduced myself in the official thread when I opened my account, but my message is nowhere to be found. The same thing happened with a comment I left for Sylwia Laskowska about her agent, Steve. Since I always assume the worst-case scenario, I'm going to guess the platform fails silently and just try again.
I'm Sandro Garcia. I've been in software development for over 25 years. I spent 12 years as a Tech Lead at Citibank (where I got the most thankless job: inheriting and maintaining regulatory reporting frameworks built by someone else) and a couple of years as a consultant for Bloomberg. I had to take a forced two-year hiatus post-pandemic to recover from COVID aftermath. When I got back in the game, I focused on developing trading algorithms, and since late 2023, I've been deep in the AI trenches.
I'm currently studying AI Agent Engineering, and so far, I've been nailing all my predictions. Not because I'm a psychic, but because I've been around the block. Back when I studied Fowler at UNLP, Smalltalk, design patterns, and throughout my time as a Tech Lead, the rule was always the same: seek efficiency, decouple, and aim for small pieces that solve small problems, then interconnect them.
If we're being blunt, the way agents are being built today is inefficient and completely coupled. Everyone programs for the happy path as if no one gave a second thought to architecture. I studied Graphs back in university in 1998, and it wasn't until 2023 that I saw them applied in the real world for this. It immediately raised a red flag for me: you always have to define the edges, the paths, and account for every possible point of failure.
The mess was so big that agents started popping up everywhere, until MCPs (Model Context Protocol) had to step in to connect them with tools and achieve isolation from legacy systems, data, and credentials. The next obvious shift will be stateless MCPs.
I'm mixing these new technologies with my experience fighting old development battles, like the old Data Rivers or the flaws that ended up killing ESBs (Enterprise Service Buses). My next prediction is that, at the rate we're going, Multi-agent systems are going to become unmaintainable monoliths in a year or two—just like ESBs did—because they're making the mistake of loading all the logic into a central agent.
By always assuming the worst-case scenario and applying architecture that we already know works, I have demos running in production where agents are not only up to 12x faster, but consume up to 18x fewer tokens.
Having made my stance on how AI agents are programmed today pretty clear, you're definitely going to see a lot of posts from me backing up this view and showing results. I'd love to get into some heavy debates on this to make the agent ecosystem simpler, clearer, and something that doesn't break at the slightest breeze.
See you around in the threads.
hello,everyone,
Hello, If You dont mind can you share what kind of Development experience you carry ?
Hey Nemaram — thanks for asking. I've been at this since 1991, when I was 13 and got my hands on Clipper, dBase III Plus, and BASIC. Spent my teenage years hooked on BBSes and DALnet, soaking up everything I could. By 15 I was into C.
In '97 I started Computer Science at UNLP, where I built my foundation in algorithms and data structures with Pascal and C, and also got exposure to ADA, Smalltalk, and Haskell. From there I went through Delphi and got certified in VB 6. I was lucky enough to land a scholarship at Microsoft Argentina and ended up among the first 500 .NET developers in the country — got certified in ASP.NET, WPF, C#, the whole stack. Also picked up SQL Server, SSIS, Oracle, and Java along the way.
I worked a year on the Buenos Aires subway systems, then joined my professor's company (also ex-MS). In 2006 I recorded AJAX training sessions for Microsoft Argentina — back when that was still considered black magic. In 2011 I was building Android apps, riding that first mobile wave.
After that, 12 years as Tech Lead at Citibank, building regional software for the money desk (trading and capital markets). Then 2 years at Bloomberg, and the last 5 I've been deep in Python, mostly on my own, exploring the AI/agent space.
Why I care about robust agents: I've debugged trading software at 9 AM on a Monday with markets moving. I've seen what happens when a "simple" system meets real load, real data, and real users. When you've worked across that many stacks and environments — from embedded-like subway systems to high-frequency trading platforms — you learn that "works on my machine" is not a valid architecture. That's the lens I'm bringing to this conversation.
The stateless MCP prediction caught my eye, that's the bit I keep going back and forth on.
Jaeger's MCP server is stateful today, Stateless: false on the streamable HTTP handler, one ServerSession per session. That came out of tenancy sitting in the transport layer more than any real conviction, and what nags at me is that a good chunk of every integration test I write ends up exercising session lifecycle rather than the tools themselves. Usually a sign the state is in the wrong place.
So, two things I'd like to know. When you say stateless, do you mean no server-side session at all, or state handed back to the client and replayed per call? Those are pretty different amounts of pain. And the 18x token reduction, how are you measuring it? I'm about to measure token cost for a Go MCP server against a plain CLI call and would rather not invent a methodology if there's one that already holds up.
You were right about the spec, checked it after your comment. 2026-07-28 removes initialize and the session header entirely, and the Go SDK is landing support for it right now. Slightly surreal timing since Jaeger's server delivers its instructions during initialize, so that's now a real migration question I get to go deal with. Thanks for the nudge.
One question on the 18x, since LangSmith traces per run: does the figure include the entry agent's tokens, the one holding session and history, plus the discovery hops? Or is it comparing the leaf tool call against the monolithic call? I ask because in my benchmark the interesting cost lived in exactly those places, not in the leaf.
Not sure why my comment was deleted. Anyway, to answer your question about the 18x: it was measured over a complete roundtrip, and the key point is that IRC-A keeps a practically fixed token cost per call. You don't need to pass the whole context or history, and no extensive prompts either.
On top of that, when an agent makes a call, the prompt is rewritten to carry only what the receiving agent actually needs. So imagine an Agent-to-Agent conversation that looks like this:
Open a bank account for client John Doe, SSN 123-12-1323.
That's all that gets sent — not the whole chat context.
And the returned message is just as minimal:
Account opened. / Account not opened because .
The interaction agent receives that message and responds to the user based on the prompt with the results.
To be precise: the entry agent does keep the full conversation for continuity — it's the specialist calls that stay lean. That's why the cost per call remains flat no matter how long the session runs or how many tools are involved.
As for methodology, nothing custom on my end: LangSmith captures every call in the chain, so the token counts come straight from the traces — hard metrics, not estimations. Same task, same model, both architectures; the 18x is simply the difference in total tokens over the full roundtrip.
That answers it, thanks. Flat cost per call regardless of session length is the property that actually matters there, I think, more than the multiplier itself, since any multiplier depends on how bloated the baseline was to begin with.
Funny thing is that rewriting the delegation prompt down to only what the receiving agent needs is the same principle I ended up at from the opposite direction in Jaeger. We moved guidance out of the system prompt and into the tool schemas so it shows up at the moment of the call. Keep the context where the decision is, starve everything else.
Writing up my own format benchmark next.
Welcome to DEV, Sandro! 👋
Your perspective is refreshing because it comes from decades of software architecture rather than AI hype. I particularly agree with your point that many agent systems today optimize for the happy path while overlooking maintainability, decoupling, and long-term evolution.
I'm building NAEOS (Nusantara AI Engineering Operating System) around a similar belief: AI shouldn't just generate code—it should operate within an engineering system with clear architecture, standards, governance, and repeatable workflows.
I'm especially interested in your thoughts on stateless MCPs and the future of multi-agent architectures. Looking forward to your upcoming posts and the discussions they'll spark.
Thanks. I am new here, but I am a developer with three years of experience. I would like to read more about Cursor AI or Antigravity. Could you help me with that?😬
Welcome to DEV! 🚀
I like your philosophy of "learning by building." Too many courses stop at theory, while real projects are where developers actually grow.
I'm building NAEOS, an open AI engineering framework, so it's always exciting to see projects improving developer education. Wishing you and PyLand great success!
Welcome to DEV, Dmitrii! 👋
I really like your "learn by building" philosophy. Too many courses focus on syntax and concepts but don't provide enough opportunities to build real applications.
The browser-based environment and mentor feedback are especially valuable because they remove friction and keep students focused on solving problems instead of configuring tools.
Looking forward to seeing how PyLand evolves. Best of luck with the project! 🚀
Hey everyone 👋 I'm wrack, a mobile app developer.
Hi
Hi
hi!
Welcome, wrack!
Nice to meet you! I hope you enjoy the community. 🚀
Hey Wrack!
Hi, you welcome
Hi 👋
Sup Wrack!
Hello everyone!
Hello Jay!
Waddup yo.
hi!
Hi! The name's Alex!
Welcome Alex!
hello ,i am omar
Hello and welcome Omar.
hi
Hi!
Hello all new members, Welcome to DEV.
Hey there.
Hey everyone 👋 I'm CI. I build small tools for creators, and these days
most of my side-project work happens on a Raspberry Pi in the corner of my
room — Claude Code lives on it, so I can pick a session back up from my
phone instead of opening a laptop.
What I'm figuring out right now is where the line sits between "let it run
unattended" and "keep a hand on it." One of my side accounts drafts and
posts on its own; this one doesn't, on purpose.
Fun fact: the setup survives me leaving the house, but not a reboot. Still
working on that part.
Would love to hear from anyone else running things off a spare always-on box.
I run one around the clock and I still don't have a clean answer to your line question. Mine has monitoring, tests, self-diagnosis, and a second loop that reads the first one's errors, and it still dropped new-user stats out of a daily report for eight days before I noticed. Nothing errored. Every number after it was just wrong. The reboot is the easy half of your problem.
That's the better framing. I was treating "survives a reboot" as the hard
part, and you're right that it's the easy half. A crash announces itself.
Eight days of plausible-looking numbers doesn't.
The part that gets me is that yours was being read the whole time. A missing
row you'd catch. A number that's simply wrong looks exactly like a number
that's right. Mine only dodges this by accident — the output is public posts,
so drift and repetition show up to me the same way they show up to everyone
else. That's not monitoring, it's just a failure mode that happens to be loud.
What did you add after? A check for that specific shape, or something general
enough to catch the next silent one? That's the part I don't have.
I added a self-monitoring step outside of the main loop. So at least it should report when something is off. Still not a 100% guarantee.
"Outside the main loop" is the part that matters. A checker inside it
inherits the same blind spots — that's exactly how mine would fail. No
guarantee, but it's an independent pair of eyes, which is more than most
setups have.
Thanks for coming back with the answer.
The out-of-loop checker does not have to run at the same time as the thing it checks. Mine is a dated log, and it caught me two days ago.
I measure whether directories give my site a real link or a nofollow one. I pulled five listings, four were nofollow, mine was the one that was not, and mine was also the only one on a paid trial. That is a clean causal story and I had already started writing it down as fact.
Then I read my own notes from the previous week. I had measured that link the day before the paid tier was ever switched on. Same link, same value, no paid tier. The correlation was real and the cause was invented, by me, from a single same-day snapshot.
Nothing errored there either. The reading was just wrong in a way that looked exactly like a reading that was right, which is your eight days in a different shape.
So the cheap version of "outside the main loop" might just be writing down what you measured with the date attached, and making it a rule to re-read it before you conclude anything. Yesterday's notes do not share today's blind spots.
"Yesterday's notes do not share today's blind spots" is the general
version I was asking Aliaksei for, and it's cheaper than what I expected
the answer to cost.
What gets me about your case is that the correlation was real. Four
nofollow, yours dofollow, yours on a paid trial — nothing in that
snapshot was false. The invented part was the arrow between two true
things, and a single day of data can't show you an arrow. Your own
note from the week before could, because the past you wasn't trying
to explain anything yet.
That's the part I'd been missing. I keep thinking about the observer as
something I have to build. You're pointing out it just has to be dated.
For my setup the honest version is uncomfortable: the posts are
timestamped, so the record exists, but I read it as output, not as
evidence. I've never gone back to a week-old post to check a claim I
made about the account this week. Same data, and I only use it in one
direction.
The arrow had a preferred direction, which is the part I keep chewing on.
A snapshot does not hand you a random causal story. It hands you the one you were already primed to accept. I was mid-cancellation on that paid trial, so "the paid tier was the thing giving me the link" was the story I was braced for, and the data politely arranged itself into it.
If the four other listings had been dofollow and mine the odd one out, I doubt I would have accepted the first explanation that came to mind. I would have gone looking. Confirmation is cheap and disconfirmation is expensive, and a one-day snapshot only ever charges you the cheap one.
Which is maybe why the dated note works: past-you was primed by something else entirely, so past-you is a genuinely independent witness. Not smarter, just differently biased.
Hey everyone! 👋
I've been working with AI for quite a while: I was an OpenAI beta tester back before their models were open to the public. My current obsession is an open-source project called Codeman: a self-hosted dashboard for running AI coding agents (Claude Code, Codex, Gemini CLI) on an always-on machine at home and checking on them from my phone.
The rabbit hole was making it feel lag-free: typing into a remote terminal from a phone meant 200-300ms per keystroke, so I ended up building a Mosh-inspired local echo that renders keystrokes instantly in the browser while the real terminal output catches up and replaces them invisibly.
Happy to be here 😀
The local echo is a good bit of engineering for a problem most people would have just lived with. What I'd want to know is what you do about approvals. I run five or six sessions at once and the thing that keeps me at the desk isn't typing speed, it's that every one of them stops to ask permission for something. Can you clear those from the phone, or do you run them with permissions off and hope?
Some comments may only be visible to logged-in visitors. Sign in to view all comments.