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 (510)
Welcome everyone to dev.to! Glad you are here! Another week! Another Thread! Make sure you drink a lot of water :)
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
Feature Comment from last week thread!
Last week, I asked the community "What is your favorite programming language?" and here is one answer that stood out to me by @techie_sprinter:
Question of the Week!
"What is the one project you are proud of? (I recommend creating a post about your project and sharing it in the comments!)"
The comment will be featured on the next Welcome Thread!
Thanks for stopping by! Feel free to introduce yourself and welcome others by replying to at least 2 people! It would be greatly appreciated! :D
Hello! I'm Mathéo, a 2nd-year CS student from France.
I'm building ZamSync, a lightweight, offline-first synchronization engine written in Rust. I designed it to help sync medical records in rural clinics with extremely flaky 2G connections. My ultimate goal is to propose this project to the Ministry of Health of Bhutan for their electronic Patient Information System (ePIS).
I just published my first article here on DEV.to about how I simulated 2G connections to test the sync engine, and the code is fully open-source. Glad to be here and looking forward to learning from the community!
Hello, Mathéo! Welcome to the DEV.to community! Your project, ZamSync, could become vital to medical systems in Bhutan. The project being written in Rust is important because it prevents certain errors due to compiler strictness and can be faster than higher level languages on older computers. Are there any other reasons you chose Rust for the project other than the reasons I just inferred? Also, does ZamSync use compression to speed up data transfer in certain rural areas? I’m wondering if the project only handles the synchronization and transit of medical data or if it also helps to save the data to the hospitals server. I wish your project luck with the Ministry of Health of Bhutan.
Hi! Thanks a lot for your message and your thoughtful questions 🙏
You’re right about Rust being a good fit for safety and performance. I also chose it because it compiles into a single static binary, which is really useful in rural environments where you don’t want to rely on installing or maintaining external runtimes like Node.js, Python, or Java. It also keeps the memory footprint very low, which helps on small machines like Raspberry Pi 3 or 4. Another important point is the absence of a garbage collector, which helps keep latency predictable and avoids unexpected pauses that could cause issues on unstable 2G connections.
For compression, ZamSync uses Zstd at level 3 for network frames larger than 64 bytes, and for very small payloads we send them uncompressed to avoid overhead. Regarding storage, it handles both sides: data is first written locally to an encrypted Write-Ahead Log so it stays safe even if there is a power loss, and then it is synchronized to the hospital server where it is immediately persisted into a secure database.
Someone also mentioned IPFS to me as a comparison. I did look into it, and while it’s an interesting system, ZamSync is solving a different kind of problem. IPFS is based on content-addressed, immutable data, which doesn’t really match the need for mutable, ordered medical records that evolve over time. ZamSync is instead designed around offline-first synchronization with strict ordering guarantees and reliable replay once connectivity comes back.
What’s your take on IPFS in this context? Do you think I might be reinventing something that already exists there, or is the problem space different enough that the comparison doesn’t really hold?
Thanks again for the discussion, I really appreciate the feedback! I dont know if I can share a repository here ^^
I think your project is definitely NOT reinventing the wheel. IPFS has no built-in privacy—content is meant to be publicly discoverable via its hash (CID). Even if you encrypted it first, since it would be publicly accessible, the possibility of it getting decrypted by someone not trusted is exponentially higher. And, there is no way to revoke access once it is sent. This means that if a patient revokes a medical institution's (or all of the places the data was sent to) access to their data or the encryption key is leaked, there would be no way to remove it. Medical institutions usually must be able to purge patient records upon request or legal mandate, which is not possible with IPFS. And, IPFS does not manage permissioning, meaning medical institutions would have to handle complex infrastructure to share decryption keys with trusted individuals. And, keep in mind, if someone has the decryption key once, they always have it, even if their access is restricted. Medical institutions could implement a private IPFS cluster, but it would require a massive amount of engineering overhead. IPFS has no built-in compression or encryption. Don't worry—your project can not be replaced with IPFS. Also, thank you for your quick reply! Also, I took a look at your GitHub, and it looks awesome! Your README is really comprehensive. Also, this is really important, I do not see a license file in your GitHub. The link titled MIT goes to a file in the root of your project titled LICENSE that does not exist. Since your project is meant to be used with medical institutions and you are planning on presenting it to the Ministry of Health of Bhutan, I would recommend that you add the file as fast as possible. I made a pull request here so it is easy for you to incorporate the fix.
Hey Tyler, sorry for the late reply, I didn't have dev.to notifications enabled and just saw your message!
Thank you so much for this breakdown, it's really thorough and you covered points I hadn't even thought to mention. The revocation problem is actually one of the strongest arguments against IPFS in this context: once a CID is out there and someone has the decryption key, you genuinely can't undo that. In healthcare that's a dealbreaker, especially with regulations like GDPR in Europe or similar patient rights frameworks that mandate the ability to purge records on request. ZamSync handles this at the WAL level: events can be compacted and dropped once confirmed, which means actual deletion is possible.
The point about private IPFS clusters is also spot on. It would technically work, but at that point you're building most of the access control, encryption, permissioning and ordering infrastructure yourself anyway, so you might as well use a purpose-built tool.
And thank you for the PR, I just merged it! 🙏 Good catch on the LICENSE file, that's exactly the kind of thing that looks fine locally and breaks silently on GitHub. Really appreciate you taking the time to open the PR rather than just pointing it out.
Don’t worry—that was not a late reply! I replied and made the PR last night, and the PR was merged and the comment was responded to in the next day (today). Also, that was my first PR, ever! I’m happy I was able to learn by contributing to your project! Also, it’s convenient you had a bunch of PRs available right when mine came in! I’m wondering, where you planning a release for today already, or did you just release it after you merged my PR?
That's so cool that it was your first PR ever, thank you for choosing ZamSync for it! Fixing the LICENSE display is one of those things that makes a real difference for anyone landing on the repo for the first time, it signals that the project is serious and properly maintained. Really appreciate you taking the time to open the PR instead of just leaving a comment.
I actually have a question for you, and I hope it's okay to ask! I'm a developer and I genuinely love building ZamSync, but I have zero experience with community building or getting a project noticed. I've been trying to do the basics, good first issues, a clean README, GitHub topics, but I have no idea how to actually get the project in front of people who might care about it.
Do you have any advice on how to share or present a project like this? Where would you post it, how do you write about it, what actually works? I'd love to hear your take since you clearly found the project and cared enough to contribute, so you might know something I don't about how people discover tools like this.
Thanks for the compliment! Also, I sadly don't think I'm the best person to ask about making projects well-known. But I definitely know one thing. That thing is that no matter how clean your code or README is, how you organize your GitHub name, tags, or description, or how good your issues are, or how many code analyzers or outdated dependency tools you have in actions, those are not enough to get your project recognized. Sure, it would be publicly accessible, but what matters is if your target audience actually knows it exists. To get people to notice it, you need to share it in the correct ways and at the right places. But, around right there is where my advice ends. I wrote a DEV.to article about my Python project, and it has around 70 views. But obviously, only a small fraction of those readers probably looked at the repository. If you want advice from someone who doesn't know themself, probably go into some Discord and ask people if they could review it or put it in like a "cool-code" or "project-sharing" channel, or post it on some Reddit (make sure they allow it!).
Oh yes I see ! Thank you very much Tyler, it's a pleasure to discuss with you :) 🤝
ZamSync is a serious piece of infrastructure. the single static binary constraint is doing a lot of work there — no runtime dependency management in a clinic with 2G and intermittent power is the right call, not an optimization.
the choice of Zstd at level 3 with uncompressed fallback under 64 bytes is exactly the kind of tradeoff that doesn't make it into whitepapers but matters in the field. did you run benchmarks to land on that 64-byte threshold, or was that empirical from actual 2G simulation runs?
the WAL-first, then sync to hospital server pattern is also the defensible architecture for this. what's your conflict resolution strategy when two clinics write to overlapping records during an extended offline period?
Thanks for your answer !
On the 64-byte threshold: it's not from a 2G simulation benchmark, it's a property of how Zstd works. The codec has a fixed frame header of about 10 to 15 bytes regardless of input size, so below roughly 60 to 70 bytes the compressed output is often larger than the raw input. 64 is the natural breakpoint where the ratio starts making sense, and it aligns with what Zstd's own documentation recommends for streaming use cases. There's also a second guard in the wire layer: even above 64 bytes, if the compressed output ends up larger than the original, the frame is sent uncompressed. Level 3 specifically is Zstd's documented default balance point between speed and compression ratio, which is the right call on ARM hardware where you don't want to burn CPU budget on encoding during a sync session on an unstable connection.
On conflict resolution: ZamSync doesn't resolve semantic conflicts, it surfaces them. The WAL is append-only, so if clinic A and clinic B both write conflicting updates to the same patient record during a 3-day offline period, both events land in the log in HLC order and both get replicated to the hub. The application layer, or the projection database via zamsync project, is then responsible for deciding what "winning" means: last-write-wins, CRDT merge, flagging for manual review, whatever fits the domain. ZamSync's job is to guarantee that every event arrives exactly once, in a deterministic order, on every node.
The design assumption is that in a clinical context you usually want to see both conflicting writes rather than silently pick one. A last-write-wins merge on a medication dosage field is dangerous. Surfacing the conflict and routing it to a nurse for review is the safer default.
What's your take on that: do you think there's a case for implementing a pluggable conflict resolution hook at the engine level, or is that better left entirely to the projection layer?
is that a Counter Strike - student ? 😏
Haha 'CS' actually stands for Computer Science, but to be fair, I've been training for this degree since I was 7, playing Counter-Strike: Condition Zero with my dad x)
lol
dev.to/etoile_bleu/-i-built-a-sync... Here is my first article ! Dont hesitate to share your 💝!
Hey Mathéo! Rust + offline-first for rural medical records is a solid choice — most people would've reached for something heavier and paid for it later.
One thing I'm genuinely curious about — what happens when two clinics update the same patient record while they're both offline? That edge case sounds like it could get messy fast.
Also love that you have a real destination in mind with the ePIS system. Not many student projects have that kind of purpose behind them. Hope you get there!
Hey everyone, excited to be here!
I'm currently a technical writer working in the observability space, so can't wait to learn more about what other devs are writing about / discussing.
Welcome Parthiv! Observability tooling is such a rich space right now — the gap between what infra-level monitoring gives you vs. what actually matters to a business is still wide. Curious what patterns you find yourself writing about most: alerting fatigue, cardinality limits, or the UX side of dashboards for non-engineer stakeholders?
Hello, Patriv! Welcome to the DEV Community! Do you mainly write about your own code, or do you write about other people’s code?
Hey Parthiv, welcome to DEV 👋
Hi Parthiv, it's a pleasure to meet you !
Good to have you here, bruv
hello
Hey Francis, thanks for the welcome! I'm Dhruv, AKA materwelon or materwelonDhruv :) and I loooove TypeScript and C# (for game dev). One project I'm proud of that I released v5.2.0 of just a day or two ago is envapt! I made a post about using it to read typed env, and much more as well.
Good to have you here bruh
Thanks for starting the thread, Francis! One project I am definitely proud of is devto-followers2md, an open-source Python program that exports information about a user's followers on DEV.to in a Markdown, CSV, or JSON format. Today, I wrote an article about it here on DEV.to, "How I Built a Python Script to Export and Analyze Your DEV.to Followers".
Hi!!
Welcome Julian!
HI
Welcome Cole :D
Thanks for starting the thread, Francis!
I’m new to DEV and just shared my first article about DockGraph, a free, source-available project I’ve been building to make Docker setups easier to understand visually.
The idea came from managing a growing self-hosted setup where containers, networks, volumes, and Compose files quickly became hard to reason about as one system. DockGraph turns that structure into a live topology view, with container details, logs, dashboard data, and Compose-aware discovery.
I’d really appreciate feedback from people who run Docker or self-hosted stacks.
I Built DockGraph: A Live Topology Map for Docker and Compose
Hey everyone! Nice to be here! I am a third year CSE student studying in India. I came here to share some of my work and learn from other devs.
The project I am most proud of is actually a rabbit hole about streaming audio output from an Android device to any other device regardless of the app generating the audio or the receiving device (preferably regardless of even the location of the devices). Somehow, achieving that goal ended up spanning across 3 repositories and 2 years.
I just published my first article/post here going over that entire journey: "I Hijacked Android's Forgotten Audio Sink to Capture System-wide Audio".
Thanks for the warm welcome, Francis! 🙌 To answer the Question of the Week — the project I'm proudest of is a hosted MCP server that gives any AI agent live prediction-market data with zero install and no API keys. Getting the honest-billing part right (never charging for a call that failed to return real data) was the most satisfying engineering bit. And noted on the water 💧😄
the honest-billing constraint is actually the hard one. "never charge for a call that returned no data" sounds obvious until you're handling partial failures, timeouts, and race conditions in an async billing pipeline — then it gets interesting fast.
curious how you handle the attribution boundary: if the agent call succeeds but the downstream data source 404s, does that count as billable? that edge case has a few defensible answers depending on where you put the system boundary.
Good question, that's the exact edge I went back and forth on. I ended up putting the boundary at the customer's intent, not the call graph. The rule is you pay for a delivered answer to what you asked, never for the attempt.
So the 404 splits two ways. If the 404 is itself the answer (you asked "does this profile exist" and it doesn't), that's billable, you got a definitive result. If the 404 just means I couldn't get the thing you actually wanted (you asked for a company's contact email and the page 404s), that's a free no-result row. You didn't get a contact so you don't pay for one.
The bug I see in most validators is folding "unknown" into "invalid". A DNS SERVFAIL or a timeout isn't a "no", it's a "can't tell right now", and billing it as a hard answer quietly deletes good leads and charges you for the privilege. So I keep three states (answer, no-result, unknown) and only the first one ever bills. Async just means a single batch can carry all three, so every row ships its own status and the meter only ticks on the answer rows.
Hi, This is Nikhil , A Full Stack Developer and Gsoc'26 Student at webpack
Welcome to DEV, Nikhil 👋
Hey!
Hey Russel! Welcome — good to have another builder in the thread. What are you working on or hoping to explore here on dev.to?
Hey everyone, excited to be here!
I'm currently a Developer working day and night to create good experiences.
Hello !!
Hey everyone 👋
I’m Saurabh, a Chief Architect based in India, working at the intersection of large‑scale software architecture and applied AI. Over the past few years I’ve been helping enterprise teams design and ship systems that are reliable in production but still move fast enough for modern product demands.
I’m here on DEV to share what I’m learning about AI‑driven architectures, platform engineering, and the “executive view” of technical decisions; as well as to learn from how you all are solving similar problems. I’m also an active open‑source contributor and love turning real‑world challenges into reusable tools and libraries.
Outside of work, I enjoy experimenting with new ideas on my OSS projects, writing about architecture trade‑offs, and having thoughtful discussions about where AI is actually useful (and where it’s just hype).
Looking forward to connecting, swapping ideas, and hopefully collaborating with some of you on cool projects!
Hello, Saurabh! I think that what you shared about what you do is really interesting. I am definitely less experienced in coding than you, since I only started coding maybe a year ago (in the 6th grade) or so, and at my age, there isn’t much for me to code that makes a difference the way you do. I decided to join DEV.to because it’s at the intersection of what I love to do at this time, coding and writing.
Hey Tyler, that genuinely made my day, thank you for sharing that!
Starting to code in 6th grade and already thinking about where it intersects with writing? That's not "less experienced," that's a great foundation. The curiosity you're describing right now is what most senior engineers are still chasing years later.
The projects that make a real difference often start exactly like this: someone young, curious, and willing to explore without the pressure of already knowing the answer. Some of the best open-source tools and ideas I've seen came from people who were just experimenting for the love of it.
Keep coding, keep writing, and keep showing up in communities like this. The combination of both is rarer than you think, and more powerful than it seems right now.
Looking forward to seeing what you build. 🙌
Thank you so much for your kind comment! When did you learn to code?
I learned coding quite late, that was around 2004/2005 timeframe when I entered into college.
But the real practice started in 2010 when I started working. 🙂
What was the first coding language you learned? For me, I learned Python first. I got the No Starch Press Python Crash Course book, and followed along until right before it taught classes (I definitely should have stayed one chapter longer the first time), then started learning by doing.
That's awesome !
I started with Java as the first programming language. We also used to write the code by hand on paper to practice and learn that time, which might sound funny now.
Also, you did exactly the right thing by starting hands-on after some learning. This is the correct and faster way - "learn by doing".
My best wishes to you.
That seems really interesting! Did you learn Java for a college class, or on your own? Also, while writing code on paper definitely seems very silly to me, I will have to do it soon for around a month. I’m going to a sleep-away camp soon where there are no electronics are allowed, so if I want to practice a bit in my free time, I’d have to do it on paper (aside from TI-BASIC on the TI-83 Plus calculator I am brining). Also, if you are wondering, they never said “no electricity”, so I’ll definitely be bringing some parts to make circuitry with. In the newer coding languages I learned, the learn-by-doing approach started sooner, like after a like an hour in separate occurrences of doing something like Tour of Rust.
You are navigating through quite an interesting learning path, really love it 😇
I did learn Java based on my personal interest, as I was from non Computer Science background. However, it was first a fun to learn programming, and second needed to get a job, as around 2005-2009 timeframe, IT jobs were blooming as prestigious work profiles.
Thanks for the clarification! Right now, I'd definitely say my experience with programming is mainly fun. But, it really cures my boredom too, because I get to read technical articles from the Communications of ACM and their external links, IEEE Spectrum articles, fast-paced news on Dark Reading for a more relaxed (very easy) read, articles here on DEV.to, listen to podcasts, read magazines, write READMEs, all in addition to just writing code! At some point in my life, I expect that my programming knowledge will have a real (work) application.
Welcome Saurabh! The "AI useful vs hype" framing is exactly the right lens. From the builder side, I've been finding AI genuinely earns its spot in structured-output pattern-matching (diagnosis over time-series data), but it's still just a fancy layer on top of a relational query when the real work is in the join logic. Would love to read your take on where enterprise teams are drawing that line in prod architectures.
Really appreciate that framing, Andres !
I’ve found AI adds the most value when it helps with pattern recognition, synthesis, and decision support across large volumes of structured or semi-structured signals. But once the core problem is deterministic business logic, hard constraints, or traceability-heavy workflows, the model often becomes an interface layer rather than the system of record.
Your point on join logic is spot on. In a lot of enterprise systems, the real value still lives in data modeling, orchestration, and domain boundaries; AI just makes those choices more visible, faster, or easier to operate.
I will be consistently posting 2-3 times per week, and would love to hear examples from your side too, especially where you’ve seen AI genuinely improve production architecture versus just adding abstraction.
Saurabh —
This framing is right. Honestly didn't have words for it until I read your reply.
Ad Engine works exactly the way you're describing. 5 detection rules, all deterministic SQL with window functions doing 7-day rolling baselines. Rule fires or it doesn't — no model in the detection path. Claude only enters after, reads context, returns a schema-enforced structured diagnosis with 3 ranked actions and an urgency enum. The deterministic system decides what's wrong. The AI translates "what" and "what to do."
Where it goes badly is the inverse — AI for join logic, ACL decisions, as source of truth. Every time, pain.
One back at you: have you seen the opposite direction work — AI proposing new deterministic rules by watching what operators escalate, surfacing them as candidates to a human-in-the-loop? Not autonomous generation, but ranked proposals. The boundary I can't find is where "rule-proposer" quietly becomes "authority" and the determinism breaks.
— Andres
This is the boundary I think about most in the memory context too. Your setup keeps it clean because the detection path is deterministic and the AI only translates after the fact, so nothing the model says feeds back into what fires. The rule-proposer loop breaks that cleanliness on purpose, which is what makes it interesting. A proposal that came from watching escalations is a pattern, not a confirmed outcome, and the quiet failure is that once it sits in the candidate list long enough it starts getting trusted as if someone had checked it. The thing that has helped me is keeping the proposal and the evidence for it as separate objects, so the proposal stays revisable and you can always ask the real question, did acting on this actually work, before it earns rule status. The human in the loop is not really gating the proposal, they are gating the promotion from "this looked right a few times" to "this is authority." Where are you putting that promotion step, at proposal time or after some track record?
Proposals should stay cheap, revisable, and evidence-backed until they earn authority.
The moment a pattern gets treated like a rule before it has track record, you stop doing inference and start doing superstition.
I’d put the promotion step after the proposal has survived real-world checks, not at the moment it first looks plausible.
In practice, that means keeping “what seems true” separate from “what we have validated,” so the system stays honest as it learns.
Good question on the human-in-the-loop, I see the human less as a gate on ideas and more as a gate on authority.
"What seems true" kept separate from "what we have validated" is a cleaner way to put it than I managed. The piece I keep snagging on is what actually flips something from the first bucket into the second. Survived real world checks is the right bar, but in practice the check is whether acting on the proposal led somewhere good, and that outcome is the thing most systems never record. So the gate ends up well defined and starved at the same time. Everyone agrees validation should gate promotion, then nobody has the validation data, because it was never captured back when the agent acted.
Your point about the human gating authority rather than ideas lands for me, with one wrinkle. The human can only gate authority if there is evidence to gate on. If the system kept the conclusion and threw away the track record behind it, the human is left approving a pattern they cannot actually inspect, which is superstition with a signature on it. So the authority gate and the keep the evidence problem turn out to be the same thing wearing two hats.
Do you store the evidence trail alongside the proposal explicitly, or reconstruct it when something comes up for promotion?
Welcome! Are you using coding agents in your day-to-day workflow yet, or mostly experimenting?
Yes, I am using Coding agents on a daily basis, mainly Claude Code and Cursor to quote.
I have also built my custom automation pipeline + agents for daily work. First example to mention is: idea (I drafting in raw form) -> analysis & drafting (Claude CLI) -> review (I making changes); and Second example is: Personal assistant built on Hermes (it does everything like a personal secretary).
These are private repos, however there are many public repos at github.com/saurabh-oss.
Hey Saurabh, Welcome to DEV 👋
Thanks for the warm welcome, Hemapriya 😊
Happy to be part of this community and always great to connect!
Hi 👋 Giuseppe from Colletorto, Italy — solo founder at Save The Brain.
I'm building the open layer for agentic commerce: KaliCart Bridge makes WooCommerce stores readable and comparable to AI shopping agents, and CartHub does AI-based cart recovery.
Glad to be here.
the "open layer for agentic commerce" framing is the interesting part. the hard problem there isn't making WooCommerce stores readable — it's the schema normalization layer: AI shopping agents need product data in a form they can reason about comparatively, and every store has a different mental model for how attributes, variants, and pricing actually work.
curious how KaliCart Bridge handles that: are you normalizing to a fixed schema on ingest, or letting the agent work with a richer but messier representation and trusting the model to figure out the comparison? the tradeoff between schema fidelity and schema consistency is where I'd expect the hard edge cases to live.
Hey Giuseppe, welcome to DEV 👋
Hello Giuseppe! Welcome to the DEV Community! I’m wondering, what is WooCommerce?
Hey Tyler! Fair question 🙂
WooCommerce is the open-source ecommerce plugin for WordPress: it turns a WordPress site into an online store.
So no, not a secret nerd club — just the plumbing behind many real online shops.
Oh, that completely changes things! I thought WooCommerce was like an Italian physical grocery store when I read your first comment.
😂😂 ... To be fair, I’m still learning English. Right now I speak a little Italian, a lot of dialect, and apparently some confusing plugin-language.
🤣... are you sure you’re not secretly French?
My cousins are French! (Second)
Hi everyone! 👋
I'm Laxman Poudel from Nepal.
I'm a student, developer, and cybersecurity learner interested in web development, internet infrastructure, and domain intelligence.
Recently, I've been building projects focused on Nepal's web ecosystem, including a domain intelligence platform called NP Radar.
Right now I'm learning more about cybersecurity, building web applications, and sharing my development journey.
Looking forward to learning from the community and connecting with other developers!
Hello, Laxman! You seem to have a wide range of complementing interests. What is it like being a developer in Nepal?
Hello Tyler,
Thanks for the welcome!
Being a developer in Nepal is both exciting and challenging. We have access to great online learning resources and global communities, but the local tech ecosystem is still growing compared to larger tech hubs.
I'm currently a student, so I spend a lot of my time learning by building projects and exploring cybersecurity and web development.
Recently, I've been working on a domain intelligence platform focused on Nepal's .np ecosystem, which has been a great learning experience.
Looking forward to learning from everyone here!
I definitely can’t say the same about my areas tech ecosystem. Where I am, it is very advanced—I’d say. Where are you a student at?
I'm currently a Grade 12 science student in Nepal.
Most of my learning in development and cybersecurity happens outside the classroom through online resources, documentation, open-source projects, and building my own projects.
That's actually how I learned enough to build projects like NP Radar. There's still a lot for me to learn, but building real projects has been the best teacher so far.
You seem to have a lot of experience for a twelfth grader! (I can't say much about a typical twelfth grader where I'm from—I am only a seventh grader). I definitely agree that a lot of learning in these topics is best done outside of school. I still have a lot to learn, too, just like you!
Welcome to DEV, Laxman 👋
Thank you, Hemapriya! Excited to dive into the community and check out what everyone is working on.
Hi everyone 👋 First time posting here. I'm a data & AI engineer working mostly in the Databricks/Azure world — these days a lot of my work is around RAG pipelines and AI agents, alongside the usual data engineering.
Outside of that I like building small open-source developer tools that scratch my own itches, and I've been doing some hands-on AI security research on the side (agent/tool safety has gotten interesting lately).
Just published my first writeup here — on debugging silent failures in pandas/polars pipelines, a problem that's cost me more afternoons than I'd care to admit. Excited to be part of a community that's into this stuff, and looking forward to learning from everyone.
The silent failure angle is the one that gets me too. The loud failures at least tell you to go look. The quiet ones, where everything returns and nothing is right, are where the afternoons go. With agents I have started thinking about memory the same way: the failure that never errors, where a run just ends and nobody confirms it worked, is the one that quietly poisons what the agent learns later. Has your safety work run into that, an agent treating an unconfirmed success as a confirmed one?
Yeah, you nailed it. Same thing in both worlds: a step returns and we treat that as it worked — but those aren't the same. A merge "succeeds" while quietly dropping rows; a tool call "succeeds" while the change never actually landed.
That's the agent failure that worries me most — no error, so the model marks it done and moves on, and if that false "done" becomes memory, everything after it builds on something that was never true.
Same fix either way: don't trust the step's word for it, verify the effect.
Are you handling that at write time or read time?
The merge that succeeds while dropping rows is the cleanest version of this I have seen anyone put. That is the whole problem in one line. The step returning is not evidence the step did what you wanted.
On write time versus read time, my honest answer is both, because they catch different halves. At write time you can check the effect, did the rows actually land, did the file actually change, and refuse to record a success you cannot confirm. That kills the obvious false done. But write time cannot see the failures that only show up later, the change that landed fine and turned out to be wrong three steps downstream. For those you need something at read time that can go back and demote a memory that looked like a success when it was written. So write time stops you recording a lie, and read time stops you trusting one you already recorded.
The part neither fully covers, and the thing I keep circling, is the slowest case. The step verified clean, got written as a real success, and only much later did acting on it lead somewhere bad. Catching that means carrying the outcome forward and letting it reach back to the memory that caused it, and that link, action to eventual result, is the one almost nothing records. Write time and read time both assume you already know what good looks like at the moment you check. The hard failures are the ones where you only find out later.
How are you drawing the line on effect checking at write time, fixed assertions per tool, or something more general? The per tool version is where I always end up, and it does not scale the way I want.
Hey Vimal, welcome to DEV 👋
Hello, Vimal! Welcome to the DEV Community! What is your favorite side project? I’d say mine is devtkit, an open-source Python application to export information from the DEV API.
the RAG + agent safety combo is interesting because those two failure surfaces are usually discussed in separate rooms. the silent failure pattern you mentioned in the pandas/polars context maps directly to the agent version — the thing that never errors but quietly discards data is much harder to catch than the thing that crashes.
your framing on AI security and agent/tool safety is where I'd be curious: are you finding the most dangerous silent failures at the tool-call boundary specifically, or further downstream in how the model interprets a "successful" response that didn't actually do what it claimed? that boundary is where I keep finding the interesting bugs.
Hi everyone, I’m Dima
I work in automation and build small products. My current project is Langooo, an app for learning languages through songs.
The idea is simple: find a song you love, follow the lyrics, understand each line, and save unfamiliar words.
I joined DEV to share the technical journey honestly: Jetpack Compose, Node.js, SQLite, translation APIs, product mistakes, and the uncomfortable shift from coding to finding real users.
Right now, my rule is: no new feature unless a real user is blocked by its absence
Looking forward to learning from other builders here
Hello, Dima! I really like your idea of learning languages through song. It seems like a new idea, considering the closest thing to what you are making is just multilingual lyric videos on YouTube (which is no where near what you are probalbly doing). Is your application, Langooo, available for usage at this time, or is it still an early prototype?
Hello Tyler! Thank you for you interest and question. App is available at langooo.app
I looked at the app. Since I am a native English speaker, I sadly do not have a use for the app. Have you thought about adding support for more languages?
There are about 50 languganges, you can chooose native langugage in home page or in settings. I'm still polishing onboarding. Thank you for your feedback!
Oh, thanks for telling me! I think your app might attract more users if you make it more easy to tell the languages it supports when looking in the App Store.
Welcome to DEV, Dima 👋
Wishing you success with Langooo and your journey as a builder.
Thank you, Hemapriya👋 Appreciate a lot 🙂
Hey everyone 👋 I'm Mitesh.
I'm building Ethos, an AI agent that's personality-first. The idea is: core beliefs stay locked, but everything else learns and evolves over time. Kind of like how a person's values stay the same but how they express them gets sharper with experience.
Here to share what I learn while building it: the wins, the broken stuff, all of it. Excited to be part of this community.
The locked core, fluid expression split is a nice frame. The part I would be most curious about in practice is how Ethos decides which experiences actually update the expression and which it lets pass. Learning from everything is easy to say and hard to do, because most of what an agent runs into is noise and only a few things genuinely should change how it behaves. Update on everything and it drifts, update on the wrong things and it picks up habits from situations that only looked similar to the ones that mattered. How are you deciding what earns an update?
Two points:
Keep in mind this judgment is made by the AI based on its instructions, so it won't always get it right. But because every note is out in the open and easy to fix, the wrong ones tend to get caught and corrected over time so it should get better, not worse, as it goes.
The make it cheap to undo instead of perfect to save move is a good one, and it sidesteps the exact thing I have been stuck on, which is that deciding what to keep is genuinely hard. If writes are reversible and readable you do not have to get the keep decision right, you just have to make the wrong ones cheap to pull back out. That is a real answer, not a dodge.
Your second point is the one I want to sit with. Tying every note to the situation it came from is a sharp fix for the failure I run into most, a lesson from one place leaking into a different place that only looked similar. A lot of setups skip that, and it is exactly where the similarity trap bites.
The thread I would pull on is what actually catches a wrong note. Easy to fix lowers the cost of the correction, but something still has to trigger it. If a bad note sits there and the agent keeps quietly acting on it, and nobody happens to read that note, the reversibility never gets used. So in practice the open notes get fixed when a human reads them, which is great, but it makes the human the detector. The cheapest trigger I can think of that does not lean on a person is noticing that acting on the note led somewhere bad, and that outcome is the thing almost nothing records. Reversibility tells you fixing is cheap. It does not tell you when to fix.
So the question back at you: what flags a note as wrong in practice? A human reading the pile, the agent catching itself contradicting a note, or something watching whether acting on it actually worked out? That last one is the piece I keep finding missing everywhere.
today in Ethos, the detector is the human.
You're right that reversibility only helps once something decides a note is wrong. Right now Ethos makes notes easy to see, edit, and remove, but it doesn't automatically question them based on outcomes.
What's interesting is that we already do outcome-based learning for goals, skills, and autonomy levels — just not for memory. Memory is still mostly additive: when something goes wrong, we add a postmortem rather than challenge the note that may have caused it.
So I think you've identified a real gap. The missing piece is outcome-anchored memory: being able to connect a note to the decisions and outcomes it influenced, so bad outcomes can eventually trigger a review of the note itself.
the locked-core / fluid-expression split is an interesting design bet. the one hard part is operationally defining what's "core" before you've seen enough failure cases to know which beliefs actually need to be immutable vs. which ones just feel important early.
Michelle's question in the thread about what earns an update is the right one. the complementary version from the other direction: what's your mechanism for detecting when the expression layer has drifted far enough from the core that the model is essentially performing the beliefs rather than holding them? that drift pattern is subtle and I'd be curious whether you're catching it explicitly or relying on human review.
Hey Mitesh, welcome to DEV 👋
DEV Team,
Thanks for the warm welcome!
I'm Victor, solo founder building Interouter — an open-source Node.js middleware that connects Next.js SSR apps to blockchain and decentralized networks. Currently supporting NEAR Protocol and OpenLedger L2 with x402 payment flows.
Looking forward to sharing more about the project and connecting with the community.
Victor
Founder @ Decision3.ai | github: @victordeflos
x402 payment flows on SSR is an interesting place to put the middleware — the latency profile is tricky since you're gating server-rendered content on a blockchain confirmation that can't be instant.
curious how you're handling the UX gap between page request and payment settlement — are you holding the SSR response, optimistically rendering with a pending state, or routing to a client-side component after initial load?
You've nailed the hard part — you can't gate SSR render on chain confirmation without killing first paint. So I don't hold the response. SSR renders the public shell + a locked placeholder immediately; the 402 challenge goes to the client (signing is client-side anyway — keys live in the browser), and gated content swaps in once the facilitator verifies the signed authorization.
The key move: I unlock on authorization, not on-chain finality. Finality is confirmed async as a separate awaitFinality stage — so the gap is a signature round-trip, not a block-confirmation wait.
Honest status: adapters are read-only / x402-exact while I lock down the settlement wire format with facilitators (Permit2, BigInt serialisation, the upto/escrow scheme for consumption pricing). I'm building solo — and it's MIT, open from day one, on purpose: the goal is infrastructure ordinary people can use without even knowing there's a blockchain underneath, and that kind of trust only earns out in the open. This settlement boundary is exactly where I'd value other minds — issues and PRs genuinely welcome: github.com/decision3-ai/interouter.
Do you treat authorization-vs-finality as the unlock point, or wait for settlement?
Welcome to DEV, Victor 👋
Hi everybody! I'm Santi.
I'm a SW Engineering student and I joined the platform mainly to work on my communication skills and to share with you guys anything valuable I learn in the process.
I'm also here to learn from you all and what you've got to share, specially if its related with production Backend systems, Devops, Cloud and ML!
Hey Santi, welcome to DEV 👋
I’m an independent maker building tools for YouTube creators.
In 2025, I ran five faceless YouTube channels and generated over 400 million views. That experience gave me a close look at how creators work, where they struggle, and what tools are still missing.
Before this, I spent 10+ years in product and user operations at major Chinese internet companies, including Alibaba.
Now I’m building products like AudienceCue, TimedSubs, and JungRoom, with more creator-focused tools on the way.
Hello, Yana! I think your experience with running faceless YouTube channels definitely complements how you make tools for YouTube creators. I used to have a YouTube channel, but the content was not very educational and did not serve much of a purpose. What type of content did your faceless YouTube channels publish, and how was that content made?
Hey Yana, Welcome to DEV 👋
Some comments may only be visible to logged-in visitors. Sign in to view all comments.