After three months of intensive collaboration with Claude, resulting in 3,500+ commits, 300+ releases, and over 1 million lines across 124 public repositories, I’ve collected some of my general thoughts in 7 Techniques for Scaling AI Usage , but also wanted to provide some specific thoughts on the Agent Experience (AX) and how to make agent-friendly software in a set of principles that I call DIRECT. These principles are designed to help us think about designing the Agent Experience, the same way that SOLID changed how we think about object-oriented design (OOD).

The Conversation Has Started — Now We Need to Codify It

The industry has started to discuss Agent Experience, or AX. Netlify launched agentexperience.ax to define AX as “the holistic experience AI agents have when interacting with a product, platform, or system” — the AI counterpart to UX and DX. This is important , and their call for community collaboration is valuable.

While discussion is a start, we need more. We need codified principles that developers and agents can apply and tools can enforce. That’s what DIRECT provides.

What is DIRECT?

DIRECT is to Agent Experience what SOLID is to Object-Oriented Design: a foundational set of principles that guide the creation of interfaces AI agents can reliably use.

• Deterministic: Agents trust the system to behave the same way each time, making safe recovery from errors natural.

• Introspectable: Agents explore capabilities and understand data structures without requiring external docs or humans

• Recoverable: Agents can diagnose what went wrong and take corrective action without human intervention

• Explicit: Agents operate within clear boundaries and constraints so they act with confidence

• Consistent: Agents build mental models once and apply them everywhere, scaling their effectiveness

• Testable: Agents can try actions safely before committing, learning what works without causing harm

These aren’t abstract ideals. Each principle addresses a specific failure mode I encountered repeatedly while working with agents.

AX Over DX: A Counterintuitive Approach

Here’s what surprised me most: I stopped using traditional Developer Experience and started relying on Agent Experience.

I built 25+ integrations for my PlexusOne stack across LLM providers (OpenAI, Anthropic, Google, xAI, Ollama), observability platforms (Opik, Langfuse, Phoenix), voice services (Deepgram, ElevenLabs, Twilio), search APIs, and infrastructure tools. Instead of reading documentation or learning SDKs myself, I provided information to Claude, such as OpenAPI specs, Python SDK source code, and we discuss the implementation together.

I know what good DX looks like, from both from using many APIs/SDKs and my time on the RingCentral Developer Program, which won seven industry awards including API World’s Best in Communications APIs (2018, 2019, 2021), DevPortal Awards’ Best Developer Dashboard, and Nordic APIs’ Best Public API.

But when working with agents, I’ve learned to make different choices. For example:

• When a human developer sees 400 Bad Request, they read the error message, check the docs, maybe search Stack Overflow. They iterate through understanding.

• When an agent sees 400 Bad Request, it can hallucinates a fix that makes things worse. Agents don’t “understand” in the human sense, so I need to step in. They need structured, unambiguous interfaces to operate reliably.

This realization led me to develop DIRECT.

How I Learned This (The Hard Way)

In Q1 2026, I ran an experiment: use AI agents as my primary development partner for as much work as possible. The results were staggering in scale:

• Commits: 3,561

• Releases: 304

• Lines Added: 1,696,636

• Lines Deleted: 689,678

• Net New Lines: 1,006,958

• Repositories: 124

But raw numbers don’t tell the entire story. The story is in what worked and what didn’t.

• What worked: When I gave Claude well-structured specifications, explicit constraints, and consistent patterns, it produced code I could trust. Iteration was fast. Errors were recoverable.

• What didn’t work: When interfaces were ambiguous or counterintuitive, when error messages were vague, when behavior varied unpredictably- the agent would spin. I’d watch it make the same mistake multiple times, until I needed to step in and suggest alternative approaches.

The pattern became clear: agent effectiveness depends more on interface design than on model capability.

The Three Things You Should Do With Agents

Working this intensively with agents taught me there are three complementary activities, all of which can benefit from DIRECT experiences:

1. Working With Agents

This is where most people start. Use Claude, GPT, or Copilot to help you code. It works — sometimes brilliantly, sometimes frustratingly.

The frustration usually isn’t the agent’s fault. It’s the interface’s fault, which is why we’ve created the practice of prompt engineering.

2. Build Tools That Make Agents More Efficient

Once you see agents struggle with the same problems repeatedly, you start building solutions. Over Q1, I built or contributed to 11 tools specifically designed for agent-assisted development:

• agent-team-release: Release automation — R, C, T

• ax-spec: OpenAPI linting & enrichment — I, E

• design-system-spec: Design systems as code — I, C

• schemalint: Schema validation for static typing — D, E

• structured-changelog: Token-efficient changelogs — I, E, C

• traffic2openapi: Generate specs from HTTP traffic — I, E

• w3pilot: Browser automation for agents — I, R, T

Each tool embodies specific DIRECT principles and are agent-first. For example, structured-changelog is designed for changelog creation using LLM agents, unlike other solutions that use raw git logs determinisiticaly. It and other tools output in TOON format (Token-Oriented Object Notation) by default — approximately 8x more token-efficient than raw git log output. When agents pay for context in tokens, efficiency matters.

3. Orchestrating Agents in Teams

The most powerful pattern I discovered: agents working together, each with specialized capabilities, coordinated through well-defined interfaces.

This is where DIRECT principles become essential. When Agent A calls a tool that Agent B will consume the output of, every principle matters:

• Deterministic: Agent B can rely on consistent output structure

• Introspectable: Agent B can discover what the output contains

• Recoverable: Errors include enough context for Agent B to adapt

• Explicit: No hidden assumptions between agents

• Consistent: Patterns learned from one interaction transfer to others

• Testable: Agents can validate their plans before execution

My release agent team orchestrates multiple specialized agents (QA, security, documentation, release management) to handle software releases. Each agent operates on DIRECT-compliant interfaces, enabling autonomous coordination. The team structure and handoff forms are defined using multi-agent-spec—a formal specification that declares agent capabilities, workflow dependencies, and typed inputs/outputs between steps.

Example: Choosing ogen for OpenAPI code generation

When generating Go structs from OpenAPI specs, I evaluated several tools. The most “ergonomic” ones for humans — oapi-codegen, go-swagger — produce code that’s easier to read but makes assumptions that can confuse agents. They might flatten nested types, use interface{} for ambiguous schemas, or generate helper methods with implicit behavior.

I chose ogen instead. It’s more verbose, less ergonomic for humans, but extremely correct. Every type is explicit. Every field is deterministic. Every validation is clear.

For a human developer, this verbosity feels like friction. For an agent, it’s clarity. The agent never has to guess what a type contains or how validation works — it’s all explicit in the generated code.

This is DIRECT’s Explicit principle in action: when the choice is between human ergonomics and machine clarity, choose clarity. Humans can learn conventions; agents need explicit declarations.

What Does “Developer Program” Mean in 2026?

This raises a question I’ve been thinking about: what does it mean to run a developer program when your users are no longer just humans?

When I ran the RingCentral developer program, success metrics were human-centric: time-to-first-call, documentation satisfaction scores, SDK adoption rates, developer NPS. We optimized for humans reading docs, humans debugging in sandboxes, humans asking questions in forums.

But if agents are increasingly the ones consuming your APIs, the game changes rom traditional UX to AX:

• Readable documentation > Machine-parseable schemas

• Helpful error messages > Structured error codes with recovery hints

• Interactive tutorials > Deterministic sandbox environments

• Community forums > Introspectable capability endpoints

• SDK convenience methods > Explicit predictable behavior

The developer program of the future might measure: agent success rate on first API call, mean time to autonomous recovery, schema coverage percentage, and how often agents need to fall back to human intervention.

This doesn’t mean abandoning human developers. It means recognizing that the “developer” consuming your API might be Claude helping a human, or an autonomous agent in a pipeline, or a human who never reads your docs because their agent already understands the OpenAPI spec.

The platforms that win will be the ones optimized for both. DIRECT principles are one attempt to codify what “optimized for agents” actually means.

Concrete Example: Error Classification

Let me show how DIRECT principles translate to real code.

The problem: Different APIs return errors in different formats. An agent calling ElevenLabs gets different error structures than one calling Deepgram. Without standardization, agents need per-provider error handling logic.

The solution: Unified error classification with 8 categories.

// From omnivoice-core/resilience
type ErrorInfo struct {
  Category   ErrorCategory // transient, rate_limit, validation, auth, etc.
  Retryable  bool
  Code       string
  Message    string
  Suggestion string
  RetryAfter time.Duration
}

Now an agent can make decisions programmatically:

if err.IsRetryable() {
  time.Sleep(err.GetRetryAfter())
  // retry…
} else {
  log.Printf("Cannot retry: %s. Suggestion: %s",
  err.GetCode(), err.GetSuggestion())
}

This is Recoverable in action. The agent doesn’t parse error strings — it receives structured, actionable metadata.

The Website and Documentation

I’ve published the full DIRECT framework at grokify.github.io/direct-principles. The site includes:

• Detailed principle definitions with examples and anti-patterns

• Compliance levels (AX-L1, AX-L2, AX-L3) for progressive adoption

• Case studies showing DIRECT applied across the tooling ecosystem

• Spectral rules via ax-spec to enforce DIRECT for OpenAPI specifications

The case study on the Agent Tooling Ecosystem walks through how each tool applies specific principles.

Why This Matters Now

We’re at an inflection point. AI agents are moving from novelty to infrastructure. The companies and developers who figure out how to build agent-friendly interfaces will have a significant advantage. Consider:

• APIs that agents can discover, call, and recover from errors automatically

• CLIs that agents can compose into pipelines without human intervention

• Documentation that machines can parse as effectively as humans can read

• SDKs with layers optimized separately for agent and human consumers

This isn’t about replacing human developers. It’s about multiplying their effectiveness. In Q1, I shipped more than I ever have — not because I worked harder, but because agents could reliably handle more of the work.

The bottleneck was never the agent’s capability. It was always the interface.

Getting Started

If you want to apply DIRECT principles:

1. Start with one principle. Add `operationId` to every endpoint in your OpenAPI spec (Introspectable). Or ensure all errors return structured codes (Recoverable).

2. Use ax-spec to audit. Run `vacuum lint — ruleset ax-spec/rules/ax-openapi.json your-api.yaml` to see where your API falls short.

3. Design for the agent first. When adding a new endpoint or CLI command, ask: “Can an agent understand this without reading prose documentation?”

4. Test with actual agents. The best validation is using Claude or GPT to interact with your interface. Where do they struggle? That’s where DIRECT principles apply.

Conclusion

SOLID gave us a vocabulary for discussing object-oriented design. DIRECT aims to do the same for agent-facing interfaces.

The principles are:

• Deterministic — Same input, same output, every time

• Introspectable — Machine-readable capabilities and schemas

• Recoverable — Structured errors enable autonomous correction

• Explicit — All constraints declared, nothing hidden

• Consistent — Patterns that generalize across the interface

• Testable — Safe experimentation without consequences

We’re early in the age of AI agents. The interfaces we build today will shape how effectively agents can augment human work tomorrow.

I believe that DIRECT principles — or something like them — will become as fundamental to agent-oriented development as SOLID is to object-oriented design.

The code, documentation, and tools are all open source. I’d love to hear what you think.

Resources

• DIRECT Principles (https://grokify.github.io/direct-principles/) — Full documentation and case studies

• AX Spec (https://github.com/plexusone/ax-spec) — Spectral rules for OpenAPI compliance

• Agent Tooling Ecosystem Case Study (https://grokify.github.io/direct-principles/case-studies/agent-tooling-ecosystem/) — How DIRECT applies across 11 tools

• PlexusOne (https://github.com/plexusone) — Organization for agent tools and SDK integrations

• Multi-Agent Spec (https://github.com/plexusone/multi-agent-spec) — Specification for defining agent teams and workflows

• PlexusOne Integrations (https://plexusone.dev/integrations/) — 25+ integrations across LLMs, voice, search, and infrastructure

1. Release Management

2. Agent Selection

3. Agent Empowerment

4. Agent Orchestration

5. Spec-Driven Development

6. Everything-as-Code

7. Scaling Human Oversight

My efforts were noted by ChatGPT which granted me a “Most Likely to Automate Their Own Brainstorm” recognition for 2025. The rest of the article describes my current approach for this, which includes references to tools I built to accelerate and sustain that acceleration.

It’s worth noting that these contributions were all for my own projects, and while these are all open source, I haven’t promoted them as I’m too busy doing my own building and I’m the primary user/persona for these projects at the moment. These projects are in various states with some actively used in production, some used as prototypes, and others not used at all yet. If you want to use any of the projects, feel free to ask me about them. I’m also highlighting some of the projects throughout the article which are more mature.

Release Management

The number one, foundational technique is not an AI technique, but the ability to manage projects at scale. To drive 1M+ additions in 120+ projects across 300+ releases, release management is a necessary foundation. For me, this consists of git, tests, and CI/CD pipelines. My default pipelines cover build, test, and SAST scanning, with SCA being covered by automated Dependabot pull requests.

With 120+ projects this level of working with AI, it’s more important to to have a systems mindset on how the libraries will interfaces with and depend on each other there are many libraries, CLIs, and MCP servers which are interconnected.

For my friends and colleagues finding the freedom of AI-powered development, git is one of the first things I tell my friends they need to adopt if they haven’t already. And a great thing about AI, is that it can help do this as well.

Of note, one reason I’m able to publish so many projects is that my projects are primarily in Go which uses git as it’s package manager, so I don’t need to publish to package managers like NPM, PyPi, Maven, NuGet, Ruby Gems or other systems. A simple git tag is recognized as a Go release. That being said, pipelines can be added to automatically push to those package managers.

Agent Selection

I’ve found it important to have an “AI-Team” to accelerate, which is a team of agents that you are very comfortable working with. There are 100s of AI services and tools available to choose from so choose wisely.

These are the ones I use now. You should try many AI agents and tools to identify the ones that can accelerate your development the most.

• Claude Code: I use Claude Code for ideation refinement and implementation. It is my execution partner for turning ideas into projects.

• ChatGPT: For ideation, I use ChatGPT and imagineering research partner. It feels super fast which is what I want for ideation, and doesn’t consume my Claude tokens which I want to save for implementation.

• Canva: This is my partner for marketing-ready vector diagrams. I use the AI Code function to generate SVG diagrams that I then incorporate into my applications. For non-marketing diagrams, I use Claude Code with Mermaid or D2 diagrams.

Agent Empowerment

After building the “AI-Team”, it’s important to work with them and empower them to make them more effective. There are many ways to accelerate work with agents including skills, hooks, MCP servers, and other tools.

AI-assisted development is rapid enough the roadmap for such tools is emergent rather than planned. If I feel like I need or just want a tool, it’s easy enough to spin up a parallel AI session to build it, and then incorporate it into the workflow.. Development of these tools is fast enough that it can be done concurrently with the implementer project.

My personal preference is to create code that can live in source control so I tend to empower my agents with CLI and MCP server tools. Here are some examples:

1. videoascode: This is project to create video files that are currently either Marp Markdown presentations or webapp demos. This supports speech-to-text and subtitles in multiple languages. Navigating slides and web apps, along with syncing with audio and subtitles, were not that straight forward, so even though both the Marp slides and voiceover text can be AI-assisted, it was important to build a reusable, tested, tool for this.

2. w3pilot: This is my browser automation MCP server and CLI with 150+ tools. It uses both ChromeDevTools protocol and the BiDi protocol. In addition to having more tools than some other approaches, it has a simple deployment approach for CI/CD pipelines since it is built in Go.

3. structured-changelog: My first highly used CLI tool was a tool to help LLMs build consistent changelogs which I wanted to track my releases. While LLMs can build changelogs directly, often times the format will change so this project is designed to have structured changelogs so that they are always formatted the same way. And while there are other changelog tools, they are built deterministically from git log and not with LLM judgement for terminology.

Some thoughts on this:

1. Emergent: While I know the high level direction I want to head, I may not have all the details which get filled in as I go. If I feel like I need a project or tool to accelerate my work, I’ll built it, and then use it moving forward at an accelerated velocity. In the past, this felt more like a detour, but with AI running many parallel projects, I spin up a parallel project, finish that project, and then move forward at a faster velocity.

2. Future Development: Ideas and code generation are not slow for me. Acceptance testing is slow because that requires me, the human, to be involved right now. I have numerous projects with multiple months and releases of development that I haven’t used. The idea is that when my human capacity has freed up to do review, many rounds of ideation and implementation have already occurred.

3. Aggressive Release Schedule: I ship a lot of releases, an average of 100 per month, and 304 for Q1. I view releases as “compacting” AI development because a release comes with CI/CD pipeline checks, documentation, release notes, and changelog. The release packages existing development so it’s easier to move on with future development.

Agent Orchestration

A key part of how I scale effort is via subagents, which can be thought of as composable prompts that can be put into workflows. A powerful thing is that they can even be called multiple times within a single workflow, such as times where I’ve had agents build a Subagent Pipeline with over 250 agent iterations working on a large code base in a map-reduce manner. Each agent iteration is designed to have enough capacity for its context window.

To scale agent building, I invested time building out Multi-Agent Spec to create a single canonical data structure for defining agents and agent tables from which I autogenerate agent definition files for Claude Code, AWS Kiro CLI, and others. While I have a 65 slide presentation on how to do this, my approach to build agents now a few simple steps to my agent:

1. read the multi-agent spec directory to create agent specs in the specs/ directory

2. create the agent files using AssistantKit in the plugins/ directory

3. review the Release Agent Team as a 1 shot example

4. load the agents from the plugins/ directory into the place the AI agent expects

I originally searched for existing agent-system agnostic specifications and found one but it was not widely adopted and it was not very Go friendly (as determined by schemalint) so I built my own.

Spec-Driven Development

I use spec-driven development (SDD) extensively along with documentation. My approach uses the following documents with the MRD (market requirements document) being optional, but for large projects, I’ll almost always have a PRD (product requirements document) and TRD (technical requirements document).

• MRD.md - market requirements

• PRD.md - product requirements - includes UX

• TRD.md - technical requirements - includes testing

• PLAN.md

• TASKS.md

• docs/design/FEAT_<feature_name>_{PRD|TRD|PLAN}.md

While a single human can build out all the specs, in a multi-person project, aka AI DLC (Development Livecycle) Mob-style team, it may be useful to have each human own their area of the requirements which can be provided to the AI agent to create the plan and tasks.

• MRD = Product Marketing

• PRD = Product Management

• URD = UX Design

• TRD = Engineering

Separate requirements documents stems from the pre-AI development world, but I still prefer the separation of concerns. This separation doesn’t exist with other SDD approaches including AWS SDD (Kiro) approach and the GitHub SDD approach (Spec Kit) which use the following files:

AWS SDD (Kiro)

• requirements.md - product requirements

• design.md - UX and engineering design

• tasks.md

GitHub SDD (Spec Kit)

• spec.md:

• plan.md:

• tasks.md:

• tasks/

Everything-as-Code

AI assistants are great handling code in the form of text files, so doing everything “as-code” which can be actual programming code or other forms of text files can accelerate agent management. I tend to prioritize an everything-as-code approach as much as I can per the following:

• Requirements: Markdown

• Apps: programming language

• API definitions: OpenAPI spec

• Interfaces: JSON schema

• Image: SVG (XML)

• Documentation: MkDocs, Hugo

• Agent Teams: Multi-Agent Spec

• Evaluations: LLM-as-a-Judge reports

• Deployment: Terraform, Cloud Formation, CDK, Pulumi

• Presentations: Marp, Reveal.js

Of note, when defining interfaces, I optimize for statically typed languages like Go and TypeScript and avoid creating interfaces that are hard to represent. To check this, I created schemalint to verify that JSON schemas are statically-typed language friendly which enables easier code generation which I do with Go structs and Zod schemas for TypeScript.

Scaling Human Oversight

Once you are calling one terminal session, the natural inclination is to add terminal sessions so you can multi-task. This is a natural evolution because implementation will take some time, so the natural inclination is to do several projects in parallel. This evolution is described in the Evolution of the Programmer from 2024-2026 diagram from Nano Banana (courtesy of Steve Yegge).

At some time Figure 7 becomes very hard to manage because I found myself clicking around in multiple windows which may not always be visible at the same time. I was doing this with many terminal tabs and several terminal windows before moving to tmux panes and finally deciding to take some time to build my own tiling windows manager, which is now available as the PlexusOne App, a macOS app built in Swift. While this app is still very new and has some quirks, it has quickly become my always on AI agent interface, allowing me to interact with Claude Code, Kiro CLI, Codex CLI, Gemini CLI and others via tmux sessions. I created the following 4x3 diagram for demonstration purposes, but I will typically use 3x2 or 3x1 layouts.

While the macOS app has dramatically improved my laptop experience, I’m also working on a mobile app, but it’s not quite usable yet. While I found quick success on macOS desktop, there are two mobile app (Swift and Flutter) but neither is usable yet.

What’s Next?

With over 1M commits in Q1, the natural question is what’s next and will I be able to maintain this pace. The answer to the latter is that that my commits are already going down when viewing the commits-per-month metric. This is because my agent stack is being built out so I can focus on the things on top of the platform. Additionally, there are less new projects and more effort on improving existing projects, some of which have over 10 releases now.

• January 2026 - 450,609

• February 2026 - 289,943

• March 2026 - 266,406

From a project type perspective, many of these projects are libraries, CLI apps, and MCP servers. Moving forward as this level of projects get filled out, different types of apps will be built on top.

What do you build and how do you build it? Do these techniques resonate with you?

• AI makes starting software projects trivial, but finishing them is now the hard problem.

• The bottleneck isn’t code quality — it’s coordination, accountability, and release readiness.

• This creates a new role: the Agent Leader, responsible for orchestrating agent teams.

• The Release Agent Team models this with six agents (Coordinator, PM, QA, Docs, Security, Release Manager) that enforce a real Definition of Done.

• Finishing reliably in the AI era requires better agent leadership, not better prompts.

Starting projects has never been easier. With modern coding assistants, you can spin up a working prototype in minutes. Features, refactors, tests, even documentation drafts appear almost instantly.

And yet—most AI-assisted projects stall.

They don’t fail spectacularly. They just… never quite finish.

This isn’t a tooling problem. It’s a leadership problem.

The AI-Start / Human-Finish Gap

What AI excels at:

• Generating code

• Suggesting fixes

• Drafting tests

• Writing documentation

What it struggles with:

• Knowing when something is done

• Coordinating across domains

• Enforcing quality gates

• Sequencing work into a real release

So we end up with a familiar pattern:

• Code mostly works

• Tests are partial

• Docs are “TODO”

• Security checks are postponed

• Releases are delayed or rushed

AI made starting cheap. Finishing became expensive.

Why This Is a Leadership Shift, Not a Productivity Issue

Historically, shipping software was about managing people:

• assigning tasks

• reviewing work

• coordinating handoffs

In AI-first workflows, much of the execution is handled by agents.

The new bottleneck isn’t execution.
It’s coordination, accountability, and definition of done.

This creates a new role that many teams haven’t named yet:

The Agent Leader

An Agent Leader doesn’t write every line of code.
They design the system of agents, define responsibilities, and enforce gates that turn output into outcomes.

Agent Leadership Means Building Agent Teams

One way to think about this is simple:

If you wouldn’t trust a single human to do everything, why trust a single agent?

Real teams specialize. Agent teams should too.

A concrete example of this idea is the Release Agent Team:
https://github.com/grokify/release-agent

It models the release process as a six-agent team, each representing a real-world responsibility.

The Six Agents That Make Finishing Deterministic

1. Release Coordinator

The leader and orchestrator.
This agent doesn’t do the work—it ensures all other agents have passed and sequences the release correctly. Final go/no-go lives here.

2. PM Agent

Defines intent:

• scope of the release

• semantic versioning

• breaking changes

• what the release means

Without this, releases drift or become arbitrary.

3. QA Agent

Owns correctness:

• builds

• tests

• linting

• runtime checks

This prevents “it works on my machine” from becoming a release.

4. Documentation Agent

Owns clarity:

• changelog completeness

• release notes

• README and user-facing docs

If users can’t understand the release, it isn’t done.

5. Security Agent

Owns safety:

• dependency vulnerabilities

• license compliance

• secret leaks

• security posture

Security isn’t a follow-up task—it’s a release gate.

6. Release Manager Agent

Owns mechanics:

• git hygiene

• CI readiness

• version availability

• tagging and pushing

This ensures the release process itself is correct and repeatable.

Together, these agents enforce a real Definition of Done.

Here are some real examples of team status:

Why This Matters Beyond Releases

The release process is just a starting point.

What this really demonstrates is a pattern:

• AI agents are powerful specialists

• Specialists need coordination

• Coordination requires explicit leadership

This applies to:

• product development

• research pipelines

• infrastructure changes

• documentation systems

• even non-software workflows

The teams that succeed won’t be the ones with the best prompts.
They’ll be the ones with the best agent architecture.

The New Skill Curve

In the AI era:

• Junior engineers learn prompting

• Senior engineers learn Agent Leadership

That means:

• designing agent roles

• defining responsibilities

• setting pass/fail criteria

• orchestrating workflows

• knowing when something is truly finished

The Takeaway

AI didn’t eliminate leadership.
It raised its abstraction level.

The future of software delivery isn’t about writing more code faster.
It’s about leading agent teams that can reliably finish what they start.

If you’re curious what that looks like in practice:
https://github.com/grokify/release-agent

This isn’t the final form—but it’s a glimpse of what Agent Leadership can become.

Once, AI’s work needed human review and polish. Now? Entire workflows can be handed over to AI agents—no expert oversight required.

Vibe Coding: From Concept to Cash

Software development used to demand years of training. Talent was scarce. Deadlines slipped. Over the past six months, though, a new reality has emerged: for certain projects, you don’t need a developer at all.

Enter the “Vibe PM.” First came the Product Engineer—combing Product Management and Engineering expertise. Now comes the Product Manager who codes through AI—Vibe Coding. It’s the art of building apps by guiding AI agents, not typing every line of code yourself.

The Prediction: Product Management Will Never Be the Same

Tech leaders have been sounding the alarm:

1. Why the next great PM will be a Product Engineer - November 16, 2024

2. The Rise of the AI Product Engineer: Redefining Product Development Through End-to-End Ownership - November 21, 2024

3. Product Management isn’t going to exist in 5 years - 2x CPO - February 18, 2025

4. The ‘vibe PM’ and the evolution of product management - March 27, 2025

The Reality: Millions Made in Months

Predictions are theory. Deals are proof.
In just six months, Base44 founder Maor Shlomo built and sold his solo-owned, vibe-coded startup to Wix for $80 million in cash. Twitter co-founder Jack Dorsey vibe-coded his latest messaging app. And Aha!—the product roadmapping giant—just launched its own AI-built prototypes.

1. 6-month-old, solo-owned vibe coder Base44 sells to Wix for $80M cash - June 18, 2025

2. That new Jack Dorsey messaging app? He vibe-coded it - July 10, 2025

3. The new Aha! AI assistant will change how you build products - July 16, 2025

Lovable: The Fastest to $100M—Ever

Driving this AI revolution is Lovable, the vibe-coding platform rewriting the rules of software creation. It rocketed from $1 million to $100 million in revenue faster than any other company—beating even AI heavyweights like Cursor and OpenAI.

Lovable turns app development into a conversation. You chat with its AI agent, describe what you want, and it builds the app for you—code, features, and all. No IDE. No syntax errors. Just your ideas, instantly alive.

And according to its website, that revenue is coming from over 500,000 users.

So… What’s It Like to Build with Lovable?

After exploring different vibe-coding platforms, I chose Lovable for my next experiment. I’d already built smaller vibe-coded projects—CI/CD pipelines, MCP servers—but this time I wanted to go bigger: a real, production-ready web app live on the internet.

Lovable gives you a chat interface powered by an LLM and integrates with services like GitHub and Supabase. I decided to skip the technical decision-making entirely—no debating frameworks or libraries—just feed it requirements and let Lovable choose the best implementation.

Six hours after dinner, my new app—VibeFlux.dev—was live. A fully functional MVP with Google and GitLab SSO, WCAG 2.3 AA accessibility, core features, and even some extras. I had it implement:

• A light/dark mode with six additional color themes, each in light and dark variations.

• A multi-type reaction system like LinkedIn’s.

All I did was provide requirements and run acceptance tests—classic Product Manager territory. The result? An incredible launch experience.

Join the Revolution—Start Vibe Coding Today

This AI-driven transformation isn’t waiting—and neither should you. Stop watching from the sidelines. Dive in, experiment, and start building with vibe coding right now. The future belongs to those who create it. So grab the tools, unleash your ideas, and lead the charge into the next era of product management. The wave is here. Catch it—today.

AI hasn’t just been democratized for end users — it’s also now accessible to companies offering services. No longer do you need to compete for a handful of PhD-level AI researchers to create a revolutionary new product.

With this explosion in productivity, everything — from understanding, to using, to enabling, to governing — is evolving at lightning speed. JohnWang.AI is here to explore these changes, because we all need to become lifelong learners… and fast!

What you’ll find here:

• Deep dives into AI trends and applications

• Practical guides and best practices for product management and engineering

• Stories and strategies from industry leaders shaping the future

• Tools, tips, and tricks to level up your craft

Join us in transforming code and concepts into real-world magic.

Subscribe now