A Walk With Cursor's Ian Huang: Coding Agents, Startups, and Remembering to Document the Process
Not long ago, I took a walk in San Francisco with Ian Huang. Ian is a founding engineer at Cursor, one of the hottest startups in SF, and co-authored Cursor's Agent CLI launch post last year. We began with life after SpaceX acquired his previous company, then got into whether Cursor is really an IDE or a coding agent. From there we moved through product validation, a communication agent I'm working on, and a question I am still thinking about: should AI make our words prettier, or teach us how to say what we mean more clearly?
Foreword
I met Ian last year and told him we should go to Barcode when he was back in Taipei. We still have not made it; apparently it is easier to meet at Monroe in San Francisco. I have friends at large companies building MVPs for products they care about, recording demos when they are ready, and showing them to smart friends around them.
Is Cursor building an IDE, or a coding agent?
I asked Ian directly: does Cursor think of itself as an IDE or a coding agent?
His answer was direct: a coding agent. The IDE side is more about meeting existing expectations for a development environment. What actually moves the product forward is whether an agent can understand a task, act on it, and verify the result itself.
That is consistent with Cursor's public direction. Cursor has extended Agent beyond the editor, letting it search a codebase, edit files, and run terminal commands. Its description of the next phase is a move away from writing code line by line toward directing agents that can work independently for long stretches. See Cursor's agent implementation advice and its post on the third era of AI software development.
What I find most interesting is that the IDE does not suddenly die. Ian still reads diffs and files directly to understand a codebase. But opening an editor and typing every character yourself is no longer the only, or necessarily the most important, interaction. The IDE becomes where a person goes to understand, intervene, and review when needed; agents begin taking on the longer execution loop.
The IDE is not disappearing; human typing is simply no longer the center of the development process.That also changed how I read my earlier post on why big companies build their own coding agents. The real value is not only whether a model can write code. It is what context it can access, what tools it connects to, and whether it can complete work in the right environment.
We also talked about why companies such as Ramp and Stripe still build their own coding agents. Ian's view is that, if it is not a company's primary revenue source, it is easy for the work to be deprioritized. That does not mean internal agents lack value; turning them into a meaningful capability requires deep organizational commitment. Cursor's direction points to the same conclusion: agents should not remain inside an editor, but work across environments and run longer tasks, with people responsible for direction and review.
Decide who you want to become, then begin
Before products, we talked about a more personal question: how does someone find direction?
Ian believes in having a specific goal, believing you can reach it, and then continually finding ways forward. You may not see every step at the start, but moving in that direction gradually turns you into that person. The point is not to describe a wish beautifully; it is to actually begin.
His example was concrete: have 500k in a bank account before turning 25. He did not specify a currency, and the number itself was not the point. It forces a wish into executable work: build projects well, find a job, learn to invest, save. Lots of people have the same goal but remain at “I will start soon.”
I liked one image he offered: live as though a documentary crew is filming your life. Not to fake it, and not because every moment has to look successful. It asks whether you could look at the camera and say that the choices you made today are genuinely what you want to do. It sounds a little adolescent, but it is practical. It makes you ask whether you are accumulating work, ability, and relationships—or avoiding what you should be doing.
“We just code” is a product method
When we got to building new products and deciding whether an idea is worth pursuing, I asked whether Cursor has a clear roadmap or validation pipeline.
His answer: “We just code.”
It sounds like an engineer's joke, but there is a pragmatic logic behind it. Cursor has users, beta testers, and an internal team that can dogfood the product. Build something first, let people whose work it will affect use it every day, then keep adjusting from the problems they encounter. Do not spend a long time explaining an idea perfectly before touching the product.
Ian remembers the early Cursor team asking the same question every day: how can we make tomorrow's use of this product feel better for ourselves? If the product is something you need daily and you honestly look forward to a better version tomorrow, that is already a strong signal.
This is not an argument against interviews, data, or plans. It puts them in their right place: they help correct direction, but cannot replace putting a real thing in someone's hands. For a developer-tools team, the shortest feedback loop is often not a dashboard. It is whether you got stuck for one less hour today.
I connected this to GTM as an engineering problem: products and distribution both need observable feedback loops. A product loop asks whether users can finish work faster; a distribution loop asks whether the next right person can find it.
Personal brand does not replace networking, but it leaves evidence
We also discussed what capabilities matter next. Rather than calling it a skill, Ian cared more about personal brand.
I agree. A résumé is useful, but a personal website someone can open, a public GitHub, and a few side projects people actually use are more persuasive than a line claiming that you are passionate. You can demo what you made in an interview; recruiters can see evidence you left in public before you apply.
That does not make networking unimportant. Our conclusion was closer to this: networking is a multiplier, not your only asset. Without work, ability, or something you can hand over, meeting more people rarely holds up over time. But after you have made a good project, a network can help the right people see it and give you early feedback.
This website is the same kind of work. It is not a prettier résumé; it is an evolving body of evidence: what I think about, what I have made, and where I am going.
The problem I want to solve is not “communication that sounds prettier”
I told Ian about a problem I have run into repeatedly.
On the sales or GTM side, you see customer requests directly. On the engineering side, you see code, existing commitments, system constraints, and a backlog. The two sides can easily disagree on what is P0, and it is not necessarily because either side is not trying. They often have different context.
I do not want to build another Grammarly that makes Slack messages more polite. I imagine an agent that understands how someone works and the context inside a team. When you need to send a message, make a request, or decide something, it could tell you what context is missing, what the other person may care about, and what question to ask next.
Ian immediately separated two problems that should not be mixed:
| Problem | What is actually missing | More appropriate product behavior |
|---|---|---|
| I do not know what the engineering team is doing | Work context | Visibility into daily updates, decisions, blockers, and ownership |
| I know the situation but do not know how to explain it to the right person | Communication judgment and social cues | Prompts, examples, role-play, and feedback afterward |
That distinction mattered to me. Better information flow can address the first problem. The second does not disappear simply because you have more information. You may know an engineer is overloaded and still not know how to make the request, who to ask first, or how to show that you understand their constraints.
Start with a small version that helps people improve
Ian's final advice was simple: build first, demo first, and see whether anyone actually likes it.
For a first version, I would not start by reading every Slack, Notion, and GitHub record in a company and trying to understand everyone. That is too large and too likely to become surveillance.
I would start with a narrow interaction: a short check when someone working across functions is about to make a request.
- State the request's goal clearly.
- Add user evidence or business impact.
- Name the constraints you already know.
- Ask a question that lets the other person add context instead of simply dropping a P0 request on them.
Then test one thing: the next time, without the agent's help, can the user make the request better? If not, it may only be a rewriting tool. If yes, it is closer to a product that genuinely lowers communication cost.
Startups, studying, and not treating university as job training
Near the end, we discussed our respective ideas about the future. I have long been interested in philosophy and literature, and I hope to return to school to study seriously one day. But I do not want to treat university now as nothing more than a credential factory for changing jobs.
I have set myself an unromantic but concrete timeline: finish a degree before thirty. Before then, I want to work, build, and learn the things I can learn on my own. This differs from the conventional path of finishing university and joining a large company, so of course I sometimes wonder whether it is right.
But Ian's reminder returned to the original point: if you are clear about what you genuinely want, start moving toward it. Do not wait for all doubt to disappear. It probably will not. You keep doing, then correct yourself in the work.
Back to “build for yourself”
After talking with Ian, I did not feel that the idea had been rejected. I felt pushed to explain it more clearly.
I had imagined an AI that could add missing context for a team. Ian reminded me that context and communication ability are separate. The first can become daily updates, decision records, or a search system. The second needs a feedback loop that helps people practice, understand, and gradually internalize better judgment.
That makes the first version more practical: not an all-knowing workplace agent, but something that reveals a blind spot to people communicating across functions.
Ideas are cheap. What is useful is building one, letting yourself and a few people with the real pain use it, and seeing whether tomorrow's work becomes smoother.
That is probably what every topic that day pointed toward. Whether you are building a coding agent, trying a startup, developing a personal brand, or deciding whether to return to school: do not leave the idea in your head. Make a version, let the world touch it, then decide the next step.
Further reading: Cursor's Agent CLI was co-authored by Ian and the team. If you are interested in the context layer for agents, see my notes on MCP, Skills, and Workflows.