6 ms·
Launch HN: Glide (YC W24) – AI-assisted technical design docs
Hi everyone! We're building an AI-enabled editor (https://glide.agenticlabs.com 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 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 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/ 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!
- bluepanda1234 3y agoI gave it access to a single private repo, but on your site I see `No repos configured`. Do I need to give it access to all my repos for it to work?
- robmck 3y agoHi thanks for trying it out! We don't automatically pull in the repos you allow access to. If you go through the configuration on the left side of the screen you should be able to add that repo. Specifically, in the "Repo to index" section, if you click the dropdown on the right side you should see the repo you have added. Hopefully that helps but let us know if you're still having issues!
- skeptrune 3y agoI really appreciate the approach of orienting this to be very much "AI-assisted" rather than "AI-driven". At no point in the process did it feel like the LLM entered a black box, did something, then made the walls transparent. There's an incredible amount of promise in this UX. Excited to see it continue developing alongside the foundation models and new technique approaches.
- robmck 3y agoThanks for the feedback! We've really focused on keeping the engineer in control.
- hubraumhugo 3y ago> but instead of directly editing your code, it helps you come up with a solid plan before implementing a change. Is this similar to Devin that just launched today, except that Glide is less autonomous and gives you more control? How do you compare to them? https://twitter.com/cognition_labs/status/1767548763134964000 https://twitter.com/cognition_labs/status/176754876313496400...
- robmck 3y agoGreat callout! I think it's similar, but our approach is a bit different from Devin's because we're currently focusing less on autonomy. It looks like Devin chooses a plan and then writes and runs the code or uses the internet to get feedback on how to change the plan/code accordingly. We focus on having the engineer work with the AI on the plan before writing the code, and the engineer is responsible for the final implementation. We found that doing everything autonomously was awesome when it worked but frustrating when it didn't; so we wanted to make the UX interactive enough to be useful even if the AI gives some unexpected results. Does that help?