DEV Community

Abhishek (landed)
Abhishek (landed)

Posted on AI-assisted

I gave my company 16 AI analysts. The bottleneck is now me.

I run landed mostly on my own. A job search product has a lot of moving parts: the landing page, signup, onboarding, matching, applications, emails, retention, costs. A normal company has an analyst or a PM watching each of those. I have me.

So last week I switched on something I'd wanted for a while. Every part of the company now gets reviewed every week by an AI, and the AI doesn't just write a report. It proposes fixes, opens the pull requests, and next week checks whether the fix moved the number it said it would.

It's the closest thing I've seen to a company that improves itself. Here's how it works, and the thing that surprised me most.

The loop

We call it DNA. It has 16 weekly reviews, one per area: Landing and SEO, Signup and onboarding, First session, Matching, Applications, Retention, Revenue, Cost, and so on. Each one runs the same cycle:

  1. Collect. A plain Python collector pulls that area's numbers from our database, PostHog, Search Console and the rest, and stores them as datasets a dashboard can render.
  2. Review. An agent reads the dashboard and last week's report and writes this week's: what moved, why it thinks it moved, and what's broken.
  3. Raise tasks. Every problem becomes a task with a kind (auto-fix, fix that needs my OK, improvement, or big idea) and, most importantly, a prediction: which metric should move, from what baseline, to what.
  4. Fix. Approved fixes ship as pull requests. Safe ones can merge themselves if I allow it for that area. Everything else waits for me.
  5. Measure. The next week's review scores each shipped task against its own prediction: worked, no effect, hurt, or too early.

On Monday I open one inbox called Needs you, and approve, drop or discuss what the agents raised.

A weekly report in DNA, written by the agent. Numbers hidden.
A weekly report the agent wrote for signup and onboarding. Numbers hidden.

What it actually found

The tasks are better than I expected, mostly because they're specific. A few real ones from the first week:

  • The Matching dashboard's collector was taking half an hour and timing out. The agent proposed a shared daily summary table so every chart reads from one precomputed view. Shipped.
  • Our email click numbers were inflated by data-centre scanners that open every link to check it for malware. The agent proposed leaving them out before anyone made a decision on fake clicks.
  • The daily job digest was still being built for a lot of people who never opened it. Small cost, but it added up.
  • Some remote jobs were tagged "remote, worldwide" when the posting clearly said one country. That breaks matching for everyone outside it.

And then the big ideas, which I didn't expect at all. The First session review proposed sending a user's first ready jobs the moment onboarding ends, instead of the next morning, with a prediction for how much it should lift day-one activity. That one is a PR now.

The task list for one review: each task has a kind, a status, the change it expects, and its PR. Numbers hidden.
Every task carries its own prediction and links to its PR. Numbers hidden.

The numbers after one week

In the first week, the agents raised 202 tasks across the 16 reviews. 74 shipped. They opened 51 pull requests and 49 have merged.

And exactly zero have a measured result yet.

That's not a bug in the system, it's the honest state of it. Most fixes shipped in the last few days, and a metric needs a week or two before you can tell a real change from noise. But it showed me something I hadn't understood before I built this.

Shipping got cheap. Knowing what worked didn't.

For most of my career the expensive part was building the fix. You'd argue about which three things to do this sprint because you could only do three.

That constraint is gone. The agents will happily raise 200 tasks a week and write the PRs for most of them. The new constraints are:

My attention. 66 tasks are sitting in "proposed", waiting for me to read them. The agents run every week without fail. I review on Mondays. If I had 16 human analysts, I'd be their bottleneck too, but they'd at least slow down to match me. The agents don't.

Measurement. If you ship 74 changes in a week, you can't tell which one moved your signup rate. Every task having its own prediction is what saves this. Without it, you just have a lot of activity and a feeling of progress.

Taste. The agents are good at finding what's broken. They're worse at knowing what matters. A dashboard can tell you a button gets few clicks. It can't tell you the button shouldn't exist.

What I'd tell anyone building this

  1. Make every task predict something. A fix without a metric, a baseline and an expected value isn't a task, it's an opinion. The prediction is what turns an AI that writes reports into one that learns.
  2. Measure next week, not this week. Scoring a change on the day it ships just measures noise. We score each task in the report the week after it ships.
  3. Separate safe fixes from everything else. Each area has a fix mode: off, PRs only, or auto-merge for safe fixes. Almost everything is "PRs only" today. Trust is earned per area, not globally.
  4. Keep the human step small and regular. One inbox, once a week. If approving things is a chore, you'll stop doing it and the whole loop stalls.
  5. Expect the bottleneck to move to you. That's the point. The work left for humans is choosing, not doing.

Where this goes

The interesting part comes in a few weeks, when the measure step has real data. Then each review knows which kinds of its own suggestions actually worked, and can propose more like those. That's the recursive part: a company where the system that improves things is itself improving.

Right now it's 16 tireless analysts and one founder trying to keep up. Next month I'll know whether they were right.


I'm building landed, which finds jobs that fit you and applies to them early.

Top comments (2)

Collapse
 
octyn profile image
OCTYN •

The bottleneck being you is the healthy version of this. The loop queues decisions, not work, and the Monday inbox means nothing ships without a named human choosing it. The part that makes the measure step real is the prediction per task: metric, baseline, target, written before the fix ships. Without that, next week's review grades on vibes. One thing worth watching at 16 reviews: whether the approval queue itself needs triage, because a Needs-you inbox with forty items becomes the thing you start skimming, and skimming is how unowned decisions sneak back in wearing an approved label.

Collapse
 
landedjobs profile image
Abhishek (landed) •

Thanks, that's the part I'd underline too. A fix without a written prediction is just activity. Writing the metric, baseline and target down before it ships is what makes the Monday inbox an argument instead of a to-do list. It also shows which of the 16 analysts are actually right over time.