Full articles mirrored from LinkedIn and kept current on the site.

The Search Box Changed. So Did the User.

For 25 years, the Google search box was a masterclass in restraint: a thin white rectangle, a blinking cursor, a few words, a list of blue links. It trained billions of people to compress complex questions into keyword fragments because that was the only way the machine understood.

On May 19, Google retired that paradigm.

At I/O 2026, the company announced a sweeping redesign of the search box itself. Not a cosmetic refresh. The literal text field where billions of queries start every day now dynamically expands, accepts images, PDFs, videos, and open Chrome tabs as inputs, and coaches users toward fuller, more conversational queries instead of abbreviating them.

Behind it, Google is merging AI Overviews (2.5 billion monthly users) and AI Mode (1 billion monthly users, doubling every quarter) into a single, seamless flow. No more choosing between a traditional results page and an AI forward experience. The distinction disappears.

This matters far beyond search.

The UX of AI adoption just crossed a threshold. Google could have kept AI Mode as a separate destination for power users. Instead, they redesigned the front door. The message is clear: the default way to interact with information is no longer keyword in, link out. It is conversational, multimodal, and continuous.

For anyone building products, managing teams, or designing experiences, the implication is practical. If the most visited interface on earth is retraining users to ask fuller questions, everything downstream adjusts. Ecommerce search. Internal knowledge bases. CRM fields. Enterprise software that still assumes users will type two words and click. Those assumptions are now legacy behavior.

The question is not whether conversational AI will reshape user expectations. It already has. Google just confirmed it by changing the most expensive real estate on the internet.

The Advantage Is No Longer Speed. It's Direction.

A common belief in the AI era: if you can ship faster than everyone else, you win.

Figma's CPO Yuhki Yamashita published a post last week that inverts that assumption. His argument: when AI makes everyone capable of building, speed becomes table stakes. What separates memorable products from interchangeable ones is not how fast you shipped. It's whether you shipped something worth shipping.

This sounds obvious until you see how most teams actually work with AI today.

The danger of easy progress. Yamashita describes the trap clearly. Today's AI tools make it dangerously easy to latch onto the first idea and go deep. Agents are "endlessly helpful and agreeable." They accelerate you forward, but not beyond your first idea. The result is tunnel vision disguised as momentum.

More experienced builders know to go broad first. Map the option space. Compare approaches. But that has its own failure mode: staying too abstract. A 2x2 or a set of wireframes are rarely enough to build real conviction.

The better way: broad and deep at the same time. AI now makes it possible to explore multiple directions in parallel while pushing each far enough to feel real. At Figma, this means prompting AI to produce multiple interactive prototypes, different takes on the same problem, laid out side by side. You invite teammates and agents in to react together, comparing real experiences, not abstractions.

This is a genuinely different way of working with AI. Not siloed and sequential. Collective and parallel.

Then there is craft. When AI can produce something that looks right at a glance, everything drifts toward the typical. "Good enough" becomes both easy to reach and easy to accept. The result, Yamashita warns, is a sea of products that feel interchangeable.

Craft is what separates the memorable from the merely functional. It is active. Choosing, not accepting. Revisiting and interrogating each decision. Pushing past the first few versions until the work has a point of view.

The line that stayed with me: "When everything works, people choose what feels intentional. What feels cared for."

In a world where anyone can build, that last mile is the only differentiator that matters.

When Every Employee Gets an AI Agent, Project Management Changes

Last week, NanoCo AI announced a $12 million seed round backed by Docker, Vercel, monday.com, and HuggingFace's CEO. Their model: one dedicated AI agent per employee.

Not one chatbot for the whole company. One agent per person, trained on that person's emails, documents, and projects. Each agent builds its own knowledge base over time. Each agent shadows its assigned employee, drafts contracts, reviews code, and manages accounts within Slack and Teams.

This is a different paradigm from the generic enterprise chatbot, and it raises questions that project managers need to be asking now.

The governance problem scales per employee. When a single AI tool serves the whole team, one governance framework covers everyone. When each employee has a dedicated agent that learns their specific work, the governance surface area multiplies. Each agent has different access, different knowledge, and different permissions.

NanoCo's approach is instructive. Every agent runs inside a Docker sandbox microVM. The blast radius of a prompt injection is strictly contained to that container. Raw API credentials never reach the agent. They pass through a Rust gateway that enforces company-defined policies. If an agent attempts a sensitive write action, the gateway intercepts it and pings the human via Slack or Teams for explicit approval.

Think of it as a junior employee who can draft anything but cannot send anything without a manager turning a key.

The project management parallel. This maps directly to RACI and delegation frameworks that PMs already use. The agent is the Responsible party doing the work. The human is the Accountable party approving the output. The gateway is the procedural control ensuring the separation holds.

For PMs managing teams that are deploying AI agents, three things to put on your risk register:

1. Access boundaries. If each agent has different permissions, who decides what each agent can access? This needs a documented approval workflow, not a default setting.

2. Audit trails across vendors. When one agent uses Claude and another uses GPT, can you produce a unified audit trail? The neutral observability layer becomes a governance requirement.

3. The approval gateway. Who has authority to approve agent actions? If the answer is "the employee the agent shadows," that is a decision worth documenting explicitly.

The tools are evolving fast. The governance questions are not new. But the scale at which they now apply is.

Title: Your AI Meeting Scribe Might Be Making Things Up. Here is What the Ontario Audit Found.

Every week, thousands of professionals let AI scribes sit in on their meetings. Sales calls, client reviews, therapy sessions, project standups. The promise is obvious: never take notes again, never miss a detail, always have a perfect record.

But here is what happened when Ontario's government actually checked whether those scribes were working.

The Auditor General of Ontario audited 20 government-approved AI scribe vendors used by doctors to automatically summarize patient conversations into medical records. What they found, published in a May 2026 report, was not subtle.

All 20 vendors had accuracy or completeness problems. Nine of them hallucinated patient information that never existed. Twelve recorded information incorrectly. Seventeen missed key mental health details that would matter for treatment. Errors included made-up therapy referrals and prescriptions that could have led to harmful treatment plans.

These were not fly-by-night tools. These were pre-qualified, government-recommended vendors with an official stamp of approval. And they were still generating plausible-sounding fiction.

If you use any AI notetaking tool for professional work - Otter, Fireflies, Granola, Fathom, or one of a dozen others - this matters to you. Not because your tool is the same as a medical scribe. But because the failure pattern is universal.

AI summarization tools are very good at sounding authoritative. They produce output that reads like a real person wrote it. That is exactly what makes them dangerous. When a tool sounds confident, your brain stops checking. You forward the summary. You file the transcript. You move on.

The Ontario audit shows what happens when nobody checks. Fabricated referrals. Incorrect prescriptions. Lost mental health context. In a clinical setting, the consequences are immediate and dangerous. In a business setting, they are slower and harder to trace: wrong assumptions, missed context, decisions based on something that never happened.

None of this means you should stop using AI notetakers. It means you need an audit habit. Before you treat a summary as truth, ask yourself: would I know if the AI made something up here? If the answer is anything but a clear yes, read the actual transcript.

The tool that sounds the most human needs the most scrutiny.

---

Title: When Code Becomes Cheaper Than Design: The Inversion Most Teams Miss

For the last decade, the design-to-development pipeline worked one way. Design was cheap. Code was expensive. You explored ten directions in Figma because moving pixels cost nothing. You picked one direction and handed it to engineering because writing code was the expensive part.

AI just flipped that equation.

Figma's Design Director of AI Gui Seiz said it plainly last week: "Code used to be expensive. Complex, laborious, hard to revise. Design exploration felt cheap by comparison. AI has inverted that dynamic."

This is not prediction. It is happening now.

Figma released an MCP server in April that lets AI agents read code and write directly to the Figma canvas as editable design layers. Designers can now generate functional wireframes by describing them in plain language instead of dragging shapes around a board. The iteration loop has shifted from layout to behavior.

The old question was: "Should designers learn to code?" The new question, as Seiz put it, is: "Why would you not ask AI to code it for you?"

Here is what this means for how teams actually work.

When design was cheap and code was expensive, you validated ideas in mockups. You showed static screens. You got approval before writing a line of production code. The gate was engineering capacity.

When code becomes cheaper than design, the gate moves. You validate ideas by running them. You show functional prototypes, not flat images. The bottleneck shifts from "can we build this?" to "should we build this?"

That is a harder question. And it requires better judgment, not better tools.

The teams that will benefit most are the ones that understand this inversion. If you keep treating design as the exploration phase and code as the delivery phase, you will optimize for a world that no longer exists. The teams that will struggle are the ones that think AI tools are the answer to everything. They are not. They are the answer to the cost of iteration. The judgment part is still yours.

So here is a practical starting point. Next time you start a project, do not ask your team for mockups. Ask for a functional prototype generated with AI. See how the conversation changes when everyone can interact with the thing instead of looking at a picture of it. The tooling is ready. The question is whether your process is.

---

Title: When AI Manages AI: The Project Governance Lesson Most Teams Are Missing

In the last two weeks, two major product launches showed us something important about where AI is heading in project work. And the pattern should look familiar to anyone who holds a PMP.

Fin, the AI customer support platform formerly part of Intercom, launched something called "Fin Operator" last week. Here is what it does: one AI agent manages another AI agent. The operator ingests a product update PDF, extracts the key information, and updates the knowledge base automatically. Work that used to take hours or days now takes about ten minutes.

On the surface, this is just faster automation. But look closer and you will see a project governance structure emerging.

Two days earlier, Anthropic released a `/goals` command for Claude Code. The command formally separates task execution from task evaluation. One model executes the work. A different model, Haiku by default, independently checks whether the completion conditions have been met. If a condition like "all tests in test/auth pass" is not satisfied, the agent keeps working. The system has a built-in separation of duties.

This is not a technical detail. It is a governance pattern.

As Sean Brownell from Sprinklr put it: "Separating the builder from the judge is sound design because, fundamentally, you can't trust a model to judge its own homework."

Project managers understand this instinctively. It is the same reason a project manager does not self-approve their own deliverables. The same reason you have a separate QA phase. The same reason a risk register is maintained by someone who can see the whole picture, not just their piece of it.

What Fin Operator and Claude Code goals represent is the first real parallel to project governance in AI systems. And it suggests something useful for PMs who are wondering where their skills fit in an AI-augmented world.

The skills that make a good project manager are exactly the skills needed to manage an AI agent workforce: defining completion conditions, separating execution from evaluation, managing handoffs between systems, verifying outputs, and keeping the whole picture in view when no single participant has it.

If your organization is deploying AI agents for customer support, code generation, or data processing, ask who is defining the conditions for done. Who is checking the output. Who is catching the handoff failures. The answer should be someone who thinks in terms of governance, scope, and quality assurance.

That is what project management has always been. The tools are just faster now.

---