typedai

implemented in the code as to not duplicate work. Look at the existing style of the code when producing the requirements. Then there is a compile/lint/test loops which feeds back in the error messages, and in the case of compile errors the diff since the last compiling commit. Aider added some similar functionality recently. Then finally there's a review step which asks: Do the changes in the diff satisfy the requirements, and explain why? Are there any redundant changes in the diff? Was any code removed in the changes which should not have been? Review the style of the code changes in the diff carefully against the original code. Do the changes follow all the style conventions of the original code? This helps catch issues that Aider inadvertently introduced, or missed. I have some ideas around implementing workflows that mimic what we do. For example if you have a tricky bug, add a .only to the relevant describe/it tests (or create tests if they dont exist) add lots of logging and assertions to pinpoint the fix required, then undo the .only and extra logging. Thats whats going to enable higher overall success rates, which you can see the progress in the SWE-bench lite leaderboard as simple RAG implementations had up to ~4% success rate with Opus, while the agentic solutions are reaching 43% pass rate on the full suite.

into coding agent and an autonomous agent with LLM-independent function calling with auto-generated function schemas. And as testing via the CLI became unwieldy soon grew database persistence, tracing, a Web UI and human-in-the-loop functionality. One of the more interesting additions is the new autonomous agent which generates Python code that can call the available functions. Using the pyodide library the tool objects are proxied into the Python scope and executed in a WebAssembly sandbox. As its able to perform multiple calls and validation logic in a single control loop, it can reduce the cost and latency, getting the most out of the frontier LLMs calls with better reasoning. Benchmark runners for the autonomous agent and coding benchmarks are in the works to get some numbers on the capabilities so far. I'm looking forward to getting back to implementing all the ideas around improving the code and autonomous agents from a metacognitive perspective after spending time on docs, refactorings and tidying up recently. Check it out at https://github.com/trafficguard/nous

t, but its up at https://github.com/trafficguard/nous I never liked the Langchain API when I looked at the examples so I built it from scratch. It has an autonomous agent with a custom XML-based function calling, memory and call history. The software engineer agentic workflow I initially dog-fooded with a prompt like "Complete Jira XYZ-123". So it gets the Jira description, finds the appropriate terraform project in GitLab, clones, edits (delegating to Aider), creates a MR and messages on Slack. It also has a UI for running agents, human-in-the-loop interactions etc.