The story starts in 2014, with building a library called Bap to code beats with Javascript. At this point, I was still not enlightened and leaned fully into mutable objects and complicated connection graphs. While it may seem like a distant memory now, at that point in time, humans were still writing every single line of code by hand, and keeping the entire context window in their own memory.

My first deep dive into music programming focused mostly on encoding musical patterns as code with user interfaces borrowed from physical samples and drum machines. As in this example, the classic MPC pands and banks is transformed into a qwerty keyboard to interact with.

In the summer heat 2015, during a cross-country bus ride with broken air-condition, I had a revelation of how one would interact with my music programming libraries. Inspired and amazed by Type Drummer, I spent a weekend non-stop coding the first version, and the next few months iterating with a handful of passionate beta testers. The environment was a lot of fun to create small sample-based loops in, but I grew frustrated with the limitations of the DSL, and started sketching on a more comprehensive and flexible music programming language and environment.

One of the limitations of the 2015 version of trn.gl was that code was just static text, with no feedback about the sounds it produced at all. But solving the feedback problem was put to the side, in favor of going deeper with the programming surface itself: the syntax, the functions and the general concepts would have to be developed first.

In 2016, while working at Microsoft after the Wunderlist acquisition, I spent my evenings tinkering with different approaches to the environment and syntax.

I was conflicted between the simplicity of the 2015 version, and the ideal expressiveness I imagined my next environment to have. What is more important - that beginners can get started easily, or trading a higher learning curve for more power and flexibility? I am still searching for an answer to this question.

In 2017 I left the corporate grind and ended up spending a few months working hard on a version of trn.gl to release to the public. This was my goal, and I came quite far, until at the end of the year I decided to found a new company together with a group of friends from Wunderlist and Microsoft. Pitch was born, and for the next few years, little progress was made with my music programming.

In 2020 or 2021, I started building new experiments, this time focused on pattern manipulation in the spirit of TidalCycles.

Progress was slow, as my day job demanded most of the creativity and problem solving ability I had. But little did I know that this constraint was about to disappear...

Fast-forward to 2026. The world of programming has changed, radically. With expressive prompts, we can generate basic apps and complex user interfaces. "Writing code was never the hard part", they say, but for this personal side project, the ability to trade a few quick prompts for finished features with no manual effort has been life-changing, and has led to the newest iteration of trn.gl.

Feedback via highlighting chunks of code is back as a first-class primitive, and this version takes the familiar shape of a coding playground like CodePen or JSFiddle. Having processed many iterations of a similar concept, both actively in the foreground but also often passively and completely in the background, writing the next prompt is never hard.

The vision of what trn.gl should become feels effortless and inevitable.

The look is modeled closely on shapedbyrobin.com, the personal site of designer Robin Granqvist (based on his "Mono" template). I'd been circling something Swiss and typographic for a while without quite landing it, and his site was exactly the thing. Full credit to Robin for the design language — I just rebuilt it in my own stack.

What I was after was restraint:

• One typeface, one weight, one size. It's all Inter medium, 16px, everywhere — the name, the body, the dates, the links. Bold shows up only for the rare bit of emphasis.
• Hierarchy from colour, not size. Black for what matters, grey for everything supporting it — my role, the dates. That's the whole system.
• Nothing decorative. No rules, no boxes, no gradients. Early drafts kept sneaking in dividing lines and I kept tearing them out. A strong typeface and simple colours carry it.
• Instead of a menu, a single black triangle that links home, and a Contact link in the top right. No footer.

The thing that makes it feel balanced is the uniform weight. Once everything is the same size and weight, the only way to signal importance is colour — and that constraint is what makes it calm.

Every design before it

Half the fun of redesigning is that the old versions don't really disappear. The Wayback Machine has been quietly snapshotting this domain since 2010, so I can travel back and watch myself change my mind. A tour:

The throughline is obvious in hindsight: I keep chasing simpler. This latest one feels like the end of that particular road — though I've thought that before, and I'll probably think it again.

Two weeks ago we launched Pitch Agent. The team put an enormous amount of work into this over the last couple of months, and I'm excited it's finally in the hands of our customers. It sets a high bar for what quality humans should expect of AI-assisted deck creation, and I'm proud to see Pitch lead the way in this new era.

Anyone can generate slides with AI now, and that's kind of the problem. The output all looks the same. Generic templates, weird colors, stock-photo filler, LLM-typical gradients. You can spot an AI deck from across the room, and if you're presenting to customers or investors, that's a dealbreaker. Your deck has to look like your company, not like everyone else's.

You give Pitch Agent a prompt or a document and it builds the deck, using your brand system along the way. Not happy with a slide? Keep prompting. And since it all happens inside Pitch, what you get is a real presentation you can edit and present, not a pile of images. Together with the rest of our platform, in particular the collaboration and distribution capabilities, Pitch is the best choice for teams and professionals that use decks to win work and drive their business forward.

Try it yourself at pitch.com.

The problem is straightforward. When you're working with Claude Code or similar tools, they can't see what's happening on your screen. You can describe what you're looking at, or take manual screenshots. Both are tedious and lossy. What you want is to just record a chunk of your workflow and hand the agent a concise visual summary of what happened.

screenframes record opens the native macOS region selector. Pick an area, do your thing, press Escape to stop. You get back the video and a set of deduplicated frames — only the ones where something actually changed.

The pipeline is simple: record with macOS screencapture, sample at 10 fps with ffmpeg, auto-crop to the region where pixels actually changed between frames, run perceptual dedup using phash to throw away near-identical frames, downscale to 1280px wide, and generate a markdown manifest with timestamps. You end up with maybe 9 frames from a 12 second recording instead of 120.

You can also skip the recording step entirely with screenframes extract path/to/video.mov if you already have a video from Cmd+Shift+5 or whatever.

The output is a timestamped directory with the cropped video, the frames, and the manifest. Drop the frames into a prompt and the agent has context it never had before.

Python, MIT licensed, pipx install from the repo. Requires macOS and ffmpeg.

github.com/adamrenklint/screenframes

I think the loop is ending.

I've been doing AI-assisted programming for a while now and the productivity gains are real. But I keep running into the same wall: the codebases I work in were never designed for this way of working. The AI fights the architecture. The context windows fill up with legacy decisions. You spend half your time explaining the codebase to the machine instead of building.

Which got me thinking. What if you designed a codebase from scratch for a world where AI writes all the code?

Three layers

The software I want to build has three properties.

AI-built. The human writes specifications and reviews visual output. The AI writes all the code, runs the test suite, fixes what breaks, opens a pull request. The human never reads the source. The codebase is optimized for machine comprehension: small files, strict types, explicit boundaries. Code review gets replaced by automated verification. Type checking, linting, security scanning, visual regression, performance budgets, architectural rules. If the machine can't verify it, it doesn't ship.

AI-powered. AI capabilities are infrastructure, not features. Model routing, prompt management, cost tracking, caching, quality monitoring. Product people iterate on AI behavior through an admin interface, not through code deployments.

AI-operated. The application monitors itself. Error tracking, anomaly detection, incident analysis. When something breaks, an agent files a bug, another agent fixes it, CI verifies the fix, and it ships. The human sees a summary in the morning.

These three things together create a development loop that can run without human intervention. I haven't built this yet. But I believe it's possible today, with current tools, if you design for it from the start.

The context engine

Here's what I think most people building AI features are missing.

Your AI is only as good as what it knows. And right now, most AI features know almost nothing about the user's world. They work with whatever gets typed into a prompt box, maybe the current document.

The real unlock is a context engine. A system that connects to everything the user works with and makes all of it available as context. When you ask the system to create a board presentation, it already knows your financials, your strategic priorities, the key updates from Slack, the metrics from your analytics. It doesn't start from zero.

This changes what a product even is. The editor is a commodity. The accumulated understanding of your world is the product.

Agents talking to agents

We build software for humans to click through graphical interfaces. I think that's about to become the minority use case.

Soon, most interactions with most software will be agent-to-agent. Your personal AI talks to your company tools, which talk to external services. The human sets intent and reviews outcomes.

Software needs to be designed for this. Two layers: a structured API for precise operations, and an intent layer where agents describe what they want and the system figures out how. The second layer is what separates software that agents can technically use from software they can use well.

What changes

When one person with AI can ship more in a week than a team shipped in a quarter, the bottleneck moves. It stops being about headcount or velocity. It becomes about clarity of vision, rigor of verification, and taste.

I find this genuinely exciting. And a little scary. The ground is shifting under everything I thought I knew about building software, and I'm curious to see where we end up.

For the last decade my day job has been Clojure, and one of my go-to references is the ClojureScript cheatsheet on cljs.info. It's fast, scannable, and gets out of the way. I wanted something like that for Tidal.

Bits of Tidal is a quick-reference cheatsheet for Tidal Cycles functions, plus a small practice companion that suggests functions to try, to help push me out of my usual patterns when I'm making music.

The entire thing was built with Claude Code. I didn't touch the code at all, just described features and reviewed the result.

Check it out at adamrenklint.github.io/tidalbits.

Being biased for making the change I want to see in the world, I decided to build it myself, but when I started to look into how to implement this feature, I came across an undocumented setting for Quickblog: :page-suffix.

If we set :page-suffix to an empty string, then links won't include the .html extension anymore. But this creates a new problem: when running bb quickblog watch, the local server doesn't know to rewrite /page to /page.html.

The solution to this was also quite simple: in bb.edn, I have one quickblog command for developing and another command for building the production version.

{:deps {io.github.borkdude/quickblog
        {:git/sha "caffe692c8d715b30c8851ab8210dbabb19a1785"}}
 :tasks
 {:requires ([quickblog.cli :as cli])
  :init (def opts {:blog-title "My blog title"
                   :blog-description "My blog description"})
  quickblog {:doc "Development mode. Run `bb quickblog help` for details."
             :task (cli/dispatch opts)}
  quickblog-prod {:doc "Production mode. Run `bb quickblog-prod help` for details."
                  :task (cli/dispatch (assoc opts :page-suffix ""))}}}

When I'm developing and writing posts locally, I run the regular bb quickblog watch. In my Github action that builds and deploys the website to Github Pages, I instead use bb quickblog render.

Github Pages comes with out-of-the-box support for extension-less paths, so accessing adamrenklint.com/foo will actually load adamrenklint.com/foo.html.

Meet Preo, a tiny library that combines the expressive power of clojure.spec with the readable errors of Expound. When I say tiny, that's not an exaggeration - the entire library is 27 lines of code. But having used an earlier version of this library in production at Pitch for a couple of years, I can confidently say that not having to re-type or copy-paste the same boilerplate over and over is a huge improvement.

Validating arguments

Imagine we have a function that takes a string s and will do string-things to it. If it doesn't get a string as input, nested string-function calls will throw errors, and we'll have to traverse the stacktrace to find the point of failure.

If we add a pre-hook with a Preo assertion, our program will throw if an invalid argument is provided and show us a contextually rich error so we can quickly find the problem.

(defn my-string-fn [s]
  {:pre [(preo.core/arg! string? s)]}
  (subs s 2))

(my-string-fn 123)

; java.lang.AssertionError: Invalid argument: s
; -- Spec failed --------------------
;
;   123
;
; should satisfy
;
;   string?
;
; -------------------------
; Detected 1 error
;
; at preo.core$throw_error_BANG_.invokeStatic (core.cljc:7)
;    preo.core$throw_error_BANG_.invoke (core.cljc:7)
;    preo.example/my-string-fn (example.cljc:0)

The stacktrace is truncated here for readability.

Validating return value

Similarly, we might want to ensure the shape of the return value.

(s/def ::pos-int (s/and integer? pos?))

(defn ret-example [v]
  {:post [(p/ret! ::pos-int %)]}
  v)

(ret-example "asdf")

; java.lang.AssertionError: Invalid return value
; -- Spec failed --------------------
;
;   "asdf"
;
; should satisfy
;
;   integer?
;
; -- Relevant specs -------
;
; :preo.example/pos-int:
; (clojure.spec.alpha/and clojure.core/integer? clojure.core/pos?)
;
; -------------------------
; Detected 1 error
;
; at preo.core$throw_error_BANG_.invokeStatic (core.cljc:7)
;    preo.core$throw_error_BANG_.invoke (core.cljc:7)
;    preo.example/ret-example (example.cljc:2)

Preo takes either predicate functions or keywords resolving to specs, and is written with CLJC to make it work in both Clojure and ClojureScript.

This library is certainly not a ground-breaking discovery, but a useful utility if you like to use pre/post hooks and are tired of manually writing assert messages with enough context.

The code is live on Github, the package is published on Clojars and I'm always eager to hear feedback or ideas. But please note: the tiny scope is a feature, not a bug, and I'm unlikely to accept any patches that increases that scope.

A recent exploration of rytmic and melodic patterns as functions of time, inspired by TidalCycles, presented the need for a pseudo-random number generator (PRNG) that takes a seed and the current time, measured on an infinite scale of "cycles", to produce a value. We need to be able to retrieve a random number at any resolution of this time scale, and the result should feel random and be somewhat uniformly distributed.

Intuition for randomness

To get a better feeling for what a "somewhat uniform" distribution looks like, let's first see how Clojure's built-in random number generator performs. Below is the result of generating 1000 random numbers with clojure.core/rand and sorting them by the first decimal. As you can see if you click "Regenerate" multiple times, the ratios change a bit but always remains in the 7-13% range. And if we 10x the sample size, the ratios get closer to an even 10%.

Our version

Most examples of PRNGs that produce a series of random numbers use a method of bitshifting a continuously mutated state, or multiple. With my hard requirement of having no mutable state, making it a pure function of the seed and time parameters, I instead came up with a version that combines the two parameters and applies a few arithmetic operations to get a predictable random number.

(defn custom-rand [seed t]
  (-> (inc t)
      (+ seed)
      (* 17.1737)
      (mod 10)
      (/ 10)))

The "magic numbers" here were just made up on the spot, once and never changed. Seven feels like the most uneven number below ten, so I intuitively used that a lot. The time is increased by one so that multiplication operations always have some effect even though time starts at 0. Let's look at the result.

Quite good distribution, comparable to clojure.core/rand above. Performance-wise it's about 2-3x slower, which is acceptable for this exercise, but I might want to revisit that topic in the future.

I wasn't able to easily move over the handful of decades old posts consisting of painful puns and outdated Javascript tricks, so I'm starting over with a blank slate.

While the design is minimal and Quickblog is refreshing in its lack of features and customisability, the new version is not lacking in spice. Using Scittle, I'm able to sprinkle Clojure in my posts and make them interactive and stateful.