Show HN: Aider, a command line GPT coding copilot(github.com)

3 pointsby anotherpaulghace 3 años4 comments

Show HN: Aider, a command line GPT coding copilot

https://github.com/paul-gauthier/aider

4 comments

Like many others, I've been experimenting with using ChatGPT for coding. Along the way, I've been building up some useful tooling. Once I gained access to the GPT-4 api, I was able to make significant improvements in the usability and reliability of my GPT coding tools.

The result is a tool called `aider'. Aider is a command-line tool that allows you to chat with GPT-4 about your code. You can ask GPT for new features, improvements, and bug fixes and aider will directly apply the changes to your source files. Each change is automatically committed to git with a sensible commit message. These frequent, automatic commits provide a comforting safety net. You can confidently collaborate with aider, because it's easy to use git to undo missteps or manage a long series of changes.

You can find out more about aider on GitHub: https://github.com/paul-gauthier/aider

I was initially using GPT to generate code snippets with the OpenAI web chat UI and generic ChatGPT command line tools like `aichat`. But that involved a somewhat klunky workflow where I had to cut and paste code into ChatGPT and then back into my source files.

I streamlined my process while developing a children's chat interface called EasyChat (https://github.com/paul-gauthier/easy-chat). I adopted a "whole file in, whole file out" workflow. I would send GPT-3.5 the entire source code of my project along with a change request and had it reply with the modified version of all the code. This approach was way less tedious than cutting and pasting code between the chat and my source files. I had some simple command line tooling to feed source files to GPT, overwrite them with GPT's modified version and display diffs. This workflow was also quite reliable: GPT-3.5 could consistently produce the code changes I requested without getting lost or confused. But it was slow waiting for GPT to retype all the code, and I quickly hit context window limits asking GPT to read and rewrite every line of the entire codebase.

Access to the GPT-4 API really unlocked a lot of possibilities for improving my tooling. GPT-4 is much better than GPT-3.5 at following directions and replying in a stable, parsable format. Aider still sends GPT-4 entire source files, but asks for replies in a concise `diff` like format. Aider automatically applies these diffs to the source files and git commits them with a GPT generated commit message. Aider lets you easily manage which of your source files are "in the chat session" to control how much code you send to GPT-4 with each request. The ability to reply with diffs makes it much less likely to overflow GPT-4's larger context window.

The resulting workflow is quite effective. You can bounce back and forth between the aider chat and your editor to collaborate on code changes. Aider's code changes aren't always perfect, but wow they are great for blasting through boilerplate or quickly integrating unfamiliar libraries or packages into your code. And if you don't like a code edit, you can quickly discard it by typing `/undo` into the chat.

I now use aider as a force multiplier for a lot of my coding. I even use aider to improve the tool itself.

Let me know if you try aider and find it helpful.

behathace 3 años

Very interesting! Good to know that gpt-4 was a step change here.

I tried with 3.5 since that's all I have access to currently, I asked it to do a few things in a ruby app step by step, touching one file at a time, and it worked well! A configuration option that lets you ask the tool to just make file edits, and let me commit later would be useful.

What happens when the files are too large?

anotherpaulghace 3 años

If you upgrade to the newest version, it has a --no-auto-commit switch.

anotherpaulghace 3 años

Thanks for giving it a try! Glad to hear it was working for you with 3.5.

If you exceed the context window, it will just throw an exception and fail.

I will add a config to disable auto commits. But I find it liberating to use the git history as an undo stack. You can do experiments on a branch and discard it if things don't work out.