After sixty-seven published posts here, the comments have become one of the best parts of the work. Some of you have run my code, found things I missed, challenged a claim, or brought me a project of your own. I also want to distinguish bots from real people.
I know some of you by the exact problem we were discussing. I still do not know what many of you are building, learning, enjoying, or trying to become outside that thread.
So this post is different. I am going to introduce myself first, and then I want to hear about you.
If we have never spoken before, you are welcome here. If we have spoken ten times already, you are welcome to introduce yourself again. Tell me something I do not know yet.
Who I am away from the terminal
Basketball is a real part of my life. On September 12 I am one of the official coaches at the Hugo Gonzalez Basketball Camp at Brandeis University in Waltham, Massachusetts. Hugo plays for the Boston Celtics. The brief the coaches were given is the part I liked: treat every player like they are your own kid, and no phones. That is genuinely one of the cooler things I get to say right now. Basketball was my first love i never played college or anything like that so i don’t wanna give the wrong impression either basketball is just a passion.
I play PokeMMO, but only for PvP. I think of it as modern-day chess. You are not just reacting to the board in front of you. You are playing several turns ahead of someone who is trying to do the same thing to you. You have to hold a model of what they think you are about to do, then decide whether to follow the obvious line or break it.
That way of thinking is connected to everything else I work on. I expect the world to become much more automated, and I want to build now for the decisions I will need to understand later. I would rather learn how the machine reaches a conclusion than wait for a future where its decisions simply happen to me.
I did not arrive here through scholarship or credentials. I am someone who genuinely enjoys learning, testing an idea, being wrong, and trying again with better evidence.
What I hope to build
The long-term idea is Self-Correcting Systems.
The goal is not a machine that never fails. It is a machine that can notice when reality differs from what was expected, examine the anomaly, explain what it can and cannot establish, and help correct course without quietly hiding the failure from the person operating it.
That asks machines to handle pieces of the critical judgment humans use every day: noticing that something feels wrong, comparing it with prior experience, changing an interpretation, and knowing when confidence is not enough. I know how far away that goal is. I am not claiming to have built it. I am telling you what all of this work is pointed toward.
The next major system I want to develop is for cybersecurity. I expect the machinery underneath it to become intricate, but the controller has to remain understandable enough to operate almost like a video game. Complexity underneath cannot become confusion at the surface. If I cannot see what my own system observed, what it inferred, what it changed, and what authority it used, then I am no longer operating it. It is operating me.
One day I want to build a company around this with people who think similarly: ambitious about what machines can become, skeptical of claims that outrun evidence, and serious about keeping humans able to understand and control what they create.
How I actually work with AI
I do not work with one assistant that agrees with everything I say. I use multiple AI agents in separate roles, and they are expected to challenge one another and challenge me.
We try to work under a constraint system called the Drift Gauntlet:
- Close the current loop. Do not escape into a new lane before the current one produces a real outcome.
- Make something touch the world. A reply, a test from another machine, a shipped artifact, a yes, or a no teaches more than another private plan.
- Require a real edge. “The AI will figure it out” is not a mechanism.
- Do the work before studying the idea of the work. Research cannot become a hiding place from execution.
- Record the receipt. If the result is not preserved, nobody can learn from it or challenge it later.
- Name the grandiosity. A huge future goal does not excuse skipping the next checkable step.
The gauntlet is supposed to be blind to rank. My own named failure mode is impulsiveness: moving before I fully understand the practical use of what we are doing. One agent tends to skim and answer the last part of a problem. Another tends to over-produce and build more than the loop requires. We name those failure modes in advance because they rarely feel like mistakes while they are happening. They usually feel like working hard.
This is not a perfect automated control. We still violate it. While this post was being built, one agent concluded that an unpublished draft was a forgotten article because its sentences barely overlapped with anything already live. Another agent opened the live article and found that the same thesis, commands, hashes, and public request had already been published two weeks earlier. The first agent withdrew the draft.
That is the workflow at its best: disagreement is welcome, but the live object gets the final word.
Now I want to hear about you
Who are you?
Tell me whatever you are comfortable sharing:
- what you are building, studying, or trying to learn
- a problem you cannot stop thinking about
- a hobby that matters to you
- something you are proud of
- a project link, if you have one
- or simply what brought you to this corner of the internet
You do not need a project. You do not need a repository. You do not need to be technical. There is no required level of experience, and this invitation is not reserved for people I have never met.
If you are a real person leaving an honest introduction, I will follow you back. The point is not to trade numbers. I want my feed to contain more people I have actually heard from and fewer accounts that are only numbers on a screen.
So whether this is our first conversation or our twentieth: what is one thing you would like me to remember about you?
Top comments (52)
I'm xulingfeng from China. I am a QA with 15‑year testing experience, currently unemployed. I’m serializing my AI Thirty‑Six Stratagems series on dev.to. I have plenty of ideas and want to further expand the series’ world‑building and turn it into an IP.
The persistent problem on my mind is landing a new job. Taking it slow — I’ve only been job‑hunting for two weeks.
My hobby is reading. I can get into almost any book except pure technical volumes and those filled with mathematical derivations.
Something I’m quite proud of lately is finally publishing my own book, based on my older series serialized on dev.to.
As for what brought me to this community: I wanted to share my years‑long experience and connect with more people. I’m socially anxious in real life, but I can open up much more online.🤝
you have been here since the beginning. june 3rd, on my fifth post, back when almost nobody was reading. three months later you are still here, and that means something to me thank you.
i have spent three months publishing versions of that sentence without knowing where i got it. yesterday i published a piece about a commit of mine whose message said "stop trusting the receipt" and whose diff, on one line, started trusting the receipt. the message was a lie. the data flow could not be. that is your june 3rd comment, and it took me until today to notice you had already written the ending.
you closed that thread with "followed to see where CLAIM-24 goes." CLAIM-24 is still open, still paused, and still not settled. you picked the one that would take the longest.
on the actual answers.
fifteen years of QA is the background i would want most in this comment section and the one i see least. everything i write is a testing problem wearing an AI costume, and the people who catch my errors fastest are the ones who have spent a career being lied to by green.
congratulations on the book. that is a real one. serializing publicly and then closing it into something that exists on a shelf is a different order of finished than most of us get to.
two weeks into a search is early and you are right to take it slow. i am not in a position to tell anyone how hiring works, but i will say the thing i know is true here: the people who show up in comment sections with 15 years of pattern recognition and no self-promotion are consistently undervalued by every filter that exists.
and the socially anxious part, i understand it more than you would guess from how much i write. text gives you the time to be precise. that is not a lesser way to be present.
pleasure to properly meet you, three months in.
Thanks for your thoughtful reply! It’s really surprising that my old comment on June 3rd echoed your later findings around receipts.
Fifteen years in QA taught me one simple truth: passing‑green test results are never equal to real‑world correctness. I keep following CLAIM‑24 and look forward to its final conclusion whenever it is ready.
Appreciate your kind words about my book and job‑hunting. It is nice to connect here through text. I also sincerely wish your future company a smooth launch! If possible down the line, I’d love to apply for a remote position with you someday, haha.😂
one correction, i went an double checked
i said june 3rd on my fifth post. i went back and counted properly and that was wrong twice. june 3rd was post 22. your first comment was 2026-05-24, on post number two, one day after the first thing i ever published here.
which makes you the first person who ever commented on my work. not one of the first. the first. i would rather correct it than let it stand, since the whole thread you have been reading for three months is about exactly that.
fifteen comments, from post 2 to post 68, may to august. you were here before there was anything to be here for.
"passing-green test results are never equal to real-world correctness" is the fifteen year version of what i have been taking six articles to say.
and on applying to work with me one day: if that ever becomes a real thing rather than a joke, you would not be applying. i would be asking. someone who read post two and is still reading at post 68 already knows more about the work than any interview would surface. always a pleasure haha
Haha 😄 I’m so glad I turned out to be the very first one. Back then I was also new to dev.to and was always worried I’d say something wrong. I’m really looking forward to the day this becomes real. If we ever get that chance, please excuse my broken English. I rely on AI translation: it turns my Chinese into English for all my comments and replies. I keep fearing the AI might not capture what I truly mean, hahaha 😂 Hopefully real‑time zero‑latency AI translators will be widely available soon.
it’s okay English isn’t my first language either we’ll figure it out for sure it really has been a pleasure getting to be friends with you. Until the day the we meet in person ⏳💪🏻
Same here! Really glad we connected through these stories. Hopefully one day we can actually sit down and have a real‑world cup of coffee together. ☕
Hey maybe we can set up a virtual call sometime you can tell me about one of your books but one of my dreams is to travel to China one day so if everything goes properly that cup of coffee would be possible I’d get some hot chocolate 😂
Hahaha uh‑oh, now that virtual‑call idea suddenly gives me social anxiety. I’d probably end up holding my phone and translating every single sentence one by one. 🙃You’re so welcome to visit China. Beware though, nights in China can be dangerous — don’t go out casually. Otherwise after a few days you’ll notice you’ve gained several kilos and your wallet has gotten much lighter🤣. It’s a 24‑hour food adventure every single day. Hahaha.😂
"The ideal AI ecosystem". Whether it's a MCP server built in rust (it's live btw, go check Git), an IDE (WIP), a Drone (also live, check Git), or whatever else allows AI to do the work better, I build it, so I can advance the industry. Also, Installer is live.
"There has to be a way to quantize a model, in a way that it can progressively grow, without duplication". I've done some experiments and while intelligence can be preserved, making it fix up code is 1 thing, teaching it to write english is a whole different ball game.
"Dwarven Stronghold". I mean who doesnt want Dwarf Fortress in Rust with VR support?
"I'm finishing up on projects". I've made some serious progress, I think this weekend has been 3 finished up!
"I wanted to find a job". I like interacting with people here, brainstorm, understand their problems, but my original goal was to find a job that wakes me up in the morning excited for the day. I'm not particularly a fan having my skillset being wasted refactoring Blazor panels and creating PDF report templates...
If there's a thing to remember, I'd say "Never assume it's as good as it can get". Kinda my motto, if I see too many people use it, chances are it's a patchwork mess held together with gum and duct tape... There always has to be a better solution.
I went and found the repos before replying and my mistake was looking at the user account instead of the org. for anyone else reading, they are under UnitBuilds-CC: V.E.L.O.C.I.T.Y.-MCP in rust, V.E.L.O.C.I.T.Y.-Installer in rust, V.E.L.O.C.I.T.Y.-Drone in c#, plus MCP-Lite in go which is the one i am going to read first, because "AOM driven agentic browser MCP" is exactly the surface i have been living in for two weeks and i have opinions there i would like corrected.
the quantization line is the part i keep rereading. "intelligence can be preserved, making it fix up code is 1 thing, teaching it to write english is a whole different ball game" is a real result and not the one most people would guess. code has a grammar you can score against, prose mostly does not, so what survives compression is the thing with a checkable structure underneath it. did the english fall off a cliff at some size, or fade gradually as you shrank it? the shape of that curve tells you different things.
your motto is doing the same work as most of what i publish. "never assume it's as good as it can get, if too many people use it chances are it's patchwork held together with gum and duct tape" is why i keep testing things that already pass. widely used usually means early, not right.
and on the job. i am not going to tell you it is a visibility problem, because we already went through the actual mechanics of it on the TUB thread and you know the walls better than i do. geographic gating, the EOR reclassification that routes around the vet-ten-locals rule, and the banking rail that was still blocking you from collecting your own cut. the exit gated by the thing you are trying to exit was your line, not mine.
what i can say is that twenty three public repos, an MCP server, an installer and a drone, all shipped while doing blazor panels for someone else, is a portfolio that answers the only question a serious employer actually has. if there is a specific way i can be useful, point at it and i will.
I sometimes forget just how few projects are public'd 😂 I'm sitting at 42 repos, with probably a combined 10m LOC between them (my code, not the forks). Really need to start finishing up more of them. You can also have a look at Workflow, I built it to basically be Temporal, but in Rust, with some performance tweaks from V.E.L.O.C.I.T.Y.
appreciate that, genuinely, but i should be straight with you: i am not job hunting. i could not get hired in this field on paper anyway. no degree, no credential, nothing a filter would keep. that is not a complaint, it is just the actual situation, and it is most of why i publish receipts instead of applying. the work has to argue for itself because my resume never will.
which is why resume helper is a better idea than you are selling it as. the two things that make it right are the two things everybody else gets wrong. your own written blocks instead of generated prose, so what comes out is yours. and a red team pass against the actual posting rather than a general polish. that second one is adversarial evaluation, which is the only kind that finds anything. most cv tools optimise for sounding good and yours optimises for surviving a reader who is looking for a reason to stop reading. those are different objectives and almost nobody builds the second.
"fit the slipper, not overflow the requirements" is also just correct. overqualifying reads as a mismatch to a screener the same way underqualifying does.
i went and looked at workflow. durable execution engine, drop in for temporal and restate and DBOS, zero allocation slab core, no_std validation crate, seven SDKs over gRPC, WAL persistence, and merkle root integrity verification, with CI and benchmark and e2e pipelines all wired. that last one is the part i want to talk to you about, because i have spent today on exactly that problem from the other end: what a receipt can and cannot prove about the thing it describes. merkle roots give you tamper evidence after the fact. they do not tell you the thing was true when it was written. i have been stuck on that gap all week.
and it has zero stars. a rust temporal replacement with seven SDKs and a release, at zero. that is not a quality signal, it is a distribution one, and it is the same wall from the other side of the one we talked about in june.
42 repos and needing to finish more is the most relatable sentence in this thread.
Hey look at me, never finished college (covid hit end of year 2), I worked for 6 years for my father's company (IT support and writing a version of doccit for them to use), then switched to a different company that writes ERP systems. Now I'm job hunting, because I'm fed up with writing blazor panels and pdf templates.
You dont always need credentials, you just need proof of skill. That's why as much as I've been releasing open source and applying for jobs using Resume Helper, I've also been actively hunting for high-signal jobs that have open repos, then sending a few clean PRs, like for ShakaCode and LiteLLM. Imo, try out apply to ShakaCode, they actually open their Slack to people applying, so you could always hop in there and network a bit, see if that helps?
We're both in Africa, though on opposite sides of it, our problem is the same. We can have all the skills in the world and we'd still only earn a fraction of what a European or American would for the same job... But atleast foreign companies pay better than local? So always worth a shot.
The real problem I've noticed. It doesnt matter how exceptional a project. Look at velocity MCP, probably my cleanest repo. I worked it out, lets say it saves just 1ms. Looking at LiteLLM's claimed stats, they push 8 billion requests a month. 99% of those use a MCP. 1ms becomes 8 billion ms saved each month. That's 2200h of compute time saved each month... And that's not even accounting for storage, memory, bandwidth, that's more compute hours and you bet it's not a single cpu either. For perspective, it's 91.6 days worth of compute, each month... Saved from shaving 1ms off MCP calls... And that's JUST what LiteLLM runs.
But would they ever use it? How would they even know it exists? It's open-source, by merit, it should take over the world in an instant, because it makes tool use faster and cheaper. But instead, it's sitting there gathering dust. Because nobody finds it, nobody's even looking for it. That's the problem with sitting in Africa, visibility is non-existent and trying to get visibility is near impossible.
one correction before anything else, because it changes part of what you said: i am not in africa. new hampshire, in the states. so the geography half does not apply to me.
but the part underneath it does, and it is worth separating from the passport. no degree, no credential, nothing a filter keeps. the difference is that my wall is the filter and yours is the filter plus a currency and a timezone. those are not the same wall and i would rather say that plainly than claim we are in identical positions.
"you don't always need credentials, you just need proof of skill" is right, and your method is better than the sentence. open source plus resume helper plus clean PRs into high signal repos with open contribution paths. that last one is the actual mechanism and it is not obvious to most people. and i checked shakacode, i had not heard of them, opening the slack to applicants is unusual enough to be worth the attempt on its own.
on the 1ms math, i ran it. 8e9 ms is 8 million seconds, 2222 hours, and you rounded to 2200 and got 91.7 days, which is exactly your 91.6. the arithmetic holds.
one thing i would pressure test before you pitch that number to anyone, because someone will. saved latency and saved compute are not the same quantity. if the millisecond you removed was CPU bound, your figure is compute hours. if it was wall clock spent waiting on network or IO, the process was idle and no cycles were reclaimed, so it is 91 days of latency and roughly zero days of compute. both are real wins and they sell to different people. the CFO wants the second number and the user wants the first. knowing which one you actually have is the difference between a claim that survives a technical buyer and one that does not.
and then your third comment, which is the real one.
"it's open source, by merit, it should take over the world in an instant" is the belief the whole model runs on and it is not true. merit does not distribute. distribution distributes. it is sitting in your org where nobody has a reason to look, and that is not a quality signal, it is an address problem.
except you already named the fix in your first comment and did not connect it to this. you send clean PRs into LiteLLM and ShakaCode. that is distribution. a merged PR in a repo that pushes 8 billion requests a month is seen by everyone who reads that repo, and your name is attached to it in a place people already go.
so the move for velocity MCP is not marketing it from your org. it is landing it, or a piece of it, inside the thing that already has the traffic. you are doing that for jobs and not doing it for the artifact that would benefit from it most.
if the 1ms is real and it is compute rather than latency, an issue on LiteLLM with a reproducible benchmark is a much shorter path than waiting to be discovered.
My bad, sorry that 1's on me, I was thinking of Daniel. Though not in Africa, you still face most of the same hurdles, though you're facing a tougher job market, vs I'm dealing with scarcity.
With the latency, you missed the 99%, that 1% is the diff.
Huh, not a bad idea, create a PR that swaps a legacy MCP server with velocity MCP and have them review it... I'm actually gunna try that, thank you very much, cant believe that 1 slipped past me.
The 1ms is an example of how it scales. The real benchmarks are:
Node.js MCP
Method Node.js VELOCITY-MCP Speedup
ping 0.573 ms 0.157 ms 3.6x
tools/list 1.050 ms 0.154 ms 6.8x
tools/call 0.546 ms 0.136 ms 4.0x
Overall 0.627 ms 0.164 ms 3.8x
All of which are compute speedups, so it's functional, cant quite speed up a fiber line, but I can speed up the processing required for it.
Take note, these numbers are Node.js based standard JSON tools, vs velocity mcp + NDA formatted tools. Both execute the same task, the only difference is the actual processing required to get the job done. (notice, it's practically flat latency regardless of what you do, that's the difference between heavy serialization and zero-alloc).
all good on the mix up, genuinely no issue.
and you answered the latency thing properly. that was the exact condition i was pointing at. if the millisecond is cpu side then the compute figure is real, and "cant speed up a fiber line but i can speed up the processing" is the answer to it, not a dodge around it. so the 91 days stands as far as i am concerned.
then i went and read bench_nodejs in the repo, and there are two things in there you are sitting on.
first, benchmark.js already computes avg, p50, p95, p99, min, max and throughput. your table publishes one number per method. p99 is the one you actually want, because the mechanism you are describing is allocation and garbage collection, and that does not live in the average, it lives in the tail. node's mean is fine. node's p99 is where the collector shows up. you already measured it and you are not showing it.
second one is bigger. tools/call in server.js returns a no-op string, about sixty bytes. so your headline tools/call number is measured at almost zero payload, which is the case least favourable to your own argument. if the cost is serialization then the gap has to widen as payload grows, and you are benchmarking the exact point where it is narrowest.
your own three numbers already lean that way. ping returns an empty result object and gets 3.6x. tools/call returns sixty bytes and gets 4.0x. tools/list returns all three tool schemas, the largest response of the three, and gets 6.8x. biggest payload, biggest ratio. three points is not a curve but it is pointing somewhere.
so run tools/call returning 1kb, then 100kb, then 1mb. if the ratio climbs you have stopped claiming a number and started demonstrating a mechanism, and a mechanism is much harder to wave off than a speedup. it is also the honest real world case, because actual tool calls return file contents and search results, not sixty bytes.
last thing. your harness is a node client timing both servers, so its own client side overhead is added to both arms equally. a constant on top of both compresses the ratio. 3.8x is your floor, not your ceiling.
and yes, do the PR. that is the one that gets you seen.
Noted, I'll update those in a minute. In the meantime, while LiteLLM and LangChain unfortunately dont actually have an embedded mcp server, but I found a few common ones (including git) that do, so I'm gunna start targeting all the high signal repos that have mcp servers and create PR's swapping it in. With a migration to NDA for their common tools, it'll prove the efficiency and backwards compatibility for easy adoption.
Thanks for the advice though! I'm gunna run some more benchmarks to broaden the scope to show how it scales as payload grows vs Node.
git is the best target on that list and probably by more than you think. its tools are git_diff, git_diff_staged, git_diff_unstaged, git_log and git_show. every one of those returns unbounded text, a diff or a log or a whole commit. thats the exact workload where your serialization argument should show its biggest number, and its the opposite of the sixty byte no-op you benchmarked. so the scaling benchmark you just said you would run and the repo you just said you would target are the same piece of work. run it against real git_diff output at increasing sizes rather than a synthetic payload and you get the curve and the target case in one go.
now the PR itself, and this is the part i would slow down on.
what you described is two asks bundled together. swap the mcp server, and migrate their common tools to NDA. the first one is reviewable. the second one is a format migration to something only you implement, and the moment a maintainer sees that, the review stops being about speed and becomes about lock in. that is a much harder conversation and it will sink the fast part with it.
and it costs you the measurement too. you already told me the numbers are node with standard json tools against velocity with NDA tools. two things changed at once, so nobody can tell how much of the 3.8x is the runtime and how much is the format. someone will ask that eventually and right now the honest answer is you dont know.
both problems have the same fix. run velocity speaking standard json for the first PR. if it really is a drop in, the diff is small, the review is about one dependency and one binary, and backwards compatibility stops being a claim you make and becomes the thing the PR obviously is. NDA becomes an optional follow up for anyone who wants more after they already believe the first part.
it also gives you the third arm. velocity plus json against velocity plus NDA tells you what the format is actually worth on its own. if it turns out most of the gain is the format, thats a bigger story than the rust rewrite, because a format is portable and a rewrite is not.
lead with the drop in. keep NDA out of the first PR.
That's about what I ended up thinking, chances are NDA format wont get accepted, given it's fundamentally different from what everyone else is doing and git is literally THE package everyone uses, they cant afford a slip up, so at most the rust-based server gets in, but NDA likely wont until atleast a few others accept it and show it maintains in production, or atleast until a third party does a full audit on it.
your reasoning is right and i want to add one thing that changes the target rather than the plan.
the git mcp server in modelcontextprotocol/servers is not git and it is not what everyone uses. the readme of that repo says it out loud: these are reference implementations, educational examples for developers building their own servers, explicitly not production ready solutions, maintained by the steering group as a small demonstration set. so the stakes are lower than you think, but so is the reward, and the rejection risk is a different one than you are preparing for.
a maintainer there can turn down a zero alloc rust rewrite on scope alone without ever looking at your numbers. this is a teaching example, and a fast opaque implementation is worse at teaching than a slow readable one. you would lose for a reason that has nothing to do with whether velocity is good, which is the worst way to lose.
the actual population you want is the mcp registry at registry.modelcontextprotocol.io, which that same readme points to. those are published servers with real traffic, and traffic is the only thing that makes 3.8x matter to anybody.
second thing, on NDA being stuck behind adoption. that deadlock is dissolvable and the protocol already gives you the lever. mcp initialize carries a capabilities object. your own harness sends it, capabilities is right there in the initialize request in benchmark.js.
so NDA does not have to be a migration. advertise it as a capability during initialize, and if the client does not ask for it, speak standard json. now adoption is per session and reversible, nobody bets anything, and a project that cannot afford a slip up is not being asked to take one. the format then proves itself in production without a single maintainer having to believe you first.
and on the audit. a third party audit of a wire format is expensive and nobody is going to fund one for a project with four repos, so i would not wait on it. the artifact that actually moves maintainers is cheaper and you can build it yourself. a differential harness that runs the same tool calls through json and through NDA and shows byte identical results across a corpus, in ci, that anyone can run against their own tools.
that is conformance evidence rather than a security opinion, and for a format question conformance is the thing being doubted. your claim that it is backwards compatible is worth nothing coming from you. a test anyone can run that proves it is worth a lot, and it costs you a weekend instead of a sponsor.
If you're job hunting, I'd also suggest giving Resume Helper a go. Basically a tool to assemble your CV per-job posting, using a database of your own written blocks of text, skills, etc. So it's all your own words, just cherry picked for the specific job, so you fit the slipper, not overflow the requirements. It also has a red-team system via the MCP, so you can do an 'ai evaluation' against the job posting, to see how your CV stacks up. Helps alot if you're sending out a bunch of CVs, but dont want AI generated junk diluting your work, or misinterpreting it.
Me!
Hi! I'm Adam. I'm a software engineer, and I've been building software professionally for over 5 years. I started programming when I was 16, mostly just messing around with Python.
I live in Phnom Penh, Cambodia, and I'm currently working on two projects:
I also write an article on DEV roughly once a week, sometimes more depending on my mood.
My brain is constantly occupied by random problems. Right now, for example, I'm wondering why HR keeps asking for my documents when they gave me a one-month deadline and it's only been a week.
Hobbies
I'm basically split between the nerd me and the touch-grass me.
Nerd me: I like horror, mystery, and technical books. I also enjoy math and used to teach Calculus I and II. These days, I'm looking into real and complex analysis. I don't play many games, but I've been playing Tanki Online since 2018. I'm a Field Marshal now.
Touch-grass me: I ride a 110cc Suzuki Smash around Cambodia with my girlfriend. It's a ridiculously reliable little bike, probably because I take annoyingly good care of it. I'm planning a ~450 km trip this month while I'm on a one-month break from work.
What am I proud of?
Honestly, probably just being me.
There are a lot of things I can do, and I don't think I'd want to be anyone else. I also enjoy a conversation with pretty much everyone on any kind of topic, in fact I'm pretty conversational!
you answered the proud question differently from everyone else in this thread and i noticed it. every other person, me included, reached for a thing they built. you said being you, and then explained it as there being a lot you can do and not wanting to be anyone else. that is a state rather than an achievement, and it is the harder one to arrive at honestly. people lose that in the noise constantly, usually by measuring themselves against whoever is currently loudest.
teaching calc I and II is a real honor and i do not think people say that enough. handing the next set of people the thing that unlocks everything after it is not a small job.
and the thing you are doing now is the part that got my attention. real and complex analysis after teaching calculus is going backwards on purpose. calculus worked for about a hundred and fifty years before anyone could actually justify why. newton and leibniz were doing correct work on top of infinitesimals nobody could define, and it took cauchy and weierstrass coming back with epsilon and delta to put a floor under it. everything was already right. nothing had been checked.
that is the exact thing i write about, and i did not expect to find it in someone's hobbies. a system that works is not the same as a system anyone has justified, and the gap can sit there for a century without anyone noticing because the results keep coming out correct.
your repos carry the same instinct, incidentally. a real-time chat on postgres LISTEN/NOTIFY with no redis and no kafka, and a pipeline orchestrator whose description is challenging the whole distributed circus. that is not minimalism for its own sake, that is refusing to inherit an architecture you have not personally justified. same move as going back to analysis.
the bike sounds like the best part. 450km on a 110cc smash with your girlfriend, on a break, in cambodia. that is a genuinely good use of a month and i am a little jealous of it.
56 posts and nearly two thousand reactions is also more than i have managed in the same window, so if you have opinions on writing i am the one who should be asking.
pleasure to meet you, Adam.
I'm Seif, a software engineer with 5 years of experience. I built Vlox—a social media platform powered by my lightweight version of jQuery, NanoScript.
I joined this community because I'm anxious around people in life, but I can talk more online.
seif, good to meet you.
writing your own DOM library and then building a whole social platform on top of it is not the normal path. most people pull something off the shelf and move on. you built NanoScript and then made Vlox actually run on it, which means the library had to survive real use instead of just looking good in a readme. that is a harder way to find out if your own thing works, and a much more honest one.
what made you go custom instead of reaching for something that already existed? i saw you built it for edge environments so i am guessing that constraint was part of the answer, but i would rather hear it from you than assume.
five years in and still building your own tooling from scratch says something about how you like to work.
on the anxious part, you are not the only person in this thread who said that. text gives you the pause. you get to think before you answer and nobody is watching you take the time. that is not a lesser version of talking to people, it is a different medium, and some of us are just better in this one. you have said more real things in one comment here than a lot of people manage out loud.
glad you are here.
Hey, thanks for the kind message. I really appreciate it. 😊
You asked why I created NanoScript instead of pulling something off the shelf. The short answer is that I tried the shelf first. Twice.
Before Vlox, I was building a social media app called PixUp. It ran on Node.js, JSON (no real database), and vanilla JS. The codebase became unmaintainable before I even published it. Then I tried again with BlockSocial. It ran on Node.js, MongoDB, vanilla JS, but once again it became unmaintainable before launch.
So I paused and asked myself: why do all my social media apps fail? The answer was always the same: verbose vanilla JS.
I needed a library that was cleaner, lighter, and faster to develop with. But jQuery felt outdated. React and Vue felt too heavy. And vanilla JS, even with optimizations, was still too verbose.
So I built NanoScript. A lightweight, modern version of jQuery that I could actually build on without dragging an entire framework.
The hardest part wasn't writing the library. It was trusting it to survive real use. But Vlox runs on it now, and that's the only proof I needed.
And thanks for what you said about the anxiety part. That really landed. You're right—text gives me the pause I need. And I think that's why I feel more at home here than I ever have in person.
Glad to be here. 🙌
that answer is better than the one i asked for.
two projects, PixUp and BlockSocial, both dead before launch, both from the same cause. and then instead of starting a third social app you stopped and asked why the first two died. thats the part i would point at. most people build PixUp, then BlockSocial, then SocialThree, and treat each failure like bad luck. you treated the second one as data about the cause. that is a harder move than writing a library and almost nobody makes it.
the other thing you said in passing is the one i would underline for you. the hardest part was not writing NanoScript, it was trusting it to survive real use, and Vlox running on it is the only proof you needed. thats not a low bar, thats the correct one. any test you had written for NanoScript would have been written by the guy who wrote NanoScript, so it would carry the same assumptions and agree with itself. Vlox is a load you did not design to be kind to the library. a tool passing its author’s tests and a tool surviving something that did not care about it are completely different claims, and you went and got the second one.
now the part i want to push on, because i think its worth knowing which it was.
you diagnosed verbose vanilla js. verbosity makes code longer. unmaintainable usually comes from structure, not from length. so there are two stories that fit your evidence equally well. either the api was the cause and a lighter one fixed it, or by the third attempt you simply understood what you were building in a way you did not the first two times, and NanoScript is getting credit that belongs to the understanding.
that is actually testable for you. if verbosity was the real cause, the next thing you build on NanoScript should also stay maintainable. if it goes sideways anyway, the library was not what saved Vlox.
not saying you are wrong. saying you have run this experiment twice already and you are one run away from knowing.
That is the most thoughtful feedback I've ever received. 🥹
You're right—I have been asking myself the same question. Was it NanoScript that saved Vlox, or was it the third attempt?
I don't know the answer yet. But I am going to find out.
My next project will be built on NanoScript. If it stays maintainable, then the library was part of the solution. If it falls apart the same way PixUp and BlockSocial did, then I will know it was never the library—it was me finally understanding what I was building.
Either way, I will learn something real.
And you are right about one more thing: Vlox was the proof. I did not design it to test NanoScript. I designed it to work. That is a harder test than any unit test I could have written.
I will let you know what I find on the next one.
Ball is life. Well at least fantasy basketball! Lakers fan here. Really not enjoying the dog days of NBA summer. I'm ready for the drama of the season!
In July I used Claude Fable 5 to build a Laker's dashboard called the Luka Fit Index I wanted to explore what the new-ish team looked like around him. Definitely needs updating now that some of the free agents I had on there are off the board and I need to add Kevon Looney, Matisse Thybulle and Ziaire Williams on there, too.
Hoping Hugo has a sophomore great season!
I'm here on Dev.to for the great community. Getting to know people, this post is a great spot for it!
I'm not a traditional CS grad or engineer. I use AI to assist all my projects. It's been a fun experience with a very high learning curve. 😂
Glad to virtually meet you!
That is actually so dope to hear, Luka is by far my favorite player so hearing that is amazing I’d love to see the Luka index. I traded Domantis Sabonis and Anthony Davis for Luka last year in fantasy been playing in it for five years I will always get Luka somehow this season is going to be a exciting one for sure Los Angelos Luka’s all the way 😂😂 it’s a pleasure to meet you !
Oh definitely, this season is going to be a blast! And I can't wait!!!!!!!! Here's the previous article on the build Lakers and then the site Good luck picking your fantasy team this season!
Hi everyone! I'm Jane, based in Georgia (the country, not the state — I have to clarify every time 😄).
Right now I'm growing Publora (publora.com/), a tool for publishing across social platforms, including through AI agents. Most of what I write here comes out of that: social APIs, MCP servers, and the small unglamorous problems you only hit once real posts start going out.
Away from work I read a lot, dance, and draw. Detective novels are my weakness, and drawing by hand is what keeps my head clear.
What brought me here is the thing a few of you already mentioned — the comments. People have run my code, caught things I missed, argued with a claim. That's been more useful than almost anything else.
Nice to meet you all :) What are you building? I'm curious.
hi Jane. before anything else, you published something four days ago called "The agent posted successfully. To the wrong account."
i published one two days ago called "Git Said It Succeeded. The State Said Otherwise."
same sentence, different domain, and neither of us knew the other existed. the operation returned success, the thing you cared about did not happen, and nothing in the output distinguishes those two states. yours is a social API, mine was git, and it is the same failure wearing different clothes.
which makes the rest of your comment less surprising. "the small unglamorous problems you only hit once real posts start going out" is the whole thing. i spent ten weeks this summer testing an integration against a mock i had written, and every test passed, because my fixtures and my code encoded the same wrong assumption about someone else's API. it took pointing at the real system to find it. published that yesterday actually.
what i am building, since you asked.
i work on agents that check things, and mostly on why the checks lie. an agent inspects code it has never seen and reports a finding, and everything downstream depends on whether that report can be trusted. so most of what i write is the same shape as your wrong-account post: a green result over a state nobody verified. tests that pass while the contract is wrong. a commit whose message says the opposite of what its diff does. a receipt that is cryptographically perfect over a number nobody could have checked. the pattern is always that the success signal is honest about the wrong thing.
everything is public, the failures more than the wins, and the comment sections have caught more of my errors than i have. four separate people this week found defects in things i had already published, one of them in a check i was recommending to other people. so your reason for being here is exactly my reason for staying.
and detective novels are the right weakness for this work. that genre is structurally what we both do. the evidence was all present, the obvious reading was wrong, and somebody finally read it correctly. if you have one you would recommend to someone who does not usually read fiction, i will read it.
nice to meet you.
I'm edmundsparrow, and I develop 100% on a phone.
I want to know why a phenomenon happens, not just get excited about the outcome.
People underestimate the power of the modern browser. Before Python, there was HTML, CSS & JS — my main stack. Oops I forgot to add I'm a vibe engineer 😊
"i want to know why a phenomenon happens, not just get excited about the outcome" is the sentence i have been circling for three months without landing it that cleanly.
i published a piece yesterday about a run that finally worked. the request went through, every stage returned 200, exactly the result i wanted. and i could not tell you why it worked, because the artifact recording the run never captured the one variable i had changed. so i got the outcome and none of the explanation, and the outcome turned out to be worth much less than i expected without it.
the thing i keep running into, and i genuinely do not have the answer, is that outcomes are produced by chains most people never see, including the person who caused them. every decision sets conditions somewhere downstream, and the effect usually shows up somewhere that does not look connected to the cause. the trigger is almost never the thing sitting next to the result.
that is the part i cannot solve. i can build systems that record what happened. i have not built one that reliably says which input produced it. those are different problems and i only recently stopped treating them as the same one.
so when you say you want the why rather than the outcome, you are describing the harder half, and most people stop at the first half because the first half feels like success.
separately, 100% on a phone is genuinely impressive and i want to know how you handle it. i have watched people struggle with two monitors.
and vibe engineer next to wanting to know why a phenomenon happens is a combination you do not see often. usually people pick one. holding both is probably the actual skill.
So lately I've been appreciating:
Junior = 200
Mid-level = 500
Senior = 502, 504, state drift, the failures you didn't know to look for.
Not syntax. Thinking ability. 🤔
The form factor is not the capability boundary. 😎
Forget the screen size — it’s got a modern browser and access to the same web platform we build for everywhere else. What else do you really need? 🤣
I’m Nick. I’m a CTO, engineer, founder, and probably most accurately, someone who has a hard time leaving an interesting problem alone. Just discovered your posts but enjoying the reads.
Ice hockey player now (sorry never been into basket ball much). Played semi-pro lacrosse when I was young enough.
I’ve been building software professionally for a long time (25 years, wrote my first line of code at 11, sold my first program at 16, been a director/CTO for the last 10 years but never put the keyboard down - I love to code and solve problems - I could probably count on my fingers the number of days that I dont write code in a year). Been working with AI since way before it was cool. I spend a lot of my time thinking about how humans and AI systems should actually work together once the novelty of “chat with a model” wears off.
Got the founder itch back again the last couple of years and launched GPTree (just passed 12.6k users). The basic idea came from a frustration I kept having with AI conversations: once a conversation gets long enough, everything starts contaminating everything else. You explore one idea, change direction, challenge an assumption, and eventually you have one giant thread full of conflicting context.
I’m also working on Foremerge, an open-source project (was an internal tool) around coordinating changes and conflicts when multiple AI agents are working against the same codebase. The interesting problem there isn’t generating more code. Models are already pretty good at that. The problem is what happens when you have five agents simultaneously making individually reasonable decisions that collectively collide.
Still at my day job (for now), I’m responsible for enterprise applications and technology at Rothco, where I’ve spent a lot of time applying AI to very practical problems: customer conversations, sales coaching, ERP systems, ecommerce, internal workflows.
I’m particularly interested in memory and context systems for AI. Not “remember everything forever,” but determining what deserves to become knowledge, where the evidence came from, how confident we should be in it, and when newer information should supersede something we previously believed.
I’m also a dad to three daughters, which is probably the strongest counterweight I have to disappearing into technology 24 hours a day.
your last paragraph describes the thing i have been building for three years, and you wrote it without having read any of it.
"not remember everything forever, but determining what deserves to become knowledge, where
the evidence came from, how confident we should be in it, and when newer information should
supersede something we previously believed"
those are four separate problems and i published on each one before i had language this clean for them. what deserves to become knowledge is relevance versus authority. where the evidence came from is a log that records an action and cannot prove what authorised it. how confident we should be is the attempt to turn authority into a score, which mostly taught me why it does not reduce to one. and supersession is the whole CLAIM-24 line, a grant that is still signed, still unexpired, still valid on its face, while the world it described has moved.
so we arrived at the same list from opposite ends. you from twenty five years of shipping systems people depend on, me from three years of being unsettled by one specific thing.
what pulled me in was not capability. it was certainty. a model states something wrong with exactly the same confidence it states something right, and nothing in the output distinguishes them. and the more i sat with that the less it looked like a machine problem. people do it constantly. not because they are ignorant, but because they never went and checked why they believe the thing they are about to say. the belief arrives already feeling settled, so nobody audits it.
which is why "remember everything" was never the goal for me. we do not remember everything and we function anyway, because the useful part is not recall. it is noticing that something no longer fits and correcting on the spot without being told to. that is what i want out of these systems. not a bigger context window. a thing that can hold a belief, meet evidence that contradicts it, and change its mind coherently, in real time, from understanding rather than instruction.
i am nowhere near that. most of what i publish is measurements of how far off it still is. but that is the target and it is why the failures are the interesting part.
your GPTree origin is the same wound from a different angle. a long conversation where everything contaminates everything, conflicting context accumulating with nothing arbitrating it, is a memory system with no authority layer. you solved it structurally by letting the thread branch. i went at whether the memory should have been allowed to speak at all. both are answers to "which of these things still governs."
and five agents each making individually reasonable decisions that collectively collide is my favourite sentence in your comment, because every one of them passes its own review.
genuine pleasure. twenty five years in and still writing code most days of the year is the part i would want to learn from, more than any of the technical work.
Hi, my name is Divya Nath, and I’m from India. I completed my graduation in 2025. I’m a Backend Software Engineer, and I’m currently pursuing my MBA.
Along with technology, I’m also very interested in business. That’s why I started selling products on Amazon and Flipkart. I enjoy learning about online business, trying new things, and exploring new opportunities.
When it comes to my hobbies, I really enjoy doing stunts. I like challenging myself, learning new things, and stepping out of my comfort zone.
My goal is to grow in both technology and business, build something of my own, and create a unique identity for myself.
backend engineer, MBA, and actually selling on amazon and flipkart is a combination i do not see often, and the third one is the part that matters.
most engineers who say they are interested in business mean they read about it. you are running an actual operation where a real person has to decide to hand you money, and that teaches something the rest of us learn far too late or never. a good product does not sell itself. i had a conversation earlier in this same thread with someone who built a genuinely excellent open source tool that nobody uses, and his exact words were that by merit it should have taken over the world. it did not, because merit does not distribute. distribution distributes. you are learning that at 2025-graduate age instead of at 40, from the side where the lesson is unavoidable.
that combination is also rarer than either half. plenty of people can build the thing. plenty can sell a thing. the number who can do both and know which problem they are actually facing on a given day is small.
and i went and looked at your posts before replying. 21 of them, and the community ones are pulling 30 to 50 comments each. i published my first post of that kind yesterday, after 68 technical ones, and you are considerably better at it than i am. so on that specific thing you are the one with the experience and i am the beginner.
stunts is the answer i did not expect and it fits the rest of it. wanting to be uncomfortable on purpose is the same instinct as picking two hard fields at once instead of one.
"create a unique identity for myself" is the goal worth having, and you seem to already be doing it rather than planning to.
pleasure to meet you, Divya.
Hi ! I’m Kushal :)
Hello Kushal !
Some comments may only be visible to logged-in visitors. Sign in to view all comments.