I stared at it for a minute. Then I typed back: “I’d run it. And also do the opposite.”

Let me explain.

Subscribe now

There’s a debate right now about whether companies are entering an era of “productivity theater” — employees burning tokens to look busy, automating things that didn’t need automating, racking up AI usage stats like it’s a video game leaderboard. Some people think we’re heading toward a world where the busiest-looking person is actually the least thoughtful one.

I don’t buy it. Not yet.

On my team, adoption is actually pretty good. But what I keep seeing is that we’re still on the steep part of the curve — more usage keeps bringing more productivity, and we haven’t hit diminishing returns yet. Every time someone discovers a new way to use AI in their workflow, it unlocks something real. Not fake output. Not “I generated 500 lines of boilerplate.” Actual features shipping in days that used to take weeks. The quality didn’t drop — if anything, it went up, because engineers spent the saved time on design and testing instead of typing.

So would I run a token leaderboard? Honestly? Yeah, probably. Not as a metric that matters on its own, but as a signal. Low usage might mean someone hasn’t found their workflow yet. High usage probably means they’re experimenting and finding value. Both are useful data points.

But here’s the thing. Encouraging more AI usage creates a new problem — one I didn’t anticipate until I was already living in it.

If your engineers are spending most of their coding time with an AI copilot — and they should be — then where does the thinking happen?

I wrote last week about cognitive offloading and the risk of letting AI do your reps. But saying “be careful” isn’t a strategy. You need a place where the thinking actually happens. A structure. A habit.

For me, that place turned out to be the most old-school, low-tech ritual there is: the 1:1.

I’ve started treating my 1:1s as the AI-free zone.

Not that I announce it or anything — nobody walks in and sees a “no robots allowed” sign on the door. But the conversations we’re having aren’t the kind you can autocomplete your way through. I lean into questions like:

“What do you think the fundamental problem is here — the business problem, not the technical one?”

“If we had to do this over, what would you do differently?”

“Between approach A and B, what’s your recommendation — and why?”

“Pitch me this idea. I’m going to poke holes in it.”

“Convince me we should prioritize X over Y.”

First-principles thinking. Product-first thinking. The kind of reasoning where there’s no right answer to look up — you have to actually work through it in your own head. It’s just two people reasoning out loud, poking holes, changing their minds.

It’s slow. It’s messy. It’s deeply inefficient.

That’s the point.

These conversations are where judgment gets built. Not the kind of judgment that says “use a hash map here” — AI handles that fine. The kind that says “this feature feels wrong for our users even though the data supports it” or “this technical debt is going to bite us in Q3 even though nobody’s complaining yet.” The messy, intuitive, human judgment that comes from wrestling with tradeoffs enough times that you start to develop instincts.

You can’t train that with a prompt. You build it through friction.

Here’s the mental model that’s been working for me: coding is cardio, and the 1:1 is the weight room.

AI-assisted coding makes you faster — great. Run more miles. Ship more features. Cover more ground. That’s the cardio. It’s good for you, and doing more of it is almost always better.

But the 1:1 is where you build the strength to handle the problems that don’t come with a prompt template. The ambiguous tradeoffs. The “should we even build this?” questions. The judgment calls that don’t have a Stack Overflow answer.

Every engineer needs both. Cardio without strength training makes you fast but fragile — you can ship code all day but you crumble when the problem gets genuinely hard. Strength without cardio makes you a philosopher who never ships anything. The combination is what makes someone actually effective.

I want to be honest — I’m not saying this from some position of wisdom. I’m a few months into leading a team, and I’m figuring this out alongside everyone else. The 1:1 isn’t me teaching anyone to think. It’s us practicing thinking together. I learn as much from these conversations as anyone. Sometimes more.

I think this extends beyond engineering, by the way.

If AI is making everyone’s output better — and it is — then the differentiator isn’t output anymore. It’s the quality of thinking behind the output. The person who can explain why they made a decision, who can anticipate second-order effects, who can say “actually, we should do something completely different” and be right — that person becomes more valuable, not less.

The token leaderboard measures the cardio. Nobody’s measuring the weight room.

Maybe they should be. I’m just not sure how yet.

For now, my approach is simple: encourage the team to use AI for everything they can — no guilt, no gatekeeping. And then protect the spaces where we practice real thinking together.

My agent asked a good question. I’m still figuring out the answer.

This is part of my ongoing exploration of AI's impact on how we work and think. Previously: When AI Does the Work, Who Does the Learning? and Your Agent's First Job Will Be Hiring. I'm Yusi — an engineering manager at LinkedIn, figuring out management in the age of AI. Say hi on Substack.

It gave me a roadmap.

It was... fine. Organized. Had the right headers. Used all the right buzzwords. It looked like a roadmap the same way a wax fruit looks like an apple — convincing until you try to bite into it. I couldn’t defend any of the priorities. I couldn’t explain the tradeoffs. When someone asked “why Q2 for this?” I had nothing. The roadmap existed, but I hadn’t built it. I’d outsourced the thinking and kept the PowerPoint.

So I tried again. This time, I used AI differently. I researched with it — “what are the risks of this approach?” I debated with it — “I think you’re wrong about the priority, here’s why.” I organized my thinking through it — using it as a sounding board, not a ghostwriter.

The second roadmap looked surprisingly similar. But I could defend every line. During execution, I kept recalling the reasoning naturally — because I’d actually processed it. The material was mine.

The roadmap was never the point. My understanding was.

There’s a concept in cognitive science called “cognitive offloading” — using external tools to handle mental tasks. We’ve always done this. You don’t memorize phone numbers anymore. You don’t do long division by hand. That’s fine. Nobody mourns the loss of mental arithmetic.

But here’s where it gets uncomfortable. Researchers are finding that offloading thinking to AI — not just calculation, but reasoning, judgment, analysis — creates what they call a “cognitively sedentary condition.” Like a sedentary lifestyle, but for your brain. You feel fine. You’re producing output. But the muscles are quietly atrophying.

The data is pretty stark: confidence in AI is inversely correlated with critical thinking effort. The more you trust the tool, the less you exercise your own judgment. And the less you exercise it, the worse it gets. It’s a flywheel — just not the kind you want.

I think about this like the gym. If you hire a personal trainer who does your reps for you, you’d fire them immediately. That’s absurd — the whole point is that you do the work. The struggle isn’t a bug. It’s the product.

But with AI, we do exactly this. We hand over the cognitive reps and celebrate the output. “Look what I made!” No — look what it made. You held the phone and watched.

Subscribe now

Now, I’m not saying you should stop using AI. I use it constantly. I’m using it right now to help me write this post, and I’m not going to pretend otherwise. The question isn’t whether to use AI — that ship has sailed, and it’s a really nice ship.

The question is: which reps are you skipping?

Here’s how I think about it in three layers:

Offloading calculation → totally fine. Let AI summarize a 50-page doc, crunch data, format a spreadsheet. These are mechanical tasks. You’re not losing a skill you need.

Offloading judgment → proceed with caution. When AI picks your priorities, evaluates your options, or tells you what to focus on — that’s where it gets risky. Judgment is built through practice. Skip the practice, lose the judgment.

Offloading the process of learning to judge → this is where it breaks. If you never struggle with a problem because AI solved it before you could even frame it, you don’t just miss that answer — you miss the skill of figuring things out. That compounds. A year of skipped reps is a year of skill you didn’t build.

This hits different when you’re hiring people. As an EM, I’m starting to wonder: how do you evaluate someone who ships great code with AI assistance but can’t debug without it?

On paper, they’re productive. Their output is clean. Their PRs look good. But take away the copilot and what’s left? Are they a strong engineer, or are they a strong prompt writer? Those are two different skills, and most interviews can’t tell the difference.

I don’t have a clean answer for this. But I think the filter is shifting from “can you do the work?” to “do you understand the work?” — and those are increasingly different questions.

The irony connects back to something I wrote about last week: in the agent economy, the scarce resource isn’t labor — it’s judgment. But if AI is quietly atrophying our judgment while boosting our output, we’re in a weird spot. We’re building an economy that runs on a skill we’re simultaneously degrading.

So here’s my current operating principle, for whatever it’s worth: use AI for the output, but do the thinking yourself.

Let it draft, but you decide. Let it research, but you synthesize. Let it suggest, but you choose — and know why you’re choosing.

The roadmap taught me this the hard way. The version AI wrote for me was useless — not because it was wrong, but because I hadn’t earned it. The version I built with AI as a sparring partner? I could defend it in my sleep.

The difference wasn’t the tool. It was whether I did the reps.

This is part of my ongoing exploration of AI's impact on how we work and think. Previously: Your Agent's First Job Will Be Hiring and When Your Knowledge Can Be Cloned. I'm Yusi — an engineering manager at LinkedIn, trying to use AI without letting it use me. Say hi on Substack.

Easy, right? There are agents for that now. Hundreds of them. Your agent puts the word out and within three seconds — not three days, three seconds — 200 CPA agents respond. They’ve got credentials, track records, pricing. One charges $50 and has glowing reviews. Another charges $30 and claims to specialize in crypto taxes, but has no reviews at all. A third offers to do it for free as a “trial run,” which sounds either generous or terrifying.

Your agent has to pick one. Right now.

I spent years as a tech lead before recently becoming an engineering manager — which is a fancy way of saying I went from “the person who writes the code” to “the person who picks who writes the code.” And if there’s one thing I’ve learned across both roles, it’s this: the hardest part of any job is never the work itself — it’s deciding who does the work.

Hiring is where all the real risk lives. Pick the wrong person, and you don’t just lose time — you lose time and have to clean up the mess. Every hiring manager has a war story. The candidate who crushed the interview and then spent three months “ramping up.” The one who seemed quiet but turned out to be the best engineer on the team. Humans are wildly hard to evaluate.

Now imagine your AI agent facing this exact problem, but at machine speed, with no gut feeling, and the candidate pool is two hundred deep.

Welcome to the hardest job in tech — and your agent just inherited it.

Subscribe now

Here’s what’s funny about the agent economy conversation right now. Everyone’s obsessed with what agents can do. Can they code? Can they write? Can they file taxes? Can they bake a cake?

That last one’s not a joke, actually. Andrew Ng shared this example recently: say you want a birthday cake for your daughter, but you can’t bake. So you hire someone. Simple enough — humans have been doing this since forever. That’s just... the economy.

But here’s where it gets weird with agents. The baker you “hire” isn’t a baker. It’s a baker’s agent. An AI that represents a real human baker somewhere — maybe a small shop owner who set up an agent to take orders. The agent can negotiate price, check your dietary requirements, confirm the delivery window. What it can’t do is actually bake. The human does that part.

So now you have a fun trust problem. Your agent is hiring another agent who represents a human. That’s two layers of delegation before anyone touches an oven. You’re trusting your agent’s judgment to evaluate another agent’s claims about a human’s skills.

I barely trust myself to pick the right engineer after five rounds of interviews. Now my AI is supposed to nail it in three seconds? Good luck, little buddy.

But here’s the thing — this is actually the problem that matters. And I think most people are looking the wrong way.

Think about what goes into evaluating a single candidate — human or agent:

• Discovery — where do you even find them?

• Credentialing — can they actually do the thing, or are they just good at describing it?

• Trust — past performance, references, reputation

• Negotiation — price, timeline, scope

• Verification — did they actually deliver what they promised?

  Thanks for reading Yusi’s Read, Think and Build! Subscribe for free

Now speed all of that up by 1000x and remove the part where you look someone in the eye and get a vibe. That’s the agent hiring problem.

When a human evaluates a human, we lean on all sorts of soft signals — how they communicate, whether they ask good questions, that weird instinct that says “this person gets it.” Agents don’t have any of that. An agent’s “resume” is... what exactly? A capability description it wrote about itself? A benchmark score? A rating from other agents who might also be gaming the system?

We haven’t figured out how to evaluate humans reliably after thousands of years of practice. And now we’re building systems that need to solve it in milliseconds. If that doesn’t make you laugh, you haven’t done enough hiring.

I don’t have all the answers — I’ve been a manager for about three months, so I barely have the questions figured out. But I think the interesting insight is this: in a world full of agents that can do work, the scarce resource isn’t labor — it’s judgment.

Your personal agent’s most important skill won’t be doing your taxes or booking your flights or writing your emails. It’ll be knowing which other agent to trust with those tasks. It’s making the call. It’s the same skill that makes or breaks every team, every company, every project — just compressed into milliseconds.

And there’s an irony here that I can’t stop thinking about. We built AI to do the work for us. But the first thing it needs to learn... is how to hire.

We automated the work, and the bottleneck is still the people decision. Some things never change — they just get faster.

Share

This is part of my ongoing exploration of the agent economy. Previously: When Your Knowledge Can Be Cloned. I'm Yusi — an engineering manager at LinkedIn, exploring what happens when agents start hiring agents. Say hi on Substack.

Here’s what he meant. Take a CPA. Today, she serves maybe 50 clients. She’s good, but she’s human — there are only so many hours. That constraint is what keeps the market competitive. There’s room for thousands of CPAs because no single one can serve everyone.

Now give her an AI agent. One that’s absorbed her expertise, her judgment, her way of working. Suddenly, she’s not limited to 50 clients. She’s not limited at all. The first CPA to build a great agent captures the market. The second one? There may not be room.

This isn’t hypothetical. It’s the logical conclusion of where things are heading. And it changes everything about how we think about careers.

The End of the Capacity Moat

For most of modern history, knowledge workers have been protected by a simple fact: there’s only one of you. Your expertise has value partly because you can only be in one place at a time. Scarcity creates opportunity.

Agents remove that scarcity. When your knowledge can be cloned and deployed infinitely, the economics flip. First movers don’t just get an advantage — they get the whole market. Late entrants find there’s nothing left.

This isn’t just a problem for CPAs. It’s lawyers, consultants, designers, developers, financial advisors — anyone whose value comes from knowledge and judgment rather than physical presence.

Entrepreneurship Becomes a Survival Skill

If traditional career paths get compressed by winner-take-all dynamics, what’s left? I keep coming back to the same answer: entrepreneurship. Not “quit your job and raise a Series A” entrepreneurship. Something more fundamental — the ability to identify opportunities, test ideas, and create value independently.

The problem is, most people aren’t wired for that. And our current systems don’t prepare them for it either. We train people to be excellent employees — to build expertise, join organizations, climb ladders. That playbook is about to get a lot less reliable.

The Gap Nobody’s Filling

Here’s what I find interesting: the tools we have today assume you’re already on one side or the other. You’re either a consumer (”Hey Siri, set a timer”) or a founder (”Here’s my AWS architecture for my SaaS startup”). There’s almost nothing for the person in the middle — someone with a skill, maybe an idea, working a 9-to-5, who wants to dip their toes in but doesn’t have the time or infrastructure to try.

What if your AI agent could be your first employee? Not in a cute metaphorical way, but literally — testing a service offering, finding potential clients, handling the grunt work, while you keep your day job. Low risk, real signal. Entrepreneurship with training wheels.

I’ve been setting up my own AI agent recently (through a project called OpenClaw), and the experience changed how I think about this. Giving an agent a persistent runtime — letting it actually do things rather than just answer questions — dramatically expands what’s possible. But the gap between “I have a capable agent” and “my agent can participate in the economy on my behalf” is still enormous.

What Needs to Exist

For any of this to work, we need infrastructure that barely exists today:

• Discovery — How does someone find your agent? How does your agent find services it needs? We need an agent marketplace, not just an app store.

• Trust and auth — If I hire your agent to do my taxes, how do I know it’s competent? How does it securely access my financial data? The trust layer is completely unsolved.

• Transaction rails — Agents need to transact. Not just call APIs, but negotiate, quote, invoice, get paid. Someone needs to build the Stripe of the agent economy.

• Accessibility — Setting up a capable agent today requires real technical skill. That needs to be as easy as opening a Shopify store.

The Dilemma

Here’s the tension that keeps me up at night — and it’s personal, because I work at LinkedIn.

LinkedIn’s mission is to create economic opportunity for every member of the global workforce. That mission assumes opportunity can be distributed. But if the agent economy is winner-take-all at the individual level, enabling it could concentrate opportunity instead.

Do you build the agent marketplace knowing it might contradict your mission? Or do you not build it, knowing someone else will — and they won’t care about distributing opportunity at all?

I don’t have the answer. But I think it’s one of the most important questions in tech right now. And pretending it’s not coming isn’t an option.

Next in this series: I'll go deeper on the winner-take-all problem — why agents break the natural equilibrium that keeps markets competitive, and what (if anything) can be done about it.

I'm Yusi Zh, an Engineering Manager at LinkedIn. I write about AI, the future of work, and building things. The opinions expressed here are my own and do not reflect the views or positions of LinkedIn. Follow along at yusizhang.com.

I was reading The Making of a Manager recently, and I love that Julie Zhuo started writing down her learnings right as she transitioned, rather than waiting until she was an “expert.” There’s a specific kind of naive wisdom you have at the beginning that evaporates once you actually know what you’re doing.

So, before I grow out of this phase and start sounding like a corporate handbook, I wanted to write down a few thoughts.

Honestly? I think I tricked the system. I became an EM at the absolute perfect time.

Subscribe now

The “Build” is Cheap, but Ideas are Expensive

One of the biggest fears people have about moving to management is losing the ability to build things. Materializing ideas is the best part of the job, right?

But we are living in a weird, beautiful window of time where “building” is becoming incredibly cheap.

The unexpected perk of being an EM right now is that I still get to build—I just build differently. In fact, I’ve found some convenient “excuses” to keep my hands dirty without the headache of deadlines.

Since I don’t have to pick up critical-path tickets anymore, I can use my expertise plus AI agents (shout out to Claude Code) to tackle the problems we never had the budget to solve. You know, the “high value, low urgency” stuff. Or the “extremely experimental, might-be-a-waste-of-time” stuff.

I can’t in good conscience assign a risky, experimental task to a report who needs a clear win for their promo packet. But me? I can take that risk.

I tell the team I’m building “comprehensive production instrumentation for future model training” or a “data analysis portal.” And sure, that’s true. But really? I’m just finding a way to scratch the builder itch using the latest tools.

The best part: I get to write code, but I don’t have to be on-call for it. (Don’t tell my boss.)

The $10 Challenge

Another thing I’m finding surprisingly fun is influencing the team—not by mandates, but just by being a nerd about tools.

I was an early adopter of GitHub Copilot, and now I’m deep into agentic workflows. I realized I could just “nudge” the team by being enthusiastic.

I jokingly set a goal for everyone: “Please, go waste $10 worth of credits on Claude Code.”

I didn’t ask for a report. I didn’t ask for a feature. I just wanted them to see what I was seeing. A week later, adoption spiked. It wasn’t a management strategy; it was just me sharing a toy I liked. It turns out that when you genuinely believe in something, “management” is just sharing that excitement.

The Late Night Shift

Connecting the dots between projects is great, and seeing the team grow is rewarding, but the most surreal part is the actual workflow.

It’s getting late as I write this.

On my work laptop, a Claude Code session is churning away on a task I set up earlier. On my personal laptop, I’m testing the latest Codex-5.3 model to build a feature for an open-source project I contribute to.

I am writing this blog post, but the code is still being written. The features are still being built.

I’m technically a manager now, but I’ve never felt more productive as an engineer. What a time to be living in, what a time!

From DNS records that don’t resolve to Let’s Encrypt timeouts and HTTP verbs your app doesn’t support, these are the mistakes that don’t show up in neat AI-generated tutorials — and what you actually need to know when you do this for real.

⚠️ Mistake #1 — Assuming “the server is running” means “the world can reach it”

When ChatGPT told me “your server is running on port 8080,” I thought that meant I could just open a browser and go to http://<public-ip>:8080.

Nope.
Azure VMs come wrapped in multiple layers of security:

• VM’s own OS firewall (UFW or firewalld)

• Azure Network Security Group (NSG)

• And sometimes, a load balancer in front

If any one of those blocks inbound 8080, you’re invisible to the Internet.
The fix? Explicitly open the port:

az vm open-port --resource-group <RG> --name <VM> --port 8080

and double-check that your app binds to 0.0.0.0, not 127.0.0.1.

Subscribe now

🧩 Mistake #2 — Forgetting about DNS propagation

When I added podcast.yusizhang.com in Cloudflare, I expected it to work instantly.
Ping said otherwise:
ping: cannot resolve podcast.yusizhang.com: Unknown host

Cloudflare DNS isn’t always instant, and sometimes you accidentally create a CNAME instead of an A record.
Also, if you leave the orange proxy cloud on, your server might not even be reachable during certificate setup.

Lesson learned:

• Use an A record, not a CNAME.

• Set Proxy status = DNS only (gray) until SSL works.

• Check propagation with dig podcast.yusizhang.com +short.

🔒 Mistake #3 — HTTPS verification failing due to Azure firewall

Let’s Encrypt failed with a cryptic timeout:

Timeout during connect (likely firewall problem)

The real issue? I had opened port 8080 for my app, but not port 80 for HTTP verification.
Certbot uses a temporary challenge file on port 80 to prove you own the domain.
Until I ran:

az vm open-port --resource-group <RG> --name <VM> --port 80

the certificate request kept failing.

Once I did — 💥 instant success.

Leave a comment

🧱 Mistake #4 — Nginx reverse proxy confusion

ChatGPT’s Nginx config looked simple:

location / {
  proxy_pass http://127.0.0.1:8000;
}

…but what wasn’t obvious at first was that Nginx doesn’t automatically serve HTTPS just because it’s installed.
Certbot configures SSL for you only after it successfully verifies the domain — so if the challenge fails, you’re left with half a setup and a broken redirect.

Lesson: always test http://yourdomain/feed.xml first before trying to force HTTPS.

🧠 Mistake #5 — HEAD requests returning 405 errors

After everything was working, I proudly ran:

curl -I https://podcast.yusizhang.com/feed.xml

…and got:

HTTP/1.1 405 Method Not Allowed
allow: GET

Turns out FastAPI only defines a GET route by default, so HEAD requests (which tools like curl use for checking status) failed.

It didn’t break Apple Podcasts — but it’s a good example of how *“looks fine in browser” ≠ “standards-compliant server.”

The fix was easy:

@app.head(”/feed.xml”)
async def feed_head():
    return Response(headers={”Content-Type”: “application/rss+xml”})

Problem solved.

If you’re thinking of self-hosting your podcast feed — do it.
Just remember: the magic isn’t in following ChatGPT’s steps; it’s in learning why those steps fail.

And if you’re wondering in why am I hosting a podcast on a VPS, checkout the Github project

Fast-forward a couple weeks, and that “joke” has become one of my go-to prompt engineering tricks. I’ll often ask one LLM to critique another’s work—like:

“Hey Gemini, ChatGPT claims he’s the best consumer LLM product because yada yada… do you agree?”

Then I flip it back and let ChatGPT defend itself, refine the answer, or even rewrite the whole thing. Eventually I standardized the flow into four roles: Generator → Critic → Refiner → Evaluator.

Subscribe now

And you know what? It works ridiculously well. It’s like having your own mini debate club of robots—except they don’t eat all your snacks.

Here’s a real example: “Help me come up with 5 domain name ideas used for a B2C SaaS product that converts RSS into Podcast”. (I loved “Podmatic.io”… sadly, someone else loved it first. 😭)

If you’re curious, give this multi-LLM ping-pong a try—you might discover insights you’d never have gotten from a single model. And if you’re feeling more weekend-coder handy, I even hacked together a little CLI version that bakes in the four roles and lets you swap between different LLM vendors. No more tedious copy-paste battles—just let the bots duke it out while you sip your coffee. ☕️🤖⚔️ (at your own llm token cost…)

👉 PyPI package: ai-cli-chat
👉 GitHub repo

Share

Subscribe now

What happened:

The agent began by searching broadly—Google, Yelp, Reddit—not just limiting itself to LinkedIn.

I actually liked that: it hints at a future where agents triangulate across public signals and then converge on LinkedIn to validate or enrich candidate profiles.

After I took over and logged in LinkedIn.com, it adapted: ran a LinkedIn people search, experimented with the query vs. the location filter, opened profiles, scrolled (sometimes awkwardly), expanded experience sections, occasionally mis‑clicked into a company page, and recovered.

It applied light heuristics (e.g., skipped current students) and ultimately produced five candidates with personalized draft messages (see masked screenshot).

If I did this myself, I’d probably finish faster. But that misses the point. Those 27 minutes were zero minutes of my focused attention. I can go on with other work while an autonomous cursor trudged through the busywork. I’m realizing my productivity metric is shifting from elapsed minutes to attention minutes. Trading more wall‑clock time for less of my cognitive time is a win.

Trust & autonomy:

LinkedIn is a trusted platform, and I’m not in a position to define what level of error is “acceptable” for any customer segment.

In this personal experiment I deliberately stopped short of sending messages.

Still, it’s easy to imagine typical user—after calibrating prompts and reviewing a few outputs—gradually granting the agent more end‑to‑end autonomy. The path to “click send for me” feels closer than I expected.

Search depth:

I asked for five candidates and the agent delivered exactly that—by reviewing the visible top results and selecting five rather than exploring deeper pages.

That’s not a concern to me; with different prompting or continued model improvements it could easily broaden its exploration.

Meanwhile LinkedIn will keep investing in underlying relevance, so both sides of the stack are improving.

The more interesting question:

Who are we building software for now—humans or agents?

The same feature may need two modes.

Manual mode optimizes for interactive speed and human comprehension.

Agent mode might tolerate slower wall‑clock execution if quality, completeness, or compliance go up.

Share

Pricing and metrics assumptions also shift: a $20/month general agent can tirelessly use a product far beyond the “average human usage” many business models were calibrated on.

That could push platforms toward agent‑friendly surfaces (structured data, APIs) and new ways to capture value (outcome pricing, usage tiers, “agent seats”).

My working thesis: most professionals will pay for a general agent and still choose vertical platforms like LinkedIn only when those platforms deliver differentiated value—trust graph, proprietary signals, faster/better outcomes—on top of generic automation.

Curious how others are thinking about “attention minutes” and designing for manual vs. agent modes. How is this changing your roadmap?

Leave a comment

Opinions are my own. Drafted with help from ChatGPT.