jake-coworker

What MCP really needs is standardized auth. There's maybe 10 different common ways to authenticate against MCP servers, and the average non-engineer can't read the docs to figure out how to configure it.

Companies can implement Individual Oauth with DCR (which makes it as easy as "log in with Google"), but many don't

one of these claimed is backed by data, one is backed by anecdotes, you can decide which you trust more

Regulation won't beat engineering here. China will continue to release open weight models that are impossible to ban without unprecedented surveillance in Western countries.

AI labs need to innovate if they want to win. Open models are capitalism. Ideally Western companies should get more efficient, but if we can't then we should be doing the opposite of regulation, and subsidizing western models.

I think this is an artifact of any large organization of people.

Humans tend toward doing things that are best for them. The challenge of large-organization-designers (governments, companies, etc.) is how to design a system that 1) leverages this behavior; ie maximize the value of ambition to the system, and 2) is not vulnerable to this behavior; ie checks & balances

Small organizations can get around this because outcomes are easier to share, and selecting people who aren't selfish is possible.

We can do our best to put guidelines around selfishness, but history tells us this is hard

One of my favorite senior developer stances is "I should be annoyed by how many questions you're asking me"

I don't love the title - the article is about differing perspectives/incentives in a company, not about senior developers' inability to communicate

That said, I think everyone will agree both extremes are failure modes - moving too fast and not having things work right, or building things too correctly and never building something people want.

IMO the two stereotypes in the article generally hold true, and the job of each in a healthy company is to present the trade-offs, and collect enough data to experimentally validate. And when you disagree, let the decision maker (CEO) decide, but disagree and commit

Most comments here are about Chromebook/Googlebook hardware. But IMO the more interesting part is AI-native OS features. Unfortunately it seems like not a ton, but I think the future is in custom software created from user prompts.

Ie the other day I wanted to track my clipboard history, and I preferred to trust a locally coded & executed AI-generated clipboard history mac app over a random github project.

Now obviously trusting AI has its own concerns vs trusting people, but interested in other ways companies will reimagine interfaces with AI

I think the logical next step is that "XYZ knowledge worker" will become a software engineer of sorts. Not literally writing code, but at minimum encoding processes/workflows into some language.

If you're a paralegal or an accountant who can't manage their workflows with AI, you're going to be way less productive than someone who can.

And if you're a paralegal or an accountant who can manage a lot of your workflows with AI, you don't need custom software (hence less dedicated software engineers).

This is surprisingly close to Haiku quality, but open - and Haiku is quite a capable model (many of the Claude Code subagents use it).

I generally agree - I think anyone who's seriously experimented with agentic coding has encountered both:

1 - Surprising success when an agent can build on top of established patterns & abstractions

2 - A deep hole of "make it work" when an LLM digs a whole it can't get out of, and fails to anticipate edge cases/discover hidden behavior.

The same things that make it easier for humans to contribute code make it easier for LLMs to contribute code.

IMO these articles are akin to "Twitter in 200 lines of code!" and "Why does Uber need 1000 engineers?" type articles.

They're cool demos/POCs of real-world things, (and indeed are informative to people who haven't built AI tools). The very first version of Claude Code probably even looked a lot like this 200 line loop, but things have evolved significantly from there

I usually share this resource when people start doing this https://google.github.io/eng-practices/review/developer/smal...