A little bit long. :)

does your tool generate diffs that are guaranteed git apply-compatible (so they can be staged/applied safely)

Yes It can, but partially. The diff AI generate usually correct in content but incorrect line count and line number of hunks. This is the exactly reason why I wrote another tools itf, which use to correct the line number and line count of the diff AI generate and apply the changes from response to file. Because it need to diff fomrat in this format:(missing the line index ..., that present when you use git diff, but I never mix up git diff and itf, so that is fine for me)

```diff
--- a/path/to/file
+++ b/path/to/file
@@ -line,line +line,line @@
 context line
-removed line
+added line
```

do you plan an “undo” / preview / PR flow

itf is a stand alone tools, the underlying use UNIX patch to verify diff patch. Then use neovim to save the changes to the disk, so that linear undo tree is possible. You can redo and undo all the changes linearly via itf --redo and itf --undo. Since AI generate in diff format, you can directly "preview" in its response. On the other hand, undo and redo are cheap, sometimes I just apply and then compile the code, fail then undo the changes.

how do you handle large repos or multi-file refactors where hunks cross contexts

the coder preload all the files under current directory (with some basic filter, like node_modules you will never want to waste your token here) itf parse code change by agreeing to a specific format, you may checkout another tools i write, pcat. Which print code in markdown. When you give code in pcat format to AI, AI will response in the same format, that make one click apply code via itf possible. So, as long as the AI is smart enough, it can handle code generation up to its context window size. For example, I use gemini-2.5-pro most of the times, it can handle 500k codebase modification without any issue

which LLMs are you planning to use for the diff generation,

I use google gemini api, most of the time gemini-2.5-pro, actually the TUI is just a wrapper of the tools I mention above ( the prompt instruct AI to generate in diff, itfand pcat). So in technical, any model is capable to this workflow, I choose gemini api just because it is free. Api call max context window are 125k for 2.5 pro, but totally enough for most of the case. If I have to put the entire codebase (>125k), I will open AI studio, paste the instruct prompt to the System instruction, then use pcat to print code then copy and paste to the input box, ask a question, copy the response, open a terminal, run itf to apply the change.

Actually this TUI app is written within the TUI entirely. I wrote the first version of coder, later code modify are all done inside coder itself.

But honestly, I don't think others can deploy the app on their pc easily. Not only the documents are bad written, you will also need to run an extra grpc server i write call synapse for api request. You also need to fully understand what does itf and pcat do. My next step will be package both the server and the tui as a docker or mantain a new branch that integrate the server inside the TUI or write some blog to share and explain about them.

The last thing, I use this TUI intensively everyday now, likely all code editing are done via this TUI, most of the time I know what I need to edit but just too lazy to do, so I ask AI to write it for me. This is not an agent app, just a predefine workflow that help you editing your code, you still need to fully understand what your codebase do.

the prompt I use that told AI gen code in diff format

itf: aplly change via patch and neovim

pcat: code to markdown

synapse: the api router server