This is my presentation from “The Rise of Agentic AI and Vibe Coding”.
This talk is about vibe coding. I know we have a pretty wide audience here; this talk is specifically in the context of a SaaS company, since that’s what I do. But there’s probably lots of bits that are broadly relevant.
I want to start with an important disclaimer, which is that nobody knows anything.
This space is changing so rapidly that by the time I finish this presentation something I say will be out of date. Don’t trust “experts”, particularly me. The best way to learn is by doing, and the best way to avoid anxiety is to not worry about keeping up with everything. So, with that said.
Software companies have always had an intrinsic tension between product and engineering. Product wants to build as much cool stuff as possible, engineering wants to build it well. I will leave you to decide who is who.
The best way to do product management is to just ask customers what they want, and build that. But most of the time engineering can’t keep up with that pace. A lot of the process you see in software development - whether it’s called agile or waterfall or shape up or whatever - exists to rate limit product ideas to a pace that can be handled by engineering.
But now, AI can write all your code. We are taking that as a given. Does that rate limit still make sense?
Let’s back up a bit for those who missed the 1 March deadline. How do you get to a stage where AI writes all your code? It’s not that complicated.
First, let’s define the baseline.
Number 1. Claude Code knows how to:
Write all your code
Run all your tests
Use your app via the browser
In other words, you have closed the loop and Claude can do things autonomously if you let it.
Number 2. You’ve got your lead engineers focused on just two things:
Shipping great products end to end
Building the right architecture
And you’ve got everyone who isn’t a lead engineer, working toward becoming one as quickly as possible.
How to get there? Here is what we did:
Take another look. Inevitably there will be a loud voice in the team who last asked ChatGPT to write code in 2023 and it didn’t work great. If you haven’t used Claude Code on your codebase, this year, to fix a real bug or build a real feature, then you are out of date, and any opinion you have about it its limitations might be void.
Do a hackathon. Most companies limit the ambition of their ideas by what they think is possible. If people think that a feature will take 5 years to build, nobody will propose it. Do a hackathon so that everyone realises how far you can get in a day. This introduces a new problem of people thinking things are easier than they truly are, but that’s a better problem to have.
Put everyone who wants to write code, on the Claude Code Team plan. People are irrationally stingy about buying AI tools or asking for access to tools you already have, so just do it proactively.
Set an AI budget. Our budget is $1000/day. I would like to see that budget get exceeded; it hasn’t happened yet.1 Again, people are irrationally stingy about AI. I have seen people make PRs to try and optimise a prompt that costs 5c to run and will run a few times per day. The point of the budget is to decrease the friction around spend, not to constrain spend - the time for that will come later.
If all this was new to you, then come back to the second part of this post after implementing it.
If you’ve successfully got everyone using AI for coding, you will inevitably encounter this problem. Sure you might have a few exceptions but they probably prove the rule.
That’s because to get full value out of AI powered coding you need to fundamentally change how you think about product management.
Now there will be stuff that you will still build, that you always would have built. Like you still need someone to build the password reset function, and AI will make it quicker to build.
But what you should be thinking about a lot, is what you previously couldn’t - or wouldn’t - build. I think this falls into a few buckets.
Some problems just feel too hard. We call it the Tanda Olympics. Every 4(ish) years someone says “why don’t we do X” and there’s a long convoluted reason filled with baggage and back story for why. Maybe in 4 years we’ll do it? You should go through all your “intractable” ideas and ask Claude how it would solve them.
This might just be me, but I get terrible writers block. When I have written zero code for a feature, sometimes I just can’t work out where to put the first bit of code. It’s a lot easier to type a prompt into Claude Code. Sometimes I even get writers block on that! I’ve found Claude Code Web to (for some reason) be more inviting and mostly cure this, allowing me to get the ball rolling on all sorts of ideas that I otherwise would never have started.
Some things aren’t hard but they are tedious. You just know “ugh, this will be a pain to build, some junior is gonna have to do heaps of gruntwork and then someone else will have to manually check it all”. Claude loves gruntwork, and Claude doesn’t complain.
The other thing you should do is rethink jobs theory. We (as in the industry) used to all use job theory to tell us what sorts of features our software should have, based on our shared conceptual understanding of what software does. In a sense, we should still do that, but our shared conceptual understanding needs to be reassessed.
In less academic terms: can you use AI coding, or build AI Features, that completely solve the job that somebody has bought your software to do? The answer is probably yes, and while that might be quite complex to do, it’s worth reassessing the scope of things you can do and stretching for it.
Most of the software I use hasn’t done that yet.
At Tanda we haven’t fully done that yet.
My hope from this talk is that you do that. I’d like to see a lot more magic!