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.
I'm thinking about the same things and landed on Rust. I think we're at a very critical point in software development and would love to chat with you and share/learn ideas. Please let me know if you're interested.
> 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 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.
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