DEV Community: Leandro

Zettelkasten as a note-taking method for AI agents

Leandro — Mon, 06 Jul 2026 18:10:44 +0000

I wanted to give AmblerTS, my Deno/TypeScript state-machine framework, the ability to record non-obvious learnings that would otherwise require significant context to reconstruct across sessions.

I turned to the classic note-taking methodology developed by the German sociologist Niklas Luhmann: the Zettelkasten (German for slip box). The methodology is elegantly simple: take atomic notes, link them explicitly to related ones, and organise them so they can be retrieved precisely when they become relevant again.

The Concept

The idea translates naturally to agentic coding:

Describe the protocol in an AGENTS.md file, a convention that coding agents like Gemini and Claude read as project-level instructions.
Implement a lightweight abstraction using AmblerTS itself, a unified azk walk that supports the full set of operations: search, create, get, update, link and delete.
The agent searches for relevant notes before working on a prompt, then feeds any new learnings back into the slip box when done.

The result is a notes folder with Markdown files for notes and a local, git-ignored SQLite database that accumulate project-specific metadata (design decisions, gotchas, constraints) accessible to any coding agent that works on the repository. Search blends FTS5 keyword matching with optional semantic re-ranking via embeddings (degrading gracefully to keyword-only when no local embeddings host is available).

Current Implementation

The implementation is intentionally minimal, enough to validate the idea. A single deno task azk <subcommand> command exposes all six operations:

deno task azk search "<query>"
echo '{"title":"...","body":"...","tags":["..."]}' | deno task zettel create
deno task azk get <id>
echo '{"body":"..."}' | deno task zettel update <id>
deno task azk delete <id>
deno task azk link <fromId> <toId> "<relation>"

What's Next

A few variants I have in mind:

• User-level note store: a single knowledge base spanning all coding agent activity across projects, backed by a user-level AGENTS.md and a shared command, rather than one database per repository.
• Hybrid Markdown + SQLite storage, keeping notes as version-controlled Markdown files with SQLite used purely as a search index. Whether that adds value likely depends on the development process: projects with meaningful git history and code review may benefit from diffable notes; others probably won't.

──────

AmblerTS is open source. You can explore the implementation and try the Zettelkasten-RAG setup at https://github.com/argenkiwi/ambler-ts.

From ANSI to Ergo: Remapping the Transition

Leandro — Fri, 26 Jun 2026 19:09:16 +0000

A common story in the mechanical keyboard community goes like this: someone starts suffering from repetitive strain injury (RSI) or general hand pain and decides to transition to an ergonomic keyboard. To make the transition easier, they look for a large layout with plenty of keys. However, once the keyboard arrives, they realize the learning curve is steep. Frustrated, they ask for help in forums, convince themselves they bought the wrong board, and buy another one. Those who don't quit often end up with an expensive collection of ornamental keyboards.

I wanted to avoid this trap. Instead of buying a series of physical keyboards until I found the one, I learned what features my ideal keyboard should have. I settled on the following: a 34-key, column-staggered, split ergonomic keyboard layout.

Next, I needed to find a way to reduce the number of keys I was using on my ANSI keyboard to 34 or less by:

Identifying which keys were truly redundant or unnecessary.
Efficiently mapping the remaining keys using a layered system.

But didn't I need a programmable keyboard for that?

Bridging the Gap in Software

That’s when I discovered KMonad: a powerful tool that allows you to reprogram any keyboard at the software/OS level. This enabled me to test and refine a 34-key layout directly on my standard ANSI keyboard before purchasing any ergonomic hardware.

Introducing Kenkyo (謙虚)

Through this software-first approach, I open-sourced my custom layout under the name Kenkyo (which means humility in Japanese). I chose this name as a contrast to the dominant Miryoku (allure in Japanese) layout.

While Miryoku is highly custom and fully featured, Kenkyo aims to be a simple, non-disruptive, software-driven bridge that allows standard ANSI keyboard users to gradually transition to a layered 34-key workflow.

Over time, I migrated my setup to more modern and lightweight alternatives:

keyd: A highly efficient keyboard remapping daemon for Linux.
Kanata: A cross-platform remapper focused on advanced features like tap-hold, home row mods, and custom combos.

By remapping the keyboard in software first, I was able to build muscle memory. By the time I received my first ergonomic keyboard I could be productive with it right away. To this day, I still use software for my layout, which allows me to switch between my ergo and laptop keyboards painlessly.

The age of forks

Leandro — Wed, 10 Jun 2026 18:58:15 +0000

It has become relatively cheap now to take an existing open source project with a permissive license, fork it and tailor it to your needs. At the same time, the internet is saturated with new projects generated with coding agents and our attention span cannot grow.

I am sure I am not alone having the following experience: there is an open source project I love, but it is missing one or 2 features that should be straight forward to implement. I create feature requests, but the author has no time to even look into them or deems them as the wrong fit or direction for the project. I create a minimal pull request with the aid of a coding agent, as I am not versed on the programming language used for the project, but the PR stays on with no signs of being reviewed anytime soon and will likely be rejected due to the use of AI. Of course, the easiest thing to do now is to simply use the fork of the project I put together for the pull-request.

But why stop there? Now I have added MacOS support for a C application that was targeting Linux exclusively and I am even porting it to Rust just so I can learn the language while I iterate over it. I tried sharing the initiative with others, but there is too much noise for anyone to pay attention. How many forests will be burnt so we can reinvent the wheel over and over? I am honestly not sure of how to feel about the direction in which software engineering is going. So many conflicting feelings.

Home-Bottom Row Modifier Clusters

Leandro — Sat, 30 May 2026 20:29:46 +0000

In the world of custom keyboard layouts, one of the biggest challenges is balancing accessibility with speed. The traditional ANSI layout forces your pinkies and thumbs to reach for distant modifier keys like Ctrl, Alt, and Shift. While "Home Row Modifiers" (HRM) have long been a popular solution, the Kenkyo
layout takes this a step further with Home-Bottom Row Modifier Clusters.

This post explains how we use Kanata to turn the home and bottom rows of a standard keyboard into a high-performance modifier engine.

The Concept: Overloading the Letters

At its core, Kenkyo uses modifier overloads on standard letter keys. Instead of reaching for a physical Shift key, you simply hold a letter on your home row.

In our kanata.kbd, we use a template called charmod. This leverages Kanata's tap-hold-release-timeout logic, but with a special twist we call flowtap:

(deftemplate flowtap (flow tap)
  (switch 
    ((key-timing $streak-count less-than $streak-time)) $flow break
    () $tap break
  )
)

The flowtap logic detects if you are in a "typing streak." If you are typing fast, the keys behave as normal letters to prevent accidental modifier "misfires." If you pause or type a single key, the hold-to-modify behavior is activated.

The Clusters: Home and Bottom Row Synergy

While standard HRM puts modifiers on A S D F and J K L ;, Kenkyo clusters them across the home and bottom rows to reduce finger strain and enable advanced combinations.

Left Hand Cluster (`mhbl`)

Home Row: s (Alt), d (Shift), f (Ctrl)
Bottom Row: x (AltGr/RAlt), v (Fumbol Layer)

Right Hand Cluster (`mhbr`)

Home Row: j (Ctrl), k (Shift), l (Alt)
Bottom Row: m (Fumbol Layer), . (AltGr/RAlt)

By involving the bottom row, we create "clusters" where your fingers can easily rock between a standard modifier (like Shift) and a layer toggle (like Fumbol).

Replacing Physical Keys

On a standard ANSI keyboard, a combination like Ctrl + Shift + T requires awkward contortions. In Kenkyo, this is achieved by holding f (Ctrl) and d (Shift) with your left hand, and tapping t. Your hands never leave the home position.

We even use Chords (pressing two keys simultaneously) to trigger common actions:

w + e = Esc
i + o = Backspace
j + k = Enter

The One-Shot Advantage: Typing at Speed

One of the most powerful features of the Kenkyo clusters is the use of One-Shot Modifiers.

A One-Shot modifier (or "sticky key") stays active only for the next keypress. In Kenkyo, we trigger these using chords within our clusters:

d + k (simultaneous tap) = One-Shot Shift
x + . = One-Shot AltGr
v + m = One-Shot Fumbol Layer

Why One-Shots?

Maintain Rhythm: When typing at speed, holding a key down breaks your "tapping" rhythm. One-shots allow you to treat modifiers as just another tap in the sequence.
Reduced Fatigue: You don't have to maintain tension on a key while reaching for another.
Misfire Prevention: Since the modifier is only active for one key, you don't accidentally "hold" it into the next word.

Advanced Multi-Mod Chords

For power users, clusters allow for complex multi-modifier one-shots that would be nearly impossible on a standard layout. For example, in Kenkyo:

x + d = One-Shot AltGr + Shift
x + d + v = One-Shot AltGr + Shift + Fumbol Layer

This allows you to access deep symbols in the Fumbol layer with a single, coordinated "pinch" or "swipe" of the fingers, keeping your typing fluid and your hands relaxed.

The Home-Bottom Row Modifier Cluster isn't just about saving space—it's about re-imagining the keyboard as a tool where every key is exactly where you need it to be, exactly when you need it.

Porting existing code to Ambler TS

Leandro — Tue, 19 May 2026 19:39:19 +0000

The quickest way to port code from a Git repository into Ambler TS is to include it as a Git submodule and leverage Ambler's agentic skills. We'll use the PocketFlow cookbook as an example.

Project Setup

Create a project folder
Initialize git
Add PocketFlow (or a Git repository of your choosing) as a submodule.
Install the Ambler TS skills

mkdir port
cd port
git init
git submodule add https://github.com/The-Pocket/PocketFlow.git
npx skills add argenkiwi/ambler-ts

Initialize Ambler

Use a coding agent (like Claude or Pi) and invoke the ambler-walk skill:

/ambler-init .

Port Code

Invoke the ambler-walk skill and provide the path to what you want to port:

/ambler-walk create chat walk from @PocketFlow/cookbook/pocketflow-chat

The agent will automatically:

Analyze the source logic.
Create the necessary Nodes in nodes/.
Scaffold a Spec in specs/.
Wire everything into a Walk in walks/.

Test Run

Once the agent finishes, verify the port:

deno test nodes/tests/
deno task <walk-name>

I hope the next generations of gaming consoles are designed to also be your household's LLM hosts so you can use the GPU and unified memory for something useful during work hours.

Leandro — Tue, 19 May 2026 16:37:27 +0000

You can use lteter tiiartnosopsn also kownn as tygmioaypcle, to make the lives of AI agents hrad.

Leandro — Thu, 07 May 2026 23:06:35 +0000

One of the selling points of open source software has always been that you could look at the code and make sure it does what is says it does. But then who could be bothered to read the source code to verify it was legit. Agents can do it for you now.

Leandro — Wed, 06 May 2026 22:29:32 +0000

Ambler TS: a minimal state-machine builder driven by agent skills

Leandro — Mon, 04 May 2026 04:41:31 +0000

Simply install the relevant skills into an empty folder, as explained in the GitHub repo, and describe you program (walk) to your coding agent, detailing its steps (nodes) and how they connect with each other (edges). Ambler TS' skills will help the agent write specs, code and tests for your project in a predictable and modular manner. You can easily run it using Deno.

I have been testing the library using local LLMs within the Pi Coding Agent. It is great for replacing automation scripts and playing with agentic workflow ideas.

Convention over configuration reaches a new level with agent skills. I built a tiny workflow orchestrator (ambler-ts, 52 lines of TypeScript with docs). But it is the skills that enforce the patterns used to write simple, readable and maintainable code.

Leandro — Thu, 30 Apr 2026 22:17:23 +0000

I have been experimenting with agent skills for software design patterns and the results have been very positive so far. I put together an Android (arch26) and Deno (ambler.ts) projects and the results are predictable while tests are written by default.

Leandro — Fri, 17 Apr 2026 16:12:33 +0000

Ambler: rules of engagement with coding agents

Leandro — Thu, 31 Jul 2025 21:58:22 +0000

I recently came across an interesting project called PocketFlow, which presents a minimalistic approach to building workflows that incorporate large language models. It is originally written in Python, a language I have never really used, so I attempted to port it to Kotlin to better understand how it works. As I progressed it became clear the project was simply a glorified state machine and it could be simplified even further. The result was Ambler: a very simple function and a very simple class definition that allow you to express a program as a series of steps that update the current state and pass it on to the next step.

Nothing groundbreaking, but the power of this simplicity is that you can describe your application logically in plain English in a markdown document and then ask a coding agent to build it for you, while keeping the application structure consistent, predictable and easy to understand.

I decided to build a simple counter application as the first example. By not specifying the programming language, Gemini CLI tended to gravitate to using Python. I went along and refined the approach until I got exactly what I wanted. By the end of it I also obtained an equivalent implementation of the Ambler code and the sample in Go, JavaScript, Kotlin, Ruby, Rust and Typescript.

I have observed something interesting when looking into the project on GitHub: the percentage of the codebase written in each language varies considerably for an equivalent implementation. It makes me wonder what the long term impact of using a less verbose, more concise programming language has on your agentic coding costs, assuming there will be a direct correlation between the amount of code needed to solve a problem and the number of tokens used.

I'll continue experimenting with this approach, but I can already see how useful it will become when needing to automate simple tasks. Gemini CLI has already made me a handy application to download URLs from an m3u file which is a great companion to an Chrome Extension Gemini CLI built for me a while ago. All I need now is more ideas to test the approach with.