AI is changing how software gets built. At Flo, we’re not just moving faster with AI, we’re being intentional about how we move faster.
Over the past year, we’ve committed to becoming an AI-first engineering organization. That doesn’t mean replacing engineers with AI. It means rethinking how humans and machines work together to build better products faster, more consistently, and more thoughtfully.
The result? A meaningful shift in how we design, build, and deliver software to our customers—especially in areas like performance reviews, where quality, trust, and nuance matter most.
To go deeper, we spoke with Robert Tester, VP of Engineering at Flo, about what AI-first actually looks like in practice.
What does “AI-first engineering” actually mean at Flo?
At its core, it’s about dramatically increasing what each engineer can accomplish.
In an AI-first environment, humans focus on judgment, system design, and product thinking, while AI handles a large portion of the implementation work: coding, documentation, and even testing.
The goal isn’t to replace engineers. It’s to give them leverage.
How much of your development is actually using AI today?
At this point, it’s nearly everything.
Roughly 95% of the code written in our products is generated with AI assistance. That number has increased quickly as the team saw how effective these tools are.
But what’s more important is how that code gets created. Engineers are spending far more time designing and planning and far less time coding.
What changed in how engineers work day-to-day?
The biggest shift is upstream.
Engineers now spend much more time:
- Defining the problem
- Writing detailed specifications
- Thinking through architecture
- Planning implementation before any code is written
Because the more precise the instructions are, the better the AI performs.
At the same time, engineers are still heavily involved in reviewing and validating outputs. We don’t assume the AI is always right—so the role has evolved into both designer and reviewer.
That sounds like a big shift. How do you make that work at scale?
We’ve grounded our approach in five core principles that guide how we use AI across engineering.
What are those principles?
1. Humans Design, AI Builds
Engineers define what needs to be built and how. AI handles the heavy lifting of implementation. This lets us focus on solving the right problems, not just writing code.
2. Standardization Over Chaos
We’ve standardized the tools and workflows we use so the team can build expertise and maintain consistency across the codebase.
3. Constrained Intelligence
AI performs best with clear rules. We encode our architecture, conventions, and best practices so AI operates within the same guardrails as experienced engineers.
4. Measurement Over Intuition
We track metrics like cycle time, output, and system reliability to ensure AI is actually improving performance—not just feeling faster.
5. Shared Intelligence
When one engineer figures something out, the whole team benefits. We capture those learnings and make them reusable across the organization.
What, if any, are the tradeoffs of using AI in development?
AI dramatically speeds up implementation.
Tasks that used to require digging through the codebase or documentation can now happen much faster. Engineers don’t need to spend as much time searching for where to make changes or how to use third-party tools.
There isn’t really a tradeoff for using AI, but it does dramatically change the way we work.
What risks were considered as AI was implemented at Flo?
Initially, I was skeptical about whether AI could really understand a complex codebase and make the right changes.
What surprised me is how effectively it can identify where to work and help plan changes before we even start coding.
That said, there are still risks. AI can:
- Choose patterns that don’t match best practices
- Make assumptions when context is unclear
That’s why guardrails, testing, and code reviews are so critical.
How do you manage quality, bias, or “hallucinations” in the code?
It comes down to structure and oversight.
We mitigate risk by:
- Defining clear rules and conventions for the AI to follow
- Using architecture documentation to guide outputs
- Relying on strong testing and CI processes
- Keeping humans accountable for reviewing everything
AI is very good at completing tasks, but it doesn’t always choose the best approach. Our job is to ensure it operates within the right boundaries.
How does this internal shift translate into customer value?
The biggest impact is speed and scale.
We’re delivering more, faster, without needing to dramatically increase team size. In fact, we’ve seen around a 40% increase in output compared to a year ago.
That translates directly into faster feature delivery and more innovation for our customers.
Where are customers seeing the impact of AI in the product itself?
We’re applying AI in very practical, targeted ways across our products.
For example:
- Performance management summaries that synthesize large volumes of feedback
- Resume parsing that actually works
- Candidate deduplication across systems
The focus is always on shortening workflows and making processes more efficient while not just adding AI for the sake of it.
Legal organizations are cautious about AI. How are you addressing security concerns?
This is non-negotiable for us.
We do not use customer data to train models, and all AI interactions are stateless, which means we only pass the specific data needed for a given task and nothing more .
Our customers’ data is protected at the same level it always has been.
Final question: what does “AI-first” look like for Flo long term?
It’s not about automation for its own sake.
It’s about building a system where:
- Engineers operate with more leverage
- Products evolve faster
- And customers get better outcomes
But we’re doing that thoughtfully, keeping humans in control, maintaining high standards, and ensuring trust at every step.
Because in the end, the goal isn’t just to build faster.
It’s to build better.
--
To learn more about how AI is used in Flo across our platform, reach out.
