Staying in the flow: some updates on my experience
Salvatore Sanfilippo on agent latency, progress updates, and staying involved in design
Salvatore Sanfilippo describes retaining creative involvement through detailed product decisions, asking agents to announce significant steps, and using observed display behavior to steer changes. He distinguishes reducing idle time with parallel projects from preserving flow, and cautions against making automation more stressful. Personal experience and advice, not measured productivity findings; summarized in English from Italian auto-generated captions.
Salvatore Sanfilippo argues that delegating implementation need not remove the pleasure of programming: choosing behavior and seeing its effects can still be absorbing. In his experience, the main interruption is waiting for the agent between those decisions. He describes ways to stay involved without turning every pause into another concurrent project. 04:59–09:03(opens in a new tab), 10:05–11:38(opens in a new tab)
This summary is translated and paraphrased from Italian auto-generated captions. The original audio was not independently checked. The talk offers personal experience, recommendations, and expectations—not measured effects on productivity or developer well-being.
Main points
- Less drudgery can coexist with less enjoyment. Sanfilippo recalls the strain of holding a large unfinished implementation in his head and investigating bugs that appear only intermittently. He says some developers he knows welcome the relief agents provide, while he misses the immediate loop of making changes and seeing their effects. His concern is recovering that involvement, not returning to every difficult manual task. 00:00–03:57(opens in a new tab)
- Stay involved through concrete design decisions. Working on an emulator, he specifies an on-screen keyboard's transparency, activation buttons, remembered position, and joystick switching. These choices draw on his preferences for interaction and his knowledge of the hardware. He finds this design role engaging even when the agent writes the implementation; his example does not establish a permanent limit on what models can design. 04:59–06:03(opens in a new tab)
- Agent waiting time breaks the feedback loop. After describing a change, he may have to wait several minutes before inspecting its result. He expects faster models to help restore continuous iteration where compilation and device updates are already quick. During longer waits, he sometimes writes prose, such as a book preface; he says switching to that very different activity is manageable for him. This is a personal coping strategy, not evidence that context switching has no cost. 06:03–09:03(opens in a new tab)
- Ask for significant-step updates so you can steer before the end. Rather than let the agent work silently until its final response, he asks it to announce meaningful steps, accepting the extra token use. Knowing its direction helps him stay engaged and correct a misunderstanding while work is underway. For the emulator, he also reports visible flickering and suggests possible communication problems for the agent to investigate; the observation guides debugging but does not by itself confirm the cause. 09:03–10:05(opens in a new tab), 10:05–11:08(opens in a new tab)
- Filling every pause is different from preserving flow. He acknowledges that running several projects in separate sessions can eliminate idle time, but argues that switching projects interrupts sustained attention and may increase stress. He also suggests writing code by hand for learning or enjoyment. His closing preference is to let automation create breathing room rather than automatically convert every saved minute into more work. 10:05–11:38(opens in a new tab)