Nick and Zack from WorkOS @ AIE: building real-world AI tools & running conference workshops
Nick Nisi and Zack Proser from WorkOS on feeding biometric data into Claude so it can push back on you, why Zack hasn't written a line of code himself since a hotel-lobby workshop build last year, and why their AI Engineer workshops deliberately avoid pitching WorkOS at all.
Recorded at AI Engineer Europe in London, this is a conversation with Nick Nisi and Zack Proser from WorkOS, who've spent the last year running some of the most hands-on AI engineering workshops on the conference circuit.
We get into "developer balance" — including Zack's habit of piping his Oura biometric data into Claude so it can tell him he's too sleep-deprived to make a good decision — the skills they've found most useful day to day, how agent identity and auth are evolving, and their philosophy for running a workshop that teaches rather than pitches.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
You've been doing a lot of workshops and building real AI tools. What have you been excited to share at the conference?
These tools are sort of nuclear now — it's incredible how fast you can go, especially once you have certain dev patterns in your brain and the agents are doing the typing for you. There's almost a temptation to just keep stacking more and more loops endlessly and go faster and faster. So what I've been thinking about is developer balance — how do you get all the key work done without burning yourself out faster than ever before. One trick: I feed my biometric data from Oura and other things into my LLMs, so the same interface I use to develop all week is aware of my projects and will push back and say, "that sounds great, but you also slept three hours last night." I don't always listen to Claude, but it's enough of a nudge to make me think about it.
Does that actually change how you work day to day?
It's an evolving thing, but yes — the other side of it is, can we get the same amount of quality work done while spending less time at the desk? With voice-first mode I can hit 184 words a minute instead of 90 typing, so does that afford a two-hour walk in the woods, or at lunch? Some days it does. And especially with remote control on Claude now, you can still poke at the code as it comes in and direct your agents — "that's not quite what I meant, do this piece differently" — without being at a keyboard the whole time.
You gave a workshop on Mastra at this same conference about a year ago. How has the way you work changed since then?
That workshop was really the start of this for us. Building it, Claude was very instrumental in getting it done on time — it may or may not have been finished in the hotel lobby the night before. That was a real proving point: we did it in such a short amount of time, and the quality was still there. We described the thing we needed — separate git branches for each step of the workshop, so if you fell behind you could just check out the next branch — to Claude, and it did it. This wasn't even Claude 4, this was 3.7 or whatever it was back then. It just worked every time, and I left that workshop realizing I wasn't going to be writing code by myself anymore. I don't think I've written a line of code alone since.
What skills have you found most useful day to day?
Image generation is huge — not just for mockups and diagrams, but for fun too, pixel art, adding color to a blog post. There's also an ideation skill that's proven really valuable: if you're starting something large, like an architectural refactor or a new project, it internalizes a kind of certainty score and keeps asking you questions to clear up the fog of war until it has a clear picture, then says "now I'm clear enough to begin implementation." It has an internal rubric with a confidence score across a few different points, and if the confidence isn't above 95% on either what you're asking for or whether it's actually possible, it just keeps asking questions until it gets there. You can start with a single sentence — "I want to do this" — instead of needing the foresight to write a whole monologue up front, and it extracts the information out of you through questions. Once it's confident, it writes a human-readable contract you can review and iterate on before it starts working from specs, broken into phases so you're not carrying 300,000 tokens of context the whole way through. There's also a skill-builder skill that can scan a week's worth of a developer's messages in Claude, look for patterns — where were the inefficiencies, what did you have to re-explain over and over — and turn those into discrete, reusable units of work that get published and shared with the rest of the team.
You work on MCP and auth — how is auth evolving as agents need to act on users' behalf, say with Gmail?
There's a really wide gamut right now — everywhere from people insanely experimenting, opening up Claude and granting it access to their Gmail account and CLI tools because they don't really care, all the way up to mature, machine-to-machine systems that are starting to come online. That's something we're actively working on at WorkOS — agent identity, and how that works. We have all the pieces; it's a question of how you assemble them in a way that works best for agents and users. In practice, once I connected Slack, Linear, and Notion into the Claude desktop app through our IT department's connectors, I could paste a Slack thread into Claude Code and it would know where to go, search Notion, pull the full context — it made it feel like magic, and I desperately miss it when I'm using a different tool. Slack specifically was the thing causing me the worst context-switch penalty, since that's where asks and bug reports come in. Once that loop was complete, I could stay in focus mode, have Claude check Slack every ten or fifteen minutes, and turn anything that wasn't already a Linear ticket into one — without alt-tabbing thirty times to fix one ticket. On one project with a Slack bot component, Claude had the full tool loop it needed: post its own test message to trigger the bug, verify by reading the result, and mark it done.
What about permissions specifically — sending an email could be pretty destructive. Are you seeing good patterns there?
I do it myself the dangerous way, honestly, just to live it out and get the scar tissue. But it's possible now to install an auth kit and an MCP server and get really granular — this tool needs permission, this tool doesn't. The developer experience there still has miles to go, but it's something we're actively working on. We have an MCP tool that helps with this — it gives you short-lived sessions, short-lived tokens you can use to get third-party data into your app more securely. It's out now, and we're actively improving it and adding new connectors. Once that's online with a few more pieces, I think we'll have a coherent experience where you can develop from an agent-first perspective.
What actually makes a workshop good?
Focus on the content — what are you actually trying to teach — and tell a complete story, because the narrative is how people remember it and have fun with it. One thing we learned from last year's workshop versus this one: think about the actual recorded output, not just the room. Last year we had dead air during hands-on working sections, which is fine live but not great to watch back. So this time, whenever there was a working section, we also had a list of topics on the other side of the slide that we could just talk about while people worked — things we're passionate about, or we could take audience questions. The first break we did that, we ended up doing nothing but answering questions, entirely audience-led, mics passed around — it was fantastic. We also always provide GitHub resources in advance, free and open source, so people can get started early, and we build in checkpoints so if you arrive late or get stuck, you can jump to any point and see it actually working — it's not hand-waving, you can run it yourself.
This workshop was about skills, not really about WorkOS as a product. Why run it that way?
Most people go to a workshop and it's "I work for XYZ, here's how to use XYZ," and people are allergic to that. What we did this time was built out of the actual day-to-day work Zack and I do, and that everyone at WorkOS does — it's really just us sharing our knowledge and our excitement about it. We had one slide that showed the WorkOS logo and mentioned we're hiring, and then we moved on to just having fun doing the stuff we love as developers and teachers. We get a lot of leeway at WorkOS to design these on our own terms, often on the plane over, and it comes out well because it's coming from a place of genuine developer joy rather than selling the whole time. If you're saying useful things, people become curious about what you're building on their own — you don't have to lead with the pitch.
You haven't been able to catch many talks here — what are you excited about in AI engineering right now?
Harness engineering has been a fascination of mine for the last couple of months — building something that tries to be me and do the work the way I would. It focuses on two things I think are underused and important: prove to me, without me having to read the code, that you did the work I expected — real evidence — and do a retrospective on yourself afterward. Have memory, understand what you did right and wrong, notice if you made redundant tool calls and fix that, and write it down. My tool runs a retrospective after everything it does and creates memory files, and it also prunes them as things become less relevant, so it stays focused and gets better every time I use it, and I can guide it too.
Links & references
- Zack Proser's LinkedIn ↗
- Zack Proser's site ↗
- Nick Nisi's LinkedIn ↗
- WorkOS ↗
- AI Engineer Europe ↗
- Oura ↗
- Mastra ↗
- Claude ↗
- Linear ↗
- Notion ↗
- Model Context Protocol ↗
This episode is brought to you by WorkOS.