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 (455)
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
Hey everyone!
Excited to join the DEV community!
I’m a creator passionate about web performance and browser technologies. Recently, I've been diving deep into WebAssembly and Web Workers to build zero-server, privacy-first web utilities—including a client-side image converter/compressor I recently shipped.
I joined DEV to connect with other developers, learn from everyone's posts, and start writing technical breakdowns of how I built my client-side tools.
Looking forward to being part of the community!
Hey! client-side / privacy-first utilities are underrated. Users get the benefit without the upload anxiety.
I’m a product designer, and that “where does the work happen?” decision (browser vs server) changes the whole UX story. What made you go all-in on client-side instead of a hybrid?
same here😀
Welcome great engineer! Waiting to read your articles
Hey there
Hi everybody! I just recently discovered dev.to and joined up to see interesting dev content and concepts in their 'raw' form since so many places like Linkedin, etc. have turned into a cluster of showing off rather than being educational, insightful and knowledge sharing as they used to be a while ago.
Felt that. I joined for the same escape hatch: less polish, more thinking-in-public. is there a topic you’re trying to learn right now, or are you mostly browsing for signal?
Hello Everyone!
I recently discovered DEV when looking for possible hackathons to sink my teeth into. I joined primarily to try my hand at one of the DEV Challenges to force myself out of my comfort zone and into a place where I can really gain more momentum with my continued learning.
I am very excited to learn as much as I can from the community and even more so to be apart of it!
hello. 👋
hello. 👋
hello
hiii
hey
hi
Hello!
Welcome!
Greetings!
Hello and welcome!
Welcome to the community!
Hi everyone! 👋
I'm building TokenLat — a unified AI gateway that routes across OpenAI, Gemini, and China's most capable models (DeepSeek, GLM, Qwen) through one OpenAI-compatible endpoint, hosted in Singapore.
Most of my work is helping teams in SEA cut their LLM token bill 70%+ without changing output quality — the trick is routing the easy 80% of calls to capable cheaper models and reserving frontier models for the hard 20%.
Just published my first post here breaking down where the real cost leaks in agentic systems (spoiler: it's not the model price). Excited to swap notes with others building with LLMs!
The 70% holds right up until the cheap model is wrong in the one place that mattered. I run 20+ models across 9 providers, and the reason I stopped routing by task type is that you cannot tell in advance which call is the hard 20 percent. Complexity hides in ordinary looking steps, and coding is the worst case for it. How do you classify a call as easy before you have seen what it produces?
Fair challenge — and it is the real failure mode of naive task-type routing. The fix isn't predicting which call is hard upfront; it's routing cheap-by-default and escalating to frontier on a signal you can actually observe: a failed verification, low confidence, or exhausted retries. Caching + small-model-friendly prompts keep the 80% cheap regardless. Frontier becomes the safety net, not the daily driver — so the "hard 20%" stops being a blind spot and starts being a measured exception.
Escalating on a signal only covers failures that raise their hand. The ones that cost me were silent. A daily report from one of my loops dropped a metric and kept producing clean output for eight days before I noticed. Nothing failed verification, nothing retried, confidence was fine.
Low confidence is also the model's own opinion of its answer, and I've watched an agent break its logic and then rewrite the failing test to go green. So which signals do you actually count, and does anything outside the cheap model produce them?
Hi everyone! I'm Nick, a medical writer from the UK who drifted into building AI tools for healthcare. What brought me here? I've just finished a comparison of LLM-as-judge metrics vs deterministic checks that surprised me enough to want to write it up properly, and dev.to seemed like the right home for it.
Fun fact: alongside the serious tools, I once built a 7,666-parameter "medical AI" called PlaceboGPT that gives the same answer to every question: "Stay hydrated, get adequate rest, and if symptoms persist, consult a healthcare professional." It remains my most reliable model.
PlaceboGPT is the only model in this thread with a stable eval score. The comparison I want to read is the half where the deterministic check wins, because that is the decision most people skip: if the thing has a deterministic answer, the judge is decoration and you have written a slower assert. Where did the judge actually earn its place?
Welcome, Nick!
I'm particularly interested in your LLM-as-a-judge comparison. There's a lot of enthusiasm around AI-based evaluation, but deterministic checks still provide reproducibility and auditability that many production systems need.
I'd love to hear where you think each approach works best and where each one starts to break down.
Looking forward to your article!
hello Nick,
welcome to the community. And nice to me you buddy
Welcome to any news users here 🌟🙌
Hi all. John here!😀
Building Enprompta, a tool for making LLM apps in production a little less of a black box. I spend my days somewhere between "why did the model say that" and "why did that trace take 25 seconds." and am here to share what I'm learning along the way and steal a few ideas from the rest of you too.😌
Both of those questions assume somebody is already looking. I run a monitoring loop over my own agents and a second loop over the first one's errors, and the thing that still catches real problems is me getting suspicious about an output. What surfaces the trace nobody thought to go look at?
I love the quality loop! Curious what tools you use
All the tools Claude Code built for itself. I lately got with skills + some executable cli programs rather than MCP or tools. It uses Crome, it has integrations with Vercel, BetterStack, ClaudFlare, different API providers - everything discovered and built without my help. I only designed this on a high-level.
Hi John,
welcome to dev.to, looking forward to read your thoughts on LLM apps.
Hello john welcome
Hello everyone, I'm Quinticus (or Quint for short), an aspiring SOC Analyst who is learning all about cyber-security concepts, focusing specifically on defensive concepts. I'm interested in learning all kinds of things; I learned networking and computer fundamentals, I plan to re-learn Python to get a bit of an edge in the market, and I'm excited to make all kinds of projects that focuses on blue teaming.
I can't wait to interact with this community of fellow programmers. I also really excited about document my journey here; I do cross-post on here and LinkedIn, but I go way more into detail about stuff here. Looking forward to posting and chatting here!
Hi everyone!
I'm Alejandro Gutiérrez. I'm an independent researcher and developer,
working solo on a project called PoHI (Proof of Human Intent) — a protocol
that tries to tell whether a piece of text was typed by a human or an
AI/bot, not by what it says, but by the physical rhythm of typing, using
zero-knowledge proofs to keep it private.
I got into this because the "is this a bot?" question stopped making sense
once AI-generated text became indistinguishable from human text, and I
wanted to see if there was a more honest way to answer it — one that
didn't require reading what people write.
Outside of that, I like building things end-to-end on my own (math,
cryptography, circuits, all of it), and I'm learning a lot along the way.
Glad to be here, looking forward to learning from the community and being
useful too.
Cheers!
Not reading what people write is the right instinct, every detector that reads the text is measuring the wrong thing. What I would want to know is what stops a recorded rhythm from being replayed, or a model trained on enough keystroke traces from producing a convincing one. Once the proof is worth having, faking the signal is worth doing. Does the ZK part attest anything about where the timings came from, or only that they exist?
Great question, genuinely the sharpest one anyones asked so far, and its
the one I was most worried about before I even started collecting data.
Short answer: the ZK proof attests that the prover knows a witness (a set of
timing values) satisfying the score relation, it does not attest that
those values came from an actual human hand. Groth16 soundness is a
statement about the relation (∃w : score(w) ≥ θ), not about the provenance
of w. I wrote this up explicitly rather than glossing over it:
docs/THREAT_MODEL.md, section 5 "The Witness Authenticity Gap".
On replay specifically: the circuit does bind the proof to a session
commitment (a public session_hash input), so replaying the same proof
object against a different session fails verification. But that only
stops replaying a proof. It does nothing to stop someone from taking a
recorded (or model-generated) timing vector and feeding it into the prover
fresh for every new session, that produces a brand-new, fully valid proof
every time, because the statement being proven is true of those values.
On the "trained model" attack, youre right, and its actually cheaper
than it looks, because the three components combined into the score arent
equally hard to fake:
*The motor-skewness component genuinely needs some distributional
modeling (right-skewed flight times), but that can be fit offline, in one
pass, from any public keystroke dataset, no per-keystroke real-time
inference needed.
*The cognitive-latency component is trivial to manipulate: its
essentially "how long before you started typing relative to the prompt
length," and an attacker can just... wait. Zero cost.
*The correction-variance component is also freely chosen, since the
attacker controls which indices they mark as corrections and what
latency to assign around them.
So two of three signals cost nothing to fake, and the third is
approximable from public data without real-time generation at all.
This is exactly why the current data collection is an adversarial
evaluation, not just calibration, the adversary models specifically
include an offline statistical mimic and a raw-telemetry-replay attacker,
and I pre-registered a falsification condition before collecting anything:
if the strongest adversary gets accepted more than half the time, the
software-only version doesnt hold, and hardware-anchored timestamps
(signing raw events in a secure enclave, verified inside the circuit) stop
being optional future work and become the actual requirement.
I dont have the number yet. Thats the honest answer.
Half the time is a generous bar to hold yourself to. Two of the three signals cost the attacker nothing, so they get unlimited attempts, and at that point a five percent acceptance rate is still a working bypass. It just takes twenty tries. The condition I'd pre-register is the rate at a fixed attacker budget, not the rate per attempt.
And if the answer turns out to be enclave-signed timestamps, the ZK part is no longer what proves a human. It's the privacy wrapper around the attestation that does.
Hi community! 👋
I'm Larbi, a software engineer and solo founder. I recently launched Roleframe, an AI resume builder made specifically for software engineers, because I got tired of generic tools that don't understand what we actually do.
I'm here to build in public, share what I learn, and connect with other devs. Excited to be part of this community. What are you all working on?
Hello larbi
Hey everyone!
I'm a second-year engineering student self-teaching backend development. Just joined the community to share some UX frictions and connect with other devs. Ive already found few frictions and studying them. I posted my first post and the next are on the way.
Excited to learn here!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.