DEV Community: PeiSong

API Tooling Didn’t Get Better. We Just Lowered Our Expectations

PeiSong — Sun, 29 Mar 2026 12:09:58 +0000

It is strange how little we talk about APIs now.

Not because APIs matter less. They matter more than ever. Modern software is held together by APIs: SaaS products, internal platforms, mobile apps, partner integrations, automation workflows, and now AI agents calling tools over HTTP-shaped boundaries all day long.

And yet the API ecosystem feels oddly quiet, almost resigned. As if the problem has already been solved. As if Postman, Swagger, a test runner, some CI glue, and a folder full of half-maintained examples are simply the natural end state.

Even newer waves like GraphQL and gRPC, important as they are, never really restarted the broader API tooling conversation. They shifted some technical boundaries, but the workflow problem remained.

I do not think the problem was solved.

I think we just got used to the friction.

The easiest API problem got dramatically better

For a long time, the most visible API problem was documentation.

Docs were incomplete. Docs drifted. Docs showed idealized examples that did not quite match reality. Swagger and OpenAPI helped a lot, but the workflow was still familiar: read the spec, hit the endpoint, discover the actual behavior, update your mental model, move on.

AI changed this surprisingly fast.

Today, if you have a half-decent spec, some examples, or even just a working endpoint, AI can explain the API, summarize it, generate payloads, compare versions, write a client, and answer questions about the docs faster than most human workflows ever could.

That is real progress. But it also exposed something deeper: documentation used to absorb a lot of our frustration with APIs. Once AI made that part dramatically easier, the unsolved parts of API work became much harder to ignore.

The real problem was never just docs

The harder problem is everything that happens after understanding an API.

How do you explore it, keep the useful parts, turn one-off discovery into repeatable verification, test a real workflow instead of a pile of disconnected requests, move from local use to CI without rewriting everything, and make this whole thing work with AI instead of around it?

That is why workflow matters so much. Workflow determines what knowledge survives, how quickly feedback returns, whether a useful experiment becomes a durable asset or disappears, and whether AI is helping inside a real verification loop or just generating more throwaway code.

Workflow is where API knowledge either compounds or dies.

This is where I think the ecosystem largely failed. We got many partial tools:

documentation tools
request senders
schema generators
mock servers
test runners
SDK generators
contract tooling

Some of them are good. Swagger is good. OpenAPI is useful. Design-first was a genuinely strong idea.

But if we are honest, none of that really changed the day-to-day workflow for most teams.

Too much of the category kept reinventing the API client while leaving the workflow itself mostly untouched.

The industry spent years polishing variations of the same request-sending model and calling that progress.

The common reality still looks the same: you explore in one place, document in another, test in another, automate in another, and debug failures somewhere else. The useful knowledge gets lost in the gaps. That is the part the industry quietly normalized.

A small example: someone changes a field name in the backend response. The frontend type is now stale. The API example in the docs is stale too. A saved request still "works" but no longer reflects the real workflow. The test suite fails later in CI, far away from the original change. Nothing about this is rare. It is ordinary API work.

Design-first made sense for the human coordination era

Design-first was not a bad idea. It was a coordination technology for humans.

It made sense in a world where frontend and backend were built by different people, often on different teams, moving at different speeds, and trying to align before implementation drifted too far. In that world, the spec had to carry a lot of weight:

team alignment
mock generation
frontend/backend parallel work
review before implementation
external documentation

That was a real problem, and design-first was a real answer to it.

But AI changes the coordination model.

Now one developer, with one or more AI agents, can often move across frontend, backend, tests, examples, and docs in a single loop. The coordination cost that used to justify spec-first workflow collapses.

The new default starts to look more like this:

AI writes backend code
AI writes frontend code
AI drafts tests
the code gets run
the spec is generated or updated only when needed

That does not make contracts unimportant. It means the center of gravity shifts away from spec as the starting point.

AI makes this problem more obvious, not less

A lot of people assume AI reduces the importance of API tooling. I think the opposite is true.

AI is very good at working with code, structured schemas, and explicit contracts. It is much less naturally aligned with fragmented click-through workflows, stale collections, and operational knowledge scattered across tools.

If AI helps you understand an endpoint, draft a request, or even generate a test, that is useful. But if the workflow still breaks the moment you want to keep that work, verify it, rerun it in CI, inspect failures, or reuse it inside a larger flow, then AI is not solving the actual problem. It is just accelerating the first step.

That is also what current AI coding tools still lack in practice. The bottleneck is usually not "more documentation." It is live execution feedback, structured traces, failing assertions, environment context, and a clean way to turn exploratory code into durable verification.

AI solved a lot of API explanation. It did not solve API workflow. If anything, it made the gap more visible.

That is why testing matters more now, not as endpoint checking after the fact, but as the place where exploration becomes verification, verification stays close to the code, and the same artifact survives local use, CI, debugging, and AI-assisted authoring.

The old center was specification. The new center should be executable workflow.

In the AI era, the source of truth is less likely to be a carefully maintained design document and more likely to be:

working code
runnable tests
traces and real responses
generated specs when needed
verification that survives across local runs, CI, and debugging

We do not need less contract. We need less ceremony and more executable truth.

That kind of workflow is what I think the ecosystem should be building toward: API exploration stays in code, useful discoveries become runnable checks, AI can help write and refactor them, and the same artifacts survive local runs, debugging, and CI.

That is also the direction I want Glubean to push toward, not as another request sender, but as tooling built around that loop.

That matters because, despite all the abstraction layers, the real boundary still looks a lot like HTTP: requests, responses, auth, retries, headers, payloads, failures, and state transitions between calls. If that boundary remains central, the workflow around it cannot stay this fragmented forever.

It is time to care about API tooling again

I do not think the conclusion is that we need another Swagger clone. And I do not think AI will make API tooling disappear.

The conclusion is almost the opposite: it is time to take the API ecosystem seriously again.

Not just as documentation, schema, generated code, or a request sender with a nicer UI, but as a workflow problem.

A real API workflow should let you understand an API, explore it, keep the useful parts, turn them into verification, run them in different environments, inspect failures, and make that whole loop work better with AI instead of breaking under it.

That is still missing.

We did not stop talking about APIs because they became perfect. We stopped talking about them because we stopped expecting anything better.

I think that is a mistake.

The reason I am building Glubean is simple: it never felt good enough in the API ecosystem. Not the exploration workflow. Not the testing story. Not the handoff into automation.

So I want to try one more time. Not because I think one new tool will magically fix everything, but because I do not think the community should give up on this problem.

Why I Replaced Postman with a TypeScript Workflow in VSCode

PeiSong — Mon, 23 Mar 2026 09:06:11 +0000

Every time I work with an API, I go through two phases.

First, I’m exploring — sending requests, checking responses, and figuring out how things actually behave. For years, this happened in Postman, or curl, or a scratch file hidden somewhere.

Then later, when I need to make sure things keep working, I move to a test file and rewrite the same requests from scratch. By that point, I’ve already forgotten half of what I learned during the exploration phase.

I kept doing this until I realized the problem wasn't laziness — it's that these two phases happen in completely different tools with completely different formats. The exploration work is always throwaway.

That’s the gap I wanted to close.

The problem with "UI-First" Exploration

Yes, Postman already solves part of this. If all you want is to send a request and inspect the response, it works.

But once the workflow gets more real, I want the thing I write during exploration to already be code: code in git, code I can review in a PR, code that can use normal npm packages, and code that runs in CLI and CI later.

That matters even more now because code works much better with AI tools. An agent can generate, edit, and refactor TypeScript much more easily than it can maintain a click-through UI workflow.

The idea: exploration and verification should be the same workflow

What if exploration and testing were the same thing?

Not "export your Postman collection as tests." Not "record and replay." Just: write a request and assertion in a real code file, run it with one click, and keep it.

By using TypeScript as the exploration tool, you get:

Full npm power: Need a random UUID? crypto.randomUUID(). Need a mock user? Use faker.
Type Safety: Your IDE tells you if you misspelled a header or a parameter before you even hit "Send."
Refactor-ability: Want to change a URL across 50 tests? Cmd+F and replace. That's just normal code — no special scripting sandbox needed.

What I built: Glubean

I built a workflow where the distance between "I'm just trying this" and "I should keep this in the repo" is much smaller.

One test, one click, one trace:

import { test } from "@glubean/sdk";

export const getUser = test("get-user", async (ctx) => {
  const res = await ctx.http.get("https://dummyjson.com/users/1");

  ctx.expect(res).toHaveStatus(200);
  const body = await res.json();
  ctx.expect(body.id).toBe(1);
});

If you've used Jest or Vitest in VSCode, you know the play button that appears next to each test. Same thing here — I click it, the test runs, and a Result Viewer opens right inside VSCode.

You see the method, URL, status code, and the full request/response body. It feels like Postman, but it's powered by the file you're actually editing.

Real workflow — shared state, steps, npm packages:

Once I have something worth keeping, I click the file-level play button and get a real result report. This is also where the workflow stops looking like Postman.

Instead of a saved request in a UI, I have normal TypeScript: I can use the builder API for a multi-step flow and pass state from one step to the next. If one step fails, the rest are skipped automatically.

import { test } from "@glubean/sdk";

const API = "https://dummyjson.com";
let userId;

// Simple test — fetch a known user
export const getUser = test("get-user", async (ctx) => {
  const res = await ctx.http.get(`${API}/users/1`);
  ctx.expect(res).toHaveStatus(200);
  const body = await res.json();
  userId = body.id;
  ctx.log(`Loaded user: ${body.firstName} ${body.lastName}`);
});

// Builder test — reads shared userId, runs multi-step verification
export const verifyAndUpdate = test("verify-and-update")
  .step("Check user profile", async (ctx) => {
    const res = await ctx.http.get(`${API}/users/${userId}`);
    ctx.expect(res).toHaveStatus(200);
    const body = await res.json();
    ctx.expect(body.firstName).toBeDefined();
    return { originalName: body.firstName };
  })
  .step("Update user name", async (ctx, { originalName }) => {
    const res = await ctx.http.put(`${API}/users/${userId}`, {
      json: { firstName: "Updated" },
    });
    ctx.expect(res).toHaveStatus(200);
    ctx.log(`Renamed ${originalName} → Updated`);
  });

Note: Tests in the same file share module scope and run in export order — getUser runs first and sets userId for verifyAndUpdate. Shared variables should be declared at module level but assigned only inside test callbacks. See Limitations for details.

The builder's .step() chain passes state between steps inside a single test. When I run the file, the result report shows each step's status and duration.

This is just a small slice of what the SDK does — schema validation, data-driven execution, custom metrics, retries, plugin support for browser, GraphQL, gRPC, and more. But the point of this post is the workflow, not the feature list.

The code I wrote while exploring was already real verification code. I didn't need to rewrite it or convert it into another format. That's the thing I was trying to get right.

Why it matters: The "Friction" Tax

The real cost of the old workflow isn't just the time spent rewriting. It's the stuff you never bother to turn into tests because the friction is too high.

You tried an edge case during exploration (e.g., "What if the price is negative?"), it worked, you moved on. Two months later it breaks. Nobody catches it because that exploration lived in a curl command buried in your terminal history or a temporary tab in Postman you forgot to save.

If trying something useful and keeping something useful are the same action, more of that work survives.

From VSCode to CI

Because it's just code, these files run in CLI and CI without any changes.

glubean run tests/

I didn't want one format for local exploration and another for automation. No more "exporting JSON" or "syncing collections." Your verification files live where they belong: in your repository, next to your source code.

The same file runs in your terminal and CI — no conversion, no export:

# Same file, same assertions — now in your terminal or CI pipeline.
# The result.json contains the exact same traces you see in the VSCode Result Viewer.
npx glubean run explore/dummyjson/smoke.test.ts --verbose --emit-full-trace --result-json ./smoke.result.json

Open any .result.json in VSCode and the Glubean extension renders it in the Result Viewer automatically — full trace inspection, assertions, and events, even when the test was run from the CLI.

That broader path is part of what I like about this workflow: start by exploring in VSCode, keep the useful parts as committed verification, run the same files in CLI/CI later, and only think about Cloud when you want help understanding failures, tracking metrics over time, and getting notified when behavior changes.

But this post is really about the first phase: exploration.

Where this is now

I'm building this as Glubean — a free and open source SDK + CLI + VSCode extension. The local workflow is free, and Cloud upload is optional. It's also designed so the platform does not need to know your secrets, but that deserves its own post. There's an AI angle too, but I don't want to overload this one: code-first exploration turns out to be a much better surface for AI authoring than click-through UI workflows, and I'll write about that separately.

If you want to try it:

Install the Glubean VSCode extension. You may need to reload the VSCode window after installing.
Create a .test.js file (no project setup needed — just one file).
Write a ctx.http.get() and click the play button.

For scratch mode limitations (TypeScript type errors, no .env support), see Limitations.

That’s the first step. Open a test file, write one request, and click play.

If you want runnable examples instead of toy snippets, I also put together a cookbook repo with patterns you can run in VSCode after a quick npm install.

If you’re still bouncing between Postman and a test suite, I’d love to hear what keeps you there.