DIY Agentic Workflows, Scheduled Claude Coding Agents

A friend, Martin, asked me to write about how I use agents to do work. My work on agents involves development of phpscript and task-ui. One is a programming language, and the other is a combination of a terminal manager, CI/CD and a harness around scripts and prompts.

This is my agentic prompt, created for the purposes of this article:

I want you to pick up maintenance work for this project.

• ensure you work on the next step of the requested implementation, or testing
• review tests and implementation to not duplicate coverage and overtest
• update dependencies with go get ./… regularly, commit and push chore commits
• randomly choose optimisations on how the request is implemented, argue better/worse
• you can change architectural decisions on how the fork is implemented, if you want

The main intent of the fork is @README.phpx.md in the repository. Implement the next step to the fork, work until you finish one more. Work may be interrupted and resumed so start with inspecting git state and git history and updating the fork to absorb latest phpscript changes. Commit and push to main. This is an unattended workflow, I’m giving you a task to run periodically and have scheduling outside your process. Questions should be answered within technical means as:

1. is this in scope of the requested fork features? no -> ignore it
2. does this work like php does? no -> implement fork behaviour

If no implementation is left over, create a list for review and verification, manage it via ACCEPTANCE.md. Extend the list with new discoveries. Update changelog.

The idea is very simple, but also very complex in execution, and hopefully self-healing as better models arrive. I can also increase the difficulty level, say words like collect coverage, memory profiles, benchmarks, diagnose bottlenecks and fix observed bugs or issues, verify against php.

It’s gonna ramble around. I can argue I don’t have any criteria of acceptance, but I did hint the fork itself that it should extend and provide tests and aim for compatibility. The question becomes eventually, how do you extend the amount of work you need to do.

Today I ran it. At midnight, it runs again. At some point, maybe the list of tests gets auto-extended. Maybe the repository gets new features if somebody files a GitHub issue. Maybe the tests measure actual coverage, can run real projects. Maybe I need to maintain them in some git repository.

Most development is just me checking over the same concerns. Especially at the stage where a lot of code is authored by LLM, I take immense steps to try and correct those outputs with deterministic and with fuzzy rules. This is not for the faint of heart, a regular expression will never be precise enough and LLM language bothers me to the point I prefer workflows where I do a little bit of overview, rather than try to digest the clanker tone in it’s replies.

What the abstraction does not add is detail. The prompt could be extended and refined, and some new tool discoveries have come out of the refinement process, but as I am currently looking at it:

• Use Claude to create tools to cover your engineering process, it makes a terrific ERD
• If you can’t make a terrific ERD with Claude, then it most definitely has to be a skills issue
• an ERD is an essential process of a data driven application, most people used to slop with ORM
• could pretty please the abstraction of an ORM with migrations just die? write SQL, agent!

I’ll say my “orchestration” vocabulary is becoming more of a yellow pages. The tools are becoming a problem and I’m trying to collapse several of them into a single linter tool. Now prose evaluation has got support in my splint tool and tries to eject the last detectable bits of LLM documentation slop. My behavior hints both of adding abstractions (in the case of phpscript), and removing abstractions (one linter tool for all project, rather than a fat toolbox).

I’ve come to the realization a long time ago, that writing code likely isn’t necessary anymore. I was always special in the sense like those vi users are special ; if you made your code writing environment an editor you couldn’t escape out of, then TaskUI tries to bring a little bit of a file manager / terminal manager experience. And when you have that, your developer environment can be local or remote. I like the browser experience of a terminal.

Things that take my thoughts currently are:

An argument could be made that a nearly real-time voice assistant like Alexa for coding would make the ideal solution for developers that say are worried about their wrists while typing. I get to the range of 40-60kb of English which is a lot of key-presses. A voice assistant gets rid of physical wrist strain. I’ve had some wrist injuries and could appreciate a real-time-ish voice interface.

and

Once you don’t have to type, you really don’t have to sit either, so you can correct your posture. I often find myself in the position of trying to work out a long-running Claude prompt, and it’s a trap. It’s better I find out what works or write down what works, and try to get those concerns out of my mind. I use claudes working time as my thinking time for validation or the next thing that’s needed or enabled now.

This still leaves a big river of guidance, where software creation is serviced with workflow, and workflow may also include these validation steps. I think there’s going to be a lot of need to do wiki as a workflow to simplify the analogy. Someone is left to gate-keep the truth from the agents, and while they are generally sand-boxed well, I do see some judgment issues and this “container escape” behavior.

As for maintenance, for some people it was enough to enable dependabot. Others could use TaskUI, enable the openrouter or Claude integration and state a similar workflow.

Just for reference, my first workflow was “fetch weather data for my location, tell me if i need to water today”. Since the API doesn’t have history, it read TaskUI run history to get the old data and judgments. I mean, the only thing better it could do is trigger an automated watering system.

I love automation, the question is is Claude necessary, or can it be in the loop just long enough to optimize itself out of the application with deterministic workflows that it writes. I’ve ran the workflow a few times already, and phpx is churning. Maybe I’ll bump it up to hourly.