Fun project with a nice compact code base. Agreed that ad-hoc scripting agents can be very powerful.
Aider has had support for scripting [0] in python or via the command line for a long time.
I made a screencast [1] recently that included ad-hoc bash scripting aider as part of the effort to add support for 130 new programming languages. It may give a flavor for how powerful this approach can be.
I was thinking about doing something like this. I write a lot of boilerplate about "ok we need to discuss before you implement, ask clarifying questions" so it doesn't go rushing ahead.
yea this boilerplate is super simple and effective. It's essentially mimicing how I use claude code and cursor, but with low level control.
A very cool thing I'm working on in this space is having an llm code with the codesys sdk, then run the code.
So imagine cursor coding a codesys file instead of doing the task directly so that it instead scripts claude code to do a sequence of actions and allows cursor/the user to simply analyze the results.
this also enables parralel claude code sessions which is super cool!
same but the interaction between me and Claude is too dynamic, and my planning framework is more robust than single files. If anything I could speed my workflow up but writing a bash script that calls gemini for my plans - i feed entire codebases or parts of a large codebase (using Prompt Tower) to gemini for the planning - Claude Code isnt as reliable. But even that is iterative with Gemini.
also MCP bloat - I prefer my Claude Code agent raw. It has it's own capable tools and plans development with task lists now - works really well with a greater meta-level tasking and context orchestration.
This is a cool little project, and honestly, pushing out simple tools early always gets my gears turning - now Im sitting here thinking about what tiny scripts in my setup could use a little love.
> But by having 155 lines of source code and through continuous use of the sdk, I haven't experienced any problems
The number of lines of code being 155 lines is not an excuse to have zero tests, especially in an SDK and it doesn't mean it works.
It only means you know it 'works' on your machine and it may not work on someone else's or in another scenario.
> Actually this comment just gave me the idea of creating a file of codesys doing just this in its own repo!
Well, you've just proven my point.
The tests should be written first before you write the actual code and to just write them after the fact defeats the entire purpose of knowing what to test for and then assuming that it 'works'.
Fun project with a nice compact code base. Agreed that ad-hoc scripting agents can be very powerful.
Aider has had support for scripting [0] in python or via the command line for a long time.
I made a screencast [1] recently that included ad-hoc bash scripting aider as part of the effort to add support for 130 new programming languages. It may give a flavor for how powerful this approach can be.
[0] https://aider.chat/docs/scripting.html
[1] https://aider.chat/docs/recordings/tree-sitter-language-pack...
Paul!!!
I first made a scripting tool of aider that I didn't open source: (https://cloudcoding.ai)
Scripting with aider gives lower level control but this is also its shortcoming to why I prefer scripting Claude code.
Claude code is like a better architect mode and people want higher and higher levels of abstraction away from the coding and more towards the vibing.
Adding Swift (and 129 others) in March was a big deal, thank you.
Is "Code Claude Code" a play on "Bob Loblaw"?
https://arresteddevelopment.fandom.com/wiki/Bob_Loblaw
I’d guess Run Forest Run.
Or for the younger generation Go Diego Go
Ha! I prefer this one
I was on Go Dogs Go!
I never heard of Bob Loblaw, so no.
It's more a play on the phrase 'Code the thing that Codes the thing'
If anyone else was curious to see the source, it’s hard to find due to the name collision on Google.
Here it is - https://github.com/RVCA212/codesys
I have been creating a change document as Claude.md and asking Claude Code to implement it. It was been working very well. Hire is this different?
I was thinking about doing something like this. I write a lot of boilerplate about "ok we need to discuss before you implement, ask clarifying questions" so it doesn't go rushing ahead.
yea this boilerplate is super simple and effective. It's essentially mimicing how I use claude code and cursor, but with low level control.
A very cool thing I'm working on in this space is having an llm code with the codesys sdk, then run the code.
So imagine cursor coding a codesys file instead of doing the task directly so that it instead scripts claude code to do a sequence of actions and allows cursor/the user to simply analyze the results.
this also enables parralel claude code sessions which is super cool!
same but the interaction between me and Claude is too dynamic, and my planning framework is more robust than single files. If anything I could speed my workflow up but writing a bash script that calls gemini for my plans - i feed entire codebases or parts of a large codebase (using Prompt Tower) to gemini for the planning - Claude Code isnt as reliable. But even that is iterative with Gemini.
I haven’t used Gemini as much but it doesn’t seem as smart as Claude, especially at exploring the codebase.
I’ve never heard of prompt tower either, so definitely something to look into!
A little tangential but, I can’t get any LLMs to write a codepen for a parallel parking animation.
Building a product brewed in the alchemy of current-day LLMs is how we end up with new langchains.
Very true!
This isn’t the product I’m building which is why i opened sourced it, but it allows for my product to be made
I’m sure Anthropic will release this exact sdk in a week or two
Is it the same lines of RooCode task orchestrator [1] or claude-task-master[2] ?
[1] https://www.reddit.com/r/ChatGPTCoding/comments/1k8641f/roo_...
[2] https://github.com/eyaltoledano/claude-task-master
Seems like this task orchestration is the next must-have thing for every agentic AI solution and it makes perfect sense.
also MCP bloat - I prefer my Claude Code agent raw. It has it's own capable tools and plans development with task lists now - works really well with a greater meta-level tasking and context orchestration.
same idea, yes
this seems simpler and more straight forward though
This is a cool little project, and honestly, pushing out simple tools early always gets my gears turning - now Im sitting here thinking about what tiny scripts in my setup could use a little love.
[flagged]
But yes, the LLM could go wrong because it's simply a wrapper around scripting claude code in non-interactive mode.
the immediate use cases are more towards automatically creating tests and documentation, as well as other non-destructive actions
such as read-only mode: https://github.com/RVCA212/codesys/blob/main/examples/exampl...
The source code is 155 lines.
You can vibe through asking cursor if it has any bugs and let me know or create a PR!
But by having 155 lines of source code and through continuous use of the sdk, I haven't experienced any problems
Actually this comment just gave me the idea of creating a file of codesys doing just this in its own repo!
> But by having 155 lines of source code and through continuous use of the sdk, I haven't experienced any problems
The number of lines of code being 155 lines is not an excuse to have zero tests, especially in an SDK and it doesn't mean it works.
It only means you know it 'works' on your machine and it may not work on someone else's or in another scenario.
> Actually this comment just gave me the idea of creating a file of codesys doing just this in its own repo!
Well, you've just proven my point.
The tests should be written first before you write the actual code and to just write them after the fact defeats the entire purpose of knowing what to test for and then assuming that it 'works'.