[HN Gopher] Launch HN: Glide (YC W24) - AI-assisted technical de...
___________________________________________________________________
Launch HN: Glide (YC W24) - AI-assisted technical design docs
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!
Author : robmck
Score : 86 points
Date : 2024-03-12 17:21 UTC (5 hours ago)
| skeptrune wrote:
| I 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 wrote:
| Thanks for the feedback! We've really focused on keeping the
| engineer in control.
| hubraumhugo wrote:
| > 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/176754876313496400...
| robmck wrote:
| Great 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?
| hubraumhugo wrote:
| Makes sense, it will be intersting to see how the balance
| between control and autonomy will play out.
|
| From Kapathy on Twitter:
|
| > In my mind, automating software engineering will look
| similar to automating driving. E.g. in self-driving the
| progression of increasing autonomy and higher abstraction
| looks something like:
|
| 1. first the human performs all driving actions manually
|
| 2. then the AI helps keep the lane
|
| 3. then it slows for the car ahead
|
| 4. then it also does lane changes and takes forks
|
| 5. then it also stops at signs/lights and takes turns
|
| 6. eventually you take a feature complete solution and grind
| on the quality until you achieve full self-driving.
|
| There is a progression of the AI doing more and the human
| doing less, but still providing oversight. In Software
| engineering, the progression is shaping up similar:
|
| 1. first the human writes the code manually
|
| 2. then GitHub Copilot autocompletes a few lines
|
| 3. then ChatGPT writes chunks of code
|
| 4. then you move to larger and larger code diffs (e.g. Cursor
| copilot++ style, nice demo here
| https://youtube.com/watch?v=Smklr44N8QU)
|
| 5.... Devin is an impressive demo of what perhaps follows
| next: coordinating a number of tools that a developer needs
| to string together to write code: a Terminal, a Browser, a
| Code editor, etc., and human oversight that moves to
| increasingly higher level of abstraction.
| robmck wrote:
| I love this anecdote because we've discussed following
| "Tesla's model" of autonomy, where they have incrementally
| delivered more complex driver-assist features.
|
| It's very different from others like Waymo, who are going
| for more of an all-or-nothing approach.
|
| Similarly, we hope to be useful early with fairly simple
| features so that we can get it into developers' hands to
| learn how to incrementally make the product better.
| ivanovm wrote:
| Building on the self-driving analogy - our goal is to
| create a good "GPS" interface where you can set your
| destination and chart a path you wanna take while driving.
| In that frame Copilot is like an advanced drive-by-sensors
| system that sees the road around you and suggests some
| turns you might wanna take based on the drive so far. What
| could make this really great is the ability to build up the
| big picture of the code change so the in-line suggestions
| are informed by the path ahead.
| breadsniffer01 wrote:
| That feels like a much better approach compared to Devin.
| Autonomous agents are great for demos, not for products.
| Their demo smelled like smoke and mirrors.
| ivanovm wrote:
| I like Devin's take on rolling up more tools (terminal, editor,
| browser) in their interface.
|
| We're thinking about this a lot, but our goal is to be very
| careful about adding complexity to the product (we failed at
| this in our other endeavors!)
|
| Echoing Rob's sentiment on autonomy, we're more focused on tit-
| for-tat collaboration between the developer and AI as opposed
| to "set it and forget it" agent execution. I think both modes
| will have a role in the dev workflow of the future
| barbazoo wrote:
| Wow this looks awesome!
|
| > 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!
|
| Personally before using this on a work repo I'd like to get some
| more info on this to make sure nothing from the private repo will
| leak out.
|
| Also I'm a bit worried about giving Glide the permission "Act on
| your behalf". Is there no more granular and less powerful
| permission you could ask for, i.e. read access only? It seems
| that only "pull request (coming soon...)" which hasn't been
| implemented needs "write access".
| robmck wrote:
| Happy to explain a bit more!
|
| Here are the steps we go through:
|
| - Checkout the code to a temporary directory (which is deleted
| when it goes out of scope in python, so at the end of the
| indexing API call)
|
| - Use Tree Sitter to create an index of just your chosen
| "Directory to Index" and then store that in a Redis cache
|
| - We clear the index from the Redis cache if you haven't used
| it in 2 hours.
|
| I don't know why exactly it says the message to "Act on your
| behalf". I just double-checked in our app, and confirmed that
| these are the only permissions we get:
|
| - Contents - Read-only
|
| - Metadata - Read-only
|
| - Email addresses - Read-only
|
| We agree that we shouldn't take write access if we are not
| writing PRs. Hopefully that helps!
| barbazoo wrote:
| Thank you!
|
| It does say which sounds really ominous:
| https://imgur.com/a/w8M0wcE
|
| The link on the page points to
| https://docs.github.com/en/apps/using-github-
| apps/authorizin... which basically says the app can do
| whatever whenever.
|
| I think if the wording was different I would be able to
| successfully pitch this to my work.
| ivanovm wrote:
| This is weird, and it does sound ominous. I went to double
| check the configuration!
|
| On-prem is on our roadmap, we can definitely make that
| happen for you. We just went this route for now to make the
| app easily accessible to everyone
| morgante wrote:
| It's unfortunately terrible wording from GitHub for any app
| install:
| https://github.com/orgs/community/discussions/37117
|
| Despite the scary warning, you're only granting the listed
| permissions.
| barbazoo wrote:
| What a terrible UX by Github.
|
| > Despite the scary warning, you're only granting the
| listed permissions.
|
| Is there a way for me to verify that that's the case? At
| least after granting the permissions?
| robmck wrote:
| Yes you can. If you click on your profile, and then
| Settings->Applications->Configure you can see the
| permissions
|
| If you have it installed for an organization its slightly
| different. Go to the organization, then Settings->Github
| Apps->Configure.
|
| For me at least, it lists the permissions the app has.
| Additionally, if we ever want to request new permissions
| in the future, you will have to grant them.
| Atotalnoob wrote:
| Act on your behalf is the correct access for GitHub.
|
| I've seen several company's receive the same complaint on
| HN.... GitHub should reword it or make it more clear in some
| way
|
| You have to "act on their behalf " in order to read private
| repos (potentially) only they have access to...
| aantix wrote:
| I'm a bit worried about exposing our codebase.
|
| I wish this ran locally or was self-hosted.
| epolanski wrote:
| +1 it's also a no go for most of my clients for whom data
| cannot even leave the country, let alone the European union.
| robmck wrote:
| We totally hear you and have been thinking through the best way
| to support this!
|
| Question for you: would the app running locally be sufficient,
| or would the LLM also need to run on-premise?
| internet101010 wrote:
| Not person you responded to but for me it needs to be able to
| connect to ollama api.
| afro88 wrote:
| Not OP but I would be happy with the app running locally and
| providing an enterprise OpenAI API key
| robmck wrote:
| This is a great piece of feedback, and getting just this to
| work would not be too difficult. Thanks so much!
| WesleyJohnson wrote:
| +1 on this as well. We have an on-prem gitlab instance, so it
| needs to run locally to ingest source anyway.
| trevoragilbert wrote:
| Looks really interesting! Would love it to support Swift, it's
| very underserved with other AI code assistant tools currently.
| robmck wrote:
| We agree Swift would be awesome to support! We're looking into
| how to turn it on. The Tree Sitter parser for Swift is a bit
| tough to work with which is why we haven't implemented that
| yet.
|
| Stay tuned!
| andrethegiant wrote:
| I was initially confused because Glide is the name of a different
| YC company (from W19:
| https://www.ycombinator.com/companies/glide). But now I
| understand that Glide is the name of your product, but not
| company
| robmck wrote:
| Apologize for the confusion! Yes, the company is Agentic Labs
| (https://www.agenticlabs.com/), and our product is Glide.
| randomoctopus wrote:
| Are you aware of the work on https://github.com/paul-
| gauthier/aider? What's your take on generating code diffs
| directly instead of code editing instructions?
| robmck wrote:
| Yes, I've seen aider and I think it's a super cool product!
|
| We tried generating code diffs with our initial product. The
| issue we had was that when that diff started to grow, parsing
| it to determine whether it did the right thing became
| increasingly difficult.
|
| We will generate code diffs in the future, but we're happy with
| generating the instructions for two main reasons:
|
| -The LLMs seem to produce better output when you write out the
| intermediate steps
|
| -The developer understands the thinking behind the code that
| was written. We feel that this is an important factor as the
| team size grows and developers have to interact more with each
| other's code
| CSMastermind wrote:
| Some initial thoughts:
|
| - 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!
| ivanovm wrote:
| We'll queue up database schemas, good call.
|
| On RAG, I have a lot of thoughts - it's my pet project to make
| it work really well. We started out down this road but in
| practice getting good results out of RAG has been shockingly
| hard on bigger, more complicated codebases. In many cases when
| we put this in front of devs that know their code, the RAG part
| has been a lossy approximation of what they already knew the
| relevant code to be, so they'd sit there and watch "is this
| thing going to find the code that I already know I need for
| this task"
|
| I think the key here will be a robust, language-agnostic symbol
| graph that maps out high-resolution dependencies, so when you
| are retrieving `foo`, you can also efficiently retrieve the
| references to and from of `foo` to some depth (often greater
| than 1). Some languages have better tools for this kind of
| symbol resolution than others, but in many cases they're highly
| bespoke. Github's stack-graphs and Sourcegraph's SCIP are the
| best attempts I've seen at solving this in a generic way, but
| neither of them have gotten all the way there yet.
|
| I've been half-seriously thinking about running neovim in
| headless mode and using it as an interface to all the LSP's for
| each language, and resolving all the edges of the symbol graph
| that way - I might still try it one of these days
|
| On design doc convention - I think you're right, it's not
| completely 1-1 with the term today, and there's not a single
| definition that everyone agrees on. We're using it as the
| initial mental model of where we want to plug in, but there
| might be a better succinct way to describe it
|
| Haven't tried the raw ast yet, curious how that goes
| robmck wrote:
| Thanks so much for the thoughts! Happy to respond.
|
| -Schema: We agree. After seeing how many times it has asked to
| see the database schema when working on a task, that is
| definitely something we will be adding.
|
| -Manual / RAG: We did some RAG magic in the first two
| iterations of our product and found it was really hard to get
| right when the task was not well defined and as the size of the
| codebase grew. We found that our users were watching it do the
| search for the files and basically saying, "Let's see if it
| finds the code file I already know we need." So, we decided to
| go manual so at least the user isn't unpleasantly surprised by
| the results while we determine the right path forward with RAG.
| Or maybe even combine both where the user gives an "entry
| point," and the AI figures out the rest of the files
|
| -I think you're right to be skeptical. In our experience, the
| LLMs are really best at breaking down a task to be just one
| notch more specific. So, I think the output here wouldn't be
| the best for a more high-level task. Our plan to handle this is
| to allow plans to be solved recursively, where you continually
| create a tree of subtasks, and only when you get to a specific
| enough "leaf" do you actually go through with generating code.
|
| -You're right; I think we used the term "technical design doc"
| more generally to steer people's thinking toward software
| design in English rather than code. I like that you mention
| diagrams, though, because we would love to incorporate diagrams
| into our documents as our tool and LLM's capabilities increase!
|
| -This is a very interesting idea! We used a version of this (a
| select set of elements of the AST that we tried to rank in
| importance) in our initial RAG system to give the AI a
| "starting point" for the RAG code search. It worked pretty
| well. My concern would be that the quality of the search might
| then depend on the naming/structure of the code (I'm thinking
| some 1000-line mega functions or something)
|
| Thanks so much for the thoughtful questions!
|
| EDIT: I see Maks also responded and I think we both offer
| similar messaging with slightly different delivery :)
| nico wrote:
| It looks great, and it's exactly the kind of thing I've been
| wanting
|
| Iterating back and forth with GPT is cool at first, then it turns
| into a pain This is a lot better!
|
| From seeing the demo, one thing I'd prefer, is if Glide would
| immediately generate everything, the thoughts, the plan and the
| code, together, then I can get a better overview and tweak where
| necessary
|
| Keep up the great work!
| robmck wrote:
| Thanks so much for the positive feedback!
|
| We've been thinking about ways to make the user experience more
| seamless, and I think what you suggest could be a good option.
| We just need OpenAI to give us more tokens/sec! So you're not
| watching code generate for 10 minutes before being able to do
| anything.
| cipherself wrote:
| I am still playing around with the project but FYI, the parsing
| for the github repo URL at https://glide.agenticlabs.com/ will
| fail if there's a trailing slash in the repo link i.e.
| https://github.com/microsoft/autogen/ won't work but
| https://github.com/microsoft/autogen will.
___________________________________________________________________
(page generated 2024-03-12 23:00 UTC)