The worst thing about vibe coding is getting so deep that you form an LLC, get a business bank account, create a company website & email, apply for a D-U-N-S number, create a TOS & privacy policy, build content moderation, and create a process for DMCA request handling just so you can launch your app that probably no one will ever use.
Thoughts
Slow down to speed up with AI.
LLMs struggle with highly complex, fragile code bases in the same way that developers struggle with them. LLM performance improves dramatically when underlying quality issues are addressed.
Over the course of a 6 month period, teams that balance structural improvements with new work end up shipping more value than teams that spend 6 months shipping new work.
Matt Beleck, Head of Engineering for ACV Auctions's Transport org, has spent years working with the team to improve code quality. This investment has paid off big as the team has aggressively adopted agentic development. Some of Matthew's tips:
- Clear naming: LLMs are language engines. Use accurate, descriptive names for methods and variables
- Logical structure: Ensure your repos are easy to navigate. Think clean directory structures, small files, and small methods.
- Codify standards: Document engineering standards into explicit, enforceable rules that the LLM can execute, not interpret. (Bonus tip: Use historical PR and task feedback to convert common patterns into rules).
- Provide context: LLMs perform best when they understand not just where to look, but when to look. Document files like SECURITY.md with trigger cues (e.g., "read this for a deep explanation of PII handling") and reinforce those keywords in prompts and code.
All of these tips probably sound very familiar. If code is easier for people to understand, it's easier for LLMs to understand.
New tools, same best practices.
CLIs are a superpower for non-technical people.
At ACV, we're seeing that PMs & designers with less technical backgrounds lean into CLIs like Claude Code. We're seeing them come up with the most creative, unexpected applications. Something about the struggle of learning how to work in a terminal, stumbling your way through set up, and finally getting everything working forces people to think differently.
I've spent more of my career as an engineer than as a PM, so CLIs come naturally to me. It was obvious to me how Claude Code could be used to create prototypes, build things, and plan changes. People without engineering backgrounds have no preconceived notions that guide them to the 'obvious' applications.
They see a weird new tool and a weird new interface and let their creativity run wild, quickly moving past PRD and prototype creation into entirely new operating flows.
Some interesting examples
One of our Lead Product Designers, Michael Belfatto, is using Claude Code to push the pace and quality of how design ships at ACV. On one of our highest trafficked, most complex flows, he used Claude Code to:
- Build a working prototype of the redesigned experience, fast enough to pressure-test the concept with stakeholders before committing engineering resources
- Translate the prototype and existing flow into detailed engineering requirements
- Hand off the project with production-ready components engineering could immediately ship from
The result was a design process that compressed weeks of back-and-forth into days, and a handoff that let the team start shipping on day one.
Chris Maue, PM for post sale, has completely changed how he approaches his hands on keyboard work. His flow looks something like:
- Dumps his unstructured thoughts into Claude Code and asks it to pressure test his ideas.
- Uses Atlassian, and GitHub MCPs to validate changes against existing docs and functionality.
- Iterates, generates a living doc and publishes it to Confluence.
- Creates a prototype, generates tickets and hands everything off.
- Claude reads Confluence and Jira to publish weekly updates to stakeholders.
All while typing away in a terminal, saving hours on manual work and hand offs.
Ashish Jain, PM for guarantees, is using Claude Code + Playwright Plugin to run a first pass 'user demo'.
- Creates user personas in .md files
- Asks Claude to 'Pretend you're a used car manager and tell me what you think of this new feature'.
- Claude then opens up the site, takes a look around, and writes a feedback doc.
It's surprising how accurate the feedback is when we move forward to demos with real users!
It's hard to reconcile AI-related claims of 10x increases in delivery speed with reality. Established companies like Google, Salesforce, Shopify, etc. are reporting more modest -10% to +30% changes.
The obvious answer is that AI is much better at creating greenfield code at breakneck speeds but struggles with established, complex codebases.
The question I'm wrestling with is whether this greenfield advantage will translate into true disruption, where new entrants build effective wedges and blaze past incumbents, or if these new entrants will quickly hit a plateau and slow down as complexity increases.
Complexity can take years to build up, and modern LLMs probably haven't been around long enough to see how this will ultimately play out. I am curious what other people are seeing.