We're an AI-First Company. Here's What That Actually Looks Like.

Anyone can say they're an AI-first company. We wanted to prove it.

At our recent company offsite, we carved out time for something we'd never done before: a company-wide hackathon where every function put down their regular work and picked up an AI tool. Engineers paired with ops. Product worked alongside customer success. Security sat next to people. No lengthy planning cycles, no waiting on resources. Just an idea, a few hours, and a chance to find out which ones had real legs.

AI-First Isn't an Engineering Strategy. It's a Company Strategy.

The conventional wisdom is that AI speeds up developers. Write code faster, ship more, reduce the backlog.

What our hackathon made clear is that AI unlocks a different kind of thinking at every level of a company. When someone in ops can prototype a tool they've always wanted in an afternoon, or a people manager can build a practice environment for their team without filing a ticket, the whole organization starts asking better questions about what's possible. Ideas stop waiting in queues. Assumptions get tested.

That's what we're building toward at Laurel, and the offsite was our chance to stress-test it.

What Teams Explored

The goal of the hackathon wasn't to ship. It was to learn. Teams built working prototypes using Claude, Devin, Dust, and other AI tools, not to fast-track anything to production, but to develop real intuitions about what AI can and can't do in their domain and to surface the ideas worth investing in properly. Some of the most interesting work came out of people collaborating outside their usual lanes.

A sample of what came out of it:

Distributing Excellence Across the Company -- Our Chief Product Officer has been sitting with a challenge for a while: how do you take the workflows your best people have developed and make them available to everyone? Her answer was what she called a "Company OS," a structured, AI-ready repository of Laurel's culture docs, product strategy, and function-specific playbooks, each shaped by how we actually operate. "For AI workflows to be really effective, you have to give it a lot of context," she said. "The question is: how do you take the people who are top 1% in a certain workflow and replicate it so that all of us have that workflow?" Her vision for what comes next: that every person who joins Laurel pulls down the Company OS the way an engineer clones a repo. "I want everyone to onboard like an engineer," she said. The concept is now informing how we think about knowledge sharing and talent development across every function.

Rethinking the Engineering Lifecycle -- Tristan Saldanha explored what it would look like to put an AI agent in the middle of the development workflow: picking up a Linear ticket, drafting an implementation plan, opening a pull request, and iterating on code review, with an engineer reviewing at each checkpoint rather than driving every step. The prototype gave the team a much sharper picture of where human judgment is irreplaceable and where the scaffolding work can be handed off. It's directly shaping how we think about what it means to build as an AI-native team, something CTO Jason Li has been focused on across the engineering organization.

AI Agents Working Overnight -- John Fiedler built a prompt library paired with a scheduling system so that AI agents run quality checks, security scans, and end-to-end tests automatically while the team sleeps. His framing stuck with everyone who heard it: bots can be productive at 3am. The prototype was built with input from across engineering and security, and it opens up a real question about how much routine oversight work can be handed off to agents running on a continuous loop.

An On-Call Incident Agent -- Jacob Dodd and teammates, working with people across infrastructure and reliability, prototyped Rocket, an AI agent that fires when a production incident opens. It assesses which services are affected, surfaces potential root causes, and posts a structured summary to the incident channel, giving the on-call engineer a meaningful head start. The prototype helped the team identify exactly where automation adds the most value in incident response and where human judgment remains essential.

None of these prototypes ships directly into our product. The value is in the clarity of thinking they produce, and in the conversations that start when someone from a different function sees what's possible and asks: why can't we do that here?

The Bigger Picture

What stood out most wasn't any individual project. It was a pattern across every team: people were asking better questions about their work than they had before. What would it look like if this didn't require a ticket? What's the part of this workflow that actually requires my judgment, and what's just overhead?

Our Chief Product Officer put it well: "How do we take the learning in one corner of our company and push it out to the entire organization?" The Company OS is one answer. So is every conversation that started at the hackathon and is now showing up in how teams approach their work.

That's what an AI-native company actually looks like. Not a handful of engineers running experiments, but an entire organization developing better instincts together.

Speed Compounds

Building fast changes how you think. When you can test an idea the same day you have it, you stop waiting for the perfect plan or the right resourcing moment. You build, you see what works, and you improve it before the energy in the room has a chance to fade.

That's not just a cultural perk. It's a compounding advantage. The organizations that build the habit of moving from insight to output faster than their competitors will consistently outlearn them, and in a market where AI is raising the speed limit for everyone, the ones building that muscle now will define what comes next.

At Laurel, we're building that muscle, not just in our product but in how we work every day.

What Comes Next

The hackathon was a starting point, not a finish line. The ideas that surfaced are now feeding into how we think about our roadmap, our tooling, and our ways of working. The real output isn't any prototype. It's sharper thinking across the team about what we want to build and why.

We'll run more sessions like this. When you see what a team can learn in a few hours with the right energy, you don't go back.

‍