In 1890, Poincaré proved that three bodies under a single force have no closed-form solution. The orbits are chaotic: nudge a starting velocity and the system ends up somewhere else. Gravity is the polite case. One force, always attractive, symmetric, one parameter per body. A software team is not under one force. Ego, ambition, incentives, fear, trust, and the educational distance between a PhD and a bootcamp graduate. These forces are asymmetric, they change sign, they are not conservative, and they interact with each other. Then Conway's law closes the loop: the system you ship copies the communication structure that built it. The chaotic trajectory of the human n-body system is not the backdrop to your architecture. It is the compiler. The counting, for a team of 12: 66 pairwise channels (Brooks), 396 if each pair carries six forces, and 4,083 possible coalitions. The coalitions decide what ships, and nobody has them on a chart. Physics never solved the n-body problem either. It learned to shape it: hierarchical configurations (tight inner pair, far third body), fewer bodies, fewer forces crossing a boundary, and interfaces that carry the coordination so the far body never needs the meeting. That last one is where API design and org design turn out to be the same discipline. Full argument, with the graphs: apilama.com/2026/10/26/conwa…

Three bodies, one force: chaotic (Poincaré, 1890). A team of 12: 66 pairs × 6 forces, 4,083 possible coalitions. Conway's law compiles that graph into your architecture. You don't solve n-body. You shape the initial conditions

Teams don't slow down because people get slower. They slow down because work starts waiting: for a review, a decision, an owner. AI makes the doing faster. The waiting stays exactly where it was.

Most AI agent demos break at the same point: the second hour of production traffic. Not the model. The retries, timeouts and state nobody designed for.

The job most at risk from AI isn't the junior engineer. It's the manager whose main output is status updates. Agree or disagree?

On Friday I asked why Greek engineers scale everywhere, but Greek tech companies rarely do. Few of you picked capital. Most said distribution or ambition. Others added things I hadn't listed: culture, regulation, a small home market, and "why leave a good role at a growing company?" The last one gets talked about the least. Which would you fix first? A) distribution B) ambition C) the safe-job pull

This week's network failures in one Google Cloud region in London took a bank's app and cards offline across Europe for hours. Regions fail. That part isn't news. Going hours without a real update is the part users remember.

An API key used to mean "this service may call that endpoint." Hand it to an agent and it means "may do anything that endpoint allows, at machine speed, with nobody watching." Same string, very different blast radius. How do you scope agent credentials? A) one key per agent B) short-lived tokens C) human approval for writes

Looking to talk with engineers who've actually trained models with RL: Prime Intellect environments, verifiers, GRPO/PPO runs, reward design. Not a job post (yet). I want to hear what broke in practice. Reply or DM me. What was the hardest part: rewards, infra, or evals?

I found new ways to use @bot, and I love it, but now, in a day, I spend my weekly balance, which, up until now, I was heavily using, was never even close.

20 years ago I was at FOSDEM watching Linux vs Microsoft like it was a holy war. Then I started the API meetup. Then the cloud computing meetup (now the AWS community group in Athens). Now I'm launching two new meetups. I had forgotten how much work this is. I had also forgotten how much I love it. Selective memory: enabled 🙃

Not every task needs a frontier model in someone else's data center. Small open models now run on a laptop, and some on a Raspberry Pi. For a lot of daily work that's enough, and the data never leaves the machine.

Ran the same agent outcome two ways. Through MCP for every step vs plain REST with a thin discovery layer. REST was about 40x cheaper for the same result. MCP still won on discoverability. Where do you draw the line for agent-facing APIs? A) MCP everywhere B) REST + thin MCP C) REST only

Your next API consumer won't read the docs. It's a model reading your schema at runtime, with nobody to ask. "Bad Request" tells it nothing. A clear field description and an error that says what to fix do more than any SDK.

I wanted to give my team a Ferrari. Turns out you also need gas. Pooled AI tokens are the new budget line. Let everyone default to the strongest model and the whole month's allowance can burn out early. Someone has to own how the team spends them. How do you handle it? A) Hard caps per person B) Cheap model by default, strong model on request C) No limits, just watch the bill

Greek engineers are everywhere in global tech teams. Greek tech companies at global scale, far fewer. Talent isn't the gap. What is? A) capital B) ambition C) distribution

For the first time, I managed to use all of my @GeminiApp tokens. Finally!

Getting the Christmas 🎁 market ready for Athens

Check out my run on Strava: strava.app.link/DER6b1Je86b

Today I ran one of the most dangerous terminal commands I've ever had to run, and I couldn't have done it without LLMs and @warpdotdev's help. On my Mac, I had done a partition on Fedora, but I wasn't using Fedora much lately, and my Mac was continuously running out of disk. After a week of this trouble repeating itself, I decided to delete Fedora. I wanted to delete the Fedora partition and reclaim that space on my Mac while macOS was running a big task. With Warp Terminal, it went smoothly: it deleted everything step by step, cleaned it up, and reclaimed the space on my Mac without even needing to reboot. A few years ago, I wouldn't even do that through a terminal. Wow, impressed.