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 (71)
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.
I ended up thinking about it, I'm now busy setting up a full suite for it. Afterwards, I'm gunna take deepseek flash and run it through swe bench and toolbench. Given that it's a MCP server and a tool format change (NDA vs JSON), specifically because NDA is meant to be more comprehensible for LLMs, I'm quite curious to see the quality difference it makes. Would be a shocker if it can boost deepseek to overtake a frontier model (though unlikely)
good, and one design note before you run it, because the setup as described repeats the attribution problem from the benchmark thread at a scale where it costs more.
if the arms are deepseek plus velocity plus NDA against deepseek plus node plus json, two things changed and a delta cannot be assigned to either. you need velocity speaking standard json as a third arm. otherwise a result gets reported as NDA helps LLMs when it may be the runtime, or the reverse, and you will not be able to answer the first person who asks.
the more interesting part is that your two benchmarks should disagree if your hypothesis is right. NDA being more comprehensible for an LLM is a claim about tool use. ToolBench measures that fairly directly. SWE bench is mostly code reasoning where the tool call format is a small fraction of the task. so if NDA is doing what you think, the effect should be visible on ToolBench and close to flat on SWE bench. if both move by similar amounts, something other than comprehensibility changed, most likely latency or truncation or a context budget difference, and that is worth knowing before you publish either number.
so the differential is your evidence, not the raw scores. a format that helps everywhere equally is suspicious. a format that helps exactly where comprehension is the bottleneck is a mechanism.
and on overtaking a frontier model, i would set that aside as a target and keep it as a tripwire. if a tool format change moved deepseek past a frontier model on any benchmark, the first thing i would suspect is the benchmark, not the format.
fair point, yes, I will be running velocity + json, as a sanity check. The reason for those 2 benchmarks is toolbench is to see if anything breaks under stress, while SWE is meant to see whether having better declared tools improve tool clarity, which in turn improve tool use accuracy. Given that the server uses convert to nda tool as a universal way to translate json tools into nda, it will be the mandate, no manual editing of tool definitions, just run that and convert. Oh something else that's actually pretty cool, velocity can add tools without needing to be restarted, you just need to call list tools again and it live-updates, while it does have a tool list cache, it does a delta check, instead of just reading the cached list. the performance gain from the server is sufficient that it still beats node.js on a warm cache hit, just a tiny bit slower on the initial run to register the tools.
velocity plus json as the sanity check is the third arm and that closes the attribution problem, so whatever the delta turns out to be you will be able to say which half it came from. good.
the automatic conversion matters more than you framed it. if the nda tools are produced by running the converter with no manual editing, then nobody hand tuned the nda arm, which kills the objection i would have raised next. worth stating that explicitly when you publish, because a reader assumes hand tuning by default.
on the SWE hypothesis, i would watch that it is a chain rather than one claim. better declared tools, then better tool clarity, then better tool use accuracy, then a better SWE score. four links. if the score moves you have evidence the chain held end to end, but not which link did the work, and if it does not move you cannot tell whether the tools were not clearer or whether clarity does not convert to accuracy on that benchmark. if you can log tool call error rate separately from task success you get to see the middle of the chain instead of only its ends.
the live tool registration is the part i had not heard before. adding tools without a restart, a delta check against the cache rather than a blind cache read, and still beating node on a warm hit. and you volunteered that the initial registration run is slightly slower, which is the kind of disclosure that makes the rest of your numbers more believable rather than less.
Thanks for the refinement! My thoughts were about that, given the merkle root audit log alongside the success/errors, it would give a clean and clear reasoning to what failed when, which is about as valuable as the speed gain
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.
Honestly, this might be one of the most thoughtful replies I've gotten to one of my “about me” comments.
I hadn't actually thought about the connection between the analysis stuff and how I approach software that way, but now that you've pointed it out, I can absolutely see it. I have a pretty strong instinct to ask “why does this need to exist?” before accepting that it should exist, whether that's an abstraction, a dependency, or an entire architectural pattern.
And yeah, the “being me” answer wasn't meant to sound particularly profound. I just genuinely couldn't think of an achievement that I'd put above being comfortable with who I am. I've spent enough time comparing myself to other people to realize that it's a pretty miserable way to measure yourself. There will always be someone louder, smarter, more accomplished, or further ahead. At some point you just have to decide you're happy being your own weird little experiment.
The calculus → analysis thing is actually exactly why I've been enjoying it. Teaching calculus gave me the feeling that I understood it, and then analysis came along and basically said, “Cool. Now prove that any of this is actually true.” 😂 It's humbling in the best possible way.
Also, thank you for the kind words about teaching. I didn't appreciate how much I liked teaching until I stopped doing it. There's something pretty satisfying about watching someone go from “I have absolutely no idea what this means” to suddenly seeing the thing click.
And yes, the 110cc Smash is absolutely the MVP here. 450km sounds significantly more impressive until you remember it's a tiny Cambodian commuter bike that refuses to die. My girlfriend and I are basically just testing the limits of its willingness to suffer. 😂
As for writing, I don't know if I'm qualified to give advice, but I think the biggest thing I've learned is that I write much faster when I stop trying to “write an article” and instead just write down something I've been arguing with in my head for the past few weeks. By the time I actually sit down to write, I've usually already written half the article mentally through various internal rants.
And likewise, pleasure to meet you. Your comment definitely made me want to read more of what you write.
your writing advice is the correct one and i think it is more than a productivity tip.
writing down the thing you have been arguing with in your head for weeks is not a faster way to write an article. it is the only way to write one worth reading, because by the time you sit down the position has already survived a few rounds against your own objections. an article written from scratch is a first draft of a thought. an article written from a long internal argument is a report on something that already got tested.
which is the same instinct as your why does this need to exist question, one layer up. you apply it to abstractions and dependencies. you apply it to your own sentences too and probably do not notice.
on the comparison thing, i would only add that deciding to be happy as your own weird little experiment is not the same as lowering the bar. the people who never make that decision usually end up with a very high bar borrowed entirely from somebody else, which is a worse position than a demanding one you chose.
and analysis saying now prove any of this is actually true is the best description of the transition i have heard. that is also the exact move that separates a system that reports it ran from one that establishes what it did, which is most of what i write about. same discipline, different domain.
450km on a 110cc that refuses to die is a better story than 450km on something built for it.
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.
you just turned a question into an experiment, and i want to make it a better one before you run it, because as designed it cannot answer what you want.
the confound is that the next project is also the next project. if it stays maintainable, two explanations fit equally well: NanoScript worked, or you understood what you were building better than you did the first three times. experience keeps accumulating whether you want it to or not, and it will be sitting in the same cell as the library.
two things would separate them. write down now, before you start, what falling apart looked like in PixUp and BlockSocial. not the feeling, the specific thing: the file you stopped wanting to open, the change that took a day, the point where you started copying instead of editing. if you name it in advance you can check for that exact shape instead of judging the result by how it feels six weeks in.
and if you have the appetite, build something small without NanoScript at the same time, at your current skill level. if the plain one also stays clean, you learned it was you. that is the control arm and almost nobody builds it, because it means doing work you already believe is the worse option.
the last thing you said is the part i would keep regardless of how it comes out. you did not design Vlox to test the library, you designed it to work, and it tested the library anyway. a test written by the person who wrote the thing shares its assumptions. a real load does not care what you assumed. you got the harder evidence by accident and most people never get it on purpose.
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!
I’m Sanu Khan a Technical Architect and Engineering Lead focused on designing and delivering production platforms that are scalable, maintainable, and built around real business needs. My experience spans commerce, travel technology, enterprise systems, integrations, and AI-enabled engineering, with hands-on involvement from architecture and API design through implementation, CI/CD, deployment, and production operations.
I work closely with engineering teams to turn complex requirements into clear technical direction, define system boundaries and integration patterns, and stay involved beyond the architecture diagram to ensure solutions are actually delivered and operable in production. I also explore agentic AI, operational intelligence, and engineering automation through my own R&D work with ZaakiyV3RSE.
You can get to know more about me at sanukhan.dev
Feel free to connect and collab happy to support and grow together
good to meet you Sanu. staying involved past the architecture diagram through to production operations is the part of that description i would actually ask about, because it is the part most architects describe and fewer do.
the line i want to pull on is operational intelligence. that is close to what i spend my time on, so tell me what it means in your hands rather than in general. what does a system of yours know about its own running state that it had to be built to know, and how do you find out when that knowledge is wrong? most production platforms report that a thing ran. very few report whether the thing accomplished what it was supposed to, and the gap between those two is where every failure i publish about lives.
Good to meet you too, and I agree with that distinction. It is actually very close to how I think about operational intelligence and what I have been exploring with Zaakiy V3RSE.
At a high level, I see observability as telling me what the system is doing, while operational intelligence should help tell me whether the system is achieving what it was intended to do.
So rather than stopping at “the process executed successfully,” I am interested in giving the system enough contextual awareness to ask a second question: “Did the expected operational outcome actually happen?”
A technically successful execution can still be an operational failure. A workflow may complete, an integration may return 200, or a scheduled process may run on time, while the resulting business state is incomplete, inconsistent, delayed, or simply not what was expected.
With Zaakiy V3RSE, the direction I have been exploring is how to make that gap visible: understanding expected versus observed outcomes, identifying meaningful deviations, and providing enough context to investigate why they occurred rather than relying purely on infrastructure-level signals.
The other important part of your question is how we know when the system's own understanding is wrong. I don't think operational intelligence should be treated as an unquestionable source of truth. Its conclusions need to remain explainable and verifiable against the underlying operational evidence, with uncertainty or conflicting signals surfaced rather than hidden.
That is the area I find particularly interesting: moving from “everything ran” toward “did we actually accomplish what we intended, and what evidence supports that conclusion?”
I’d be very interested to hear how you approach that distinction in the production failures you study.
your split is the right one, and this week gave me two clean examples of it.
an agent auditor i built takes instruction text and reports authority conflicts. i gave it two lines: verify the live artifact before publishing, and publish immediately without checking. it returned low observed risk and zero conflicts. execution succeeded, outcome absent. the failure was upstream of scoring: extraction merged the two instructions into one item, leaving the conflict detector a population of one.
a nightly drift check gave me the opposite failure. after i restored the wrong revision, it reported DRIFT on all five probes even though every output hash matched the baseline, because the comparison read the wrong awk field. correct alarm shape, wrong reason.
the method i use now is to bind the expected outcome before the run, capture the resulting state rather than only the process exit, record the observed reason for the verdict, and keep not evaluated distinct from passed. but expected versus observed still has a hole: the same party can author the expectation and the instrument.
a reader in this thread supplied the sharpest example. his gate blocks users before they reach the page that records a visit. normal traffic is therefore compatible with nobody being blocked and with every targeted user being blocked. the observation process excludes the evidence needed to distinguish the outcomes.
what survives better is a claim whose validator consults evidence outside the claim. in my finding schema, cited bytes must occur exactly once in the frozen corpus file or validation throws. that does not prove the citation is relevant, but it lets the artifact disagree with the report. most of the other fields are only shape checks.
so i agree with your last paragraph. surface uncertainty and conflicting signals, but also make absence of observation structurally different from a successful observation. the local repair is intended to emit an uncovered-domain finding when no rule evaluated an instruction. it is not deployed or covered by a regression test yet, so it remains a repair under test rather than a solved control.
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.
Hi, I’m Shima
I’m a Python/Django backend developer. I spend most of my time building web applications, APIs, working with databases, and trying to make software behave reliably when the real world inevitably decides to do something unexpected :)
Outside work, I enjoy building random side projects and open-source stuff. I’ve gone from Python packages and security tools to browser extensions and Linux/GNOME applications, mostly because I tend to get curious about things and then refuse to leave them alone.
I’m also pretty interested in AI-assisted development and how AI can change the way we build and maintain software.
One thing to remember about me: if I get curious about something, there’s a good chance I’ll end up building it.
P.S. Yes, I shamelessly borrowed some of this from my LinkedIn bio :))))))))
good to meet you Shima. the range is what stands out, python packages to security tools to browser extensions to gnome applications, which is not a career path, it is a person following curiosity until the thing is built.
the security tools are the ones i would ask about. what did you build and what was it defending against? most security side projects start because somebody noticed a specific thing that bothered them, and the thing that bothered you is usually more interesting than the tool.
and the postscript is the best part of the introduction. saying you borrowed it from your linkedin is more honest than most people manage when they are trying to sound impressive. I will give you a follow on linkedin.
Thanks
I really appreciate that
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.
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? 🤣
Some comments may only be visible to logged-in visitors. Sign in to view all comments.