That was enough to make computers feel magical. A computer was a place where you could make something from nothing if you learned the right incantations. As I got older, I became interested in authoring anything I could make on a computer: posters, crosswords, printouts, little documents that felt official because they had been produced by a machine.

If I created something particularly good, I would print it on my dad's ImageWriter II. The result invariably had the creative feel of an invoice, but I was still proud of it.

That early interest in using new technology to create things followed me into adulthood. It has probably defined more of my vocation than any single course, job, or framework.

The Security Era

To my dad's immense misfortune, one of my first technological interests was how data could be locked down and secured. At the time, "data" mostly meant my dad's work documents and spreadsheets.

If there was a way to set a password on something, I would try it. Throughout my childhood I protected, encrypted, or otherwise locked down almost anything that could be locked down. Since my dad used a serious computer for work, I sometimes tried these techniques on his work computer, occasionally during the most intense of his deadlines.

Thankfully, he has always been patient with me. But it must have been a relief when I eventually got a computer of my own.

The JavaScript.com Era

I have always had a strong curiosity about computers. I have gone down many rabbit holes that will never be useful, just to understand how things work. But there was always an underlying motivation: what could I build?

I cared about building because I loved showing people something they didn't know was possible, or something they hadn't thought of solving in a particular way. That habit has stayed with me. I have always had a decent awareness of developer tooling and the primitives you can use to take software from prototype to production. I tend to notice what is possible now, what's about to be possible, and what you can just about make work.

This created a long-running tendency to collect building blocks: tools, playbooks, platforms, techniques. I get excited about each issue of the Thoughtworks Technology Radar, new cloud services, and new applications of neural models.

But before this programming interest became "engineering", the building blocks I relied on most came from JavaScript.com. It had a large collection of snippets for various things: largely fun, mostly impractical pieces of code you could copy into your own web page to make it more interactive. They had Breakout, calendars, calculators, little toys, and many strange effects.

My older brothers knew what made me tick, so as a Christmas gift in the early 2000s they bestowed upon me my own domain name: frikki.com. "Frikki" is my Icelandic nickname, which I have had to drop in the Anglo world because of its unfortunate similarity to "freaky".

In my first real venture into interactivity and programming, I would diligently copy and translate code snippets from JavaScript.com to power the interactivity on my personal website, which I built in Microsoft Publisher 98.

The site had all the markings of a 13-year-old's website in 2002: a chat room, JavaScript games, links to my personal "award sites", cheat codes for SWAT 3, and dynamic forms for things too operationally important to simply go to email: guestbook, story competition, contact me.

The JavaScript games felt cutting edge in my circles. I did not understand much of the code, except where to find the strings I needed to translate into Icelandic and carefully encode as ISO-8859-1. But it didn't matter. I copied and pasted, and at the time that was frontier enough.

The Era of Defense

In the mid-2000s, the internet shifted from relatively innocent and underpowered into a more dynamic place with more interesting web services and a higher degree of danger.

At this stage I was doing most of my computing on Windows, and serious zero-day exploits seemed to arrive constantly. Malware was rampant, and many viruses were not caught by antivirus software.

This started a more serious interest in computer security. It was also the start of another information revolution: podcasts. In 2006, Steve Gibson and Leo Laporte started Security Now!, which helped me tremendously in my understanding of computers and security.

Steve would go into rich detail about exploits and how they used weaknesses in operating systems. But the episodes were also a great introduction to cryptography, randomness, VPNs, DoS attacks, NAT, Wi-Fi, and DRM. This was before YouTube was widely popular and years before I started college, so I owe much of my operating systems foundation to Steve and Leo.

But an even more significant personal shift toward defense was happening elsewhere. I had found my way to a very special chat community called Spinchat. It was not IRC, but a German proprietary chat protocol built by a few friends that seemed like they were into the Chaos Computer Club, with a web client written in Java.

The chatrooms were friendly and fun, and it was my first time meeting people from all over the world. People mostly talked about day-to-day things and had a laugh with each other. But it also became my first time working hard for a promotion and climbing the proverbial ladder.

There were two tiers of operators in Spinchat's chatrooms: temps and perms. Temps had a blue name and could kick people out of the chatroom while they were online, but lost the power when they went offline. Perms had a red name and always had their powers, including kicking and banning IPs.

Being a temp was shift work, assigned when a perm was too busy to watch the channel for people swearing or "cyber". You would usually do an honest shift until you went offline, but then you might not be needed for days.

I became very interested in the work. I got some kind of joy out of enforcement and maintaining a happy equilibrium in the channel. So when I was opped by a perm, I was on it. I was going to do the best job I could, because one day I would become a perm.

Being a temp had its problems. It affected my interest in leaving the house or joining family activities, since it was my time to shine. My family appreciated my enthusiasm for technology, but they did not fully grasp that becoming a respected member of a German internet community was worth some sacrifices.

There were great reasons to want to become a perm. One I cherished was the freedom of the lifestyle: I could come and go as I pleased, and if a friend wanted to hang out during my tour of duty, I could take a break and come back.

But an even stronger motivation was the ability to maintain order. You might expect that the worst internet crimes in the mid-2000s were swearing and cybersex. But there was a more sinister force in those early chatrooms: flooders.

Flooders would join a room and fill it with messages so nobody else could enjoy the chat. The most egregious ones were both lewd and loud. Their relentless work to destroy a good time gave me a sense of purpose, and eventually led me to programming.

The initial flooders were just fast at copy-pasting, but over time they adopted programmatic tools, or "bots". Since you could only IP-ban an online user, flooders would come back and leave the server quickly enough that they could not be banned. A flood wave started, filled a screen, and finished within a second. To many ops, they were uncatchable.

The people who built the chat service were German and rarely seen in the English chatrooms. I had grave concerns about the flooding situation, and one day I was lucky enough that someone introduced me to a Multi User Dungeon that served as the hangout for these lords of chat, mostly conversing in German.

Multi User Dungeons were the metaverse of the terminal age. You moved between rooms and chatted with people, with a map drawn in ASCII. If you were in the same room as someone else, you could talk. There were probably many secrets in those dungeons, but I don't think I went far beyond the lobby.

I pleaded with the owners about moderation on the international side of the web site (in contrast to the prudently moderated German one), and in particular about flooders. I had come across unsanctioned documentation for their proprietary protocol, and in my effort to see if I could build a bot I had some success using Telnet to connect to their servers, join rooms, and send messages. The protocol was terse and cryptic, and I had no real programming experience to build with it.

I don't know what led to it: my incessant pestering, the desire to empower someone to solve the problem, or the kindness of an experienced tinkerer helping a teenager take his first steps with programming. But one of the owners gave me a Perl socket library and a scaffold to connect to the servers and send and receive messages. That was enough to start a long road fighting flooders.

And thus began my first programming project: Thunder, a flood-fighting bot incarnated as a long spaghetti Perl script and later elevated with features like hugging and poking back, so it could behave reciprocally when someone typed /me pokes Thunder.

As it was, the war with the flooders was unwinnable. As our techniques got more advanced, so did theirs. Although the fight was adversarial, the stakes were low. Flooders were an annoyance, but nobody was harmed, and as determined as I felt about ensuring an uninterrupted chat experience, I never felt much animosity toward them. If anything, they were a good challenge.

When I eventually ended my Spinchat chapter in my later teenage years, what remained was a new love for programming.

Many early adopters of agents, including myself, have started to feel the urge to have many agents running in parallel and to always keep them occupied.

This is not a new desire at work — we all organize our work to happen efficiently. But now, the number of work items that can be happening in parallel is becoming practically unbounded.

On top of this comes an added burden of context-switching. Today, the experience involves agents coming back to you with results across many different applications — Claude, Cursor, Codex, and ChatGPT. Of course, you still have Slack, e-mail, and texts to attend to.

We are, of course, in the early days and on the leading edge, and right now the edge is sharp. But seeing where we're going should lead us to think about how we want things to be, so we can stop messy ways of working from lingering.

The risk is that we move fast on tasks at the cost of our judgement and perspective. That we become efficient but not effective, and robbed of our clarity and calm.

If we think about our future through the lenses of user experience and human-computer interface design, we are hopefully compelled to think beyond another conversational interface.

Instead, we would consider:

• cognitive aspects, like context switching
• psychological aspects, like need for achievement
• convenience aspects, like using a tablet with voice

Courtesy of Claude, here's a sketch of what such a workplace should look like:

• one tab to gain clarity — progress, plans, problems
• one tab for focused work — review, research, read
• one tab for conversation — with agents and humans
• one tab for fleet — to see how agents are progressing

This is a simplification of a complex problem. But it illustrates what I hope is the future — a workplace designed to be productive and enjoyable, designed from first principles.

Whether it will be a product like Slack or something that many companies evolve internally, the best productivity tool of the next decade is going to be the one that best preserves our energy and clarity.

You have three main ways to reduce the odds of bugs in a codebase:

• Document — write "don't do X" in dev docs or agent rules.
• Detect — add tests and lints to catch mistakes after they're written.
• Prevent — design interfaces to make wrong code impossible.

Prevention (or possibility reduction) is the principle that if you want to avoid a class of bug, you make that bug impossible to create. Testing does not achieve impossibility, because you can forget to write the test.

You can achieve this through different methods — strict typing, abstractions that make footguns private, even formal methods. The most basic example: if you have a switch-statement, it should be impossible to miss a case. Languages with rich type systems help a lot.

Agents, like humans, are prone to missing steps. They'll change a string in one place and forget to change it in another. But unlike humans, they don't know to be extra careful in the most critical parts of your code.

So I now try to ask these three questions for every agent bug:

1. Can I prevent this class of bug at compile time? If no…
2. Can I detect it at test time? If no…
3. Can I document it well, and detect it when it fails in production?

When you put it like that, it's pretty obvious which one you don't want. If you've spent time in incident postmortems and maintained systems over a long time, you're rehearsed in this thinking.

But one thing is changing: prevention was historically a lot more expensive than detection, but there are now many cases where that's no longer true, particularly because large-scale migrations to safer abstractions can be orchestrated by agents.

Some recent examples of things I've done to apply this in practice in Tumbric's evaluation and training codebase:

• Ideally Rust, (almost) never Bash. I'll use Python or TypeScript is if it's essential for the use case. Everything else is in Rust.
• Typed state machines for workflows. In event handlers, transitions to illegal states are prevented at compile time.
• Predicated events. The API for processing events forces events, at the type level, to declare the state they were predicated on, so version conflicts can be detected systematically.

// transition accepts any string
type Run = { status: string };

function transition(
  run: Run,
  to: string
): Run {
  return { ...run, status: to };
}

transition({ status: 'pending' }, 'executing');  // OK
transition({ status: 'pending' }, 'completed');  // compiles, bug ships

// destination comes from the current status
const next = {
  pending:   ['executing'],
  executing: ['completed', 'failed'],
  completed: [],
  failed:    ['pending'],
} as const;

type Status = keyof typeof next;
type Next<From extends Status> =
  (typeof next)[From][number];

function transition<From extends Status>(
  run: { status: From },
  to: Next<From>
) {
  return { ...run, status: to };
}

transition({ status: 'pending' }, 'executing');  // OK
transition({ status: 'pending' }, 'completed');  // compile error

The kind of serious investment I used to put into the reliability of payments systems is now something I'm putting into a "casual" internal system to track training runs. That's because the cost of adding strictness is now very low, the added friction is imperceptible, and the benefits are enduring.

It doesn't matter how fast the agent can code. We can't move fast without safety. So simplifying systems, adding strictness, and making error states impossible is a core human engineering activity in a world where agents do more of the implementation work.

It's never been a good use of developer time to study SaaS APIs. Field-level API details of a third-party product are a small and unleveraged part of an engineer's job, and this is becoming much truer with coding agents.

I regularly ask agents to integrate with SaaS tools. The agent flails for 30 minutes, hits some 500 errors, and gives up eventually because it needs information that's only available through the UI. I switch to a simpler product (often one with a good llms.txt), and integration takes 5 minutes with an agent.

The reality is that if you're building devtools, polished SDKs and beautiful UIs are becoming secondary interfaces and you're now an API company.

What this means:

• If there's a button in your console, it needs to be an API operation.
• If your product ingests or produces data, there needs to be an API to export it.
• If you're seeing people hit edge cases in Sentry, expect 10x more in 6 months.

Your primary DX surface is now for agents. The good news is that you can literally just run a test suite against it. And if you do it well, you can ease up on pixel-perfect and concise docs — developers will probably just ask Claude about your product anyway.

Mass adoption of coding agents is still early but things are moving fast. So now's a great time to become the best product for agents in your space.