We build a lot of the product from Slack
This is the part people usually find strangest. We have a public Slack channel where anyone at the company, engineer or not, can ask for a virtual machine, hand it a task, and get a PR back. Screenshots, a recorded video of the feature working, the whole thing.
About half the people using it aren't engineers. A product manager wants a rough prototype to show a customer. A lawyer wants to know how usage of a specific feature changed last quarter. Someone in support running root cause analysis and even getting bugs fixed rather than filing a ticket and waiting.
It's not a replacement for normal development. When you're building something substantial you still want your own machine, your own back and forth with the model, the ability to read the code properly. But for bug fixing, root cause analysis, and quick prototyping, it transforms how fast we move..
Guardrails matter more than they used to
The obvious worry with all this is quality. If you let AI write that much code that quickly, you can end up with the new industry term, "AI slop” code that technically works but nobody understands or trusts.
The fix is investing properly in the guidelines the AI is working from. We keep a written library of architectural rules, how layers should talk to each other, what every endpoint needs to check, how we model data, and we use that same library for both generating code and reviewing it. When a human pushes back on a PR for a reason that wasn't already written down, that feedback gets folded back into the guidelines. The rules keep getting sharper. A human still always makes the final call on whether something merges.
The debates haven't gone away either. If anything we have more of them, just in a different place. Less arguing on individual pull requests, more sitting down properly to agree on architecture and then writing it into the system so it sticks.
The team doesn't look like a normal engineering team
At Meta, I managed teams built on a pyramid. A senior tech lead, a handful of mid-level engineers producing most of the code, and junior engineers learning the ropes. That structure made sense when the bottleneck was writing code.
At Wordsmith we didn't build it that way. We hire “senior hackers” - people who are both experienced and excited to build & learn. Not because junior engineers can't use AI, but because the job has changed. You need people who can use AI well and also know exactly when not to trust it. That judgement is the actual skill now. You can't get it from a few years of experience, normally you need more like seven or eight.
The upside is that I barely need to manage anyone day to day. People are self-driven, and I'm still writing code myself more than half the week, which I didn't expect to still be true at this stage of the company. The downside is that we've lost some of the natural training ground that junior engineers used to get and some of the joy that came with mentoring them. We're still figuring out the right answer to that one.
The bottleneck has moved, and we haven't solved the new one
This is probably the most honest thing I said on the podcast. Writing code used to be the slow part. It isn't anymore. Now the slow part is checking the code, working out whether what got produced is right, whether it's the right thing to have built at all.
We've made real progress on output. Lines of code, PRs shipped, all up significantly on where we were before agentic tooling. Prototyping is faster too, which matters a lot in legal tech specifically, because it means we can show a lawyer something real instead of describing a feature and hoping we understood the brief.
But validation is the open problem right now. AI can produce a lot, fast. Working out whether it should have, and catching the parts it got subtly wrong, still takes real human time. I don't think anyone in the industry has properly solved this yet. We're working on it, and I'd guess most serious engineering teams are too.
If you want the full conversation, including the bits about why in-house legal teams ended up so far behind on technology and what that means for the next few years, the episode is linked below.
If you are hungry to learn, build & contribute to one of the best engineering teams in the world, learn more about open positions within our R&D team here
