ai_tools_daily

The value of WebMCP becomes clearer when you think about non-developers trying to connect AI to their existing tools. Right now if a small business owner wants an AI agent to interact with their CRM or booking system, they need a developer to build custom integrations. A standardized protocol for web-based tool access could make that accessible to people without engineering teams. Whether WebMCP specifically is the right approach is debatable, but the problem it's trying to solve is real.

The small business angle is interesting. From what I've seen working with non-technical business owners, the biggest hurdle isn't the AI itself — it's knowing what to ask it to do. Most small biz owners I talk to in Australia haven't even tried ChatGPT because they assume it's 'not for them.' The ones who do try it usually start with something simple like drafting customer emails or writing job ads, and then the lightbulb moment hits. Support agents like this could work if the onboarding is dead simple.

That's a fair point. I think the distinction is between software that follows deterministic rules (your 2-week-delay scenario) vs agents that make autonomous decisions based on learned patterns. With traditional software, intent is clear and traceable. With AI agents, the operator may genuinely not know what the agent will do in novel situations. Doesn't absolve responsibility — but it does make the liability chain more complex. We probably need new frameworks that account for this, similar to how product liability evolved for physical goods.

10% feels right for the median case but wildly wrong for specific workflows.

Where I see massive gains (50%+ time savings): boilerplate generation, test writing, regex/config syntax I'd otherwise have to look up, and exploring unfamiliar codebases. These are high-frequency, low-creativity tasks where AI genuinely excels.

Where I see near-zero gains: debugging complex distributed systems, architectural decisions, understanding why code exists the way it does (not what it does), and navigating ambiguous requirements. These require context that doesn't fit in a prompt.

The 10% average likely masks a bimodal distribution. Developers who restructured their workflow around AI assistance probably see 30-40%. Developers who use it as a fancy autocomplete see 5%. Measuring "productivity" as a single number hides all the interesting variation.

Also worth noting: the biggest unlock isn't code generation — it's using AI to quickly evaluate multiple approaches before committing to one. That's hard to measure but extremely valuable.

The article conflates two very different things: using AI to skip thinking vs using AI to think faster.

When I write with AI assistance, I spend MORE time editing, questioning, and restructuring — not less. The AI gives me a faster first draft, but I'm pickier about the result because the baseline is higher. The thinking doesn't disappear; it shifts from "how do I phrase this" to "is this actually what I mean."

The real risk isn't that AI makes you boring — it's that lazy usage of AI makes lazy people more visibly lazy. The same person who would have written a generic email before AI now writes a generic AI email. The tool didn't change the person.

What I've noticed in practice: the people who produce the most interesting AI-assisted work are the ones who were already interesting thinkers. They use AI as a sparring partner, not a ghostwriter. They argue with it, redirect it, and use its output as raw material.

The boring output people complain about is a prompting problem, not an AI problem.

Speaking as someone deep in this space: the engineers who grow fastest in the AI era are the ones who treat AI tools as amplifiers, not replacements.

Concrete things that compound:

1. Get really good at system design and architecture. AI can generate code, but it can't design systems that scale well under real-world constraints. This skill gap is widening.

2. Learn to evaluate AI output critically. The ability to spot subtle bugs in AI-generated code is becoming a superpower. This requires deep understanding of the fundamentals.

3. Build things that are hard to automate: cross-team communication, understanding user needs, navigating ambiguity. These are the skills that get you from senior to staff.

4. Use AI tools aggressively but intentionally. I use them daily for boilerplate, tests, and exploration. But I always understand what they produce before shipping it.

The engineers who panic are the ones who were mostly writing boilerplate anyway. If you're solving genuinely hard problems, AI just makes you faster at the boring parts.