Revenge of the SVP of Partnerships
Everyone in the building is building.
A guest post by David Valerio Gilmore, founder & CEO of Memex
Imagine walking into work and discovering your SVP of Partnerships wrote more code than any individual engineer last week. Or that a “non-technical” product manager on your team shipped a new feature all by herself – one that engineering had estimated would take weeks. And a tech sales rep who hadn’t written code in years whipped up a working prototype during the meeting where the problem first came up. These scenarios would have seemed preposterous just months ago. Now, it’s increasingly becoming reality at companies embracing AI-driven development.
Engineering leaders are grappling with how to use agentic coding solutions to 10x their teams’ productivity. That’s a crucial opportunity they need to get right, but it stops short of the full opportunity. We’re entering an era when everyone in the building can build, not just the software engineers. The winning companies of the future will be powered by engineering organizations that:
can 10x their engineers with agentic coding, and…
…enable their non-technical employees to vibe code effectively.
These issues are more related than may be obvious. In fact, the same techniques to measure and improve the productivity of engineering teams with AI may be the same key ingredients to enable non-technical employees to vibe code effectively. To make that case, this post is organized as follows:
First, in the section measure engineering productivity through a PLC lens I make the case that engineering productivity metrics are important heuristics, and to be most useful they must be viewed through the lens of a product’s stage in the product lifecycle.
Second, in empower non-developers to vibe code I make the case that product and engineering leaders need to work together to lead the adoption of vibe coding within companies. Done right, companies will realize enormous productivity gains. Done wrong, it will be a free-for-all train wreck.
Finally, in the SVP of Partnership’s revenge I connect these ideas and contend that a company full of AI-enabled builders, regardless of whether they’re vibe coders or engineers, can lead to more validated product roadmaps, happier customers, and more profitable growth for the companies that get it right.
Measure engineering productivity through a PLC lens
In his post “Revenge of the Junior Developer”, Steve Yegge anticipates engineers will soon act like managers overseeing fleets of AI "workers" coordinating parallel tasks like bug fixes, feature builds, and refactoring. He’s not alone: this vision is a part of the product strategy at frontier labs like Anthropic. Software engineering is shifting from manually writing code to managing AI agents that generate it. Steve anticipates org charts in FY26 will include IC engineers managing fleets of AI agents.
Regardless of whether IC engineers are delegating work to AI managers next year or not, AI is already clearly reshaping how engineers build. And the pace of progress suggests that this type of org chart is inevitable. If engineering organizations get behind in FY25, they’re only going to fall further behind in FY26.
Of course, AI inference is also not free, and agentic coding tools are among the most expensive applications of AI given the high rate of token consumption. As a result, engineering leaders must increasingly consider how to balance spending more on AI to increase the productivity of their existing teams vs expanding headcount. Doing so requires examining the productivity of their teams. Here’s my take on some of the engineering productivity metrics that are useful in the AI era:
DORA: This metric tracks how quickly and reliably teams deliver and recover software, regardless of whether code is written by humans or AI. Because it’s instrumented on DevOps events instead of code events, it’s less sensitive to whether it’s AI or humans writing the code.
Code churn: This tracks the volume of code modified, added, and deleted over time. I find it’s a more favored metric in the AI era for capturing the ebb and flow of automated generation and subsequent refactoring. It offers teams real data on where AI agents may be creating technical debt faster than humans can clean it up.
Developer sentiment: AI is changing a lot about how engineers work, but it’s not replacing them. The pulse of engineers’ opinions, comfort, and confidence with their tools and workflows is a useful leading indicator of team health.
These metrics can be useful, but I also contend they fall short without broader context. Why? Because they don't fully reveal the impact of the solutions that engineers deliver. AI is accelerating our ability to produce functional software, but functional software has always just been half the battle. We also have to create software that people use and derive value from.
To get the complete picture, we must increasingly view the productivity of engineering through the lens of product value metrics. More than ever, engineering leaders need to link arms with their product management counterparts to track the value indicators of the products their teams deliver. This is easier said than done, because products are measured differently depending on their stage in the product lifecycle (PLC). Here’s a common framework for the product lifecycle and the metrics that matter in each stage.
Early stage: prioritize product-market fit. Run fast, focused experiments that prove users truly value what you’re building. Track metrics like weekly active users (WAU), activation rate (the percent who complete a key “first‑value” action), and short‑term retention. Productivity here is measured by how many clear, learn‑or‑fail hypotheses you can cycle through per week, and whether each experiment yields actionable insights.
Growth stage: sustainable expansion. Expand your user base and deepen engagement without sacrificing quality. Measure net revenue retention (NRR), time‑to‑first‑value (how long new users take to hit that “aha” moment), and feature‑adoption rates. Keep an eye on lead time for changes and error rates, as your ability to deliver high‑impact features quickly and reliably is the key productivity lever at this stage.
Maturity stage: optimize for efficiency. Shift focus from building new features to optimizing what you’ve already built. Monitor infrastructure cost per user, average cost per feature release, and reliability metrics. Here, productivity means reducing waste (consolidating services, refactoring cruft, and automating toil) so you can sustain high availability at the lowest possible cost.
Factoring these lifecycle-aware product metrics into a toolbox of engineering productivity metrics will help ensure that AI investments are truly driving results. It forces us to anchor to outcomes over outputs: did engineering drive revenue, user satisfaction, or risk reduction?
Crucially, using these metrics are about more than just setting up the product analytics infrastructure. It’s about anchoring both product and engineering on product outcomes to align engineering output to tangible business outcomes. Not only will this lead to more productive engineering, it’s also a necessary ingredient for teams to navigate the second impact of AI coding.
Empower non-developers to vibe code
The second impact from AI coding is arguably even more disruptive: coding is no longer the exclusive domain of engineers. Thanks to increasingly powerful vibe coding tools, we’re seeing the beginnings of a Cambrian explosion of “citizen developers.” These are folks in non-engineering roles – product managers, data analysts, designers, marketers, sales ops, you name it – who can now create software solutions without formally being software engineers. When I say “everyone in the building builds,” I mean everyone. The barrier between “technical” and “non-technical” colleagues is blurring, fast.
New AI tools are explicitly targeting this democratization of coding. I know this from experience building Memex, a vibe coding tool for tech-savvy professionals. We have many engineers as users, but the majority of our users have never written a line of code. Of course, there are also many other players in this market, many of whom have the explicit goal of empowering non-developers to build, and it’s working.
Given this shift, my conviction is that Steve Yegge’s org chart stopped short. The actual org chart of FY26 is going to look something like this:
We’ve had “low-code” and “no-code” platforms for years, but this is different: truly general-purpose AI coding assistants that can turn natural language into full-stack software. The domain experts with the ideas and the context will increasingly be the ones creating the solution, end-to-end. It starts with internal tools and scripts, but it won’t stop there. It’s not just Excel macros or Zapier hacks. We’re talking real applications, even customer-facing features, built by people whose job titles never included “software engineer.” If this sounds radical, consider again the real-world signs of the times. A product manager today can indeed ship a working feature without dev help – we’ve seen it happen. All the examples I provided in this post’s intro are real examples of our users at Memex.
This shift comes with risks. Non-developers might be able to produce working code with vibe coding tools, but they usually don’t understand the broader SDLC version control, testing, security best-practices, and safe-deployment strategies are not in their arsenal. Coding without observing these practices introduces risks.
Engineering teams and IT organizations have two options. Resist the use of these tools and confine them to “shadow IT”, or guide the shift to how they’re adopted. The former will end up a losing battle.
Will there be false starts and facepalms along the way? Absolutely. Not every non-developer coding attempt will end in success – at least not initially. Perhaps most will fail. But here’s the thing: mainstream adoption is still inevitable. Why? Because the genie’s out of the bottle. The productivity boost and empowerment that AI development tools provide is just too revolutionary. If you try to ban it, people will simply find a workaround – much like what happened with the rise of cloud SaaS tools becoming shadow IT. The better approach is to get in front of it and guide it. Tech leaders need to channel this trend in a positive direction, not play whack-a-mole trying to suppress it. In fact, I’d argue it’s the responsibility of CTOs and CPOs to partner with one another and champion this movement proactively, so it doesn’t turn into an unmanageable free-for-all.
Put up guardrails for vibe coding in the company
To make “everyone builds” a success rather than a train wreck, organizations need to establish guardrails and support for non-engineering developers. Here are a few steps and principles that I believe engineering and product leaders should consider:
Provide approved tools & training: Don’t leave eager non-dev builders to grab random AI tools off the internet. Offer officially supported platforms (for example, tools that meet your security requirements) and training on how to use them. Teach the basics of version control, testing, and prompt crafting for these tools. This way, employee-built apps start off on the right foot, and IT has visibility into what’s being built.
Integrate with the dev lifecycle: Everyone can build doesn’t mean anything goes. Fold these citizen-developed projects into your normal software development lifecycle as much as possible. Require code lives in company Git repositories, uses automated CI/CD pipelines, and has lightweight code review or approval processes. (Yes, an engineer might still need to glance over that marketing-built microservice before it hits production!). By integrating, you ensure maintainability and quality standards aren’t lost.
Automate the safeguards: Use tooling to catch issues that less-experienced coders might miss. For instance, run static analysis and security scanners on all code (whether written by an engineer or an AI or a salesperson). Enforce linters and dependency checks. If an AI-generated app has a known vulnerability, your pipeline should flag and reject it. Automated tests and monitoring can provide a safety net, giving confidence that these new apps won’t bring down the house.
Assign “buddies” or owners: Consider a mentorship or ownership model. If someone in HR builds a new app that becomes mission-critical, pair them with an engineer who can co-own the project or at least act as an advisor. This doesn’t mean the engineer takes over – rather they ensure the app follows best practices and can be maintained long-term. It creates a bridge between citizen devs and professional devs, facilitating knowledge transfer both ways.
Foster a supportive culture: Perhaps most importantly, set the tone that this is a good thing. Encourage experimentation and celebrate wins (“Hey, look at the prototype our ops manager built!”). Also be transparent about mistakes – use them as learning opportunities rather than reasons to say “never again.” If people fear backlash, they’ll just hide their skunkworks projects until something blows up. Instead, make it safe to surface these efforts early so the organization can support and improve them.
Perhaps most importantly, engineering teams will need to consider building differently. Think of it this way – non-technical builders aren’t coding. Instead, they’re managing an AI agent to code for them. The engineering team needs to ensure that the vibe coding tools used by non-technical users have the context about the company’s systems, the engineering team’s preferences for code styling and frameworks, and other non-functional requirements to ensure that the code produced aligns to the practices embraced in the organization.
The SVP of Partnership’s revenge
Steve Yegge’s post about the Revenge of the Junior Developer originated as a response to his earlier post The Death of the Junior Developer in which he was bearish on career prospects for junior devs in the age of AI. But he found that, in a turn of events, the junior developers are often the most eager to adopt the new agentic coding systems, and as a result they are seeing the fastest growth in productivity.
With that context, what is the SVP of Partnership’s revenge? And who is the SVP of Partnerships anyway?
In my years working in product management I had daily conversations with stakeholders about their ideas for how we could increase market share, increase spend with top customers, enter into a new market segment, and countless other great business opportunities. I said “no” to 90% of them. The “SVP of Partnerships” is my moniker for these stakeholders, and saying “no” to them so often was really hard to do because their ideas were almost always great. The job was hard precisely because we had to prioritize across a number of different great ideas, instead of just filtering out bad ideas. For so many people outside of product and engineering it is a common frustration to see great ideas get shut down.
The thing is, these stakeholders are often the same people whose jobs it is to talk with customers and prospects all day, every day. They understand the domain. They have the customer relationships. They deeply understand the requirements. But they haven’t had the skills to build… until now.
And this is the idea that connects it all: non-engineers within the company are transforming from stakeholders of product and engineering to participants in the product development lifecycle. Rather than diminish the role of product and engineering leaders, this puts even more responsibility on their shoulders. Their jobs become guiding how the whole company can participate in creating solutions and innovating at scale.
Instead of scheduling a meeting with a PM, stakeholders can Slack a link to a working version. Instead of asking the engineering team to run analysis on something, stakeholders can create their own custom dashboards–complete with a pipeline to transform the data into the right format. Roadmap prioritization can become deciding which bets to double down on, not which ones should even be made in the first place.
Closing thoughts
To wrap up, let me be absolutely clear: the train has left the station. AI-driven development is changing how engineers work and who gets to be a developer. Everyone in the building is building. You can either get ahead of it and turn it into a competitive advantage, or ignore it and scramble in a year when half your company is running on unsanctioned Python scripts and AI-built apps anyway. My advice (and fervent belief) is that CTOs and technical leaders need to embrace this change now. Be bold in reimagining team roles and productivity – your engineers should spend less time typing code and more time designing and supervising AI systems. And be bold in opening the gates of software creation to the rest of your organization – with the right safety nets. The companies that master this symbiosis of human and AI, of developer and “citizen developer,” will build better and faster than those that don’t. In the end, that’s what this is all about: unlocking the creative building capability of your entire organization. We have the technology; now it’s on us to lead the cultural and process changes that make it work. When everyone builds, amazing things can happen, and engineering leaders have the opportunity to lead the charge.
What’s at stake? Companies have in front of them an opportunity to expand into market segments with niche requirements at scale, to launch more early stage bets and double down on the winners, and to delight whale customers with customized features to drive higher contract values without overburdening the engineering organization. We’re still in the early innings, but those companies that put in the guardrails, foster the supportive culture, and start iterating cross-functionally have a tremendous opportunity in front of them.
This is the revenge of the SVP of Partnerships. Done well, companies have a unique opportunity to transform themselves. Those that do it well will create a new breed of companies with Rule of 40 growth, fueled by AI.
 | A guest post by
|