AMA with Sterling Chin, Senior Developer Advocate at Postman

API Pulse
1

Hey everyone, I’m excited to kick off Postman’s first AMA!

I’m Sterling, a Senior Developer Advocate here at Postman. Over the past few years, I’ve helped launch features like Postbot (our AI assistant), Flows, gRPC, GraphQL, and Agent Builder. Before jumping into DevRel, I led engineering in Postman Labs, where we turned early ideas into full products.

On the personal side — I’m a dad of two, and my family just made the move from Texas to San Francisco. Between wrangling my boys and wrangling APIs, I’ve learned a thing or two about balance.

Ask me questions about:

  • Building with AI

  • Scaling API technologies like GraphQL and gRPC

  • How AI and APIs fit together in practice

  • Moving from engineer → manager → advocate

  • Or honestly, anything else you’re curious about — career growth, work-life balance, or what it’s like shipping new features at Postman

:light_bulb: How it works:

  1. Drop your questions in this thread anytime this week.

  2. I’ll be here answering throughout the week.

  3. The questions that sparks the most discussion may win some Postman swag.

4 Likes
2

@sterlingchin

What’s the biggest difference between being a developer advocate and an engineer?

1 Like
3

Hi Sterling, hope you’re having a good day. Could you share about your challenges with the Postbot project and how you overcame them? My second question is: what were the milestones that took you from junior to senior role, and beyond that? And final question, how do you balance work and time with family? Thank you!

1 Like
4

Hey Sterling, I’ve got a few questions:

  1. What’s been the hardest part of making Postbot actually useful in a real developer workflow, instead of it just feeling like a neat AI toy?

  2. Looking ahead, where do you think AI + APIs will make the biggest impact beyond just code completion?

  3. From your experience, what’s one common mistake developers make when working with APIs that you wish more people avoided?

1 Like
5

As a developer, I spent my time working toward sprint goals, and my stakeholders were internal. I was writing code for features or bug fixes.

Now the code I write is for the purpose of teaching. I’m working on a new video series for Postman where I’ll be building agents. So I’m still writing and shipping code, but the audience and purpose are different.

It’s been a transition for sure, and finding the right balance between building for developers and also marketing Postman has been difficult sometimes. The reality is that engineers hate being marketed to, but we love being sold on products/features that actually work.

1 Like
6

Holy cow, great questions! I’ll reply in order:

Postbot challenges

Postbot wasn’t easy to begin with. When we kicked off the project back in March of 2023, the AI industry was very much in it’s infancy, so we didn’t know where things were going to go. Back then there was very little infrastructure from the major labs like OpenAI and Anthropic, so we faced so many scaling issues as they were facing them.

We struggled with users asking Postbot to do more than one thing. Chain of Thought still didn’t really exist, but so many users were asking Postbot to write tests and docs at the same time, so we had to come up with a way to solve for that. I remember the team came up with a multi-agent platform where there was a primary agent that would take in the requests and it would divvy out the work to sub-agents that were designed for one task only (like writing tests). I’m not going to say we pioneered multi-agent systems, but we were one of the early adopters for sure.

But to answer your question about how we overcame them, it was because we didn’t build or write code to be perfect. Our focus was to get something out in front of developers quickly, get feedback, and then rapidly iterate. We were shipping many times a day. So many projects get bogged down in being perfect, but you just need to get something in front of your core audience and see if they like it.

Milestones

This is one of my favorite questions to be asked because it’s not something we’re good at doing as an industry. Junior to Mid is the easiest. It’s all about the ability to work independently without a lot of oversight. Juniors need, and should receive, a lot of coaching and teaching from a senior+ developer. Given a task, the Junior engineer should be having regular check ins with a senior to make sure they’re on the right path. And when coding questions come up, they work toward solving them. My advice to all of the junior engineers I mentored was the 45 minute rule: “Work on a problem for 45 minutes. If, at the end of 45 minutes, you’re still spinning your wheels and haven’t gotten anywhere, come find me and let’s figure it out.”

Once a junior starts to be able to manage themselves on tasks, then it’s time to look at the mid-role. This timeframe is different for everyone, but my rule of thumb is that juniors should be juniors for 1-2 years.

Mid level engineers stay the longest, anywhere from 3-7 years in my opinion. Mid level engineers can do a lot, but the jump to senior is about experience, not about time. A good senior has the experience under their belt to solve problems they encounter. So if you’ve been at your company as a mid for 4 years, you likely have seen some stuff. You’ve seen prod go down, you’ve seen major bugs get shipped, and you’ve probably shipped some yourself. But if you’ve got the experience of being able to bring prod back up, or reduce bugs being shipped, and if your team has the confidence in you that your work is high quality, it’s time to look at senior roles.

Balance work and family

For me, I put my family first, and then fill in the rest of the time with work. For instance, when my oldest gets home from school and asks me for help on their math homework, I prioritize that because I also know that once they’re in bed, I’ll be able to finish what I’m working on.

AI has been a huge unlock for me though too. I’ve got so many tools that I use now that help me stay on top of everything that I can accomplish a lot, even on the go.

2 Likes
7

What’s been the hardest part of making Postbot actually useful in a real developer workflow, instead of it just feeling like a neat AI toy?

First off, we needed to know where developers needed help. We needed to understand where the pain points were in API development and then use AI (via Postbot) to make those workflows and pain points easier to deal with. Part of taking AI out of being just a neat new toy is about understanding who we’re building for. It sounds like a no brainer, but we wouldn’t put image generation into Postbot, but I’ve seen other AI chatbots online that have image generation on them. Toys aren’t useful, but good tools are.

Where do you think AI + APIs will make the biggest impact beyond just code completion?

This is where I step in with my love of MCP (model context protocol). AI is only as good as the knowledge it has, and the tools it has access too. Prior to MCP, you would have to manually program a bespoke integration of an API so that the AI would have access to it. Now with MCP, you can create the tool list (APIs and function calls) and give it to the LLM to decide when to use it. I’ve used this example before:

  • LLM alone = A great mechanic with all the knowledge, but no tools
  • LLM + Bespoke Integrations = A great mechanic with all the knowledge and a micromanager telling them exactly when to use the 10mm
  • LLM + MCP = A great mechanic with all the knowledge and a garage full of tools at it’s disposal to pick and choose from.

What’s one common mistake developers make when working with APIs that you wish more people avoided?

Error codes and error messages. I wish I could shout this at the top of my lungs from the highest mountain! Everyone’s error codes and messaging sucks! I try to integrate with someone’s API and when I run into an error, it’s always one of 2 errors, 404, or 500. But there is no additional messaging letting me know exactly what’s wrong. With AI now, we should be able to make our API specs extremely clear and very clear error codes and messages, and since most of our APIs will now be exposed to LLM via protocols like MCP, we need to make our APIs ready for AI consumption.

1 Like
8

How do you see AI changing the API development workflow in the next 2-3 years? What should developers be preparing for?

1 Like
9

With AI and agents becoming more integrated into developer workflows, how do you see the role of an API-first mindset evolving—and what skills should developers focus on now to stay ahead in this shift?

2 Likes
10

This is near and dear to my heart, and I have a lot of varying opinions on this topic. Let me start a bit more generally and then drill down into api development.

Generally speaking, AI is fundamentally changing how developers write code. The rise of vibe coding tools like Lovable and Repl.it have brought on a new kind of developer, while tools like Claude Code that lives in your terminal and can navigate, write, and debug codebases is going to be like giving experienced developers super powers. In the next 2-3 years, we’ll likely see well over 75% of all new code being written by AI.

Now to drill down into API development. If AI is fundamentally changing how we write code, then, by extension, API development will also be impacted. We will need to start to build APIs that are designed solely to be consumed by AI. The API protocols that exist may have to change and evolve to be better suited for AI. For instance, HTTP/REST/SOAP were originally designed with humans in mind, long before we even thought AI would exist. I think we need to rethink API design from the ground up, and even look at new protocols. GraphQL and gRPC are great candidates for AI usage. GraphQL because the AI can create its own requests and get exactly that it needs from the graph, and gRCP (or any RCP for that matter) are blazing fast, which is necessary for AI when it can do thousands of calculations a second, so much faster than a human. Or we have to come up with new protocols that are AI specific.

As developers now, I’d just keep looking to trusted sources of information, and evolve with industry. Unlike past technical revolutions, the AI revolution is moving 100x faster. What would take 2 years to evolve, is evolving in 2 months. So I’d just keep learning. We’re in a very exciting time in the industry. It’s never been more fun to be a software engineer.

11

I think API first is more important now than ever before. LLMs are only as good as the data they’ve been trained on. So giving them access to the tools (through APIs) to accomplish tasks is when we unlock the power of AI. This is why I’m so bullish on MCP. MCP unlocks the power of AI to accomplish tasks by giving them access to the tools and resources it needs to formulate the solution. I’ve seen full workflows created into agentic workflows because the apis all exist. AI is only going to be as powerful as the APIs it has access to.

But we also need to rethink our APIs and the protocols we use. I firmly believe that we need to start having an AI-first & API-First mentality. We need to realize our API will be consumed by AI agents, and rethink how we build APIs.

I love the question “what skills should developers focus on now to say ahead”. My recommendation is to be curious. Be willing to learn something new. Right now everything is in flux and nothing is sacred when it comes to AI. The second skill, if you could call it that, would be the ability to iterate rapidly. Agentic workflows I created only a few months ago no longer work. That’s not because I failed. It’s because as new models get released, there are more capabilities that it can do, nullifying my agentic workflows. And that’s ok! I’m better off now for learning how to build agentic workflows and adapt.