leaping

have been using it ourselves for development over the past few weeks. Using this pytest plugin, you’re able to reason at a much higher level than conventional debuggers and can ask questions like: - Why did function x get hit? - Why was variable y set to this value? - What changes can I make to this code to make this test pass? Here’s a brief demo of this in action: https://www.loom.com/share/94ebe34097a343c39876d7109f2a1428 To achieve this, we first instrument the test using sys.settrace (or, on versions of python >3.12, the far better sys.monitoring!) to keep a history of all the functions that were called, along with the calling line numbers. We then re-run the test and use AST parsing to find all the variable assignments and keep track of those changes over time. We also use AST parsing to obtain the source code for these functions. We then neatly format and pass all this context to GPT. We’d love it if you checked the pytest plugin out and we welcome all feedback :) . If you want to chat bugs, our emails are also always open - kanav@leaping.io

variant of omniscient debugging. We think it was a nifty idea, but we couldn’t get past the performance overhead/security concerns. Approaching the problem differently, we thought - could we not just grab a stack trace and sort of “figure it out” from there? Whether that’s possible in the general case is up for debate – but we think that eventually, yes. The argument goes as follows: developers can solve bugs not because they are particularly clever or experienced (though it helps), but rather because they are willing to spend enough time coming up with increasingly informed hypotheses (“was the variable set incorrectly inside of this function?”) that they can test out in tight feedback loops (“let me print out the variable before and after the function call”). We wondered: with the proper context and guidance, why couldn’t an LLM do the same? Over the last few weeks, we’ve been working on an approach that emulates the failing test approach to debugging, where you first reproduce the error in a failing test, then fix the source code, and finally run the test again to make sure it passes. Concretely, we take a stack trace, and start by simply re-running the function that failed. We then report the result back to the LLM, add relevant source code to the context window (with Tree-sitter and LSP), and prompt the AI for a code change that will get us closer to reproducing the bug. We apply those changes, re-run the script, and keep looping until we get the same bug as the original stack trace. Then the LLM formulates a root cause, generates a fix, we run the code again - and if the bug goes away, we call it a day. We’re also looking into letting the LLM interact with a pdb shell, as well as implementing RAG for better context fetching. One thing that excites us about generating a functioning test case with a step-by-step explanation for the fix is that results are somewhat grounded in reality, making hallucinations/confabulations less likely. Here’s a 50 second demo of how this approach fares on a (perhaps contrived) error: https://www.loom.com/share/a54c981536a54d3c9c269d8356ea0d51?sid=aeafd2d1-9b86-43ad… We’re working on releasing a self-hosted Python version in the next few weeks on our GitHub repo: https://github.com/leapingio/leaping (right now it’s just the demo source code). This is just the first step towards a larger goal, so we’d love to hear any and all feedback/questions, or feel free to shoot me an email at adrien@leaping.io!