DEV Community: Blake Aber

Your beta users are lying to you. Your synthetic ones won't.

Blake Aber — Mon, 29 Jun 2026 00:33:49 +0000

Real user research structurally excludes the people most likely to tell you what's broken. Synthetic focus groups plus behavioral eval personas close the gap. 30 minutes, under $2, before anyone knows you're building it.

Blake Aber · Predicate Ventures · 2026

"Get it in front of users as fast as possible."

Correct advice. Almost universally misapplied.

Most technical founders hear "get it in front of users" and reach for the same list: their waitlist, their Twitter followers, the three founders from the last cohort who owe them a favor. These people opted in before they saw the product. They're going to be polite about the parts that are broken.

What you actually need is signal from the people who tried your product and left, evaluated it and said no, and who'd warn a friend against it. They know more about your failure modes than your most engaged customers ever will.

The problem: they won't take your Calendly link. They've already moved on.

The three patterns that compound each other

Confirmation bias by selection. You recruit from your waitlist. Your waitlist signed up because they believed the pitch. You interpret enthusiasm as validation. You're asking people who already agree with you to agree again.

Optimizing for the early adopter who isn't your customer. Early adopters tolerate broken onboarding and missing docs. A reliability engineer at a 20-person company and a developer who "just wants to tinker" have different trust thresholds. Build for the tinkerer who stayed, churn the engineer who should have converted.

The silent abandonment problem. NPS is calculated from people who use your product. It says nothing about people who evaluated it last month and never activated, or activated, hit one silent failure, and quietly canceled. Those are your most important data points. You have no mechanism to reach them. A teardown of one agentic product's onboarding showed exactly this: 70% leaked before the moment of value, and every one of them was invisible to the team's interviews.

The sampling frame is the insight engine

This is not a survey. Not a chatbot asking leading questions. Not "ask an LLM to pretend to be your user."

The mechanism: declare a falsifiable hypothesis, define a sampling frame that forces inclusion of people who would never talk to you, run parallel synthetic interviews, score each hypothesis against what came back.

The hypothesis has to be falsifiable. Not "who are my users." That's a topic. Not "what do users think of our onboarding." That's a survey question. The same discipline that separates a specification from a prompt applies here: a vague ask returns vague output, whether you're prompting a model or interrogating a market. A falsifiable hypothesis takes a position:

"Do early adopters of multi-agent workflow tools abandon after initial setup because agent coordination failures erode trust faster than successful automations build it?"

The sampling frame mandates minimum representation from every adoption posture: adopters, partial adopters, abandoners, evaluators who rejected, people who've never tried it, people who actively warn others against tools like yours. The last three categories are the ones real user research structurally excludes. They're also the ones who know exactly what's broken.

Running this against a multi-agent tool hypothesis produced four behavioral archetypes:

Audit-Burdened Reliability Engineers. Treat silent partial correctness as strictly worse than a crash.
Solo Operators Retreating to Single-LLM Scripts. Tried multi-agent orchestration, concluded it multiplies hallucination surface without payoff, went back to single calls.
Pre-Refusal Pattern-Matchers. Recognize the silent-failure pattern from prior exposure, won't trial without a correctness story.
Hedged Partial Adopters. Quarantine the tool to low-risk workflows, keep paying, never expand.

These aren't demographics. They're behavioral archetypes defined by relationship to failure.

The decision report output: "Abandonment is almost always triggered by plausible-but-wrong output cosigned by a downstream agent, not by crashes."

Hypothesis verdicts, archetype profiles, prioritized interview questions. 30 minutes, under $2.

What Playwright can't tell you

In 2025, backend functionality ships at near-zero cost. The bottleneck isn't building. It's knowing whether what you built serves the person you built it for.

Playwright doesn't have goals. It doesn't feel friction. It passes tests on pages that would cause a real user to close the tab.

Behavioral persona evaluation uses the same browser automation substrate. Instead of testing "does the button click," it tests: Does Priya, a reliability engineer who won't trust a green checkmark over a probabilistic output, achieve her goal in this session?

I converted the four behavioral archetypes into canonical eval personas. Each with mindset, constraint profile, failure mode, and AI adoption history. Then I ran them as browser agents against the live product. They navigated the onboarding flow, selected goals, described their first tasks, and tried to reach the core product.

What they found was not what the research had predicted.

What the agents actually found

The research predicted: trust erosion at agent coordination failures. The moment a multi-agent pipeline produces a plausible-but-wrong output.

The eval found: trust erosion happening at a different inflection point entirely.

Priya navigated 11 pages deep: through /onboarding/goals, /onboarding/provider, /onboarding/first-task, into the authenticated product (Projects, Your Team, Workflows, Library). The navigation structure was intuitive. What she found inside:

No SOC2, HIPAA, or BAA documentation visible anywhere in the UI. A hard blocker for regulated-enterprise procurement.
Your Team page rendering a loading spinner with no agents to inspect.
Workflow creation returning a 500 error: no Anthropic key configured, nothing executes.

Maya (solo operator) got into /workflows/new?flow=brief. Her assessment: "I could see how someone would input a task like 'Triage incoming support tickets' and have the system generate a plan. That's the core value prop and it's conceptually sound."

She never got to use it.

The kill shot: after completing onboarding and clicking "Create a Plan," the app redirects to /login and discards all progress.

This happens after maximum user investment: 5 onboarding steps, a described workflow, a primary CTA click. The session dies with nothing saved. Two of four personas hit it independently:

"I just spent 10 minutes filling out my workflow and it dumped me back to login? If it loses my work I'm gone."

"I clicked 'Create a Plan' after filling in my first task and got sent back to login. That's not a feature gap — that's a broken flow."

A third finding, from Priya on the homepage:

"Wait, this says 'scan subscriptions for charges'? I came here for research workflow automation. Am I on the wrong site?"

The homepage headline described a subscription scanner. Every new user evaluating a multi-agent automation platform read it and questioned whether they'd reached the right product.

Playwright's verdict on all three: ✅ page renders, ✅ button exists, ✅ form submits.

Behavioral eval scores: overall 3–4/10. Trust: 1–2/10. Efficiency: 1–2/10. Would pay: 0/4. High retention risk: 4/4.

Top three backlog outputs:

Fix session loss on "Create a Plan." Users who complete onboarding must land in their workspace, not at /login.
Homepage headline. The copy describes a subscription scanner. Every persona who saw it questioned whether they'd reached the right product.
Pre-populated sandbox project. Every persona independently asked for proof-of-output before committing credentials or OAuth access.

The research → eval loop

1. State a falsifiable hypothesis (15 min)
2. Run synthetic research: 12 subjects, 4 segments (~30 min, ~$2)
3. Get hypothesis verdicts + behavioral archetypes
4. Bridge archetypes to eval personas (automated)
5. Run behavioral eval against your running app
6. Get prioritized backlog from 4 behavioral angles
7. Recruit real users — targeted questions, not open-ended discovery

Step 7 is where the shift happens. Instead of scheduling open-ended discovery calls with whoever takes the Calendly link, you recruit against specific archetypes (find someone who matches the Solo Operator pattern) and ask specific questions the research generated:

"Walk me through the last time a multi-agent tool produced a plausible-but-wrong output."
"What did you try before? Why didn't it stick?"
"If this worked perfectly, what would you be able to do that you can't today?"

If 2 of 3 real users contradict a synthetic finding, the finding is wrong. If 2 of 3 confirm it, you have a validated assumption: in 48 hours instead of 6 weeks.

The constraints

A language model simulating user behavior doesn't know your specific market, your NPS distribution, or your support tickets. It generates confident-sounding outputs about uncertain things. Every session produces a SYNTHETIC-DATA-NOTICE.md: "Treat every finding as a hypothesis to test, not a conclusion to act on."

The right use: synthetic research maps the hypothesis space fast enough to act before committing three months of engineering to the wrong direction. Real users prove whether the map is accurate.

On timing

Real user testing is expensive in calendar time, structurally biased toward people who opted in, and opaque about failure modes — churned users don't explain why they left.

Synthetic focus groups are cheap, fast, and structurally include the users who would never accept an interview request.

Use synthetic focus groups to decide what to validate. Use real users to validate it.

The most important user research is with people who don't want to talk to you. Synthetic simulation is how you hear from them first — before the product is public, before the pitch deck is final, before anyone knows you're building it.

AI for Venture Capital: A Practical Guide

Blake Aber — Mon, 29 Jun 2026 00:33:24 +0000

AI is reshaping how venture firms find, evaluate, and support companies—but only where the work is structured enough to model.

Blake Aber · Predicate Ventures · 2026

Where AI Fits in the Venture Workflow

Venture capital runs on three repeatable activities: sourcing deals, evaluating them, and supporting the companies you back. Each has a different ratio of structured data to human judgment, and that ratio decides where AI earns its keep.

Sourcing is the most data-rich part of the job. Diligence sits in the middle. Portfolio support is the most relational, and the hardest to automate.

The firms getting value from AI are not chasing a single tool. They are mapping each task to the right method and accepting that some parts of the job stay manual.

Deal Sourcing

Most firms still source through warm intros and inbound. That approach scales poorly and skews toward networks the partners already have.

AI changes the math by reading the entire market instead of the slice you already see. Models can scan company registries, hiring data, product launches, code repositories, and funding announcements to surface companies before they raise.

Signal extraction

The useful work is signal extraction, not list generation. A long list of startups is worthless. A short list of startups that just doubled engineering headcount, shipped a second product, and started hiring a head of sales is a real lead.

The models that work combine multiple weak signals into a ranked view. No single data point predicts a good investment. The combination narrows the field.

Ranking against your thesis

Generic sourcing produces generic results. The advantage comes from training the ranking on your own outcomes—which deals you took, which you passed, and how they performed.

This turns a partner's taste into a reusable filter. It does not replace the partner. It lets one analyst cover ten times the surface area.

Diligence and Evaluation

Diligence is where AI saves the most time and creates the most risk. The time savings are real. The risk is that a confident summary hides a shaky source.

Document review

Data rooms are dense and repetitive. Language models read contracts, financials, cap tables, and customer agreements faster than any associate and flag the items that need a human.

Use them to find the questions, not the answers. A model that surfaces an unusual liquidation preference or a missing assignment clause has done its job. A model that tells you the company is a good investment has overstepped.

Market and competitive analysis

AI compresses the early hours of market work. It maps competitors, estimates market size from public data, and assembles a first draft of the landscape.

Treat that draft as a starting point. The numbers need checking, and the framing reflects the model's training, not your conviction.

The hallucination problem

A model that invents a fact in a diligence memo is worse than no model at all, because it produces false confidence. Every claim that feeds an investment decision needs a traceable source.

The firms doing this well require citations on every generated statement and reject outputs that cannot point to a document. This discipline is the difference between a tool and a liability.

Portfolio Support

Once you invest, the value of AI shifts from selection to operations.

Monitoring

Firms manage dozens of companies with thin teams. AI reads board decks, financial updates, and product metrics to flag the companies drifting off plan before the quarterly call.

This is pattern detection, not advice. The flag prompts a conversation. The partner decides what to do.

Talent and customer matching

Much of a firm's post-investment value is connection. AI matches a portfolio company's hiring needs against the firm's network and matches their product against potential customers inside the portfolio.

The matching is mechanical. The introduction still requires a person who knows both sides.

Build Versus Buy

Most firms should buy. A handful with engineering teams and a clear edge should build.

When to buy

Vendor tools cover sourcing databases, document review, and CRM enrichment. They improve quickly and spread the cost of model development across many customers.

If your firm's edge is judgment and relationships rather than data infrastructure, buying lets you stay focused on the work that wins deals.

When to build

Build when your proprietary data is the asset. A firm with twenty years of outcome data and a distinct thesis can train ranking models that no vendor can replicate, because no vendor has the data.

Building also makes sense when your workflow is unusual enough that off-the-shelf tools force you to change how you operate.

The middle path

Most firms land between the extremes. They buy the infrastructure and build a thin layer of proprietary logic on top—custom prompts, scoring weights, and connections to their own deal history.

This keeps engineering cost low while preserving the part that reflects the firm's view.

What AI Does Not Do

AI does not pick winners. It widens the funnel and speeds the review, but the judgment about a founder, a market shift, or a moment in time stays human.

It does not build conviction. A model can tell you a company is growing. It cannot tell you whether you believe in the team enough to wire money.

It does not replace relationships. The best deals still come from trust built over years, and trust is not a feature you can ship.

How to Start

Pick one task with clear inputs and outputs. Deal sourcing or document review are good first choices because both have measurable results.

Run the AI process alongside your existing process for a quarter. Compare what it surfaces against what your team finds. Keep the tool only if it adds deals or saves hours you can prove.

Expand from there. A firm that adds one working AI process per quarter will operate differently in two years than one that waited for a single platform to solve everything.

The firms that win with AI treat it as a set of specific tools for specific jobs, not a replacement for the judgment that defines the business.

Is This Workflow AI-Ready? 3 Questions

Blake Aber — Sun, 28 Jun 2026 22:05:27 +0000

A two-minute self-check before you fill out the full Scorecard.

Blake Aber · Predicate Ventures · 2026

Not sure whether a workflow in your business is worth taking to AI? Start here. Three questions, two minutes. This isn't the full diagnostic. The 30-Day Shippable Scorecard is. But these three tell you quickly whether the conversation is worth having.

Question 1: Does one named person in your business spend 5 or more hours a week on this workflow?

If yes → keep going.

If no → not ready. AI can't return hours from a workflow no one has measured. Figure out who owns it and how much time it actually takes, then come back. The five AI wins under $10K each started with a named person whose hours were already measured.

Question 2: Does the workflow produce the same kind of output every time, even if the specific inputs vary?

If yes → keep going.

If no → probably not a 30-day fit. AI is good at "this looks like the last hundred of these. The answer is X." It's bad at novel situations that require judgment you've never applied before. If every instance of the workflow is fundamentally different, the problem is workflow definition, not AI.

Question 3: Would you be comfortable with AI handling 80% of this workflow if a human reviews the remaining 20%?

If yes → this workflow is worth a longer look. Forward it to whoever manages that workflow and have them fill out the 30-Day Shippable Scorecard.

If no → pause here. The 30-day model requires a human in the loop. Some workflows need to be 100% correct with no review stage: medical, legal, or financial decisions with direct consequences. That's a different conversation, and a different timeline.

If all three are yes, the workflow is likely in the zone. The 30-Day Shippable Scorecard takes 10 minutes. It tells you whether it's a clean fit before we ever talk.

The next chapter org psychology was always going to write

Blake Aber — Sun, 28 Jun 2026 22:04:46 +0000

Multi-agent systems aren't disrupting organizational psychology. They're the latest in a century-long pattern of coordination technologies that have reshaped the discipline from the inside out.

Blake Aber · Predicate Ventures · 2026

There's a bold claim making the rounds in AI circles: that organizational psychology as a discipline is being fundamentally reshaped by multi-agent systems.

I think the claim is correct. But not for the reasons most people assume.

The standard version of this argument goes something like: "AI agents are so powerful that they'll change everything about how we work, including the science of how we study work." That framing is both overconfident about the technology and underconfident about the discipline. It treats organizational psychology as a passive recipient of technological disruption. The discipline has always evolved in direct response to new coordination architectures.

Once you see that pattern, multi-agent systems stop looking like a speculative leap and start looking like the obvious next chapter.

The pattern: coordination technology in, disciplinary evolution out

Organizational psychology didn't emerge from abstract theorizing. It emerged from the factory floor.

Frederick Taylor's scientific management in the early 1900s wasn't just an efficiency framework. It was the first systematic attempt to optimize the fit between humans and the coordination technology of the industrial age: the assembly line. The resistance it generated, the social dynamics it created, the questions it raised about worker autonomy and meaning: those became the raw material for an entirely new field.

The Hawthorne Studies in the 1920s and 1930s arose because Taylorism couldn't explain what was actually happening when humans coordinated at scale. Elton Mayo discovered that informal relationships, group norms, and emotional dynamics drove productivity as much as process design. None of that had anything to do with time-and-motion studies. The human relations movement was born.

World War II forced another evolution. The coordination challenge wasn't factory throughput. It was placing millions of people into the right roles across a technologically complex military apparatus. New psychometric tools, team development methods, and performance systems emerged not from theory but from operational necessity.

The shift from industrial to knowledge work in the mid-20th century spawned yet another wave: organizational culture, psychological safety, team dynamics, intrinsic motivation. Peter Drucker didn't invent knowledge work and then wait for psychologists to study it. The coordination architecture changed, and the discipline followed.

Email. The cubicle. Distributed teams. Slack. Zoom. Each coordination technology didn't just change work. It changed what organizational psychologists needed to study, measure, and design for.

The pattern is remarkably consistent: new coordination technology → new social dynamics → new organizational psychology.

Why multi-agent systems are the next inflection

Every previous coordination technology changed how humans coordinated with other humans. Email changed asynchronous communication. Slack changed real-time collaboration. Zoom changed distributed presence. But the agent on the other end was always a person.

Multi-agent systems introduce something categorically new: coordination between humans and non-human agents, and between non-human agents themselves.

This isn't theoretical. Anthropic's 2026 Agentic Coding Trends Report describes multi-agent systems replacing single-agent workflows. Orchestrator agents delegate subtasks to specialized agents working in parallel. Less "chatbot helper," more "AI scrum team." Their Opus 4.6 model introduces "agent teams" where multiple AI instances work in parallel, with a lead session coordinating work, assigning tasks, and synthesizing results while team members communicate directly.

The infrastructure being built for these systems reads like an org design textbook: role definition, task allocation, permissions, state management, handoff protocols, error recovery. In practice, these primitives are exactly what spec-driven orchestration encodes as machine-readable contracts. Anthropic's Managed Agents platform is already in production at Notion, Asana, Sentry, and Rakuten. It handles secure sandboxing, long-running session management, multi-agent coordination, and scoped permissions.

These are organizational coordination primitives. They just happen to be running on silicon instead of being mediated through Slack channels.

What the experts are actually saying (and why the disagreements strengthen the case)

The most interesting thing about the current discourse: even the people who disagree about the technology agree about the organizational implications.

Ethan Mollick, perhaps the most empirically grounded observer of AI in organizations, has been explicit. In a Deloitte interview, he stated flatly that the transition from AI as a tool to AI as a workforce "is not actually a technology problem. It's a process problem." At Valence's 2026 AI & Workforce Summit, he argued that HR (not IT) is the function best positioned to lead organizations through the agentic transformation. That's an organizational psychology claim, not a computer science claim.

His research has surfaced a phenomenon that belongs in every I-O psychology textbook: the most advanced AI users inside organizations are often working in secret, hiding their usage because 2023-era policies create fear of punishment rather than enablement. That's a psychological safety problem. Amy Edmondson would recognize it immediately.

Adam Grant has been updating his priors in public, a scientist's highest virtue. At Indeed FutureWorks 2025, he admitted he'd been confident that AI wouldn't catch up to human empathy. Then the evidence showed that people actually felt more supported chatting with AI than with humans in certain contexts. He's now actively researching "cognitive debt": how accelerated AI adoption may reduce human capacity over time. These are organizational psychology questions that didn't exist three years ago.

Gary Marcus provides the essential counterargument, and paradoxically strengthens the case. His prediction that AI agents would be "endlessly hyped but far from reliable, except possibly in very narrow use cases" has been largely validated. RAND research found that over 80% of AI projects fail at roughly twice the rate of non-AI IT projects.

But here's the thing: Marcus's critique is about technical reliability, not about whether the organizational questions are real. His argument actually makes the organizational psychology case stronger. If you're deploying imperfect agents into human workflows (and organizations are doing this at scale), you need more organizational science, not less. You need better frameworks for trust calibration, human oversight design, error recovery workflows, and the psychology of appropriate delegation to imperfect systems.

Dario Amodei has been perhaps the most direct about the structural implications. In his January 2026 essay "The Adolescence of Technology," he warned that AI could displace half of all entry-level white-collar jobs within one to five years. He raised the prospect of wealth concentration exceeding the Gilded Age. These aren't technical predictions. They're organizational and societal restructuring predictions that demand psychological science to interpret.

The specific questions that break existing models

Multi-agent systems don't vaguely "affect" organizational psychology. They break specific existing models and demand new ones:

Trust and delegation. The canonical models of organizational trust (Mayer, Davis, and Schoorman's framework of ability, benevolence, and integrity) were designed for human-to-human relationships. How do you calibrate trust in an agent that's 95% reliable on routine tasks but fails unpredictably on edge cases? Part of the answer is technical, the kind of observability and silent-failure detection that production harness engineering provides, but the calibration problem is psychological. Aviation psychology has studied "automation complacency" for decades. Now every knowledge worker faces the same challenge. Mollick captured this: if we don't think hard about why we're doing work, "we are all going to drown in a wave of AI content."

Team composition. Joan Woodward's contingency theory showed that optimal organizational structure depends on production technology: small-batch versus mass production versus continuous process. Multi-agent systems create a new category entirely. Teams where some members are human, some are specialized AI agents, and the coordination architecture is software-defined and reconfigurable in real time. The group dynamics literature has no model for this.

Performance attribution. Anthropic's data shows developers use AI in roughly 60% of their work but can fully delegate only 0–20% of tasks. When a human architect directs three agents that produce the code, who "performed"? Traditional performance management assumes you can attribute outcomes to individuals. That assumption is breaking.

Identity and meaning. Amodei's essay raises the deepest question: what happens to human purpose in a world where AI exceeds human capabilities across virtually all domains? This is an existential challenge for a discipline built on the premise that work is a site of human meaning-making.

The honest framing

Am I saying the transformation is complete, or that current multi-agent systems are mature? No. The failure rates are real. The reliability gaps are real. Many organizations are still running 2023-era AI governance playbooks against 2026-era capabilities.

But the parallel to previous transitions holds. Scientific management didn't arrive fully formed at the Bethlehem Steel Works. The human relations movement didn't spring complete from the Hawthorne plant. The discipline evolved because new coordination technologies forced new questions that existing frameworks couldn't answer.

Multi-agent systems are doing precisely this, at a velocity and scale that exceeds any previous coordination technology shift.

The discipline isn't being reshaped because the technology is perfect. It's being reshaped because the questions have changed.

And organizational psychology has always followed the questions.

Internal First, Portfolio Second

Blake Aber — Sun, 28 Jun 2026 22:00:03 +0000

The sequencing mistake most PE firms make with AI programs. And the 90-day internal win that changes the calculus.

Blake Aber · Predicate Ventures · 2026

The pattern I keep watching: a PE firm announces an AI initiative for its portfolio companies. The announcement is LP-facing. The initiative is visible. The firm looks like it's ahead of the curve.

Eighteen months later, the portfolio companies are still running pilots. The AI initiative is still being announced. The GP team has spent considerable time running workshops and writing frameworks. Portco results have been uneven.

The problem isn't that the firm was wrong about AI. It's that the sequence was wrong.

Why firms start with portfolio AI

The LP optics pull strongly toward portco visibility. AI transformation at the portfolio level is a thing you can describe in a fund letter. It sounds like value creation. It's what other GPs are talking about at conferences.

Internal AI (AI that makes the GP team's work better) is invisible from the outside. No LP ever asked a GP: "How much faster are you doing due diligence now that you've automated memo synthesis?" The incentive to publicize what's visible outweighs the incentive to build what's useful.

So firms start with portfolio AI. The GP team hires a "Head of AI" or brings in consultants. The portcos get workshops. Some pilots run. Some don't.

The problem with portfolio AI first

Here's what the firms that sequence this way discover at around year two: they're trying to provide AI support to portfolio companies without having built the AI muscle internally.

When a portco CTO calls to ask for advice on eval harness design, the GP team doesn't have a practiced answer. They haven't built an eval harness themselves, so they can't speak to why production AI is mostly harness and only a little model. When a portco initiative stalls at the organizational seam between product and engineering, the operating partner doesn't know how to diagnose it. They haven't worked that seam internally.

The advice is conceptually correct but operationally thin. The portco can tell. The relationship suffers.

Firms that skip internal AI first are usually still doing portfolio AI three years later with thin results. They haven't compounded, because you can't compound from a base you don't actually have.

The sequence that works

Internal ops AI first (0-9 months): Start with the GP team's own workflows. Three of them work in 90 days or less, without enterprise-scale infrastructure:

Due diligence memo synthesis. A named analyst spends 8-12 hours per deal synthesizing interview notes, financials, and reference calls into a memo. AI reduces this to a 90-minute review and editing job. Ships in 30 days. Immediate compounding.
LP reporting automation. The quarterly LP letter has a predictable structure and a predictable set of inputs. AI drafts 80% of it. The senior team reviews and personalizes the 20% that matters. Ships in 45 days.
Deal-screening signal surfacing. The analyst team is reading a thousand news items and LinkedIn posts a week looking for signals that match the investment thesis. AI surfaces and scores the relevant ones. Human judgment remains the gate. Ships in 60 days.

Internal investment AI (9-18 months): Build on the internal muscle. Now the GP team can talk about AI from experience, not from frameworks.

Portfolio AI support (18+ months): Now you're actually helpful to portcos. You've solved the problems they're facing. You can speak to the organizational seam question, the eval harness question, and the build-versus-shepherd staffing question that sinks junior-IC-led programs from lived experience.

The question worth asking

What is the internal AI your GP team runs on today?

Not what you've recommended to portcos. Not what you've told LPs. What is the AI that your analysts and partners actually use, every week, to do their jobs faster and better?

If the answer is vague, that's where the AI program actually starts.

The IC Trap

Blake Aber — Sun, 28 Jun 2026 21:59:23 +0000

Why assigning AI transformation to your best junior engineer is a rational decision that almost always fails.

Blake Aber · Predicate Ventures · 2026

Let me steelman the decision first, because it genuinely looks smart.

A portfolio company has a talented young ML engineer. She's excited about the AI initiative. She understands the technical stack. She has time, or can make time. She's already an employee, so there's no recruiting cost. And she's cheap relative to a senior outside hire.

So the GP suggests: put her in charge of the AI program. She builds the prototype. It's impressive. Everyone agrees it could ship in 90 days.

Eighteen months later, the prototype is still not in production. The engineer is still in charge. The company is still "almost ready to ship."

This is the IC trap.

What the IC can't do

The individual contributor can build. What she can't do, not because she's incompetent but because of her organizational position, is shepherd.

Shepherding an AI program into production requires walking into a VP's office and saying: "This workflow needs to change, and I need you to change it before we can ship." It requires telling a department head that the process they've run for seven years is the reason the AI can't work. It requires the authority to reject a scope change from a senior stakeholder, even when that stakeholder outranks you.

An IC doesn't have this authority. She can flag the organizational blockers. She can write them up in a Confluence doc. She can escalate them to her manager. But she cannot resolve them herself. The blockers sit in the backlog, and the prototype sits in development.

The failure mode looks like this: excellent technical work, accumulating organizational debt, a growing list of "dependencies on other teams" that never resolve. This is the same organizational seam where portfolio AI programs stall: no one with the authority to resolve the blockers actually owns them. The prototype is impressive at month three. It's still impressive at month eighteen. It's never in production.

A composite example

At one portco I've seen this pattern, the Head of AI was a brilliant ML engineer in his mid-twenties who'd shipped four compelling demos in his first six months in the role. The VP of Sales had never seen any of them. Not because the demos were bad. Because no one had built the bridge between "here's what the AI can do" and "here's how the sales team's workflow needs to change to use it." The engineer didn't have the organizational authority to build that bridge. So it never got built.

The demos got better. The production deployment didn't happen.

The staffing pattern that works

The person who builds the AI and the person who shepherds the adoption are almost never the same person. These are different skills, and more importantly, they require different organizational positions.

Build is an IC job: machine learning, engineering, evaluation harness, observability infrastructure. Find your most technically capable person.

Shepherd is a senior practitioner job: workflow change management, stakeholder alignment, specification clarity, production ownership. Find someone with the organizational authority to get a workflow changed, and pair them with the builder.

At portcos under 100 people, the shepherd is often a fractional engagement rather than a full-time hire. The domain expertise is already in the company. What's missing is the person who can move the org around the AI program rather than waiting for the org to accommodate it. This is also why firms that build the AI muscle internally before pushing to portfolio tend to staff these roles more deliberately: they've felt the build-versus-shepherd split firsthand.

How to Implement AI in Business Without Wasting a Quarter

Blake Aber — Sun, 28 Jun 2026 21:54:40 +0000

Most companies do not have an AI problem. They have an execution problem.

Blake Aber · Predicate Ventures · 2026

That distinction matters when you decide how to put AI into a business. The market is full of demos, vendor promises, and one-off experiments that never reach daily operations.

What moves the needle is not access to more tools. It is a disciplined plan that ties AI to margin, throughput, client experience, and risk control.

The right question is not "Where can we use AI?" It is "Where can AI remove friction, improve decision quality, or increase output without adding operational chaos?" That is where implementation starts to stick.

Implement Through Priorities, Not Model Debates

AI should enter a business the way any meaningful operational initiative does: through business priorities, process analysis, and accountability.

If the work starts with a model selection debate or a broad innovation mandate, it usually drifts. If it starts with a specific workflow tied to cost, speed, revenue, or quality, it has a much better chance of producing a real return.

The first step is choosing a narrow business problem with visible economics. Good candidates sit in repetitive, delay-prone, or judgment-heavy processes.

Client intake, sales qualification, proposal generation, support triage, internal knowledge retrieval, document review, scheduling, and reporting are common examples. They are not glamorous, but they affect labor cost, turnaround time, and customer responsiveness.

Not every process fits. If a workflow is poorly defined, changes every week, or depends on tacit judgment no one has documented, automation may expose the mess rather than solve it. In those cases, light process design has to happen first.

Start With Business Value, Not Features

Executives often get pulled into conversations about model quality, copilots, agents, or platform comparisons. Those details matter later. At the start they distract from the bigger question: what result are you buying?

Identify one metric that should improve if the implementation works. Reduced time to first response. Fewer hours spent on manual review. More proposals per employee. Lower churn in support. Faster close cycles.

If there is no clear metric, the initiative is still too vague.

This is also where trade-offs surface. Some use cases are easy to deploy but produce modest gains. Others carry larger upside but require integration work, policy controls, and stronger change management.

A firm improving internal meeting notes can move quickly. A healthcare-adjacent company automating intake recommendations needs much more oversight. Speed matters, but not more than business fit and risk profile.

Assess Your Data and Process Reality

AI systems are only as useful as the inputs, workflows, and decisions around them. You do not need perfect data before starting. You do need a realistic view of what the system will read, generate, classify, or recommend.

Look at three things.

Where the information lives

If the use case depends on data spread across inboxes, PDFs, CRMs, shared drives, and team chat, implementation is possible, but orchestration becomes part of the project.

Whether the process is consistent

If five employees handle the same task five different ways, define the target workflow before layering in AI.

What accuracy is actually required

Some internal draft-generation tasks tolerate occasional errors when a human reviews the output. Client-facing or regulated workflows need stricter guardrails.

Many businesses either overestimate readiness or become too cautious. You do not need enterprise-grade data infrastructure to begin. You do need enough process clarity to know what the system should do, when a human should intervene, and how success will be measured.

Build a Pilot That Survives Contact With Operations

A pilot should be small enough to launch quickly and serious enough to test real operating conditions. That usually means one workflow, one team, one owner, and one decision path.

A professional services firm might deploy AI to draft follow-up emails and summarize discovery calls for business development. A startup might categorize inbound support and recommend responses. A mid-market operations team might automate invoice exception review or internal knowledge retrieval for frontline staff.

Each pilot is narrow, measurable, and tied to existing work. The goal is not to prove AI is interesting. The goal is to prove the business can use it repeatedly, safely, and consistently enough to justify broader deployment.

That shapes the design. A pilot needs a clear owner, baseline metrics, usage expectations, escalation rules, and a review cadence.

If no one owns adoption after the demo, the project stalls. If no one tracks impact, it becomes a belief system instead of an operating improvement.

Treat Governance as Part of Implementation

Governance cannot be deferred until after the tools are already in use. By then, informal adoption has usually spread faster than policy.

At a minimum, a business needs clarity on what data can be used, which systems are approved, when human review is required, and how outputs are monitored.

The right level depends on company size, customer expectations, and regulatory exposure. A 15-person firm does not need the same control structure as a 300-person organization handling sensitive financial or customer records. Both need basic operating rules.

This is where initiatives become too loose or too heavy. Too loose, and you create security, compliance, and quality risk. Too heavy, and the team avoids the tools entirely. Good governance makes deployment safer and faster, not buried in approval cycles.

Choose an Implementation Path That Fits Your Size

Business size affects AI implementation more than most vendors admit.

Startups usually benefit from focused advisory and technical direction rather than broad platform rollouts. They need speed, a sensible architecture, and enough governance to avoid building fragile systems they will have to replace. Often that means lightweight internal automation paired with a product strategy lens, especially if the company plans to present AI capability to investors or customers.

Smaller firms with 5 to 50 employees get the best results from workflow automation tied to client delivery and back-office throughput. They rarely need a large transformation program. They need a few high-impact systems that reduce administrative drag and let a lean team operate at a higher level.

Mid-market companies need more structure. The challenge is not just identifying use cases. It is aligning stakeholders, integrating with existing systems, managing access controls, and building a repeatable operating model. Assessment, pilot design, and deployment governance matter more than tool experimentation.

Measure Outcomes That Finance Will Respect

Many AI projects look promising in a demo and weak in a budget review because the measurement model is sloppy. Saying a team "saved time" is not enough.

The business needs to know whether savings changed throughput, reduced staffing pressure, improved retention, increased capacity, or lowered error rates.

Define value in operating terms. If AI cuts proposal drafting from three hours to 45 minutes, what happened next? Did the firm send more proposals, respond faster, or improve win rate? If support triage became faster, did response times improve enough to affect satisfaction or renewal risk?

Those second-order effects are where the real return sits.

This is why systematic adoption outperforms ad hoc tool usage. When implementation connects to process owners and operating metrics, you can decide whether to expand, refine, or stop. That discipline matters more than enthusiasm.

Expect Change Management to Be Part of the Job

AI implementation is not purely technical. It changes how people work, what they trust, and where decisions get made. Some employees over-rely on it. Others ignore it. Both responses are normal.

The fix is not motivational messaging. It is operational clarity. Teams need to know what the tool is for, where it helps, what good usage looks like, and where human judgment still applies.

Training should be tied to actual workflows, not abstract AI education. When people see the system reduce repetitive work without lowering quality, adoption gets easier.

This is where an execution-first partner is useful. Firms like Predicate Ventures focus on moving from assessment to deployment with business controls intact, which is often the missing piece for companies that know AI matters but lack the internal bandwidth to architect it correctly.

The companies that get value from AI are rarely the ones making the loudest announcements. They treat implementation as an operating decision, not a branding exercise. Start with one workflow that matters, put guardrails around it, measure the result, and expand from there. That is usually how real progress begins.

AI Strategy and Implementation That Works

Blake Aber — Sun, 28 Jun 2026 21:53:59 +0000

The gap between AI interest and AI results is rarely about model quality. It is about execution.

Blake Aber · Predicate Ventures · 2026

Most companies do not have an AI problem. They have an execution problem.

The distance between interest and results is usually not model quality or tooling. It is the absence of a clear plan tied to one business outcome, one owner, and one operating process that can actually change.

That distinction matters whether you run a startup, a professional services firm, or a mid-market company under real delivery pressure. Leaders do not need another workshop on what AI could do someday. They need a disciplined way to decide where it belongs, how it gets deployed, who owns it, and what financial improvement it is expected to produce.

What AI strategy and implementation actually means

Strategy is the decision layer. It defines where AI fits in the business, which workflows matter most, what success looks like, and what risks are acceptable.

Implementation is the delivery layer. It turns that strategy into working systems, operating rules, integrations, and measurable process changes.

Many firms separate these two steps too aggressively. That is where momentum dies. Strategy without implementation becomes slideware. Implementation without strategy creates scattered pilots that never reach daily operations.

The right approach connects both from the start, so every recommendation is judged by whether it can be deployed, adopted, governed, and measured.

For most leadership teams, this is less about buying a platform and more about redesigning a process. If the workflow is unclear, the approvals are inconsistent, or the data is unreliable, AI amplifies confusion rather than removing it.

Start with operating pain, not AI use cases

The fastest way to waste budget is to ask, "Where can we use AI?" That question sounds reasonable, but it produces a long list of disconnected ideas.

A better question is, "Where is the business losing time, margin, consistency, or client confidence?" That shift changes the conversation immediately.

A law firm may not need a dozen AI pilots. It may need faster intake, cleaner matter summaries, and better internal knowledge retrieval. A services business may not need generative AI across every team. It may need faster proposal drafting, stronger CRM hygiene, and fewer manual handoffs between sales and delivery.

Start with operational friction that already has a cost. If you can quantify the current pain, you can prioritize implementation rationally. If you cannot quantify it, you are probably still in the idea stage.

The best priorities are narrow

Executives often assume the first AI initiative should be broad and transformative. In practice, the best first move is usually narrower than expected.

It should affect a real workflow, touch a manageable set of users, and produce a visible business result in weeks, not quarters. That might mean reducing client intake time by 60 percent, cutting internal research time in half, or improving support response quality without adding headcount.

These are useful starting points because they are operationally specific. They have a baseline, a process owner, and a path to adoption.

Broad ambitions are still valid. But they come after the business proves it can move from concept to production. AI maturity is earned through repeatable execution, not announced through strategy decks.

What good implementation looks like

A credible implementation has four parts working together.

Define the workflow

Understand how work moves today, where decisions happen, what inputs are needed, and where errors or delays occur. Without this map, teams automate isolated tasks while leaving the real bottleneck intact.

Match technical design to risk

Some use cases run on lightweight tools and standard APIs. Others need stronger controls, human review, audit trails, or private infrastructure. There is no prize for overengineering, but underengineering client-facing or regulated workflows creates expensive problems later.

Assign ownership of adoption

This is often missed. A technically sound solution still fails if nobody is accountable for rollout, training, exception handling, and process enforcement. AI changes work. If leadership does not manage that change directly, usage becomes inconsistent and the business never captures full value.

Measure against operating metrics

Time saved is useful, but margin impact, cycle time reduction, utilization improvement, conversion lift, and service quality are better indicators of whether implementation is worth expanding. Vague satisfaction scores are not.

Why pilots fail

Most failed pilots are not technology failures. They fail because the business treated the pilot as a demo rather than a controlled operating experiment.

A demo proves a model can generate output. A pilot proves a business can use that output inside a real process with acceptable quality, speed, and oversight. Those are very different standards.

Pilots usually stall for one of three reasons. The first is poor problem selection: teams choose something flashy instead of something operationally valuable. The second is weak governance: nobody decides where human review is required, what data can be used, or how performance gets monitored. The third is the lack of an implementation path: even when the pilot works, there is no plan for integration, ownership, or process change.

This is why serious firms treat pilots as production rehearsals. The point is not to impress stakeholders. It is to generate enough evidence to make a deployment decision with confidence.

Different companies need different operating models

A startup does not need the same model as a 200-person services company. Company stage matters because decision speed, process maturity, and internal technical capacity all change the shape of the work.

A startup often needs fractional senior guidance more than a large program. The focus is usually product direction, investor-ready technical clarity, lean internal automation, and early governance choices that will not create debt later. Speed matters, but so does architectural discipline.

A firm with 5 to 50 employees usually benefits from workflow-level automation and practical systems design. Intake, proposals, documentation, scheduling, reporting, and knowledge retrieval often produce immediate returns. Leadership in these firms wants fast implementation and clear savings, because every recovered hour affects capacity and client service.

A mid-market organization with 50 to 500 employees needs tighter coordination across functions. The challenge is less about finding use cases and more about sequencing them, standardizing governance, and avoiding fragmented tools across departments. Here, AI should be treated as an operating capability, not a series of isolated experiments.

Governance is not optional overhead

Many executives hear "governance" and assume bureaucracy. That is usually a mistake. In AI deployments, governance is what allows a company to move faster without creating preventable risk.

Good governance answers practical questions. What data can be used? When is a human required to review output? Which systems are approved? How are prompts, agents, and automations versioned? What happens when output quality drops or a workflow changes upstream?

The right level depends on the use case. Internal drafting support does not need the same controls as client-facing decision support. But every company needs a minimum operating standard. Without one, teams improvise, and improvisation becomes hidden risk.

This is one reason firms like Predicate Ventures focus on systematic adoption instead of one-off experimentation. The goal is not just to ship something quickly. It is to ship something the business can trust, extend, and govern over time.

How to evaluate whether AI is working

The cleanest test is whether the business runs better after deployment. That sounds obvious, but many teams still evaluate AI on novelty instead of operational effect.

A useful scorecard includes speed, quality, adoption, and financial impact. Did cycle times improve? Did output quality hold or improve? Are teams actually using the system in the intended workflow? Did the business reduce manual effort, expand capacity, improve conversion, or protect margin?

There is also a trade-off to watch. Some AI systems save time but increase review burden. Others improve consistency but reduce flexibility for edge cases. That does not make them bad investments. It means implementation needs refinement. Mature teams expect these trade-offs and adjust the operating design rather than declaring success too early.

The companies that win are usually the most disciplined

The market still rewards speed, but speed without structure creates rework. The companies getting real returns from AI are usually not the loudest adopters. They are the ones making sober decisions about process, ownership, controls, and metrics.

They pick a small number of high-value workflows. They assign executive ownership. They build with production in mind. They measure outcomes that finance and operations both respect. Then they expand from evidence, not enthusiasm.

That is the real advantage of strong AI strategy and implementation. It turns AI from a talking point into an operating capability. When a business does that consistently, the upside is not theoretical. It shows up in cleaner execution, faster teams, better client experience, and margins that improve for reasons you can actually explain.

The VC Due Diligence Process, Explained

Blake Aber — Sun, 28 Jun 2026 21:48:34 +0000

Due diligence is where a verbal yes either becomes a wire transfer or quietly disappears.

Blake Aber · Predicate Ventures · 2026

Most founders treat the term sheet as the finish line. It is closer to the starting gun. The due diligence process is the period between interest and money, and it is where deals slow down, get repriced, or fall apart.

Understanding the sequence helps on both sides of the table. Investors run it to confirm the story they were told. Founders survive it by knowing what is coming.

What Due Diligence Actually Tests

Diligence is verification, not discovery. By the time a firm starts, it already believes the company could be a good investment. The work that follows checks whether the claims behind that belief hold up.

Three questions sit underneath everything:

Is the business what the founder said it is?
Are the risks the ones the firm already priced in?
Will anything found later embarrass the partner who championed the deal?

That last question drives more behavior than founders expect. Diligence protects the investor's standing with their own partnership.

The Stages

The process moves from cheap checks to expensive ones. Firms front-load the work that can kill a deal fast.

Initial screening

This happens before any formal diligence. The partner forms a view from the pitch, the deck, and a few reference calls. Most companies are passed on here, and the founder never sees the deeper machinery.

A deal that clears screening gets a term sheet or a strong signal of intent. Diligence proper begins after.

Commercial diligence

The firm tests the market and the company's position in it. They look at customer demand, competition, pricing, and how the product is actually used.

This often means calling customers directly. A founder who lists references is signaling which conversations they are comfortable with. Sharp investors also find customers the founder did not name.

Churn gets examined closely. Logo retention, net revenue retention, and the reasons behind cancellations tell a clearer story than top-line growth.

Financial diligence

The numbers in the deck get reconciled against source data. Bank statements, accounting records, and revenue recognition all get reviewed.

Common snags surface here. Bookings counted as revenue. One-time deals presented as recurring. A burn rate that assumed funding already in hand.

For earlier-stage companies the financial review is lighter, because there is less to examine. For growth-stage rounds it can involve outside accountants and weeks of work.

Technical and product diligence

The firm assesses whether the product works and whether it can scale. This may include code review, infrastructure review, or a technical advisor speaking with the engineering team.

The deeper question is dependency. How much of the technology relies on one engineer, one vendor, or one model provider? Concentration risk shows up more often than outright failure.

Legal diligence

Lawyers review the cap table, the incorporation documents, IP assignments, and existing contracts. They confirm the company owns what it claims to own.

Problems here are usually fixable but slow. A founder who never signed an IP assignment, a former co-founder with unclear equity, an outstanding SAFE no one remembered. Each one adds days.

Reference and background checks

The firm calls people who have worked with the founder. Former colleagues, prior investors, and people not on the reference list.

These calls matter more at early stage than founders assume. With little business history to examine, the team is most of the asset. Investors are checking how the founder behaves under pressure and whether their account of past events matches other accounts.

How Long It Takes

Timing varies with stage and round size.

Pre-seed and seed: days to two weeks. Diligence is light; the bet is on the people.
Series A: two to four weeks. Commercial and financial review become real work.
Series B and later: four to eight weeks, sometimes longer. Outside firms get involved, and the document requests grow.

Speed is itself a signal. A firm that drags diligence is often hesitant and looking for a reason to walk. A firm that moves fast has usually decided and is confirming.

Why Deals Die in Diligence

Most failures trace to one of a few patterns.

The story did not survive contact with data. Growth that looked steady in the deck turns out to be two large customers. The reference calls reveal complaints the founder downplayed.

A new risk appeared. A legal issue, a key employee leaving, a customer concentration the firm had not priced.

The market shifted. A competitor raised, a buyer changed direction, the firm's own thesis moved. Diligence gives a polite exit.

Trust broke. A founder who was evasive, who hid bad news, or whose account kept changing. Investors rarely fund people they have caught being careless with the truth.

The last one is the most damaging because it is hard to recover from. A bad metric can be explained. A pattern of selective disclosure cannot.

How Founders Should Prepare

The founders who clear diligence smoothly do the work before the term sheet, not after.

Keep a data room ready. Financials, cap table, key contracts, and customer metrics should be assembled and current. Scrambling to produce documents reads as disorganization at best.

Disclose problems early. Every company has them. Surfacing a known issue at the start lets the investor price it. Letting them find it later looks like concealment, even when it was only an oversight.

Line up references who will speak honestly and well. Then accept that the firm will go past your list.

Know your own numbers cold. A founder who fumbles their churn rate or burn during a diligence call invites deeper scrutiny of everything else.

The Underlying Point

Diligence is the moment a firm decides whether to stand behind a deal in front of its partners. Founders who treat it as an adversarial audit tend to perform worse than those who treat it as the last step of a shared decision.

The goal on both sides is the same: confirm the company is what everyone hopes it is, and find the surprises while they are still cheap to address.

Will Private Equity Be Replaced by AI?

Blake Aber — Sun, 28 Jun 2026 21:48:31 +0000

AI will rewrite the work inside private equity firms long before it threatens to replace them.

Blake Aber · Predicate Ventures · 2026

The Question Is Framed Wrong

The question assumes private equity is a function that software can absorb. It is not. Private equity is a structure: pooled capital, a fee model, control positions, and a holding period that ends in a sale or recapitalization.

AI does not change that structure. It changes the labor that fills it.

The better question is which tasks inside a firm move from human hands to models, and what that does to the economics of the people who remain.

What AI Already Does Well

Deal sourcing is the clearest case. Mid-market firms screen thousands of companies to close a handful. Models now read filings, parse industry data, and surface candidates that match a thesis faster than an associate working through a list.

This compresses the top of the funnel. A team that once needed weeks to build a target universe can do it in days.

Diligence support follows. Models summarize data rooms, flag inconsistencies in financials, and draft first-pass memos. They do not replace judgment, but they remove the hours spent assembling the inputs to judgment.

Portfolio monitoring is a third area. Firms holding dozens of companies can track operating metrics continuously instead of waiting for quarterly board packages. Drift in a key number gets caught earlier.

These are real gains. They are also the parts of the job that junior staff did, which is where the pressure lands.

What AI Does Not Do

A control investment is a negotiation. Price, terms, governance, and the relationship with a founder or management team are set by people who can read a room and hold a position. A model can draft a term sheet. It cannot sit across from a seller who is deciding whether to trust the buyer.

Value creation after close depends on operating decisions inside a real company. Hiring a CEO, fixing a sales motion, integrating an acquisition—these require accountability that sits with a partner, not a system.

Fundraising is also human. Limited partners commit capital to people with a track record. They are buying conviction in a team, and that conviction is built over years of meetings, not generated by a model.

The parts of private equity that justify the fee are the parts AI handles poorly.

The Real Effect: Fewer People Per Dollar

The likely outcome is not replacement. It is a thinner firm managing more capital.

If two analysts can do the work that previously took six, the firm either takes on more deals or keeps the same volume with a smaller team. Both paths raise output per person.

This matters for how firms are built. The traditional pyramid—many juniors feeding a few partners—assumed a fixed amount of manual work at the base. As that work shrinks, the base narrows.

The result is a talent question. Firms have long trained partners by running them through years of associate work. If models do that work, the apprenticeship that produced senior judgment gets shorter and thinner. Where the next generation of partners comes from becomes a live problem.

Where Differentiation Moves

If every firm has the same models reading the same filings, sourcing stops being an edge. The advantage moves to proprietary inputs and relationships.

Firms with operating data from prior deals can build models that read a sector better than a generic tool. A consumer-focused fund that has owned twenty retail businesses knows which signals predict trouble. That knowledge, fed into a model, produces sharper screening than a competitor working from public data alone.

Relationships hold their value because they are not copyable. A firm known for treating founders well sees deals before they reach an auction. No model substitutes for that reputation.

The edge shifts from doing the work faster to having inputs no one else has.

A Note on the AI-First Fund

Some investors describe building a firm designed around models from the start—lean teams, automated sourcing, fast diligence. The pitch is that such a firm out-executes incumbents weighed down by headcount.

The logic holds for sourcing and analysis. It breaks at the parts that need people. An AI-first fund still has to negotiate, sit on boards, and raise capital from LPs who want to meet the team. The savings are real but bounded.

The more likely path is that incumbents adopt these tools faster than a new entrant can build a track record. Distribution and reputation are hard to start from zero, and those are exactly what models do not provide.

What to Watch

Three signals indicate how far this goes.

Deal velocity. If firms start closing meaningfully more deals per partner without quality dropping, the tooling is doing real work. Flat velocity suggests the gains are smaller than claimed.

Headcount mix. Watch the ratio of junior to senior staff. A shrinking base confirms that models have absorbed entry-level work.

Fee pressure. If AI cuts the cost of running a firm, LPs will eventually ask why management fees stay the same. The first firms to pass savings along will pressure the rest.

The Answer

Private equity will not be replaced by AI. The structure—pooled capital, control positions, a holding period, a fee for returns—does not dissolve because models can read a data room.

What changes is the work. Sourcing, diligence support, and monitoring move toward automation. The firm gets thinner, more capital flows through fewer hands, and the edge shifts to proprietary data and relationships.

The people most exposed are not the partners. They are the juniors whose work was the easiest to automate and the apprenticeship that turned them into partners. How firms solve that training gap will shape who runs private equity in a decade.

The institution survives. The job inside it does not look the same.

DEV Community: Blake Aber

Your beta users are lying to you. Your synthetic ones won't.

The three patterns that compound each other

The sampling frame is the insight engine

What Playwright can't tell you

What the agents actually found

The research → eval loop

The constraints

On timing

AI for Venture Capital: A Practical Guide

Where AI Fits in the Venture Workflow

Deal Sourcing

Signal extraction

Ranking against your thesis

Diligence and Evaluation

Document review

Market and competitive analysis

The hallucination problem

Portfolio Support

Monitoring

Talent and customer matching

Build Versus Buy

When to buy

When to build

The middle path

What AI Does Not Do

How to Start

Related reading

Is This Workflow AI-Ready? 3 Questions

Question 1: Does one named person in your business spend 5 or more hours a week on this workflow?

Question 2: Does the workflow produce the same kind of output every time, even if the specific inputs vary?

Question 3: Would you be comfortable with AI handling 80% of this workflow if a human reviews the remaining 20%?

Related reading

The next chapter org psychology was always going to write

The pattern: coordination technology in, disciplinary evolution out

Why multi-agent systems are the next inflection

What the experts are actually saying (and why the disagreements strengthen the case)

The specific questions that break existing models

The honest framing

Related reading

Internal First, Portfolio Second

Why firms start with portfolio AI

The problem with portfolio AI first

The sequence that works

The question worth asking

Related reading

The IC Trap

What the IC can't do

A composite example

The staffing pattern that works

Related reading

How to Implement AI in Business Without Wasting a Quarter

Implement Through Priorities, Not Model Debates

Start With Business Value, Not Features

Assess Your Data and Process Reality

Where the information lives

Whether the process is consistent

What accuracy is actually required

Build a Pilot That Survives Contact With Operations

Treat Governance as Part of Implementation

Choose an Implementation Path That Fits Your Size

Measure Outcomes That Finance Will Respect

Expect Change Management to Be Part of the Job

Related reading

AI Strategy and Implementation That Works

What AI strategy and implementation actually means

Start with operating pain, not AI use cases

The best priorities are narrow

What good implementation looks like

Define the workflow

Match technical design to risk

Assign ownership of adoption

Measure against operating metrics

Why pilots fail

Different companies need different operating models

Governance is not optional overhead

How to evaluate whether AI is working

The companies that win are usually the most disciplined

Related reading

The VC Due Diligence Process, Explained