So I figured out a way to mount my Peak Design Everyday Backpack on the side of my bike, with no additional equipment, just using the straps of the backpack.

I attached the backpack to the rear rack using the external carry straps.

To make sure the shoulder straps don't get tangled in the wheel, I fold them over and use the sternum strap to keep them in place.

I attach the backpack as far to the back of the bike as possible to give my heal enough space when pedaling.

When hooked in to the attachment points, the external carry straps keep the backpack securely attached.

It’s more tedious to mount and dismount than a pannier bag, and not as fool-proof. Once, one of the external carry straps came loose, likely because I hadn’t properly attached it in the first place. Because of the second strap, the backpack was still attached though.

I’m still looking for an easier way to mount my backpack on my bike, without getting a different backpack or adding gear to my backpack. This hanger looks like it might solve my problem.

I had previously tried Claude Code for some personal projects, but opencode was the first terminal-based

AI agent I tried that worked well with my company's internal LLM proxy.

Recently I shared my experience with agents and AI coding with some colleagues.

This post is a write-up based on my preparation for that session.

What are agents?

There are many different definitions of "agent".

I'm happy with the one Simon Willison settled on:

An LLM agent runs tools in a loop to achieve a goal.

Let's break this down:

• LLM: The language model provides reasoning and decision-making
• Tools: Functions the agent can call - web searches, file searches, creating and editing files, running shell commands
• Loop: The iterative cycle of reasoning → tool use → evaluation → next action
• Goal: A bounded objective that provides a stopping condition

Evolution of AI coding

Jason Liu and Beyang Liu describe three

distinct areas in the evolution of AI coding:

1. the autocomplete era
2. the RAG chat era
3. the agentic era

The latest transition from the RAG chat era to the agentic era comes with an inversion of how some of the context is provided to the LLM.

Whereas in the RAG chat era, a RAG system first retrieved context with a similarity search on top of the original query

and then passed this context to the LLM to generate a response,

in the agentic era the LLM itself decides which tools to use and which context to fetch.

But this does not completely relieve the engineer from thinking about context completely.

While the LLM is able to fetch context, left unchecked, an LLM agent tends to pollute its context window with irrelevant information.

Context engineering

That's where context engineering comes in.

As Dex Horthy from HumanLayer, who coined the term "context engineering", says:

Everything is context engineering.

LLMs just turn inputs into outputs.

Everything that goes into the LLM is the context.

To get good output, you need good input.

Creating great context means being intentional about the prompt you give to the LLM, the additional documents that are retrieved,

and any chat history, including tool calls and results.

How can we do great context engineering in practice when using agents for coding?

Context engineering is the delicate art and science of filling the context window with just the right information for the next step.
— Andrej Karpathy

My workflow

What works well is tackling an implementation in phases.

Along the way, I create artifacts (markdown files) to help transition between phases.

This approach prevents the history of a previous phase from polluting the context window of the next one.

The input to one phase should only be the outcome of the previous phase.

The phases in my workflow (and many others') are: research, plan, implement.

How you got to the result of the research is not relevant when planning and how you decided on a specific plan is not relevant

during implementation.

Research

During the research phase, the goal is to understand the codebase, the data flow, potential problems and their causes.

Sometimes I skip this phase or include some minor research in the planning phase.

Plan

During the plan phase, the goal is to decide on an approach to implement.

I usually start by asking for possible implementation approaches, explore them, challenge the provided suggestions,

clear up misconceptions and then decide on an approach for which I let the agent write a plan.

Implement

Once the plan is set, the implementation can commence.

I usually do this in small iterations, following the plan and reviewing code changes along the way.

When possible, I start by writing failing tests and then continue by making the tests pass.

What do you do when the result of the implementation is wrong? Here's Dex Horthy again:

Implementation is compiling the spec to code.

If your compiled program is wrong, you don't change the assembly, you rewrite the code and recompile.

If your code is wrong, don't resteer live, go fix the plan and restart the implementation.

Put more generally, the impact hierarchy for coding agents explains what you should spend human effort on.

Impact hierarchy for coding agents

In keeping with my pattern of freely copying from Dex and the folks at HumanLayer, here's the impact hierarchy for coding agents they propose.

At the very top with the most impact we have a bad line in your agent instructions, e.g. CLAUDE.md or AGENTS.md.

It affects every phase in your workflow and every session.

I started my AI coding journey without an AGENTS.md file to get an understanding of the behavior of an agent without it.

Over the past months I've been slowly adding some instructions, and monitoring how it affects the coding agent.

The remaining levels of abstraction align closely with the phases of the workflow described above.

The specification is the input to the research phase, the research is the input to the plan phase,

and the plan is the input to the implementation phase.

As you step down these levels of abstraction, the impact lessens.

Conclusion

I'm still working on getting a better understanding for what works when coding with AI.

For example, I'm currently interested in ways to streamline the hand-off between phases.

Currently, this is a very manual process for me.

I'm not re-using any prompts.

Additionally, I'm curious about how to effectively use intentional compaction to keep the context window relevant.

What helps me is reading others' experience with AI agents.

Here are some posts that I've found helpful:

• Dex Horthy on getting AI to work in complex codebases.
• Calvin French-Owen on how different AI coding tools shift your "thinking budget" between providing the right context, planning, implementation, and review.
• Atharva Raykar on the Nilenso blog on AI-assisted coding for teams that can't get away with vibes.
• Sean Goedecke on how being good at code review translates to being effective with AI coding agents, emphasizing the importance of structural thinking over nitpicky line-by-line fixes.
• Thomas Dohmke on how developers are evolving through distinct stages of AI adoption, from skeptic to strategist, and how the role is shifting from writing code to orchestrating and verifying AI-generated work.
• Vicky Boykis on her favorite use-case for AI: writing logs.
• Armin Ronacher on agentic coding things that didn't work.
• Conrad Irwin on the Zed blog on why LLMs can't really build software.
• Peter Steinberger on his AI coding workflow.

Bonus: Shreya Shankar on writing in the age of LLMs.

Not directly related to coding but still relevant for software engineers.

If you're new to AI coding agents, I'd recommend:

Download a coding agent and try using it for most (if not all) of your coding work for a week.

I like opencode for its defaults and the ease with which you can switch between models, even of different providers.

But any other coding agent like Claude or Codex will give you a similar experience.

The bahá’í song project YouTube channel has 4500 subscribers and bahaisongproject.com reaches 3000 users every month.

The current architecture for the website evolved from my experimentation with new technologies and leveraging free-tier services.

I often say I’ll re-architect and refactor everything someday—but that day has yet to come.

Current architecture

The song sheets containing ChordPro files with lyrics and chords live in this public repository.

On each push to the repo I build and publish the song sheet PDFs.

The song data, such as titles, artists, tags, languages and texts the song is based are stored in

a Postgres database.

I expose the song data with a GraphQL API.

I finished the first version of the GraphQL API in early 2019.

At the time i was nearing the end of my studies in computer science,

but doing more machine learning research than software engineering.

GraphQL was very hyped-up at the time, and so it happened that the first API I've ever

built was a GraphQL API.

I generate bahaisongproject.com as a static website using the GraphQL endpoint.

This repository is also public.

The only dynamic element is search, which I added with Algolia.

I additionally use the GraphQL endpoint in a script that I run manually when creating the song sheets to add song data

to the song sheet.

I do this so that I only have to maintain the song data in one place, the database.

Current pain points

I frequently get messages with corrections or submissions of new songs.

Currently, to add or update a song, I need to spin up Prisma Studio locally.

When I add a song, I need to update multiple tables separately.

This is a lot better than directly interacting with the database, but still cumbersome.

This means that fixes and new song submissions are often delayed.

Additionally, I create a song sheet in ChordPro.

I link the song sheet to the song data via the slug of the song title which also serves as file name of the song sheet.

When the song data changes in the database, I then run a local script to update the song sheets and push them, triggering another build.

I also need to manually trigger a rebuild of the website to include the new or corrected data.

These are too many steps.

I spend more time thinking about the steps I need to take, than with doing the actual work of adding or correcting song data.

This is helpful for reviewers and for me while working on a PR.

If my commits tell a story, it's easier for me to start working on a PR again after a context switch and

for reviewers to quickly grasp what the PR is changing.

It also gives reviewers the possibility to review the PR commit by commit instead of only looking at the full diff.

Mystery meat

I find it difficult to review PRs that do not have a description, and where I cannot look at the

commit history to understand what the PR is doing.

I do not know what's inside, until I start dissecting it.

Like mystery meat.

The only option I have is to look at the complete diff.

This works for smaller PRs, but gets difficult quickly for bigger PRs.

Narrative commits

A good first step to reduce the mystery is to write a description for the PR.

The next step is to make the commits tell a story.

You make commits tell a story by ensuring each commit does only one thing (atomic commits) and by writing concise commit messages.

My story usually starts with some refactoring to prepare for the changes that I'm about to make.

Then, when possible, I add failing tests.

Finally, I implement the changes to make the tests pass.

Here's an example:

a8f2c94 extract the csv parser from the handler to set up isolated changes
b3e7a01 add support for multiple pool assignments - add failing tests
c5d8f92 add support for multiple pool assignments - implement
d9a4b7e handle overlapping assignments - add failing tests
e2c1f58 handle overlapping assignments - implement

I like continuously rebasing my PR while I'm working on it.

I usually don't know the exact story I want to tell when starting, but it becomes clearer as I make progress.

When I feel like the story in my head is diverging from the story my commits are telling, I rebase.

This can happen multiple times while working on a PR.

I like using the interactive rebase tool in the JetBrains IDEs for this, but I when I started doing this

I did it with the git cli directly.

Let's explore how this cognitive bias works through the lens of mobile phone plans.

The diagram above illustrates the three different decoy effects on a quality-price grid.

The competitor and target products are fixed points, with three distinct regions where placing a decoy product can influence consumer choice.

The basic setup

Our target phone plan costs thirty euros per month and includes ten gigabytes, while the competitor’s plan offers six gigabytes for twenty euros.

Asymmetric dominance

Asymmetric dominance occurs when we introduce a decoy that's clearly inferior to our target product:

Here, the decoy is both more expensive and offers less data than our target, making the target appear as a more rational choice.

Attraction effect

When we position the decoy slightly below the target in both price and quality we can observe the attraction effect:

The decoy's presence makes the target's premium features more attractive, despite its higher price point.

Compromise effect

When we position the target as the "middle ground" option, in this case by creating a decoy that's more expensive but also higher quality, the compromise effect occurs:

By introducing a high-priced option, the target appears as a reasonable compromise between price and features.

Acknowledgement

Based on lecture notes from the winter term 2017/18 lecture Digital Communities at TU Berlin.