Per Møldrup-Dalum

Project Command And Control, or how programming is becoming fun again and solved an actual problem

On my first computer, there was only one thing to do: write a program. If I wanted to do anything with the computer, I had to write a program to do it.

zx-for-loop
Screenshot from Fuse, the Sinclair ZX Spectrum emulator showing a program that prints a table of the first 10 square numbers.

I still vividly remember the first time I managed to draw a circle using sin() and cos(), or when I implemented a subset of LOGO and Turtle Graphics—which, in hindsight, was really a subset of Lisp. I had seen something like it demonstrated on national television, but there was nowhere to find other people’s code, so I wrote it myself on my ZX Spectrum.

Unfortunately, I lost the source code. I never made a hard copy on our Microline 80 dot matrix printer, no artifact survived—not even a tape cassette.

Later, in junior college, graduate, and postgraduate studies, I kept writing programs to support calculations in mathematics, chemistry, and physics – and computer science 🤷‍♂️— as well as various small tools. This was on DOS, Apple, VAX/VMS mainframe, and Unix machines, first using BASIC and Pascal, and later FORTRAN and C.

It wasn’t until my postgraduate studies that I discovered the next level: scripting. This dramatically lowered the barrier from idea to program. No more low-level file or memory handling. But it also introduced a new kind of complexity: package management—finding, installing, and using code written by others. Of course, this existed in C as well, but my experience back then was that most of what you needed came with the compiler, or you wrote it yourself, borrowed it from a colleague, a paper, or an FTP site—and then compiled it and understood how it worked.

After university and earning my MSc, I spent about a decade as a software developer, writing software for others. This primarily was in Tcl, C++, Java, and PHP, but also involved building tools and utilities, mostly in scripting languages—primarily Tcl and Perl. Much of it was headless server software, but also some GUI elements using a proprietary extension of Tk, and later Java Server Pages and PHP.

In the two decades that followed, my work shifted more toward architecture and data analysis—especially how to manage and make large collections of cultural heritage data usable for research and the public. My own programming gradually centered on R after a period working with Apache Hadoop during the heyday of Big Data. Somewhere along the way, the Python explosion in data science happened while I was briefly looking elsewhere—so R remained my main tool.

A small aside: since my graduate days, I’ve been deeply interested in Wolfram Mathematica both as a language and as a way to think about computation. I still am, and it remains an important part of my toolbox. But I digress.

Alas, over the past decade, my programming-fu have atrophied somewhat. So, for a long time, I’ve missed being able to quickly build tools on platforms I enjoy such as macOS or the web. I can still write clever awk or Bash scripts, and use Python, Perl, Tcl, Lisp, or the Wolfram Language when needed—but it’s not the same as creating a proper user-facing tool.

Then, in November 2022, this changed and now I believe we’ve passed a pivotal point in software development.

LLMs have rekindled both my joy and my ability to use the computer the way I used to—to make it do what I want, rather than relying on companies or open-source projects to build something that almost, but never quite, solves my problem.

That said, LLMs come with their own issues—some of them ethical. I’m not blind to these concerns, nor do I accept them uncritically. I actively engage in discussions and projects aimed at addressing and mitigating them.

The specific problem at hand

I work on a lot of different projects—many of them orthogonal to each other—spread across a multi-dimensional space of project properties. One colleague once very accurately described it as having ten part-time jobs.

For decades—really, since I moved away from analog, paper-based task, note, and project management—I’ve been searching for the perfect tool to manage all of this. Of course, I haven’t found it. That system doesn’t exist. The domain itself is shaped by constantly shifting forces, some of which actively work against users, as tool creators are pushed to extract more and more value. Cory Doctorow has a name for this: enshittification. It’s real. I’ve experienced it multiple times, and I know it will happen again — right now, I'm mostly worried about the Apple platform becoming enshittified beyond recognition 😟

Well, along the way, I’ve tried countless ready-made solutions: Kinkless (if you know, you know 😁), OmniFocus, Things, Midnight Inbox, Apple Reminders, Notes, and Calendar, OneNote, Outlook Tasks, Evernote, Roam Research, Obsidian, Taskwarrior, Logseq—and a long tail of smaller tools. I've learnt about David Allen's Getting Things Done, Stephen R. Covey's 7 Habits, Kanban boards, Bullet Journals, Scum and Agile methodologies, etc. An interesting and reflective observation is that whenever I get too stressed, I tend to move everything onto paper, which to me is a sign of a deep incompatibility between my mind and IT systems for this…

Anyway, I’ve also built my own systems in Emacs Org-mode, Vimwiki, and even custom command-line tools from scratch.

And yet, none of them have been good enough to let me relax. Either they fail to meet my needs and I must work against them or they demand too much meta work or maintenance. Systems like Emacs Org-mode, for all their power, come with a maintenance burden that becomes overwhelming over time. There’s a great piece on this by Terry Godier (https://indieweb.social/@tg, “The Last Quiet Thing”) that captures the problem well – and yes, my main watch is a Casio W-202: simple, quiet, maintenance-free. I want more quiet things in my life.

Yet again, I digress. The question now is: how could yet another tool possibly be the answer?

A possible solution

Where and how the projects I’m involved in are managed is often outside my control. They might live in a shared folder in Microsoft 365—SharePoint, OneDrive, or Teams—in a Confluence wiki somewhere in the cloud, in another organization’s Microsoft setup, in Overleaf, GitHub, or Slack. And, of course, a lot of coordination still happens via email and instant messaging—across a whole plethora of platforms, which means a lot of important stuff is stored in those platforms and programs.

For most projects, I also maintain a local folder with my own notes and supporting material, and I rely heavily on the Terminal in my daily work. The result is that it often takes far too long to find what I need—and I hate that feeling of lacking control, of loosing time due to insufficient systems. On top of that, this is before even getting to the actual tasks within each project. This latter problem is by design left outside the solution described here. Right now, I manage most of my actual tasks in Taskwarrior, the calendar, and Apple Reminders. I also have shared project task boards, and off course this is also a big mess.

Well, about six weeks ago, I sat down with Codex and built a quick proof of concept in SwiftUI: a small program to help me manage projects, cases, and areas of responsibility. To my surprise, it immediately proved useful. From day one, I’ve used it daily—and it’s clearly given me an edge.

At its core, the system acts as a kind of dispatch center for all my projects, with quick access to wherever they actually live. As an added feature, I can “tap” a project whenever I engage with it. This creates a lightweight log of activity—helping me see not only what I’ve worked on, but also which projects risk being neglected. I think of it as a kind of project command and control (“Command and control - Wikipedia”).

Yesterday morning, I decided to take the proof of concept—and everything I’ve learned from using it—and turn it into a real application. Today, I have a first release, and I genuinely think it will make my days better.

At its heart, it’s simple: a registry of my projects, a text filter with some basic boolean operators, and a state filter. From there, I can drill into each project to access a richer set of metadata that makes sense to me and me alone.

project-list-view
A screenshot of the application's main view that lists all projects.

I also have a visual overview of my projects.

project-visualization
A screenshot of the Overview view of the application, that shows the visualizations of the data.

I've created this to fit my exact needs and have the tooling to improve and bug fix as much as I need. Enshittification will never happen. Data lock-in will never happen. I'm happy.

You can inspect, download and build the vibe coded project at my GitHub account project-cc. The source code is released under MIT and it comes with absolutely no guarantees for correctness, support, or data integrity.

Reflections

Will LLMs make it possible for anyone to describe a problem to a coding agent like Codex or Claude Code and get back a working program?

In this project, I leaned on decades of experience in software design, development, and hacking. I know why things break, and how to articulate a fix. But over just the past couple of months, something has shifted: I experience a real shift in the capabilities of the agents. This time, I didn’t have to pull the system back from a wrong path even once. I know, people have been writing this for almost a year and now I see it as well.

That said, I do think experience still matters. People who know how to think computationally, who recognize what a good tool feels like, who have a sense for structure—and who have built instincts across languages and platforms—have a clear edge. They can suddenly operate effectively in territories where they’re not fluent.

Someone like me, who has a general understanding of software and a reasonably clear idea of what he wants, can step into something like Swift and SwiftUI without spending months becoming “native” first. The distance from idea to working tool shrinks. The set of things that feel like “I can probably build that" expands.

Where this goes in a few years is wide open—but undeniably interesting. I just hope I get to keep the fun parts, while delegating the tedious, repetitive work to AI.

So this isn’t the end of craftsmanship. It’s a redistribution of where craftsmanship matters.

Future Work

References

“Enshittification - Wikipedia”. Set 30. marts 2026. https://en.wikipedia.org/wiki/Enshittification#cite_note-1.

https://indieweb.social/@tg. “The Last Quiet Thing”. Set 23. marts 2026. https://terrygodier.com/the-last-quiet-thing.

“Command and control - Wikipedia”. Set 29. marts 2026. https://en.wikipedia.org/wiki/Command_and_control.