Four questions to ask Andy on day one
Start with a few read-only questions. Within minutes you'll know whether Andy actually understands your system.
Meet Andy
Andy is an AI teammate for product teams. It lives in your Slack and understands your code, your tickets and the conversations that led to them.
Mention it in a thread and it reads the repo, checks the backlog and proposes a plan. Once you approve, it builds the change and opens a PR. Every step stays in the same thread.
We built Andy around one observation: everyone on the team now has their own AI, yet the team as a whole isn’t much faster. Every handoff still means someone re-explaining the context. Andy works in the thread the whole team shares, so context travels with the work instead of staying stuck in one person’s chat window.
People decide. Andy executes.
Day one: start with questions
Many teams hand Andy a big job on the first day: “build this whole feature.” That can work, but it isn’t the best way to get to know a new teammate.
We suggest starting with a few read-only questions instead. No code gets touched, but within minutes you’ll know whether Andy actually understands your system.
Here are the four we recommend starting with.
1. “What does each of these repos do?”
For you: Whether you’re joining a new project or onboarding onto a new team, the first days go to figuring out how things work today. Andy reads the code itself, not a README that may be years out of date, so you get the system as it actually is. It’s also the quickest way to check whether Andy really understands your project.
For the team: Senior engineers stop getting pulled away to explain what a repo is for.
In practice: An engineer at one of our customers joined a new project with more than a dozen repos. Instead of booking an afternoon with a colleague, they had Andy walk them through the repos and knew where to start the same day.
2. “Can our code support this?”
For you: While a feature is still under discussion, you need an answer grounded in the code, not a “probably” or an estimate that arrives three days later.
For the team: The PM and the engineering lead read the same analysis in the same thread, so they’re debating the same facts. Feasibility stops being a call inside one engineer’s head and becomes something everyone can see.
In practice: We wanted paying customers to be able to upgrade and downgrade their own plans. Andy’s answer: “Yes, with no database changes, but this is real billing backend work.” It then listed the gaps and the questions we needed to answer before committing. Once our CTO answered them and we decided to build it, the prototype, the plan and the PR all came out of that same thread.
3. “Is this ticket already fixed?”
For you: A lot of tickets in any backlog were quietly fixed along the way and never closed. Instead of digging through commits one ticket at a time, you just read the verdict.
For the team: The backlog reflects reality, so prioritization isn’t cluttered with ghost tickets.
In practice: We gave Andy a few of the oldest tickets in our backlog to check at once, and two turned out to be already fixed. Andy linked the PRs that fixed them, explained the cause, and noted which parts it hadn’t verified itself. We closed both, and the only human time spent was a few minutes reading the results.
4. “Do we already have a ticket for this?”
For you: A customer asks for something and you vaguely remember discussing it before, but can’t remember where.
For the team: No duplicate tickets, and no re-arguing a decision the team settled a month ago. Past decisions and the reasons behind them are easy to find.
In practice: A customer asked whether they could connect their own MCP server. Andy found the existing roadmap item and backlog ticket, summarized the history and the open questions, and pointed out which tickets only looked related. Once we decided to build it, we kept working in the same thread to design the approach, then had Andy build it and ship it.
After day one
These four questions show what Andy is really for:
- For individuals: Less time spent figuring out where things stand, more time for judgment and decisions.
- For the team: Context no longer lives only in someone’s head or someone’s private AI chat. Every question and answer stays in the thread the team shares, so whoever picks the work up next doesn’t have to start over.
- For delivery: By the time you decide to build something, Andy already has the full context. The prototype, the plan and the PR come out of the same thread, with no extra handoff.
The longer you use Andy, the more of that context builds up, and the better it understands your team.
Curious how Andy would answer these four questions about your codebase? Let’s talk →
