Hi everyone! We're building an AI-enabled editor (
https://glide.agenticlabs.com) that helps developers write technical design docs faster. It’s like an IDE with Copilot, but instead of directly editing your code, it helps you come up with a solid plan before implementing a change. There’s a basic demo here (
https://youtu.be/5uEapdT6nYE), and we also recorded a session with one of our early users running through an unusual task (calling a Fortran algorithm from Go,
https://youtu.be/ppluB0Z1OIA)
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!
- It would be significantly more helpful if it could ingest my database schema.
- Why make me manually pick files instead of indexing them all and doing some RAG magic?
- Having used ChatGPT for similar tasks, I'm skeptical that step 2 you have, where it generates a high-level solution, will work all that well. Right now, LLMs work best for me when I'm giving them much more specific tasks and keeping the high-level plan in my head.
- This isn't really a technical design doc in the sense that I use the term? This might just be me using language incorrectly but I typically call a tech design doc a document that explains the inner workings of a system, normally with something like a UML or similar diagram. This just seems like todo list or subtask generation for writing a feature.
- Have you considered feeding the AST directly into the LLM? Honestly just curious how well it would understand the code if you did that vs. giving it the raw source.
Either way, congrats on the launch!
reply