Claude Code, Cursor, GitHub Copilot, Windsurf, ChatGPT, Gemini — I call them my assistants.
Lately, I’m not so sure who’s assisting whom.

Agentic tools keep handing me decisions in the same shape:
– Option 1 (Recommended)
– Option 2
– Other

When I know the domain, I actually choose. When I half-know it, I read the alternatives and make a decision. And when I don’t know enough to judge? I click Recommended and call it trust.

It reminded me of Delegation Poker from Jürgen Appelo’s Management 3.0, which describes seven levels of delegation between a manager and a team:
Tell → Sell → Consult → Agree → Advise → Inquire → Delegate

Tell – I make the decision and announce it. No discussion expected.
Sell – I make the decision, but I explain my reasoning and try to get you on board.
Consult – I ask for your input first, then I make the decision.
Agree – We discuss it and decide together, by consensus.
Advise – You make the decision, but I give you my recommendation first.
Inquire – You make the decision, then explain it to me afterward.
Delegate – You decide, full stop. I don’t need the details.

Map that onto an agent session, and the level can shift by the minute. And some afternoons, I’m just the Clicker:
– Read the summary.
– Hit Approve.
– Move on.

Here’s the uncomfortable part: Clicking Approve on a plan you can’t evaluate is Delegate wearing an Consult costume. An approval step only counts if you have enough context to reject it.

So now I try to choose the delegation level per decision, before the session starts, based on two things: Blast radius and reversibility.

Formatting? Fully delegated. Anything touching data, architecture, or high-level design? I stay involved.

Maybe, after all… I’m not sure who’s assisting whom. I started calling AI my assistant. Now I’m wondering if I should start calling myself the assistant to my assistants. 😂
Okay, let me ask my boss.

Foreword: Thorngate’s postulate of commensurate complexity

The postulate of commensurate complexity is a description of a phenomenon in social science theorizing. Karl E. Weick claims that research in social psychology can always only possess two of the three meta-theoretical characteristics: ‘Generality’, ‘Accuracy’, and ‘Simplicity’. Therefore, one of these three characteristics must always be subordinated to the other two. Simply put, a model can only possess two of the three characteristics of being general, accurate, and simple, and never all three simultaneously.

This postulate is named after the Canadian social psychologist Warren Thorngate from the University of Alberta. In describing the problem, he states: “In order to increase the generality and accuracy of theories, their complexity must inevitably increase.”

Karl Weick used the image of a clock below to illustrate this concept. On this clock, at 12, 4, and 8 o’clock, the three terms Generality, Accuracy, and Simplicity are written. Now, pay attention to the concepts of 2, 6, and 10 o’clock:

– 2 o’clock: Research is universally applicable and highly detailed, but it becomes complex and loses its simplicity.

– 6 o’clock: Research is useful for a specific context, but its results are not generally applicable to other contexts and lack generalizability.

– 10 o’clock: Research is universally applicable and easily understood, but it lacks sufficient detail and high accuracy.

Karl Weick claims that you must make a tradeoff when choosing these three characteristics, because only two of them are achievable at any given time.

Discussion: What time is it in your model’s world?

The interesting point is that Thorngate’s model can be applied to software. And what’s even more interesting is that when we face a problem and want to provide a solution for it, we map out certain aspects of the solution (read: the model) in our minds.

Let’s solve a simple example together. We want to design the database for a small banking system that handles deposits and withdrawals. Do you consider two separate tables for deposits and withdrawals, or a single table named “transactions” that includes both? Now, if you look at your own solution through the lens of simplicity-generality-accuracy, what time are you positioned at?

Now is the time to review some of your previous solutions and see what time it is in the world of your solutions.

Source:

The idea for this post comes from the book Mastering DDD by Annegret Junker.

In 1995, Watts Humphrey handed every developer a personal process.

It failed.

His Personal Software Process (PSP) let a single developer run a defined, measured, continuously improving process. It worked, but the bookkeeping killed it. Time logs, defect logs, forms after every task. Almost nobody could sustain it. Humphrey moved on to team processes, and for thirty years the smallest unit of process design has been the team.

I think that just changed.

Look at what an AI coding assistant actually gives you:

→ Skills: reusable SDLC activities such as analysis, design, testing, review
→ Subagents: roles with responsibilities
→ Hooks: quality gates that run every single time
→ Memory files: your standards, written down

Put these together and you have a full process, with you as its designer.

To be clear, this is not the “army of agents” story. The agents were never the point. The point is that the machine now absorbs the overhead that killed PSP: the constant logging, measuring, and enforcing. Humphrey was right. He was just thirty years early.

I call it the Process of One. It’s what I’m building now.

I’m designing my own process: the activities, the roles, the quality gates, the retrospectives. Everything I once designed for teams, I now design for a team of one. And this time, the machine carries the bookkeeping that defeated Humphrey.

The first rule of AI engineering applies at this level too: if you don’t measure it, you’re guessing. So I hold my own process to the same standard I hold the AI systems I build, and I keep asking: does it actually work?

You are a team of one now, with a process of one. How would you design yours?


Comment:
I’ve also started a catalog of these patterns: 19 so far, researched and organized together with the very assistant they describe. Each one written the same way: the situation, the problem, the solution, the source. Link on GitHub.



Quote:
Nothing that exists in the world is outside of you.
Seek within yourself whatever you want,
for that you are!
Rumi

If you use AI for coding every day, you may have noticed something strange: Your AI coding assistant gets dumber the longer you talk to it.

Most developers feel it but can’t name it: you start a chat, it’s brilliant. An hour later — same model, same task — it’s forgetting your instructions and repeating bugs it already fixed. You blame yourself. Don’t.

Matt Pocock calls it the smart zone and the dumb zone. A model is sharp early in a session, then quality slips well before the chat feels “full.” And here’s the surprising part: those huge new context windows everyone is talking about? They don’t give you more smart zone. They just give you a bigger dumb zone.

(Technically: a model’s effective context length is much shorter than its advertised window. As the thread grows, attention spreads thinner across more tokens, mid-context detail gets underweighted — “lost in the middle” — and the model keeps conditioning on its own earlier mistakes still sitting in the history.)

So the fix isn’t a better prompt. It’s a shorter memory. One task. One conversation. Then start fresh.

For larger work, move the memory outside the conversation: define the destination in a a shared specification, break the journey into small independent tasks, and give each task a clean context. The goal isn’t to give the AI everything it could possibly know. It’s to give it exactly what it needs for the task in front of it.

Your assistant was never getting tired. It was getting full.

Highly recommend Matt Pocock’s “Full Walkthrough: Workflow for AI Coding.” I learned a lot from this workshop.

Source:
Matt Pocock’s “Full Walkthrough: Workflow for AI Coding” (AI Engineer). The smart zone / dumb zone section is worth the watch if you use an AI assistant daily: Link

One practical tip from it: keep a token counter visible in your setup, and clear the chat when a task is done rather than stacking the next one on top. A fresh session beats a smart prompt.

Excerpt:
Every breath, the world is made new — and we, unaware of our renewal, endure.
Rumi, Masnavi

Almost everything I’ve ever built has been retired, replaced, or shut down. Except one. It has no users to please, no metrics, no roadmap, no deadline. And next month, it turns twenty.
It’s a weblog.

I started it on a Friday in the summer of 2006 — جمعه سیزدهم مرداد 1385 — in Persian, on one of the old blogging platforms, with no plan and no audience. I called it Somamos, after the highest peak in Gilan, in the green north of Iran. My family’s village, Bibalan, sits on the plain below, with Somamos rising on its horizon. The name was how I kept home in sight.

There was never a topic. There was only a rule I didn’t know I was following: if I loved it, it went in. A line of classical poetry. A book, a film. A thought about language. A knot in some code I’d finally worked loose. An idea in AI I was still turning over. A memory I refused to lose.

A public notebook, written for my friends.

It outlasted jobs. It outlasted cities. It crossed the ocean with me to Canada and didn’t miss a beat. Twenty years of software came and went around it — platforms died, formats changed — and the notebook just kept filling.

It lives at bibalan.com now, and recently it learned a second language: I’ve started making it bilingual, Persian and English side by side. I’ll be sharing some of these pieces here on LinkedIn too — so they reach not just the friends I wrote for in 2006, but the ones I haven’t met yet.

Twenty years ago I shared what I loved with people I knew.
Now I’m sharing it with you.

Preface:
In the world of software development, coding is only part of the story. The human side of the work is no less—perhaps even more—influential in a project’s success than the technical side. The human side of software development becomes far harder and more complex when we move from “coding side by side” to “occasional glimpses of each other from a distance, from behind a screen,” and then to “teammates we’ve never met.”

A while ago I came across a very instructive guide on the website of the SQLModel project. The lead of this project, Sebastián Ramírez (known as @tiangolo), is the creator of FastAPI, one of the well-known web development frameworks in Python. Below I’ve included part of the guide that Ramírez himself wrote for Repository Management Tasks. The goal of the non-technical part of this guide is not only to promote professional behavior, but also to build a lasting culture within the software developer community—a culture in which, even in challenging moments and technical disputes, the priority is respect for people and appreciation of their efforts.

The Guide: Be a Good Person!

Above all else, be a good person. If you were added to the team, it means you’re probably an exceptionally good person already, but it’s worth reminding ourselves of it again.

For when things get difficult!

When things are going well, the work is easier and there’s no need for long lists of instructions. But for the difficult times, here are some guidelines.

Try to see the positive side. In general, if people aren’t behaving unkindly, try to thank them for their effort and interest—even if you disagree with them on the matter at hand (a technical discussion or a PR). Thank them for caring about the project or for the time they spent trying to get something done.

Expressing emotions in text is hard; use emojis to convey your feelings.

In technical discussions and PRs, people often express their frustration directly and unfiltered—they frequently exaggerate, complain, act entitled, and so on. These behaviors really aren’t right, and when someone does them it lowers our priority for solving their problem. Even so, try to take a deep breath first and then give calm, polite replies. Try not to be sarcastic or passive-aggressive. If something is wrong, instead of being sarcastic, it’s better to say what you mean directly and openly (while staying calm and polite).

Try to be as precise and fact-based as possible, and avoid sweeping generalizations.

For the harder conversations—such as rejecting a PR—you can ask me to handle it myself.

Source (SQLModel guide): https://sqlmodel.tiangolo.com/management-tasks/#when-things-are-difficult

Introduction: Picking Fruit from the Orchard

There are fruit orchards you are allowed to enter, pick the fruit with your own hands, and, after paying the grower, take home the fruit you have hand-picked yourself. As far as I have learned, these are called U-Pick orchards. A few days ago, after a long period of staying home because of COVID, I got the chance to see one of these orchards up close. For me, someone for whom trees have always been a part of life, the experience carried a nostalgic feeling and reminded me of Bibalan.

You enter the orchard from the right side of the little cabin, and after picking fruit you leave from the left side. Naturally, the scale sits on the left side of the cabin, and the cash box is placed in the middle of the cabin, closer to the scale.

On the way in, you are handed a metal bucket—like the old water pails—to put your picked fruit in. Besides a metal handle, these buckets also have a metal hook designed for hanging them from a branch. When you enter, one of the orchard staff shows you how to detach the fruit from the tree in a way that causes the least harm to the tree. When we wanted to use a stepladder, another staff member came and explained the correct way to set it up! I wanted to tell them that I don’t need a stepladder or a ladder—if you’ll allow me, I’ll just climb the tree. It was a familiar experience!

Managing Service Capacity

Up to this point, as I said, our visit felt very familiar, and picking oranges was the closest thing that came to mind. On the way into the orchard, a kind, elderly woman on the staff guided us to grab buckets and head in. Since there were several of us, we told her that just one bucket would be enough and that we didn’t want to pick more than a single bucket of fruit. She smiled warmly and said: “Oh! Yes, I understand! But these buckets aren’t just for picking! We use them to count the number of people inside the orchard!”

I was stunned! Wow! What a clever idea! Managing the orchard’s admission capacity with buckets! What an amazing little lesson!

It reminded me that David J. Anderson, in the introduction to his book on Kanban, gave an example of the Imperial Gardens in Tokyo. He wrote that the museum staff use a simple yet effective Kanban system to manage visitors. On entry, they give each visitor a card (like a playing card or a student ID), and take it back on the way out. Whenever these cards ran out (the garden’s capacity was full), visitors had to wait behind the entrance gate until cards were returned. How wonderful!

Afterword

I think to myself that the world is full of things to learn! I can learn from any phenomenon and from anyone—even from a visit to a fruit orchard! I hope I am a talented student.

“Kanban is neither a software development methodology nor a project management approach.” — David J. Anderson