I did have an initial key insight which led to a repeatable strategy to ensure a high level of fidelity between DTU vs. the official canonical SaaS services:
Use the top popular publicly available reference SDK client libraries as compatibility targets, with the goal always being 100% compatibility.
You've also zeroed in on how challenging this was: I started this back in August 2025 (as one of many projects, at any time we're each juggling 3-8 projects) with only Sonnet 3.5. Much of the work was still very unglamorous, but feasible. Especially Slack, in some ways Slack was more challenging to get right than all of G-Suite (!).
Now I'm part way through reimplementing the entire DTU in Rust (v1 was in Go) and with gpt-5.2 for planning and gpt-5.3-codex for execution it's significantly less human effort.
IMO the most novel part to this story is Navan's Attractor and corresponding NLSpec. Feed in a good Definition-of-Done and it'll bounce around between nodes until it gets it right. There are already several working implementations in less than 24 hours since it was released, one of which is even open source [0].
I'm testing a theory that large-scale (LoC) generated projects in Rust tend to have fewer functional bugs compared to e.g. Go or Java because Rust as a language is a little stricter.
I've not yet formed a full opinion or conclusion, but in general I'm starting to prefer Rust.
Re: generalizing mocks, it sounds interesting but after getting full-fidelity clones of so many multi-billion dollar SaaS offerings, I really like it and am hooked. It pays nice dividends for developing using agentic coders at high scale. In a few more model releases having your own exhaustive DTU could become trivial.
This one's a bit clever in that it actually comments back.
I feel like I've been pointing them out too much lately so I wanted to wait until somebody else did first.
They all seem to take advantage of accounts that are a few years old with zero posts and then suddenly make a bunch of AI-generated comments on a single day, like this one did (account from 2023, no posts until today.)
The last bot I pointed out that did the same thing ended up having its "owner" make a post about it that didn't get any attention:
What would be great, and I don't know if @dang / the mods would take on requests like this, would be for bot participants to be allowed but the account flagged. So e.g. the user name just says "[bot] Zakodiac" or something.
As well as being an ethical approach - I think it's wrong to try to impersonate humans and/or not announce AI output as AI - it would also be handy for new filter options: all bot posts are OK, hide bot leaf comments, or hide all threads with bot comments. etc.
[edited as my robot unicode/emoji char didn't come through]
Comments like "X is the right track [...] Then finish with a question?" do have a bit of an LLM smell to them.
The finishing with a question thing is prevalent with both accounts on Twitter, presumably because it "drives engagement" with the accounts.
It's particularly frustrating because it amplifies how much time is wasted - people don't just waste time reading comments by bots, they then invest effort in thinking about and replying to them.
> The Go to Rust rewrite is interesting - was that driven by performance or more about the ecosystem/tooling for this kind of work?
I'm testing a theory that large-scale (LoC) generated projects in Rust tend to have fewer functional bugs compared to e.g. Go or Java because Rust as a language is a little stricter.
I've not yet formed a full opinion or conclusion, but in general I'm starting to prefer Rust.
Re: generalizing mocks, it sounds interesting but after getting full-fidelity clones of so many multi-billion dollar SaaS offerings, I really like it and am hooked. It pays nice dividends for developing using agentic coders at high scale. In a few more model releases having your own exhaustive DTU could become trivial.
> The tradeoff is LLMs still struggle to produce good idiomatic Rust consistently so it takes more iteration cycles to get there (good agent tooling helps, linting/checks/etc.) The compile times on those iterations can be brutal sometimes depending on the project size which adds up for sure. The crafty agents can still find ways to satisfy the compiler without actually solving the problem correctly too, so the cheating risk of course doesn't fully go away.
I’ve gone ahead and completely banned ‘unwrap_or_default’ and a bunch of other helpful functions because LLMs just cannot be trusted to use them properly.
This is great feedback, appreciate you taking the time to post it. I will set some agents loose on optimization / purification passes over CXDB and see which of these gaps they are able to discover and address.
We only chose to open source this over the past few days so it hasn't received the full potential of technical optimization and correction. Human expertise can currently beat the models in general, though the gap seems to be shrinking with each new provider release.
I'm one of the StrongDM trio behind this tenet. The core claim is simple: it's easy to spend $1k/day on tokens, but hard (even with three people) to do it in a way that stays reliably productive.
By default it runs in docker, and also includes an extra sophisticated macOS-native --darwin mode which goes beyond the capabilities and guarantees of the likes of sandbox-exe, bubblewrap, and in some ways docker. Leash provides visibility into and control over every command and network request attempted by the coder agent. Would appreciate any feedback, and will try to get in touch with the author (Gordon).
Now I'll definitely look into automatically supporting pass-through auth for at least gh cli in Leash - always looking for what folks will find useful.
X-Mouse Button Control (XMBC for short) is a handy Windows app to override mouse buttons to do arbitrary other actions on a program/App -specific basis.
However the docs (which are excellent!) were published by the developer as PDF-only, so I did a nice transform to HTML and posted it on my personal website. I will do my best to host it until I'm dead, and also submitted it to TIA:
I did have an initial key insight which led to a repeatable strategy to ensure a high level of fidelity between DTU vs. the official canonical SaaS services:
Use the top popular publicly available reference SDK client libraries as compatibility targets, with the goal always being 100% compatibility.
You've also zeroed in on how challenging this was: I started this back in August 2025 (as one of many projects, at any time we're each juggling 3-8 projects) with only Sonnet 3.5. Much of the work was still very unglamorous, but feasible. Especially Slack, in some ways Slack was more challenging to get right than all of G-Suite (!).
Now I'm part way through reimplementing the entire DTU in Rust (v1 was in Go) and with gpt-5.2 for planning and gpt-5.3-codex for execution it's significantly less human effort.
IMO the most novel part to this story is Navan's Attractor and corresponding NLSpec. Feed in a good Definition-of-Done and it'll bounce around between nodes until it gets it right. There are already several working implementations in less than 24 hours since it was released, one of which is even open source [0].
[0] https://github.com/danshapiro/kilroy
reply