
In 2000, Joel Spolsky published his famous "Joel Test" - a simple 12-point checklist for evaluating the quality of a software team. One of the key points was "Do you use the best tools money can buy?" As Joel noted, even minor frustrations from underpowered tools add up, making programmers grumpy (guilty here) and unproductive. In 2025, this principle remains as relevant as ever, but the landscape of "best tools" has dramatically evolved. Weʼve seen tools like Rider compete with Visual Studio, Microsoft .NET become platform agnostic allowing developers to use Mac or Windows, and now even more change with the emergence of AI.
At Empower, we've embraced AI not just for code generation (which has been widely discussed), but across our entire development lifecycle. Our CTO and cofounder Justin Ammerlaan has started an internal AI Ambassadors group. This group consists of at least one person from every aspect of the business— Data Science, Backend, Web, iOS, Android and more. We have been tasked with evaluating a wide range of tools, and more importantly monitoring how AI is being used across teams and sharing those learnings early and often with our own teams to increase adoption.One example of using the best tools has been our early partnership with Factory, where we served as a beta partner for both their Review Droid and Assembly products. This early adoption and close partnership has allowed us to provided early stage feedback on these tools to better serve our engineering needs, while giving us a head start in integrating AI across our development workflow.
On-Call Support: From Exception to Investigation
For engineers, of the most impactful ways we've integrated AI is in our on-call incident response process. Almost 100% of engineers will tell you they’re at least slightly nervous when on call, or they’ll lie to you— the outliers are either superhuman or just haven’t been on “that one outage call” which you’ll remember for years to come.
Now, unless it’s a familiar issue, the first thing I do is review our internal run books. If those are not satisfactory, the next step is a prompt such as the following:

This has significantly reduced the time to resolution and made both my on-call duties as well as assisting with unblocking release issues less stressful.
QA Engineers: Understanding Impact at a Glance
Our QA engineers have found a particularly powerful use case: rapid impact analysis of a change and it’s impact across multiple platforms. Historically our QA team has been challenged with timezones, where a USA developer pushes code and someone working Melbourne time picks it up for testing. Minor gaps in understanding lead to a 24 hour delay. With Factory, the team is now empowered with prompts such as the following

This generally provides a high level executive summary of what has changed. Sometimes you’ll learn it’s a logging only change or change such as creating a new database table that isn’t referenced yet. Other times you’ll learn this change has a larger impact.

This type of prompt is where Factory really shines. We’ve found it extremely useful to trace backend code all the way through client side screens, including older areas of the code base that aren’t always front of mind.
Product Managers: From Questions to Clarity
Beyond our engineering team’s use of Factory, one of the most exciting applications of Factory is helping Product Managers understand complex technical systems.
Instead of scheduling multiple meetings which interrupt developer productivity or diving into codebases they might not be familiar with, PMs can now:
- Ask natural language questions about how specific features work
- Generate flowcharts to visualize user journeys and system interactions
- Get quick explanations of technical decisions and their business implications
This capability has dramatically increased productivity in product development discussions and helped bridge the gap between technical and non-technical team members.
Last, when Factory cannot get a satisfactory answer, you can prompt it for a clean handoff.

Automated Code Review: The Power of the Review Droid
Factory’s second product, the Review Droid is a simple yet powerful tool. Essentially how it works is you add a droid.yaml file in your repository, then provide natural language prompts that get run against every pull request.
Through our early partnership with Factory, we've been able to fine-tune our .droid.yaml configuration to create a powerful automated review system. Our experience as a beta partner has helped shape the tool's capabilities, and we've implemented several custom checks that have since become common patterns for other teams. Some key checks we've implemented include:
- Enforcing our coding standards such as file-scoped namespaces for new C# files
- Validating that Entity Framework queries include necessary navigation properties
- Checking that strings in database schemas use appropriate varchar limits
- Ensuring proper implementation of our internal IHaveCreatedAt and IHaveUpdatedAt interfaces so that timestamps in the database get populated automatically
This automated review process helps us maintain code quality standards while staying true to our mission to rapidly work towards making our app better for our customers every day.
Catch and correct any obvious bugs in the code that would cause the code to not function as intended.
This simple command has caught numerous small bugs. One example to help visualize the power of this is if you had the following log message, the droid would quickly catch the mismatch between variant and name. These types of bugs are easy to miss with a human eye, but the review droid does a fantastic job.
_logger.LogInformation("Assigned {name} to experiment variant {variant}", variant, name);
The Evolution of "Best Tools"
Reflecting back on the Joel Test's principle of using the best tools, it's fascinating to see how the industry has redefined what "best" means over 24 years. In my early dev career, the Joel Test was talked about most often with hardware— almost everything chuuuugggeed using Visual Studio + Rider. Now the scales are tipping back to software, with even a several year old Macbook Pro M1 being a best of a dev machine.
It’s important that companies focus on enabling their development teams to do their best work. I’m excited to see Empower’s continued dedication to this.
Looking Forward
As one of Factory's early partners, we've seen firsthand how rapidly AI tools can evolve and improve. Our experience has shown that early adoption and active participation in shaping these tools can provide significant competitive advantages. The key lesson I've learned is that AI's value extends far beyond code generation and it’s not about replacing people - it's about enhancing human capabilities across all aspects of software development so that worker productivity increases.
The best tools are those that make teams more effective, and in 2025, that increasingly means tools that can think alongside us, helping to bridge gaps in understanding and automate routine cognitive tasks. Joel Spolsky's principle remains true - we should use the best tools available. The difference is that today's best tools are smarter than ever before.