July 16, 2025
When I meet with founders and engineering leaders, I naturally get asked lots of questions about the types of automated tests that their team should be writing and how AI applications can help.
The buzz makes sense. We're at an inflection point when it comes to AI adoption, with hot companies like Intercom, Shopify, and Duolingo announcing mandates to go AI-first.
When I dig deeper into these engineering leaders' needs, it usually becomes clear that the more important question that they should be asking is: how do I build a quality-first culture into my software development lifecycle?
To be clear, these are top 1% engineers I am speaking to. Some are heading Engineering at unicorn companies, and others are technical founders backed by the likes of Y Combinator, General Catalyst, and Initialized Capital.
The reason these questions still crop up is that enforcing quality-first engineering is much less of a technical problem than it is a people and process management problem.
I've done my best to distill the top advice I've given during these discovery meetings into actionable items.
One thing that Dalton Caldwell, former Managing Director at Y Combinator and now Co-Founder & Partner at Standard Capital, regularly stresses to startup founders is that you must know the minigame that you're currently playing.
Imagine you're playing The Legend of Zelda, and you've just started a new save file. You enter the first dungeon and are immediately introduced to puzzle-solving mechanics like lighting torches or using a slingshot to open doors. Awesome, you now know that's possible.
As you progress through the temples, you start recognizing patterns for success. If there’s a big eye on a monster, shoot an arrow at it. If there’s a cracked wall, blow it up. Suspicious floor switch? Find something heavy to hold it down.
The game teaches you these patterns gradually, then expects you to recognize and apply them in increasingly complex combinations. What starts as "shoot the eye" becomes "shoot the eye, then quickly roll under the closing gate, push the block onto the switch, and light the torch before the timer runs out."
The startup game is similar. Knowing your current minigame allows you to make better decisions around automated testing.
When we were going through YC, one helpful advice we received was that you earn the right to deal with tech debt. Code is cheap at this stage, and should be written without hesitation to throw away later.
At the startup stage, your primary minigame is finding product-market fit. Everything else is secondary.
You're moving fast, iterating constantly, and quite frankly, some features you build today may not exist six months from now. Your codebase is small enough that a single engineer can hold most of it in their head, and when something breaks, you can usually trace it back to a recent change within minutes.
Some solutions we’ve seen startups implement successfully:
Your time is generally still better spent talking to customers and shipping features. The cost of a production bug at this stage is relatively low. You have a small user base, and they're likely early adopters who are more forgiving of rough edges.
That said, there are still critical paths in your application that warrant basic test coverage. For example, your authentication system, payment processing, and core business logic should have some safety nets.
Once you've found product-market fit and are scaling your team beyond 15 engineers, the minigame changes completely.
The goal is now to achieve sustainable growth rather than optimizing for pure speed. This is when automated testing transitions from a nice-to-have to a business requirement.
The challenge is that retroactively adding comprehensive test coverage to an existing codebase is incredibly time-intensive. Your engineers are already stretched thin shipping new features, and asking them to pause development to write unit tests for existing code creates a productivity bottleneck.
This is the problem we built Tusk to solve. Instead of pulling engineers away from feature development, Tusk automatically generates unit tests on every PR through your CI pipeline. We've seen teams like TeamFeePay increase their test coverage by 30% in just 3 weeks by implementing this form of the Boy Scout Rule.
The key insight is that at the growth stage, you need test coverage that scales with your team and codebase growth. Manual test writing doesn't scale. AI-powered test generation does.
When you're operating at enterprise scale, the minigame shifts once again. It’s no longer just growth. You're also putting a premium on software reliability.
The enterprise minigame is about systematic risk reduction. At this stage, production bugs aren't just inconvenient; they can cost millions of dollars. Some real concerns we've experienced from talking to engineering teams at this stage:
Enterprise organizations typically have dedicated QA teams and a Platform Engineering team to maintain testing infrastructure. However, without a quality-first engineering culture, manual test coverage can be difficult to enforce across teams and services.
Moreover, you need guardrails to catch edge cases and integration issues that human engineers might miss in their PRs. And you need to implement these quality gates without slowing down your engineering teams.
This is where AI-powered solutions like Tusk become force multipliers. Companies like DeepLearning.AI have used Tusk to prevent edge case bugs in 43% of their PRs, catching critical regressions that are 1) time-intensive to identify, and 2) expensive to fix in production.
At enterprise scale, the ROI calculation is clear: the cost of comprehensive AI-generated testing is orders of magnitude lower than the potential cost of production incidents, especially when you factor in regulatory compliance, customer trust, and brand reputation.
The common thread across all these stages is that the best time to implement automated testing is earlier than you think.
Startups should focus on testing critical paths. Growth-stage companies should implement comprehensive coverage before technical debt becomes unmanageable. Enterprise companies should treat testing as a non-negotiable part of their SDLC.
The important thing is to match your testing approach to your minigame. Don't let perfect be the enemy of good, but also don't let good be the enemy of necessary.
Whether you're a three-person startup or a thousand-person engineering organization, the question isn't whether you need automated testing. It's about how to implement these quality gates in a way that accelerates rather than hinders you from achieving your current objectives.
When I chat with engineering leaders today, I try to meet them where they are and be candid about what they actually need right now. At the same time, I impress upon them the world we’re moving towards––one where AI practically eliminates all the manual overhead that make testing feel like a chore.
In this new world, AI testing platforms will embedded in tech stacks from the beginning, and then scale seamlessly with your needs. I guess then the title of this post is a trick puzzle of its own, and it really is more aptly titled “How to Implement Automated Testing.”
---
Ready to see how AI-powered test generation can fit into your current development workflow? Book a demo to learn how Tusk can help your team hit your code coverage goals and prevent regressions without slowing down your release cycle.
