Why Toss Frontend Developers Don’t Read the Docs

Korean version: https://toss.tech/article/toss-frontend-ai-docs

When you start developing a new feature, there’s always that moment: your monitor is crowded with dozens of tabs, and you’re trying to find the internal documentation on how to use a team tool–but you can’t even remember where the document is. You end up messaging a colleague, waiting for a reply, and losing your development flow. Sound familiar?

The Toss Frontend Chapter also faced similar challenges. But instead of just improving our documentation to encourage visits, we approached the problem differently: we made the documentation come to the developers.

Breaking Path Dependence in Documentation

Path dependence in documentation refers to the fixed steps users must take to find the information they need. Traditional technical documentation is often structured from the providers’ perspective, requiring users to search or navigate multiple layers to locate what they’re looking for. To break this dependence, we started by observing how developers work and conducting interviews.

The most common way developers find information? “Asking”. They ask the colleague sitting next to them or post a question in the Slack channel. It’s an intuitive and relatable behavior. So, instead of forcing developers to adjust to documentation, we decided to adjust the format of the documentation to respect their natural habits.

The best part of asking questions is its immediacy. It’s much quicker and easier to ask to colleagues than to sift through a massive document. If we wanted our documentation to be more actively used, it needed to offer the same immediacy. Imagine being able to “ask” a document a question and get an instant, context-relevant answer–just like a conversation.

That’s the vision behind ‘Mr.Park’.

Mr.Park: Conversational Documentation

• What it does: Ask a question, and Mr. Park provides answers based on the documentation. No need to disrupt your workflow.
• Where to find it: Integrated into your IDE (e.g., VSCode, Cursor) and internal messenger (Slack).
• Why it works: Instead of “searching the docs,” you can simply “ask” and get the knowledge you need, as if you’re chatting with a colleague.
• Fun Fact: Mr. Park is inspired by Sojin, the Head of the Frontend Chapter.

Mr.Park is a RAG(Retrieval-Augmented Generation) based chatbot, designed to provide reliable and precise answers by leveraging existing documentation. It also includes the source of the information, so users can verify its accuracy, Unlike asking colleagues, Mr. Park delivers consistent responses and avoids the risk of miscommunication.

However, for Mr Park to provide high-quality answers, it needs a solid knowledge base. That’s why we focused on improving both the quantity and quality of our documentation. But scaling this effort with just technical writers and a handful of developers wasn’t feasible. To make this system scalable, we needed a way for everyone to contribute to documentation effortlessly. That is Sillok Bot.

Sillok Bot: Automating Documentation

• What it does: Transform Slack conversations into documentation.
• How it works: Add the customized Sillok emoji to a thread or mention @silllok, and the bot analyzes the conversation, summarizes it, and creates a pull request for the documentation repository.
• Why it helps: Instead of manually dedicating time to writing docs, documentation happens naturally and automatically during problem-solving.

Developers constantly share knowledge by answering questions or discussing issues on Slack. The problem? These conversations quickly disappear and the same questions keep popping up. SIllok bot solves this by summarizing useful threads and creating pull requests to record them in the documentation repository with minimal effort.

For example, a team member might flag a Slack conversation about a bug fix as useful by calling Sillok Bot. The bot then turns that discussion into a document, which Mr. Park can learn from. This allows team members to find answers easily without repeating the same questions. It’s not documentation for documentation’s sake–it’s documentation created naturally in the moment when knowledge is shared.

A Team Where Knowledge Flows

Thanks to Mr.Park and Sillok bot, the Toss Frontend Chapter no longer struggles with knowledge bottlenecks or repeating questions. By providing information precisely when it’s needed, we’ve created an environment where knowledge flows naturally, improving team productivity and efficiency. Observing developers’ behavior and treating technical documentation as a dynamic system for learning and problem solving–not just a static repository of knowledge–has proven to be highly effective.

Technical writing is evolving too. It’s no longer just about structuring information from the provider’s perspective to explain features effectively. Now, the focus is on creating a system that helps developers make the best use of documentation. At its core, technical writing is about one thing: how documentation can help solve developers’ problems.

The Toss Frontend Platform team is looking for a developer to join us on our journey to create a knowledge-sharing, accessible learning infrastructure, further develop our AI-powered documentation system, create a documentation automation system that naturally connects with code, and build a docs ecosystem that works well across platforms, including our internal messenger.

If you’re interested in taking the DX to the next level by creating an environment where developers can work more efficiently, apply for the Frontend Platform Engineer position! Let’s build a better development culture together.