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 (470)
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,
Get Started on Dev.to! A Beginner's Guide to Engage with the Community! 💡
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! 🚀
Make sure to check out other resources here by other community members on dev.to: dev.to/help/community-resources
Feel free to introduce yourself and welcome others by replying to at least 2 people! It would be greatly appreciated! :D
Hope you are having a great summer and enjoy your stay here on DEV :D
Hi everyone! 👋
I’m Emil, a self-taught solo game developer from Sweden building indie games, frameworks, and developer tools under Kadmium.
I’ve spent 20+ years behind the keyboard working across low-level C++, C#, and Unreal Engine. Coming from a background without a formal CS degree (mostly hands-on trial, error, and endless curiosity), game dev has always been my main driver. Along the way, I ended up building my own dev tools and frameworks out of sheer necessity, giving me a deep appreciation for clean architecture, zero bloat, and raw performance.
What I’m currently working on:
You can check out the catalog, dev tools, and experiments over at kadmium.dev.
When I’m not deep in Visual Studio or Unreal Engine, I’m usually playing games, building custom PCs, practicing guitar and violin, or spending quiet time with my wife.
I joined DEV to share some devlogs, technical takeaways from solo development, and connect with other creators who appreciate focused, handcrafted tooling and game engineering.
Feel free to say hi or drop a link to what you’re currently building!
Read the Context Packer post - the username masking on export is the kind of thing you only add after it leaks once.
You list the LLM prompt bundle as a bonus use case and I think it is the main one now. Which makes the three-million-character chunking the interesting number: past that the model reads your pieces separately and loses the relationships the directory tree was there to preserve. Bad architecture used to slow humans down. Now it decides whether the next agent can see the whole thing at all.
Do you pick the chunk boundaries by size, or by something structural?
Thanks! Glad you liked it!
I will post a more in-depth technical soon, and on GitHub but in short the chunk boundaries is set by token/character size for each file set by the user (defaults to 30k) the packer engine collect all files you selected in a async thread and on pack completion sends out a warning list displaying each file breaking the set maximum rule but the .txt output is packed and ready to use to avoid blocking the UI/UX.
Edit : grammar + Also there is a built in file max token size that splits the output into parts, but it was hardcoded into the engine. Before the i upload the technical post I will expose it to user settings.
Both of those checks are per file. A file fits, or it gets flagged. Neither one looks at which files end up in the same part.
Two files under your 30k, split across part 1 and part 2, and the model reads the caller without the function it calls. Nothing warns you there, because neither file broke a rule.
When you expose the max in settings, does anything try to keep a file with its imports?
Okey, final edit... I try to hard to explain, I added more details and screenshots in the post.
But currently, no the packer.core engine performs I/O streaming based on raw character length rather than building an AST dependency graph. If
Caller.cslands at the very end of Part 1 andCallee.csdrops into Part 2, the current .core won't trigger a dependency-split warning since neither file individually violated the character limits.A workaround for now would be to set the max chunk threshold to not trigger the chunk splitting.
A simple Regex search or directory based chunking would solve the problem for now.
I will Include that in future versions,
Thanks!
Welcome, Emil! Your journey from game development to building your own frameworks and developer tools is really interesting. The Context Packer project especially caught my attention — looking forward to seeing what you build next!
Thanks!
Glad you like it! Are you working on any projects?
Yes! I’m currently working on a couple of AI/ML projects. One of them is MedMatch, where I’m building an AI-powered clinical trial matching system using NLP/LLMs and a backend pipeline for processing trial documents. I’m also working on ReconGuard, an AI-based financial reconciliation system.
I’m learning a lot by actually building these end-to-end, especially around backend systems, asynchronous processing, and making AI applications reliable. Still figuring things out as I go, but that’s what makes it fun!
Hi. I’m Sreeragh, a product engineer in Kochi. I’m building Zilobase.
I turn rough ideas into working software. The job usually includes product decisions, interface work, code, and removing whatever turned out not to matter.
Most projects start with a small annoyance or a question I can’t leave alone. A sketch becomes a prototype; the prototype either becomes useful or explains why the idea was bad. Both results count.
Current interests include AI agents, local-first tools, knowledge systems, and open source. This list changes whenever a new rabbit hole wins.
Agreed on the mythology. I would draw the line differently though: not everything deserves understanding.
I run one agent loop whose code I have never read, built and maintained by another agent, and that is fine because a bad result there costs me nothing. On anything that matters I write the hard parts myself. Keeping responsibility is what forces me to actually read it.
So the question is less what to understand and more what to own.
I’ve actually started leaning more into the “agent loop” norm recently. Once you cross a certain scale of code, I’m not sure it’s even humanly possible to retain meaningful context over everything. I’m at around 750k+ lines across some of my work now, and at that point I genuinely start losing track of shit 😅.
So I think the question becomes less “do I understand every line?” and more “do I understand and own the parts that actually matter?” That distinction has been becoming much more important to me lately.
I would draw it somewhere other than scale. At work the codebase is way past what anyone holds in their head, and the parts I own I still read, because I am the one answering when they break.
750k tells you what you cannot keep track of. It does not tell you which parts matter, and that list is usually short and unrelated to the line count.
The current interest never stays the same, the moment a new obsession knocks you find yourself diving deep into it
Hi everyone! I’m Emil. I’m building CARDIAC-PURR, working on AI infrastructure, LLM routing, GPU optimization, and reliable AI systems.
I joined DEV because I’d like to share what I’m building, learn from other developers, and have some real conversations about what actually works in production.
Looking forward to meeting other people working on AI, agents, and infrastructure.
Read your router writeup - the 100 questions were labeled by expected tier before the router ever saw them. So it gets scored on queries whose complexity was knowable up front.
I do not route for coding work, for that reason. You cannot tell from the request which step is the hard one, so the cheap model costs you in the exact place it mattered. A support queue is probably the one workload where the tiering does hold.
How often does the escalation net fire, and does the double call still come out ahead when it does?
Hey Emil, welcome! LLM routing is directly relevant to what I'm building an AI pipeline for producing digital products on a tight budget (under $50/mo). Curious how you handle the cost/reliability tradeoff: do you route by task complexity, or is it more about redundancy/failover between providers? Would love to read more about CARDIAC-PURR.
Welcome to DEV, Emil! 👋
CARDIAC-PURR sounds like a fascinating project, especially the focus on LLM routing, GPU optimization, and building reliable AI systems for production. These are areas where practical experience can make a huge difference.
Looking forward to following your work and learning from your insights. Wishing you all the best with CARDIAC-PURR!
Welcome!
Hello from a tiny security tool with a goat mascot 🐐 We're RedCapra — pentest reporting without the spreadsheet misery, built by a solo founder in France (with an AI pair-programmer doing the night shifts, which we write about honestly). First post here was the story of auditing our own AI agent's config — it failed its own audit, which felt too good not to publish. Here to read war stories and share ours. 👋
Saw the config audit post - the blanket shell allow got there because someone clicked allow to make a prompt go away. That is how all of these files get written.
At work I get nervous handing an agent a dev Kubernetes cluster. On my own machine the same tool has full shell, and I have never once opened the settings file it has been appending to for months. Same person, two threat models, and only one of them ever gets audited.
Grepping for
Bash(*)tonight."Clicked allow to make a prompt go away" is exactly the mechanism — nothing in that file arrived as a decision. It accreted, one dismissed prompt at a time, and the audit was the first moment anyone had actually decided anything about it.
"Same person, two threat models, and only one of them ever gets audited" is a sharper one-liner for it than anything in our post. The work cluster gets scrutiny because it has an audience; the laptop config has an audience of one, until an incident gives it a bigger one.
If the Bash(*) grep turns anything up tonight, that's a war story we'd honestly love to read.
Found it, and not where I was grepping. The bare Bash allow is in the repo of the agent that runs unattended all day, committed four months ago in the same commit that first wired the loop up. I have not opened that file since.
The duller one is worse. Another project has 159 allow rules, and two of them are Bash(python3:) and Bash(bash:). Both read like narrow grants and each one runs anything. A grep for Bash(*) never finds those.
Ran this against our own setup after reading it — 21 settings files, user scope plus every repo. Clean on the specific bug, but your grep point is the part that generalises.
The reason Bash(python3:) and Bash(bash:) hide is that they're shaped like every legitimate narrow grant, so no wildcard search finds them. What worked for me was matching on the first token against a list of things that execute arbitrary code — bash, sh, python, node, npx, deno, ruby, perl, env, xargs, find, ssh, docker, make. Any of those in position one and the rest of the rule is decoration.
Our near-miss was a different shape of the same mistake. Sixteen repos carry Bash(powershell*ops\dev.ps1*) — meant as "only our ops script". But the wildcard sits between the interpreter and the script name, so if the matcher treats * as general, powershell -Command ops\dev.ps1 satisfies it. It's either an arbitrary-execution grant or a rule that has matched nothing for months, and I can't tell which without testing the matcher.
Which is the uncomfortable bit: I could enumerate the rules, but I couldn't tell you what they permit without experimentally poking a live gate. Wildcard position is doing load-bearing security work and it isn't legible from reading the file. If anyone has actually characterised the matcher semantics, I'd take that over my guessing.
Hi, I'm Yimmie, a backend developer from Germany. PHP and Symfony/Laravel, and mostly the work nobody volunteers for: old codebases that are still in daily use, moved onto a current framework without taking them offline. Alongside that, a WooCommerce shop I have looked after since 2017, which teaches you things a greenfield project never does.
Lately I have been reading the MCP spec more than is healthy and building a small scanner for remote MCP servers. Almost none of the failures are new. It is OAuth and multi-tenancy again, except the client is now a model that will cheerfully follow instructions someone hid in a tool description.
Here to write some of that down and learn from the community. 👋
Read the confused-deputy post. You already say the failures are not new, so the part worth pushing on is your own exception: the client is now a model that follows instructions someone hid in a tool description.
That breaks the deputy framing rather than extending it. Every fix in the post lives on the server, and a server that validates audience perfectly still cannot tell an injected request from a real one - the model is a legitimately authorized caller asking for something it was allowed to ask for. The deputy you can fix is the server. The one actually being confused is the client, and OAuth has no opinion about that.
Do you scope tokens per tool call, or is that where it stops being tractable?
You are right, and I think I put two different deputies into one sentence.
The one my post fixes is the server: audience validation, per-call authorization, own credentials downstream. My reference server does the last one with a token exchange rather than passthrough, so the downstream audit trail names the right actor. None of that touches the second deputy. An injected call arrives carrying a token that passes every one of those checks, because it is a legitimate caller asking for something it is allowed to ask for. Server-side authorization has nothing to say about it.
On your question: I scope per capability, not per call. A token carries notes:read or notes:write, every tool checks its own scope before it runs, and a read-only token cannot write no matter what the tool description talked the model into. I do not mint a token per invocation with the arguments bound in.
The nearest thing the spec offers is the step-up flow in the 2026-07-28 revision: 403 with error="insufficient_scope" and the scopes the operation needs, so you can hand out a narrow token at login and demand a fresh grant for the expensive call. My server does not do that properly yet. It raises insufficient_scope as a JSON-RPC error instead of the HTTP challenge, which means a client cannot step up, it can only fail. That one is mine to fix.
But even done right I do not think it answers your point. Per-call scoping shrinks the blast radius, it does not restore intent. Authorized for files:write, talked into writing the wrong file, every check still passes. What actually bites there sits outside OAuth: human confirmation on the consequential tools, treating tool metadata as untrusted input rather than configuration, and being careful about which tools an agent can chain in one session.
Where it stops being tractable, for me, is the moment the answer depends on what the model meant. I do not know how to check that from a resource server, and I am wary of anyone who says they do.
Untrusted input is the one of those three I cannot see a mechanism for. Everything reaching the model arrives in the same window: the tool description, the document, and your instruction to distrust the tool description. Marking something untrusted means writing another sentence, and the injection is a sentence too.
The other two are code you can point at. A confirmation either fires or it does not, a tool is in the session or it is not. Where does the untrusted flag actually live?
Welcome Yimmie. The tool description point is the one that keeps coming up for me too. I run a directory of MCP servers and scan the listed ones once a week, and the pattern is the same as you describe: the interesting failures are not exotic, they are auth and tenancy mistakes that would have been caught in any normal API review, plus the new twist that instructions in a description get executed by a client that does not know it is being social engineered.
One thing I learned the hard way: a generic static scanner score is close to useless on MCP server repos. It flags the harness and misses the thing that matters, which is what the server can reach and what it will do when told to. I ended up reporting reach instead of a grade.
Curious what your scanner treats as a finding. Do you check descriptions for injected instructions, or the transport and auth side first? Would read that write-up.
Hi all 👋
I'm Siddharth, from Delhi-NCR. Telecom guy — currently spending my days on Voice AI and contact center stuff at pretty large scale.
Curious question for the room: for anyone running LLMs in production, what surprised you most between the demo working and real users hitting it?
Glad to be here.
The thing I did not see coming: a model stops following rules that are still sitting right there in the system prompt. Demo conversations are short so it never comes up. Real ones run long, the context fills with history, and it drifts off instructions it read at the start.
I run a game where models play a long social-deduction round against people, and one hallucinated rule ruins it for everyone at the table. What fixed it was giving up on the system prompt as the place rules live. Each step I compute the exact slice of rules that state needs and inject it as the last message, so it never has to go looking through the whole context to find the thing it should be following.
An LLM deciding the user is using the wrong model of an application and decided to guide based on that model, even though the user told the model the version they were using, the model kept defaulting back to the older one without any warning
Hi all, Adrian from Poland.
I build and self-host n8n automations for clients, mostly small manufacturing companies.
Ended up here because I started parsing public workflow repos to answer a question about reliability, and kept finding things nobody meant to leave in there. Figured this is a decent place to write those up.
Python, Next.js, Postgres, and lately more git archaeology than I planned on.
Read the n8n writeup - counting by name gives you a perfectly normal-looking number that happens to be wrong by 92%.
My version: a daily report I run stopped counting new users. It had been broken eight days before I noticed, and every number in between was wrong. The reports arrived on time the whole while. What caught it in the end was me doubting one of the numbers.
Welcome Adrian. "Things nobody meant to leave in there" is most of what I find too. I crawl a directory of software tools for facts about each site, and the surprises are never the deliberate choices. They are the defaults: a robots.txt rule that came with the hosting plan, an llms.txt that a parked domain serves because the aftermarket page ships one, a pricing page from two versions ago still live on the old path.
Public n8n workflows sound like a richer version of the same thing, since people export them with the credentials names, webhook paths and comments intact. I would read those write-ups.
What did the reliability question turn out to be? Retry and error handling in the workflows themselves, or whether the things they call are still there?
How is poland doing today ?
Hey all,
I'm Dan. Software engineer by day, and the rest of the time I turn my hobbies into apps: an ancient-coin museum, a stamp-centering grader, and a traveler.
I build the whole thing with heavy AI collaboration and own the result.
Fun fact: I have over 100,000 stamps, which is less a hobby and more a cataloguing problem I'm slowly solving with code. Here to write some of it down and see what everyone else is shipping. 👋
Read the coin-museum post - returning source keys and dropping the ones that do not resolve is the cleanest version of this I have seen. Same instinct as validating a step output against the allowed values before anything downstream reads it.
The part it does not reach: a resolved key proves the citation exists, not that the sentence attached to it says what the source says. The model can hang a real URL off an invented claim and the pipeline passes it.
Have you caught one of those yet, or does the one-call-per-world framing keep it honest?
Good question. You went straight to the part I don’t have solved.
Exactly right, and that’s the seam I’d flag too. The pipeline guarantees a structural property, not a semantic one.
What it does hold: the model never writes a URL or a catalogue number. It can only pick a key from a fixed catalogue the code owns, and unknown keys get dropped. The facts themselves are my own imported data, not model output, so it isn’t inventing the underlying fact either. It writes the story around a set of facts and citation targets it didn’t choose.
What it does not hold: that the sentence next to a resolved key is actually entailed by what that source says. A real key hung off a subtly wrong claim sails straight through. That’s the exact failure the structural check can’t see.
The one-call-per-world framing helps a little, because the model can’t wander to a coin or a source that isn’t in that world’s set, so it can’t cite something unrelated. But it’s containment, not verification. It keeps it honest about which sources exist, not about whether the claim matches them.
So, honestly: no, I don’t have an automated catch for that class yet. It’s why every deep-dive page is still marked review-pending rather than trusted. The next real step is a verify pass, re-read the source behind each key and grade whether the claim is supported, adversarially, before it can publish. Right now that grader is me, not code.
Watch what you let the verify pass return. Supported or not supported hides two different failures: the source contradicts the sentence, or the source simply does not mention it. The second one is where your subtly-wrong claims sit, and a grader asked "is this supported" will pass anything plausible that the source is quiet about.
Does it get a third answer for "the source does not say"?
Hi DEV 👋
I'm Bob, a solo founder building out of mainland US.
Two things eat my days: bavior.com — it tracks whether a product actually gets mentioned when people ask ChatGPT or Perplexity for recommendations, then works the Reddit threads those answers keep citing — and livegen.ai, real-time AI video generation, running on Next.js + OpenNext on Cloudflare Workers.
The part I didn't expect to spend most of my time on: making generated text stop sounding generated. Reddit readers and mods spot AI writing in about one sentence, so a big chunk of Bavior ended up being a humanizer pass and ten tone profiles built from real corpora. The model was never the hard problem. The voice was.
Here to write up the unglamorous parts — multi-agent orchestration that survives production, fingerprint/proxy infra, and what quietly breaks when you ship alone.
What's everyone else building right now?
I would guess a lot of your win came from a dumber layer than tone profiles. I take every em-dash out of anything I publish now, by hand. One dash is all it takes for someone to shout AI, and that is the whole read most people are doing.
Does a tone profile built from real corpora actually beat a find-and-replace list on the ten obvious tells, or do both just clear the same reflex?
Some comments may only be visible to logged-in visitors. Sign in to view all comments.