I think this is where the future of coding is. It is still useful to be a coder, the more experienced the better. But you will not write or edit a lot of lines anymore. You will organize the codebase in a way AI can handle it, make architectural decisions and organize the workflow around AI doing the actual coding.

The way I currently do this is that I wrote a small python file that I can start with

    llmcode.py /path/to/repo

Which then offers a simple web interface at localhost:8080 where I can select the files to serialize and describe a task.

It then creates a prompt like this:

    Look at the code files below and do the following:

    {task_description}

    Output all files that you need to change in full again,
    including your changes. In the same format as I provide
    the files below, that means each file starts with
    filename: and ends with :filename
    Under no circumstances output any other text, no additional
    infos, no code formatting chars. Only the code in the
    given format.

    Here are the files:

    somefile.py:
    ...code of somefile.py...
    :somefile.py

    someotherfile.py:
    ...code of someotherfile.py...
    :someotherfile.py

    assets/css/somestyles.css:
    ...code of somestyles.css...
    :assets/css/somestyles.css

    etc

Then llmcode.py sends it to an LLM, parses the output and writes the files back to disk.

I then look at the changes via "git diff".

It's quite fascinating. I often only make minor changes before accepting the "pull request" the llm made. Sometimes I have to make no changes at all.

There are a lot of them. I collected a list of cli tools that does this:

https://prompt.16x.engineer/cli-tools

I also built a GUI tool that does this:

https://prompt.16x.engineer/

Added some benchmarking to show how fast it is:

Here is a benchmark comparing it to [Repomix][1] serializing the Next.js project:

      time yek
      Executed in    5.19 secs    fish           external
         usr time    2.85 secs   54.00 micros    2.85 secs
         sys time    6.31 secs  629.00 micros    6.31 secs



      time repomix
      Executed in   22.24 mins    fish           external
         usr time   21.99 mins    0.18 millis   21.99 mins
         sys time    0.23 mins    1.72 millis    0.23 mins

yek is 230x faster than repomix

[1] https://github.com/jxnl/repomix

i guess I shouldn’t be surprised that many of us have approached this in different ways. it’s neat to see already multiple replies of the sort I’m going to make too, which is to share the approach I’ve been taking, which is to concatenate or to “summarize” the code, with particular attention on dependency resolution.

[chimeracat](https://github.com/scottvr/chimeracat)

It took the shape that it has because it started as a tool to concatenate a library i had been working on into a single ipynb file so that I didn’t need to install the library on the remote colab, thus the dependency graph was born (as was the ascii graph plotter ‘phart’ that it uses) and then as I realized this could be useful to share code with an LLM, started adding the summarization capabilities, and in some sort of meta-recursive-irony, worked with Claude to do so. :-)

I’ve put a collection of ancillary tools I use to aid in the pairing with LLM process up at https://github.com/scottvr/LLMental

Adding my take to the mix, which has been working well for me: https://github.com/ClaireGSB/project-context.

It outputs both a file tree of your repo, a list of the dependancies, and a select list of files you want to include in your prompt for the LLM, in a single xml file. The first time you run it, it generates a .project-context.toml config file in your repo with all your files commented out, and you can just uncomment the ones you want written in full in the context file. I've found this helps when iterating on a specific part of the codebase - while keeping the full filetree give the LLM the broader context; I always ask the LLM to request more files if needed, as it can see the full list.

The files are not sorted by priority in the output though, curious what the impact would be / how much room for manual config to leave (might want to order differently depending on the objective of the prompt).

Has anyone build a linter that optimizes code for an LLM?

The idea would be to make it more token efficient and (lower accidental perplexity), e.g. by renaming variable names, fixing typos and shortening comments.

It should probably run after a normal linter like black.

I have a very simple bash function for this (filecontens), including ignoring files based on gitignore & binary files etc. Piped to clipboard and done.

All these other ways seem unnecessarily complicated...

This has some interesting ideas that I hadn’t seen in the other similar projects, especially around trying to sort files according to importance.

(I’ve been using RepoPrompt for this sort of thing lately.)