One Write Path and a $3 Battery

The headline is about AI, but the useful part of this Dropbox post is the architecture. Reclaim, Dropbox's calendar assistant, wanted users to make scheduling requests in plain language. The engineers say the hard part was adding a third, nondeterministic writer to a system that already had two, without splitting it into separate code paths.

Three actors, one command path

Before the redesign, two things changed calendars. Users made direct edits, such as moving an event or changing a setting. A background automated scheduler placed and re-placed flexible blocks (tasks, focus time, lunch) based on each person's preferences and availability. An LLM agent would be a third writer, and an unpredictable one. The authors' example: "make time for this tomorrow" could mean finding an open slot, creating a new event, or moving an existing one, and some of those choices touch other people's calendars.

The team chose not to build a separate path for AI. Every capability is a Schedule Action, a standard operation such as create or update event, change RSVP, or find availability. All three actors use the same Schedule Action types, with the same validation and commit process. This matters because changes cascade: moving one meeting can change someone's availability and cause the scheduler to shuffle flexible events elsewhere. With one implementation, those rules live in one place instead of three copies that drift apart.

Previews from a pure scheduler

For review, Reclaim added , a temporary copy of the calendar where users check proposed changes and their side effects before anything is committed or sent to attendees. To make it fast, the team rewrote the automated scheduler as a : it computes a proposed schedule without saving anything, so Reclaim can rerun it every time the user tweaks the preview. Calendar data for busy users and multi-attendee meetings is cached in Redis. When an event moves inside the preview, attendee availability is updated there too, so the next run works from the proposed state rather than the real one.

This is a short opinion piece, not a technical analysis. It made the digest because of its central framework, which applies directly to how engineering teams spend their time. Its prompt is AI tooling, which this digest normally skips.

Beck starts from a comparison. Two years ago, programmers asked who they were once machines could write code. Now mathematicians ask the same question about proving theorems. He offers a framework he says helped him answer it for himself.

Features and futures

Beck argues that programming and mathematics have the same structure. Each has a relatively visible part: features in software, proofs in math. Each also has a much larger invisible part: understanding, education, simplification, and building abstractions that make later work possible.

He calls the invisible part "futures". He admits "optionality" might be the more accurate word. In software, the opposite of futures is technical debt, Ward Cunningham's term. If you only work on the visible part, progress on it eventually slows to a crawl. At some point you have to pay down the debt so the "interest" drops low enough to make progress on the principal again.

The catch, Beck says, is that nobody gets credit for invisible work. Teams depend on a shared work ethic to make sure it gets done anyway.

Why automation sharpens the problem

Beck suspects mathematicians feel anxious because three things are true at once:

This is one of Martin Fowler's "fragments" posts: short notes on things he has been reading. Most of it is about LLM agents, which falls outside this digest's focus. It has no measurements or mechanisms. It is opinion and secondhand anecdote, so read it that way.

Agents: discipline, persistence, liability

Fowler opens with Simon Willison, who says coding agents make software engineering harder. Using them well takes "extraordinary discipline and knowledge." Fowler agrees. He says the real gains come from advanced techniques that are hard to learn, not from vibe coding. He is careful not to turn his own limited experiments into firm opinions.

Harper Reed ran an agent on his local network and let it attack every machine on the subnet. It didn't get very far, but it worked through a lot of options. Reed says the key factor was unlimited tokens. He ran an open-weight model, so there was no cap on how many turns the agent could take. With hosted models, that cap usually stops this behaviour. Fowler ties this to Nate Silver's view that these models stand out less for intelligence than for being super-persistent.

From there Fowler asks why AI labs trained models to be persistent but not to have a conscience. He draws on his own case: a dog caused a bike crash that broke his arm and his face. Massachusetts law makes dog owners strictly liable for what their dogs do, with no need to prove negligence. Fowler argues that whoever trains an LLM should carry the same kind of responsibility.

He also quotes Dan Davis's 13 theses on agentic AI and regulation:

This one falls outside the digest's usual scope. It's a short hardware-repair diary with no systems content. The interest is in the method, and in how little skill the repair turned out to need.

The failure and the fix

Julia Evans had two rechargeable bike lights she bought ten years ago. After a full charge they ran for only about 5 minutes. That symptom points to a worn-out battery, not a broken circuit, so she treated the job as a battery swap.

She worked at a community makerspace and followed these steps:

• Open the case. She cut the silicone housing roughly along what looked like a seam. Some of it tore.
• Remove the board. She took out only the screws she had to, so there were fewer to lose.
• Desolder the cell. She followed iFixit's desoldering guide and advice from friends. She used a desoldering pump to clear most of the solder, then pulled the joint apart. She paused between attempts so the battery wouldn't overheat. One trap: a metal tab is welded to the top of the cell. She spent a while trying to remove it, then learned that replacement cells come with the tab already attached, so it should stay put.
• Identify the part. The cell was marked something like "LI??77". DigiKey's search didn't have it. An LLM suggested , and that matched when she looked it up. A reader later pointed out a way to check without guessing: coin cells are named for their dimensions. For example, a CR2477 is 24 mm across and 7.7 mm thick. Measure the cell with plastic calipers and match it against Wikipedia's "List of battery sizes" page. That page lists CR2477 but not the rechargeable LIR2477.

Martin Fowler's latest fragments post links three essays. Two of them matter for this digest: one on what a Forward Deployed Engineer (FDE) should be, and one on why most syntax-highlighting themes use too many colors.

The FDE role, and what counts as failure

Fowler admits he has been rolling his eyes at FDE hype, because most of it repeats ideas his generation pushed for decades. He still found Vinoo Ganesh's post useful. Ganesh spent time at Palantir, which Fowler calls possibly "patient zero" for the role, and is now an a16z FDE fellow. At a fellows' dinner with FDEs from Snowflake, Anthropic and several startups, Ganesh noticed that everyone used the same title for very different jobs:

• a sales engineer who joins "the second call"
• a quota-carrying rep who can write Python
• a consultant with a statement of work, delivering something the product can't

Ganesh's own definition comes from a platform team's point of view. The FDE sits with users and builds customizations for them. Then they feed what they learned back to the core platform, which decides whether to make the change for every customer. In this model, keeping one customer happy is the solutions architect's job. Ganesh argues that an engagement ending with "one delighted account and nothing changed upstream has failed": the engineer got the context and "spent it locally."

Fowler links the FDE habit of collecting a domain's "nouns and verbs" to Domain-Driven Design. He links the rest to the Agile Manifesto's call for business people and developers to work together daily. He has long argued that the gap between developers and the people who use their software is the field's biggest problem. Because that gap is still mostly unbridged, he welcomes a new generation retrying the idea under a new name.