At 25 minutes, the timer does not make a polite sound.

An arm drops onto the MacBook and physically closes it.1

Lewis Menelaws started with a simple complaint: productivity apps are easy to ignore. A notification can be dismissed. A timer can be delayed by one minute. A website blocker can be disabled by the same person who installed it with tremendous moral confidence half an hour earlier.

Lewis, who says he has ADHD, built an intentionally absurd experiment around two systems that make procrastination harder to ignore.1

One can affect his reputation. The other can affect his computer.

The useful part starts when both can trigger the same physical consequence.

The first robot was too polite

Around 4:19 in the video, Lewis shows the first physical prototype.1

It is simple: a servo, a 3D-printed arm and an ESP32. Every 25 minutes, the servo lowers the arm onto the laptop lid.1

It works.

It is also useless for his intended constraint.

Lewis can stop the arm with one finger. A servo applies a programmed, predictable push that is easy to resist. The robot behaves less like an enforced break and more like somebody tapping your shoulder to gently mention that perhaps enough tabs have been opened today.1

So the first prototype goes on the shelf.

That failure clarifies the actual design problem. Closing a laptop is trivial. Creating an event Lewis cannot renegotiate in the moment is not.

Version two stores energy instead of pushing with a motor

At roughly 5:50, the mechanism changes.1

The new arm is held upright under spring tension. A 12-volt solenoid holds the latch. When the timer reaches zero, the solenoid releases it and the spring drives the arm down.1

Lewis adds foam to the contact surface and tests different springs. Too weak and the mechanism remains easy to resist. Too strong and the productivity experiment becomes an Apple repair experiment instead.1

Spring choice becomes the real tuning parameter.

The robot still uses an ESP32, connects over Wi-Fi and listens to a webhook. Software elsewhere can trigger the mechanism remotely.1

Lewis happens to have exactly that software.

The second robot has no body

Earlier in the video, Lewis describes a script watching the active window, idle time and selected domains during a focus block.1

If it decides he has been procrastinating for long enough, it can publish a prewritten message to a real social account without a confirmation dialog.1

The point is to attach a cost that cannot be quietly dismissed.

That is also where the build becomes relevant to agents and automation more generally.

Lewis notes that an ordinary software bug may produce an error page. A false positive here can publish something publicly and trigger a physical mechanism.1

Software failure suddenly has a very literal blast radius.

He adds logging and observability before connecting the script to his real account. Part of this sequence is sponsored by Sentry, so the product demonstration deserves normal commercial skepticism. The design principle survives without the sponsor: the more power an automation receives, the more important it becomes to reconstruct why it acted.

Then the system does exactly what it was told

Lewis reports using both pieces together for one day.1

The 25-minute breaks become difficult to ignore. The system also ends up interrupting him during a video call.1

That failure makes the experiment better.

The automation had not necessarily malfunctioned. It was applying a rigid definition of acceptable work to a context its rule did not understand.1

An automated system can be perfectly correct according to its rule and completely wrong according to the person living through the result.

Coding agents have the same failure mode. The danger is not only that a system ignores an instruction. Sometimes it follows an incomplete instruction extremely well.

Lewis eventually criticizes the machine he just built

Around 8:28, the video changes tone.1

Lewis questions whether becoming productive because he is afraid of his own desk is actually desirable. He explicitly frames the build as entertainment and asks whether differences in how his brain works should really be treated as something deserving punishment.1

That boundary matters.

The video does not show that a spring-loaded robot treats ADHD. It is not even a meaningful efficacy study: one person, one day, and a machine built partly because the idea makes a good video.

Its value is elsewhere.

Lewis makes a hidden trade-off physical: every effective constraint has a cost when it is wrong.

A notification is easy to dismiss because the consequence is tiny. A mechanical arm is hard to dismiss precisely because it acts in the world.

Between those extremes is a design decision about how much authority a system should have.

The most useful robot in the experiment may therefore not be the one that closes the MacBook.

It is the one that makes it impossible to forget that once automation gets a body or a connected account, it also needs a very good way to decide when to do nothing.