Permalink: 20260814144813

Found at “How Claude marks AI-generated content” on 2026-08-14T14:48:13+02:00.

As AI-generated content becomes commonplace, greater transparency and signals about where content comes from can give people useful context about the information they consume. To support transparency and comply with our legal obligations, Anthropic is working to include machine-readable marks in content that Claude generates.

Permalink: 20260814144544

Found at “Watermarks in the Sand: Impossibility of Strong Watermarking for Generative Models” on 2026-08-14T14:45:44+02:00.

Watermarking generative models consists of planting a statistical signal (watermark) in a model’s output so that it can be later verified that the output was generated by the given model. A strong watermarking scheme satisfies the property that a computationally bounded attacker cannot erase the watermark without causing significant quality degradation.

Permalink: 20260723120822

Found at “From Capabilities to Responsibilities” on 2026-07-23T12:08:22+02:00.

High-stakes AI systems must be designed around responsibilities, not capabilities.

Permalink: 20260723120702

Found at “Industrialism and the slippery slope” on 2026-07-23T12:07:02+02:00.

Quality, by definition, is meeting spec. If you don’t like the spec, make the spec better.

Permalink: 20260719105922

Found at “The New Software Lifecycle” on 2026-07-19T10:59:22+02:00.

AI compresses the lifecycle, but unevenly, and the unevenness is the whole story. Implementation drops from weeks to hours. Requirements, architecture, and verification stay slow because they’re judgment work. So specification quality becomes the bottleneck, and verification moves to the middle.—Addy Osmani

About this new AI-driven SDLC, Kin Lane asked me and other API product folks on LinkedIn:

How does this apply to the API lifecycle?

This is my answer:

The article and the paper it refers to validate the importance of doing API Design the right way: capturing JTBD, writing user stories, understanding consumers’ needs, iterating using API prototypes, and validating before implementing.

Building things incorrectly isn’t a risk anymore because the cost of implementation has dropped dramatically. LLMs can now build what you ask them to in any programming language, bug-free. What’s now a risk is building the wrong things. That’s why validating your API design is so important.

A “side effect” of this new SDLC is that now almost anyone can build an API. You don’t need to be a developer to be able to design an API, implement it, and release it. You don’t even have to know OpenAPI or any other API specification. What you do need to know, however, is your domain. You need to understand what you’re building and who you’re building for.

Permalink: SDD for API Design

Today, I put together a few pieces that looked totally disconnected until now.

I was reading some random article about how AI, and in particular the specification-driven development (SDD) methodology, can open software development to non-technical people. The first step of SDD is to define the specification of the software that you want to develop.(1) (1)“This isn’t about technical stacks or app design. It’s about user journeys, experiences, and what success looks like,” wrote Den Delimarsky in September 2025 (see Spec-driven development with AI: Get started with a new open source toolkit). In October 2025, Birgitta Böckeler added that “a spec is a structured, behavior-oriented artifact (…) written in natural language that expresses software functionality” (see Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl). Who has better knowledge of what should be built than someone who has expertise in their area of work?

I immediately thought about the kinds of profiles that thrive in an AI-oriented world and job market. Expert generalists, or T-shaped professionals, are probably going to rule this AI wave.(2) (2)“We’ve observed that Expert Generalist capabilities are considerably more valuable with these LLMs,” wrote Martin Fowler et. al. in July 2025 (see Expert Generalists). There’s no room or time for specialists. Why? Because writing code is cheap.(3) (3)“Coding agents dramatically drop the cost of typing code into the computer,” wrote Simon Willison in February 2026 (see Writing code is cheap now). Translating is cheap. Building things is cheap. You know what isn’t cheap? Understanding what to build and understanding why you should build it.(4) (4)“The ability to define what needs to exist is becoming the scarcest and most valuable skill in any organization,” wrote Ivan Misic in May 2026 (see When AI Makes Building Cheap, Knowing What to Build Becomes Everything). That’s something an expert generalist can do better than a specialist.

And then I thought that SDD can be used by expert generalists to design and build APIs. APIs that really make sense and offer value to consumers. Expert generalists have the knowledge of their area of expertise and are generalist enough to understand what API operations they should build.

Permalink: 20260623105720

By classifying operations as atomic, workflow, asynchronous, introspective, discovery, reactive, bulk, or simulated, you create a predictable map that helps machines navigate APIs safely.—The Taxonomy of API Operations

Inferred API operation categories. This is the distribution of API operation categories after analyzing more than 50k OpenAPI documents from public GitHub repositories. I inferred a taxonomy by comparing the morphology of each API operation with a set of pre-established heuristics.

Permalink: 20260617111326

Found at “Expert Generalists” on 2026-06-17T11:13:26+02:00.

We’ve long noticed that not just anyone succeeds as an Expert Generalist, but once we understand the traits that are key for such Expert Generalists, organizations can shape learning programs, hiring filters, and career paths that deliberately develop them.

Permalink: 20260604110757

Found at “Enshittification, Despotification, and the Open Internet” on 2026-06-04T11:07:57+02:00.

There’s no reason we can’t build a new generation of services that restores that democratic, decentralized promise—an open internet that empowers users rather than funneling control to gatekeepers.

Permalink: 20260526104220

Found at “Appearing Productive in The Workplace” on 2026-05-26T10:42:20+02:00.

Generative AI can produce work that looks expert without being expert, and the failure arrives in two shapes. The first is when novices in a field are able to produce work that resembles what their seniors produce, faster or more advanced than their judgment. The second is when people generate artifacts in disciplines they were never trained in. The two failures look similar from a distance and are not the same. Research has mostly measured the first. The second is what it is missing, and in my experience it is the riskier of the two.

Permalink: 20260525123455

Found at “From Hierarchy to Intelligence” on 2026-05-25T12:34:55+02:00.

At Block, we’re questioning the underlying assumption: that organizations have to be hierarchically organized with humans as the coordination mechanism. Instead, we intend to replace what the hierarchy does. Most companies using AI today are giving everyone a copilot, which makes the existing structure work slightly better without changing it. We’re after something different: a company built as an intelligence (or mini-AGI).

Permalink: 20260505171152

I’m currently starting a new line of research about API-related taxonomy. Here’s a very early exploration on the taxonomy of API operations, where I identify eight operation categories:

• Atomic
• Workflow
• Asynchronous
• Introspective
• Discovery
• Reactive
• Bulk
• Simulated

This is very early work, which means that even this list of categories isn’t yet final.

Permalink: 20260505102545

Found at “Agent Skills” on 2026-05-05T10:25:45+02:00.

AI coding agents are extremely capable junior engineers with no instinct for the parts of the job that don’t show up in the diff. The senior-engineering work (surfacing assumptions, sizing changes, writing the spec, leaving evidence, refusing to merge what can’t be reviewed) is exactly what an agent will skip unless you make it impossible to skip. The job, increasingly, is to encode that discipline as something the agent cannot talk itself out of.

Permalink: Second-degree user experience is the most overlooked aspect of API design

When designing an API, most teams focus exclusively on the Developer Experience (DX). But there is a deeper, more critical layer: the second-degree user experience. This is the experience of the end-users who interact with the applications built on top of your API.

I always advocate for looking beyond the developer and understanding the end-user’s journey. An API isn’t just a bridge for code; it’s the foundation for the final user’s experience.

—Pedro, B. (2024), Building an API Product (p. 30), Packt Publishing

Permalink: An API needs a plan for its own end

Many teams launch products without ever thinking about how to turn them off. This leads to “zombie APIs” that drain resources and create security risks for the company. Leaving an old service running forever is not a strategy; it is a burden.

My experience managing API lifecycles shows that deprecation is a core feature. I’d focus on defining a clear sunset policy before the first version even launches.

Permalink: 20260414102651

Found at “Building a CLI for all of Cloudflare” on 2026-04-14T10:26:51+02:00.

(…) we needed more than could be expressed in an OpenAPI schema. OpenAPI schemas describe REST APIs, but we have interactive CLI commands that involve multiple actions that combine both local development and API requests, Workers bindings expressed as RPC APIs, along with Agent Skills and documentation that ties this all together.

(…)

So we introduced a new TypeScript schema that can define the full scope of APIs, CLI commands and arguments, and context needed to generate any interface. The schema format is “just” a set of TypeScript types with conventions, linting, and guardrails to ensure consistency. But because it is our own format, it can easily be adapted to support any interface we need, today or in the future, while still also being able to generate an OpenAPI schema.

Permalink: An API is a conversation between you and your users

Many product managers ship a feature and then wait for support tickets to arrive. This reactive approach means you only hear from the users who are frustrated enough to complain. You miss the quiet majority who just stop using the product.

I have spent years setting up feedback channels for global platforms. I’d focus on building “telemetry of intent” to see where users struggle before they ever reach out for help.

Permalink: 20260409154029

Found at “reShapr” on 2026-04-09T15:40:29+02:00.

reShapr is the open source, no-code MCP Server for AI-Native API Access. Designed to bridge the gap between traditional REST/GraphQL/gRPC services and Large Language Models (LLMs).

Permalink: 20260409110148

Found at “Four Open-Source Agentic Authorization Alternatives” on 2026-04-09T11:01:48+02:00.

The Agentic Authorization OAuth 2.1 Extension is an IETF draft that was first created in May 2025. It’s now in its version 01 and provides a solution where AI agents can identify their users and, in turn, use their identification to obtain OAuth access tokens.

Agentic Authorization OAuth 2.1 Extension (AAuth). During the interaction between an agent and a human, the agent requests certain pieces of PII that it can then use to obtain an authorization. The goal is that having those details about a user will be sufficient to provide a valid proof of identity. All these exchanges are done as part of the new Agent Authorization Grant that issues low-privilege, user-specific access tokens. The system can also escalate and ask for a human to intervene in situations where there’s a high risk potential.