An Old Problem Exposed by a Scheduling Meeting

At last month's sprint planning meeting, both the frontend team and the client team came to me asking for interface definitions. The backend's response was: "The docs aren't ready yet—get the API working first, and just understand it from the response samples."

I've heard that line no fewer than ten times. The result: the frontend had a Postman screenshot and had to guess field types on their own; the client team got a screenshot from a different point in time, where the fields had already changed; and the QA engineer wrote test cases based on the frontend's understanding, giving birth to yet a third "understanding." By the time we actually got to integration, the three sides' type definitions didn't match—whether the four-level nested data.items[].user.permissions in the response structure was an array or an object turned into a heated argument.

For a five-person team, this kind of waste is invisible: it never shows up on any timesheet, but it happens every single week. As a team lead, I don't care whether AI can write flashy code—what I care about is whether it can eliminate this kind of process waste.

The Process Change I Had the Team Make

The change we made was small: insert an AI type-inference step between "backend provides response samples" and "frontend starts writing code," and standardize that step.

The new process looks like this:

1. The backend provides the interface response sample (in JSON format, even raw data copied straight out of Postman)
2. Anyone feeds that sample to an AI, which infers and generates the TypeScript type definitions
3. The generated type definitions are committed to the team repository's types/ directory, serving as the single source of truth
4. When the interface changes later on, run through this process again and review the type changes with git diff

The key isn't step 2—AI inferring types is nothing new—it's steps 3 and 4. I turned the AI's output from "an individual assistant's result" into "a team asset," and that's what gives it managerial significance.

Here's the prompt template we use (ready to copy and use directly):

你是一名资深前端工程师。请根据下面的接口返回JSON样例，反推完整的TypeScript类型定义。

要求：
1. 为每个嵌套对象提取独立的 interface，命名使用大驼峰，字段语义化命名
2. 字段类型不能只看样例：对于可能是可选的字段，标记为可选并注释说明
3. 对于样例中为 null 或含义不明的字段，列出"待与后端确认"清单
4. 数字类型需区分 number，时间字段若为时间戳需注释说明单位
5. 输出按文件组织，最后附上字段与原始JSON路径的对照表

接口名称：{接口名}
JSON样例：
{json_content}

Rule 3 is the essence. The biggest risk with AI isn't getting things wrong—it's being overly confident in its inferences. If id is a number in the sample, it writes number, but the backend might actually use strings. Forcing the AI to output a "to-be-confirmed list" means having the AI generate a communication agenda for the team, rather than making decisions on the team's behalf.

Before and After AI

Before the change:

• After receiving response samples, frontend devs spent an average of 2–4 hours hand-writing types, longer for deeply nested interfaces
• Type definitions were inconsistent across platforms, adding an average of 1–2 extra days of rework during integration
• When interfaces changed quietly, nobody found out right away—it was usually discovered through production errors
• Type definitions were scattered across each platform's codebase; new hires had to do archaeology to get up to speed

After the change:

• Type definition generation went from hours to minutes; the human's job became reviewing the AI's "to-be-confirmed list"
• Types live uniformly in the repository, all three platforms reference the same copy, and integration rework has essentially disappeared
• Interface changes go through the process, and the type changes in the git diff serve as the change notice—reviews now have something concrete to grab onto
• New hires can understand the full interface structure through the types/ directory on day one

All told, for a medium-sized project (around 30 interfaces), type-related workload shrank by roughly seventy percent. More importantly, scheduling became predictable—before, "integration" was a black box; now it has clear inputs and outputs.

Three Things Managers Must Keep Under Control

After running this process for over a month, I've summed up three lessons, all learned the hard way:

First, AI output must be reviewed by humans, and the review criteria must be written up as a standard. We mandated that the "to-be-confirmed list" must receive a written reply from the backend before anything can be merged. Once, to move fast, we skipped this step—and it turned out a status field the backend actually returned as a string enum got inferred as a number by the AI from the sample, costing half a day of rework. The premise of AI-driven efficiency is humans holding the acceptance gate.

Second, the samples themselves need quality standards. Garbage in, garbage out. We require that samples provided by the backend must include edge cases like empty arrays and null values, otherwise the AI infers too optimistically. This rule is written into our team collaboration guidelines.

Third, control tooling costs and account risks. As the team grew, every member registering their own AI service meant scattered accounts, scattered bills, and chaotic key management—when something went wrong, nobody could explain it. We later consolidated everything through an AI gateway: all members call models through the same entry point, with permissions and usage centralized in an admin-side dashboard; for specific pricing, refer to the official pricing page. For managers, this follows the same logic as a unified code repository—individual productivity tools only deliver sustainable returns once they become team infrastructure.

Final Thoughts

The biggest insight this round of practice gave me: an AI's value to a team doesn't depend on how impressive any single output is, but on whether you've designed a process that makes its output accumulable, reviewable, and traceable. Type inference is just the entry point—the same approach can easily extend to scenarios like API documentation generation, mock data construction, and error code mapping tables.

If you're also leading a small team and struggling with the hidden costs of API integration, start by trying out this one step. And if you need a unified entry point for managing your team's AI calls and account permissions, check out this platform: https://api.thistoken.ai/register

---

Every example in this post runs with a single API key — get yours at https://api.thistoken.ai/register and start in minutes.