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
