Misc updates

Thanks to the Claude Max subscription, I was able to work on several sideprojects simultaneously these last few days.

Scripts orchestrator

The scripts-orchestrator has evolved significantly.

It now supports regular bash commands, is aware of monorepos & produces a live json & html report as it orchestrates your commands. The report has a gantt chart, which can help you see the critical path of your pipeline

Sometimes, a command is too expensive to be anything but sequential so a simple gantt chart can mislead. So the report also displays the time, memory & CPU usage for each command.

The orchestrator also automatically throttles operations which have been configured as parallel based on the actual number of CPUs available and executes them in sequence on low-end machines

1
2
3
4
[INFO] 🧠 memory-guard: hold next command below 15% available RAM, abort below 5% for 15s
[INFO]    ↳ Too strict? Disable it for this run with --no-memory-guard, turn it off in config with `memory_guard: false`, or relax the thresholds via `memory_guard: { minFreeRatio, abortFreeRatio, sustainedMs }` (lower the ratios / raise sustainedMs).
[INFO] 🧮 Max concurrency: 11 (of 12 CPUs) — commands per phase run at most this many at a time

It can also give you a recommendation on what you can do to make your pipeline smarter.

1
2
3
4
5
6
7
8
9
10
11
12
Scripts-Orchestrator — resource-aware phase recommendation (advisory)
   Source: logs/monorepo-quality-report.json
   Aggregated across 6 scope(s) — pooled onto one host
   Fan-out 2 read from the report.
   Budget: 9.60 GB (RAM 24.00 GB × 0.8 ÷ fan-out 2) · core share: 5 cores (12 cores − 2 ÷ 2)

   Estimated makespan
  observed (sequential phases): 6m 53s
  recommended (packed):         6m 46s  (−7.0s)
  theoretical floor (∞ RAM):    2m 5s

Verdict: ❌ No — The current layout is already within ~7.0s of the packed optimum — re-grouping is not worth it.

Code Reviews

Earlier blogs on this topic are here

This article by Addy Osmani was very enjoyable.

My focus recently has been on optimisation, I’d forgotten to remember to learn from AI. Amongst the many insights in the article is one that recommends using AI to identify code that needs attention. I’m adding it into our AI review systems now.

Github Project Visualiser

Earlier blogs on this topic are here

The project visualiser evolved from my need to understand progress from the repo. And to be able to give quantifiable feedback to my team. As the number of graphs grew, it started to feel clunky. Last week, I pivoted to a more user driven UX. After fetching metrics for your repo, you can click on a question you want answered & delve deeper into the rendered graph.

NOTE: If you do try it out, I don’t recommend using this to rate the people in your team. That is NOT what it was meant for.

AI driven project Management

I’d explained a discussion-based approach to break down complicated problems in my previous blog. Used it to break down a large project for myself but I wanted a project plan as the output.

You can use AI to help you break down the tasks, identify the dependencies, risks, people etc and capture it in the appropriate format. But when it comes to doing calculations, scheduling etc, using AI is not a good idea.

Instead, you can use Task Juggler for this step. It supports a simple text based format and can take this textual input & do the calculations. It can even generate several customised project plans for various audiences & help you identify over-allocation, calculate critical paths etc.