amterp

Why not? This seems to greatly help with interpretability, which should help with alignment, no?

I had very similar thoughts to this piece at the beginning of the year but I took a bit of a different approach with the tool I built, Kan [0]. Rather than markdown files in directories like OP went with, I went for plain json files stored in a `.kan` directory, with the primary interface being not the files themselves but the CLI and an embedded frontend which could be run with `kan serve`. Agents work really well with the CLI and the frontend provides a nice snappy UI for humans to interact with and manage their tasks in a kanban format, all offline and acting entirely on files in the repo's VCS (somewhat like Typemill).

Overall it's been a great workflow and it works great with agents, it's the main way I manage tasks with agents, I agree the 'tickets in the repo' approach works really well.

[0] https://github.com/amterp/kan

Shameless plug but I hit these exact same kinds of walls and I tried out alternatives like agent-deck or herdr, but ultimately didn't enjoy the TUI approach that herdr/Tmux solutions offer, so I built Muster [0] and I'm quite proud of it -- it's turning out really well and is my daily driver at home and at work. It uses libghostty so I get the same sort of Ghostty-feel as Ghostty by itself provides. It supports SSH / remote machines well too and allows agents from different harnesses to message and work together thru 'muster daemons'.

[0] https://github.com/amterp/muster

Continuing to work on Kan, an offline Kanban board which operates on plain text files in your repo, so you can just commit the entire board into Git!

I'm finding it really good for agentic work these days as, using the kan CLI, agents do really well with it for tracking work and leveraging the board. I'm using it for all my projects these days.

https://github.com/amterp/kan

Big fan of gron[0] and zoxide[1]. Gron for flattening and viewing JSON, and zoxide (z) for fuzzily jumping around on my system or on remote systems with z installed.

Also been using Rad [2] (disclaimer: am author) to replace my suite of Bash scripts and write new ones, quite happy with one atm which sets reminders e.g. 'remind 2h check the CI build' which will give me an OS reminder in two hours, I use it a ton at work.

[0] https://github.com/tomnomnom/gron [1] https://github.com/ajeetdsouza/zoxide [2] https://github.com/amterp/rad

I'm working on two main projects at the moment.

One is Rad [0], a programming language tailored for writing CLI scripts and tools (mainly an alternative to Bash), taking a declarative approach to things like script arguments. Latest push has been largely on static type analysis, since making that really good is the sort of thing that helps both people and AI agents write good Rad.

Second project is Kan [2], a Kanban board which operates on text files on your machine, and is designed to be Git friendly so you can check it into your repo.

[1]

https://github.com/amterp/rad https://amterp.dev/rad

[2]

https://github.com/amterp/kan https://amterp.dev/kan

Happy for the devs, they deserve the presumably massive payout for the amount of value they’ve brought to the Python community.

I am continuing to work on Kan [0], a dev-focused kanban board that works via plain text files in your repository. I am finding it really useful for solo projects, giving a really simple way to get per-project Kanban boards that I can sync via Git. Since it's local only, it's really snappy, and given the dev-focus, it can offer some pretty nice workflows with local hooks, customization, etc.

The other project I am continuing to work on is Rad [1], a programming language tailor made for writing CLI scripts. It's not for enterprise software, it specializes specifically in CLI, offering all the essentials built-in, such as a declarative approach to arguments and generated help (as opposed to Bash where you have to roll your own arg parsing and help strings each time).

[0] https://github.com/amterp/kan

[1] https://github.com/amterp/rad

I've been working on Kan [0] which is a CLI written in Go that can serve a Kanban board ( `kan serve` ). Serving the Kanban board means opening up a localhost page for a Kanban board which acts on files stored locally on your machine, in your repo. Just plaintext JSON & TOML files. The Kanban board is written in TypeScript. You commit Kanban board changes like any other files.

I use it for all my personal projects. Any new project where I will have todo lists, I'll run `kan init` and `kan serve`, and begin tracking tasks. Because it's a CLI, you can interact with the board thru the CLI with commands like `kan add` and `kan edit`, so I've even included a SKILL markdown file in the repo which I use to let Claude read and interact with my boards. You can also navigate all your boards from a single `kan serve`, so it's convenient and snappy cross-project too.

[0] https://github.com/amterp/kan

Really appreciated this perspective. Much more tempered and less hype than a lot of other articles I see.

I thought the "dont let agents finishing interrupt you" workflow was an interesting point. I've set up chime hooks to basically do the opposite, and this gives me pause to wonder if I'm underestimating the cost of context switching. I'll give it a go.

Yep each one is a fresh session. Are you asking because you'd like a persistent one?

This is exactly the frustration that lead me to write Rad [0] (the README leads with an example). I've been working on it for over a year and the goal is basically to offer a programming language specifically for writing CLIs. It aims for declarative args (no Bash ops parsing each time), automatic --help generation, friendly (Python-like) syntax, and it's perfect for dev build scripts. I'll typically have something like this:

    #!/usr/bin/env rad
    ---
    Dev automation script.
    ---

    args:
        build   b bool    # Build the project
        test    t bool    # Run tests
        lint    l bool    # Run linter
        run     r bool    # Start dev server
        release R bool    # Release mode
        filter  f str?    # Test filter pattern

        filter requires test

    if build:
        mode = release ? "--release" : ""
        print("Building ({release ? 'release' : 'debug'})...")
        $`cargo build {mode}`

    if lint:
        print("Linting...")
        $`cargo clippy -- -D warnings`

    if test:
        f = filter ? "-- {filter}" : ""
        print("Running tests{filter ? ' (filter: {filter})' : ''}...")
        $`cargo test {f}`

    if run:
        bin = release ? "target/release/server" : "target/debug/server"
        $`./{bin}`


    Usage: ./dev -b (build), ./dev -blt -f "test_auth" (build, lint, test auth), ./dev -r (just run).

Actively being developed!

[0] https://github.com/amterp/rad

I am working on Rad [0], a programming language built specifically for CLI scripts, so you don't need to write Bash, and it offers CLI-tailored features which make it a better choice than Python.

Lately I've mainly been working on stability and bug fixes. I've released some big features the past few months so I'm doing a big push on polish, before I again tackle some larger features that I'd like to implement.

If CLI scripts is something you're interested in at all, give it a go! We have docs and a guide [1] for getting started, feedback very welcome :)

[0] https://github.com/amterp/rad [1] https://amterp.github.io/rad/guide/getting-started/

This looks great!

I'm currently using Material for MkDocs but was thinking of switching off it, in part due to the lack of options around having custom highlighting in code blocks (my docs website is for a programming language I am working on). What are Zensical's plans here? Tree sitter highlighting would be perfect in my case.

Love this, lots of great ideas I'll be stealing :)

Folks interested in scripting like this might like this tool I'm working on https://github.com/amterp/rad

Rad is built specifically for writing CLI scripts and is perfect for these sorts of small to medium scripts, takes a declarative approach to script arguments, and has first-class shell command integration. I basically don't write scripts in anything else anymore.

Working hard on Rad, which is aiming to be a Bash-replacement for writing CLI scripts. The goal is to allow users to write maintainable scripts with declarative argument parsing, built-in JSON processing, HTTP requests, and interactive prompts - all in a familiar, readable syntax (Python-like!). Here's an example of the declarative approach to script args:

  args:
      username str           # Required string
      password str?          # Optional string
      token str?             # Optional auth token
      age int                # Required integer
      status str             # Required string
  
      username requires password     // If username is provided, password must also be provided
      token excludes password        // Token and password cannot be used together
      age range [18, 99]             // Inclusive range from 18 to 99
      status enum ["active", "inactive", "pending"]

Rad does all the arg parsing for you (unlike Bash), including validation for those constraints you wrote, and you can get on with writing the rest of your script is a nice, friendly syntax!

Very keen for feedback so if any of that sounds interesting, feel free to give it a go!

https://github.com/amterp/rad

Work continues for me on Rad[0]. It's a programming language designed specifically for CLI scripts. I was sick of writing Bash scripts and thought we could do much, much better, so that's the goal with this project. Been working on it for a bit over a year now, and I'm using it every day! Still have many big features in mind, such as commands, I suspect I'm still only at the beginning at this journey!

[0] https://github.com/amterp/rad

Very much agree with the article, this is one of the reasons why I wrote Rad [0], which people here might find interesting. The idea is you write CLI scripts with a declarative approach to script arguments, including all the constraints on them, including relational ones. So you don't write your own CLI validation - you declare the shape that args should take, let Rad check user input for you, and you can focus your script on the interesting stuff. For example

  args:
      username str           # Required string
      password str?          # Optional string
      token str?             # Optional auth token
      age int                # Required integer
      status str             # Required string
  
      username requires password     // If username is provided, password must also be provided
      token excludes password        // Token and password cannot be used together
      age range [18, 99]             // Inclusive range from 18 to 99
      status enum ["active", "inactive", "pending"]

Rad will handle all the validation for you, you can just write the rest of your script assuming the constraints you declared are met.

[0]: https://github.com/amterp/rad

Modern cmd line scripting is an interesting area and I like seeing people's different approaches to improving it. Personally, I want to get as far away from writing control flow, loops, etc in Bash as I can. I'm working on https://github.com/amterp/rad which is a CLI scripting language that takes a more Python-like approach, which people here might find interesting, though it serves slightly different cases than Modernish.

Been working on https://github.com/amterp/rad for almost a year now. It's a programming language designed for writing good CLI scripts, so it's aiming to replace Bash but is much more Python-like, and offers unique syntax and a bunch of in-built support for scripting.

Please check it out if it sounds at all interesting! Keen for feedback :) I've written some docs, including a "getting started" guide, linked in the GitHub page.

Thanks! :) Yeah in my experience they're okay at Bash but I'm never happy with the scripts it makes, I feel like the ceiling is pretty low on how good Bash scripts can get without a disproportionate amount of effort.

I'm taking a lot of inspiration from Python in the syntax and I'm actually worried it will trip up any LLM I train on my language since I think it will risk probabilistically just reverting to Python mid-answer Time will tell

I've been working on a programming language for about a year which aims to replace Bash for scripting but is far closer to Python. It's something I hope to see used by many other people in the future, but a very common objection I hear from people I pitch it to is "yeah but an LLM could just generate me a Python script to do this, sure it might be uglier, twice as long, and not work quite as well, but it saved me from learning a new language and is probably fine", to which I have lots of counters on why that's a flawed argument, but it still demonstrates what I think is an increase in people's skepticism towards new languages which will contribute to the stagnation the author is talking about. If you're writing a new language, it's demotivating to see people's receptiveness to something new diminish.

I don't blame anyone in the picture, I don't disagree that time saved with LLMs can be well worth it, but it still is a topic I think we in the PL community need to wrestle more with.

I'm working on a programming language aiming to replace Bash. It specifically targets CLI scripts where Python or Rust are overkill, but it contains a bunch of constructs that make it particularly well suited for CLI scripts, including arg parsing, table formatting, HTTP querying, Bash command invocation, etc.

Keen to hear people's thoughts and feedback! GitHub here: https://github.com/amterp/rad

The docs site also contains a guide for getting started, including some of the unique features: https://amterp.github.io/rad/guide/getting-started/