Why use design docs? Mainly because on complex software projects, if you don’t have a careful strategy, a few lines of code can lead to a ripple effect across the whole codebase. You're working on a small new feature and suddenly, your PR is touching dozens of different files in a handful of directories, and you may be questioning if it still makes sense at all.
Laying out your approach in a technical design document helps to avoid these situations, so tech companies often embed this practice in their engineering culture. Unfortunately, producing these write-ups is a manual and time-consuming process that keeps you switching between typing in Confluence, searching on GitHub, and drawing on a whiteboard.
For example, one of our early users is building a RAG (Retrieval Augmented Generation) system in Rust, and needs to rewrite their original chunking algorithm that was created in Python. A change like that involves not only porting the chunking logic but also defining new structs, choosing the Rust libraries for text parsing, re-integrating with the Rust server, and changing the endpoint on the front end. Simple-sounding changes like these can end up with many "tentacles" devs have to work through. Our product helps teams like this spec out their approach more quickly.
The need for this hit us when we were working on a product using LLMs to turn tickets into PRs. You can just assign a ticket to GPT-4 and review the PR, right? Turns out that most people (including us) don’t write very complete or specific tickets on the first pass, and when they do, that ends up being more effort than just doing the whole thing yourself.
What was missing was a fast way to iterate on goals, requirements, and implementation plans for code that could then be useful to developers (whether AI assisted or not) to implement with high confidence. Our editor, Glide, splits this process into the following stages and lets you spend as much or as little time on each stage as makes sense.
(1) We index your project code with Tree-Sitter and make it searchable, so you can add relevant parts of the codebase to the task context.
(2) AI writes the first pass for a high-level solution outline given the code and the goal. It will try to point out missing details or ambiguities about the task so far.
(3) As a developer you can easily edit the generated content—tweaks like “change step 3” or “remove the part about caching” don’t require additional back-and-forth conversation.
(4) The next stage is a step-by-step plan—a pseudocode-level guide for how to complete the change. AI generates this, and again you can make adjustments in-line as needed.
(5) There is a chat mode for deeper discussions about the content—just highlight any text and click chat. This works well for exploring alternatives, getting more specific on a particular point, or understanding why the AI wrote what it did.
(6) Once the plan looks good, you can have AI generate code edits for each step. You’re free to make additional changes here or just open the markdown doc with code edits in your local VSCode via an extension, so you have it as a reference while you implement.
This looks a lot like collaborative Chain of Thought, explicitly writing out each step in a line of reasoning, for both the developer and the LLM. Breaking down a high-level task with AI this way can work well for building consensus on the desired end state of your change.
We plan to charge companies per seat, but today, it’s free for individual use as we get more feedback on the product. One future area we’re excited for is multiplayer mode—where a few developers can share, edit, and leave comments on the generated docs in a shared workspace. If you have ideas for this experience, we’d love to hear them.
We would love for you to give it a try at https://glide.agenticlabs.com/ and tell us what you think! We’re excited to discuss this with any comments you have!
P.S. We only keep the indexed code in an in-memory cache while you’re using it. We don’t store your code or use it as training data!
by Andrey
Azimov