Accidentally in Code

Engineers, we use a lot of words to talk about architecture, but at a fundamental level, I think architecture is about making good decisions easier, on a timeframe you can reason about.

→ Small startups can’t reason about a long timeframe, so architecture has limited ROI.
→ Banks have requirements around audit trails and – for trading systems – response times, that influence their architectural choices.
→ Open source projects are constrained in their choices by downstream users.
→ Large companies are usually constrained by long-term customers – Windows and backwards compatibility, for example.

Often architectural disagreements are less about the architecture itself, and more about what constitutes a reasonable decision. On what timeframe?

I have been working on a slide deck for the past few weeks. Using Claude Design, exporting things to PowerPoint, importing them into Google Slides, having Claude in Chrome clean up the little bits of positioning that mess up along the way. Keeping track of all the things that need to be fixed in Claude Code (where my todo list lives).

And it occurs to me that I have the same complaint now that I did years ago when I worked on the mobile app for Google Slides. A lack of proper API. Something to do with live editing had meant it made sense for everything to live in the JS layer.

Lately I think of that decision – I’m sure a reasonable one, made thoughtfully by smart people with the context and priorities they had – every time a Google Docs MCP is disappointing to me.

This, I think, is the challenge of the timeframe. The timeframe of that decision didn’t include the rise of phones and tablets and people doing real work on them – let alone MCPs.

In a startup, trying to get traction and survive, you are thinking about the immediate future, hoping that a long term will emerge. You need to be flexible, and stay flexible. Bad choices can bite you over time, but good choices can be too expensive to justify.

When we shipped the Twill replatform in 4 months, we got there by being strict about scope creep. Keep things simple. Don’t overcomplicate.

However, I did make a couple of architectural choices that were relatively expensive, but that I believe merited the effort. And that is because when we talk about making good decisions easier, and agentic development, there are some things that are really important.

The first was building a design system. It makes it easier to have rules around testing and accessibility, and ensures visual consistency.

The second one, more interesting, was a role-based access control (RBAC) model. This is something I was quite intense about, for a few reasons.

First, it’s a multi-user platform, so the same data gets viewed in different ways by different people. A member gets one view, a candidate another, a recruiter a third, etc. Being clear about who can see what is critical, and so the easier that is to reason about, the more it pays off.

Second, this is a place of churn as we figure things out. It was somewhere I thought it would be important to be able to add new types, and move things around – something that did indeed happen. I wanted it to be easy to add a new type, and one line in a table that means hasPermission() now returns true.

Third, this is a place where security considerations are front and centre, and having something tidy and easier to reason about makes those easier to enforce.

Neither of these choices would have been justifiable in a pre-agentic-development world. But in an agentic development environment, I have seen the impact in both. They are areas of high churn and potential complexity that have caused far fewer problems than you’d expect. As I noticed emergent architectural problems elsewhere, I added more work of this kind – for example moving the hand-written SQL to generated queries.

There is an argument here about how agents compress the timeline and follow patterns blindly. But I think the more interesting one is about what constitutes a reasonable decision for an agent. Humans have an unusually rich sense of time. We can relive the past and imagine our future selves – what psychologists call mental time travel – in a way few, if any, other animals can. Agents talk about time, but they don’t experience it.

Humans, we don’t just know what happened in the past; we viscerally feel the moment when the thing we could have prevented came to pass. And we care about what comes next, and the people who will live with what we build. The ability to reason about the future, and about what’s likely to change in it, is human, and as such a human responsibility.