Feedback needed: New AI Editor Integration Feature

I'm looking for feedback on a new feature in the latest LINQPad 9 build.

In LINQPad's AI Chat window, you can now click Enable Refactoring and the system prompt will change to tell the model to emit unified diffs when proposing changes to your code.

This results in the model emitting diffs, which LINQPad detects, enabling automatic source control-style diffs to appear in the editor, with deletions & insertions in red and green and Accept / Reject buttons. This makes it much easier to integrate changes.

LINQPad also creates automatic checkpoints, so you can safely hit Accept All and then edit the updated code, while being able to later revert all changes if it turns out the model was out of its depth or on acid.

The diffing engine is a bespoke project comprising thousands of lines of code and has been tested with most major models including GPT 5 Chat, GPT 5 Reasoning, GPT 4.1 and Sonnet 4.

Comments

  • Hi,

    In previewing this I hit a "'temperature' does not support 0" error (see screenshot). I found that changing the model from "gpt 5 chat" to "gpt 5 reasoning" (with think faster checked) gets around the issue.

  • Duplicate accept / reject buttons on diff item.

    It looks like there are multiple accept / reject buttons on each diff item, where I assume there should be one?

  • Restore checkpoint

    Button tooltips

    For restore checkpoint (but also all other controls like 'think deeper / faster' in the chat pane) it would be great to have a brief tooltip description. For restore checkpoint specifically, I'm not immediately clear on what I'll be restoring to (ie just this diff item or all of them). I appreciate the ellipsis, but a tooltip feels more reassuring.

    Restore action

    It's great to be able to roll back. My ideal would be to have a panel that displayed all of the current change sets or checkpoints and then as I select each one the diff would be displayed again. ie I'd like more reassurance that I know what I'm changing.

  • Incorrect insertion point

    One of my test diffs seems to insert the new code in the wrong place - above void Main().

    Here's the diff items code:

    *** Begin Patch
    *** Update File: LINQPadScript.cs
    @@
     void Main()
     {
    @@
        foreach (var animal in animals)
        {
            animal.Dump();
            var t = animal.GetType().Dump();
            t.GetInheritanceHierarchy().Dump();
            // 'is' can work for subtypes
            (animal is Bird).Dump($"{animal.Name} is a type of Bird");
            t.IsSubclassOf(typeof(Bird)).Dump($"{t.Name} IsSubClass of {typeof(Bird).Name}");
        }
    +
    +   // Alternative naming example: more generic class names
    +   var creatures = new List<Organism>()
    +   {
    +       new Raptor() { Label = "Rita Raptor", Wingspan = 95, FlightRange = 180 },
    +       new Canine() { Label = "Carl Canine", Wariness = 30 }
    +   }.Dump("Creatures");
    +
    +   foreach (var creature in creatures)
    +   {
    +       creature.Dump();
    +       var ct = creature.GetType().Dump();
    +       ct.GetInheritanceHierarchy().Dump();
    +       (creature is Avian).Dump($"{creature.Label} is a type of Avian");
    +       ct.IsSubclassOf(typeof(Avian)).Dump($"{ct.Name} IsSubClass of {typeof(Avian).Name}");
    +   }
     }
    *** End Patch
    
  • @JohnGoldsmith - the tooltips on the Accept/Reject buttons explains the difference between the buttons. I will add tooltips to Think Deeper / Think Faster as you suggested. Thanks for the bug report in the differ - this should be fixed in the next build in a week or so.

    Regarding the UI for the checkpoints, it's indeed not ideal right now and will be reworked. It will also become less important as a consequence of another change that I'm planning.

    That is, the diffing strategy will change from pessimistic to optimistic, i.e., the workflow will assume that want to at least test - if not accept - the changes. So instead of clicking Preview and then seeing proposed changes, you will click Apply and see actual changes.

    The diff tags will still be there, but the buttons will change from Accept/Reject into Accept/Undo. The benefit is that you can immediately press F5 to test the updated version, and if you don't like it, hit Undo or Undo All. Right now, to test the changes, you must first Accept All, and then if you don't like it, rely on the rollback feature.

  • Thanks very much for the insight. The optimistic approach sounds good and more in line with VS Code, which I really like. Looking forward to the next updates.

  • Hi, Just trying out 9.2.12 and have some feedback. (Please hold up a hand if this isn't what you're after at this stage)

    Accept buttons - it's only trying these out again that I realised there's a difference between the two. I found that there's only a tooltip on the ">" arrow buttons, and not the non-arrow ones. If there were a setting I think I would default to just moving to next automatically.

    Enable refactoring - Not sure if this moved since the last build? Possibly not, but I found I missed this a couple of times and then realised I had to click it at the beginning. Would an AI toolbar at the top (that doesn't scroll out of view) work for this kind of session wide button? Maybe including a button for Ctrl+P as well?

    Compact UI - I know you've talked about vertical space elsewhere, but on the non-refactoring responses my initial reaction is that I find it tricky to read. I think this is somewhere I'd like more vertical space but I was also wondering if adding a bullet point for each item (see red arrow) would help?

    Anyway, thank you for the update.

  • I'm not sure about removing the option to accept/reject without moving to the next edit. Sometimes you want to accept but then make some changes to what it did.

    The Enable Refactoring button is temporary. Once this feature is promoted out of the experimental phase, it will become a checkbox that will be checked by default for prompts that use editor text.

    Turning the links into bullets would consume a lot of vertical space, and this would be incurred with every code-type model response message. Are you sure this is what you want?

  • Accept / Reject "Sometimes you want to accept but then make some changes to what it did." Yes, I agree with you - reflecting on that I would modify the default to be 'not to step forward' as I can scroll when I'm ready + there's the arrows "< >" at the top. My preference would still be one button for accept and one for reject.

    Enable refector checkbox - got you. Thanks.

    Bullets - sorry, I meant inline. Like this:

    These are all quite minor personal preferences and I can certainly live with this as it is.

  • Just trying the the Enable Refactoring toggle in 9.2.16 - is this meant to work if you change the toggle state part way through a chat session?

    I started off creating some code with the Enable Refactoring set to off and inserted at the cursor. I then turned Enable Refactoring on and asked for a change in the code and only got the results in the AI window. I was expecting the diff'd code to be added to the editor. Have I got that right?

  • Also in 9.2.16, do I have to have accepted / rejected all before carrying out a subsequent change? I think VS Code supports this.

    For example I'm creating a LINQPad.Controls based form and trying to fix an error in my code. Gpt suggests using 'Placeholder' and shows the diff. If I say to it: no, there's no such control it will offer an new diff but I guess at that stage it's out of sync with the previous diff that hasn't been fully applied.

    I'm fully ok with 'too complex' or 'not yet' but just flagging that this is very convenient in VS Code.

  • If you toggle the refactoring checkbox later in the session, it will update the system prompt, so diffs should be produced from that point on. LINQPad sends whatever you see to the LLM, so if the instruction is to emit diffs, that's what should appear.

    You can process new diffs without accepting/rejecting previous ones, as long as it doesn't generate conflicts.

  • Oh ok, thanks. I guess this is different from VS Code where the green code immediately becomes the 'current' version and you can then undo (reject) that to go back (to the red). This means that following updates get diff'd with the current code. I'm not saying this has to be a mirror of VS Code, but I suppose it's what I've got used to.

    For the error messagebox I think I'm not clear on what the result of "Do you want to ask the model for complete code?" will be if I click yes. Will this replace the entire script? My ideal at this stage would be that, if there's a sync issue then I want a warning and an option to go back, sort out the accept/rejects and then have another go at the apply.

  • I guess this is different from VS Code where the green code immediately becomes the 'current' version and you can then undo (reject) that to go back (to the red).

    This is exactly how LINQPad works. The only proviso is that it will currently ignore diffs that overlap with existing ones. I could make this work - do you think it's important? It's tricky because it requires merging the diffs in a way that displays correctly, while ensuring that an Undo operation still gets you back to the previous diffs. It may need to merge two or more diffs into one, or split one into two. I could enable it for just the simple cases such as inserting into an insertion. It's the edge-cases that take time to code and test.

    Note that the errors you were seeing might have been for a different reason. A message with that many failures is unusual.

    For the error messagebox I think I'm not clear on what the result of "Do you want to ask the model for complete code?" will be if I click yes

    It does exactly that - it asks the model for the complete code which you will then see in the Chat window, but doesn't apply anything unless you then use one of the links provided (replace editor code, insert into new script, etc). The most common reason for a diff failing is not a sync issue - it's that the LLM generated a bad diff. You can use any workflow you like in the chat window to deal with this. For instance, you can type "The diff failed to merge - can you have another go?" and then apply the new diff that the model generates. Or you can click "Get second opinion" and see whether another model can generate a diff that applies correctly. GPT 5 reasoning or Sonnet Reasoning will nearly always get it right. From my testing, bad diffs were quite rare - maybe one in twenty.

    LINQPad's new inline AI feature uses an agent, so it has the ability to go back to the model automatically if a diff fails to apply. I have not enabled this feature yet though as there are some more valuable agentic workflows that I'm prioritizing.

  • Thanks very much for this.

    For the overlapping diffs - 'do you think it's important?' I guess it's my expectation from VS Code in terms of, if an existing diff block overlaps then I'm happy (and would like) the new amend to take precedence. In my mind, if I've not accepted or rejected then I'm still playing with options. So to be able to say, not like that, like this without thinking would be useful. I'll leave the work/benefit decision to you of course. Alternatively if I know about the no overlaps rule, it's not that much more effort to make sure I accept or reject first.

    Move 'using' directives into Script Properties - For that previous example with multiple MatchNotFounds, I just wondered whether adding code that includes new 'usings' throws out the line count? I think I've managed to repro with the attached saved prompt if that's useful.

    Do you want to ask the model - I think I didn't click yes before because I thought that the script would get completely replaced (and immediately on clicking yes). Having plucked up the courage to click yes, I see that it just adds another prompt. I wonder if the message could say something like "Add new prompt to request complete code with suggestions, corrections & diffs integrated?" Not a big deal of course - I'll learn :)