Vibe Coding as a Job & StrongDM's AI-Powered Software Factory

Lenny Rachitsky - Getting Paid to Vibe Code: The New AI-Era Job#

Source: https://www.lennysnewsletter.com/p/getting-paid-to-vibe-code Credibility: High (detailed interview with Lazar Mitrovic from StrongDM, first-person account of organizational changes)

What happened: Lenny published an interview with Lazar Mitrovic, revealing how StrongDM created a 3-person "AI team" that ships production features without traditional coding. The role: "vibe coding"—using AI to describe what you want, iterate on outputs, and ship software.

Key organizational patterns:

What vibe coders actually do:

• Describe features in natural language to AI tools (Cursor, v0, Claude Code)
• Iterate on AI-generated outputs through conversational refinement
• Test and validate AI-written code without understanding implementation details
• Ship features directly to production with engineering review gates

The hiring profile shift: StrongDM's vibe coding team includes:

• Former sales engineer (no coding background)
• Product manager (light scripting experience)
• Designer (no traditional development skills)

What they shipped:

• Customer-facing dashboards with real-time data
• Internal tooling automating manual processes
• Integration workflows connecting multiple systems
• Each project: 1-3 weeks from idea to production

The quality debate: Engineering teams initially resisted: "AI code is messy, hard to maintain." But the trade-off works when:

• Features are isolated (don't touch core systems)
• Iteration speed matters more than code elegance
• Business value justifies technical debt

Why "vibe coding" as terminology: The term captures the shift from technical precision ("write this function") to outcome-oriented description ("make the dashboard show monthly revenue by region"). The coder's job: communicate intent clearly, not implement algorithms.

Why it matters for PMs: This validates the pattern from Jan 29-30 updates (Sensay 6-week build, Stripe 5-hour app): AI tools are creating a new job category between "write code" and "describe requirements." For PMs, the question becomes: should you hire vibe coders to ship internal tools and prototypes, or keep all development with engineering?

Critical questions:

• At what scale does vibe-coded software create unsustainable technical debt?
• How do you measure productivity—features shipped or maintainability?
• What happens when the vibe coder leaves and nobody understands the AI-generated code?
• Does this pattern work outside SaaS products (e.g., infrastructure, embedded systems)?

Action you could take today: Audit your feature backlog for "nice to have" internal tools or customer-facing features that aren't core product. Estimate how long they'd take with traditional development. Then consider: could a non-technical team member ship this with AI tools in 1-3 weeks? If yes, prototype one feature to calibrate realistic output quality.

Simon Willison - How StrongDM's AI Team Builds Serious Software Without Coding#

Source: https://simonwillison.net/2026/Feb/7/software-factory/ Credibility: High (detailed technical analysis from respected developer, includes specific architectural patterns)

What happened: Simon Willison analyzed StrongDM's "software factory" approach—a 3-person AI team shipping production features without traditional coding. His breakdown reveals the technical patterns enabling this workflow.

Key technical architecture:

The AI toolchain:

• Cursor: Primary IDE for generating and editing code
• v0: Scaffolding complete applications from descriptions
• Claude Code: Complex reasoning and architectural decisions
• GitHub Copilot: Code completion and refactoring
• Prompt engineering patterns: Structured prompts that generate maintainable code

What makes it work technically:

1. Isolated feature architecture: Features built by vibe coders don't touch core systems. They're:

• Standalone services with API boundaries
• Self-contained UI components
• Isolated database schemas or separate datastores
• Minimal dependencies on existing codebase

2. Quality gates with engineering oversight:

• Code review by senior engineers before merging
• Automated testing catches basic errors
• Architecture review ensures features don't create coupling
• Production monitoring flags issues quickly

3. AI-friendly tech stacks: StrongDM standardized on patterns AI tools generate well:

• React for frontend (AI generates clean components)
• REST APIs (AI understands HTTP patterns)
• PostgreSQL (AI writes correct SQL)
• Standard authentication/authorization patterns

The limitations Simon identifies:

What vibe coding can't do (yet):

• Performance optimization (requires profiling and algorithmic thinking)
• Complex state management (AI struggles with coordination patterns)
• Security-critical code (requires threat modeling beyond AI capability)
• Debugging production issues (requires deep system understanding)

Why it matters for PMs: Simon's analysis reveals this isn't "AI magic"—it's deliberate architectural choices. Features must be isolated, stacks must be AI-friendly, and quality gates must be robust. For PMs evaluating whether to adopt this pattern, the question isn't "can we do vibe coding?" but "can we architect our product to support isolated features with strong boundaries?"

Critical questions:

• What's the right boundary between vibe-coded features and engineering-owned core systems?
• How do you prevent accumulation of technical debt when vibe coders ship fast?
• Does this pattern create a two-tier system (clean core, messy periphery)?
• At what company size does this organizational model break?

Action you could take today: Map your product architecture to identify isolated feature areas—places where new functionality doesn't require touching core systems. These are vibe coding candidates. If your architecture is tightly coupled everywhere, that's a constraint preventing adoption regardless of AI tool quality.