Will cheaper code make us less attached?

Hal Shin wanted his recording software to help him remember what he had just said. In an October 2026 video, he describes building a feature that played back the previous good take. About three weeks into the project, he realized that seeing a live transcript of that take would have met the need. Other features had consumed time, and the playback feature was broken when he demonstrated it. The experience had taught him something quite specific about the tool he actually wanted. ¹

That is an appealing account of personal software because the goal is so ordinary. You finish one take, start another, and need to recover your place. It is also easy to imagine how the project grows around that moment, acquiring screens, options and promising side features, each giving its maker another small accomplishment. By the time the original problem becomes clearer, the application may contain a great deal that already feels worth keeping. What makes it possible to let some of it go? ¹

Nate Jones’s November 6, 2026 essay approaches that question through his interview with OpenAI’s Vijaye Raji. Raji advises against becoming attached to code, and Jones describes cheaper implementation as an opportunity to explore and discard more approaches. Jones also warns that a polished prototype can make an untested idea feel ready to ship. His proposed standard is what the attempt teaches about the customer’s problem. This is a practitioner argument about how to work, supported by an interview. ²

An older consumer-psychology experiment complicates the assumption that attachment will fall as making gets easier. In the final journal article on the IKEA effect, Michael Norton, Daniel Mochon and Dan Ariely asked 52 university participants either to assemble a plain storage box or inspect an assembled one. Those who built the box bid more to keep it and reported liking it more. The comparison used the same box design. The experience of making one contributed something to its perceived value. ³

Completion mattered too. In another experiment, 39 university participants either finished assembling a box or were stopped before the last two steps. The people who finished offered higher bids. The unfinished group had the remaining pieces and could have completed the task after buying the box. The authors interpreted this as evidence that successful completion helped connect effort with valuation. In their account, labor mattered partly because it ended with a completed object. ³

Those findings leave an interesting uncertainty for AI-assisted work. An agent may reduce the effort needed to produce a functioning prototype while preserving the satisfying moment when an idea becomes something you can use. Could that moment sustain attachment even when the code was cheap? That is a hypothesis prompted by the readings. The experiments examined physical objects and willingness to pay among university participants. They do not establish how people value software built with an agent, or whether less effort would strengthen or weaken the effect. ^{2, 3}

Shin’s example suggests a useful way to think about that uncertainty. The underlying need stayed recognizable while his preferred way of meeting it changed. He could carry his understanding of what helped him recover his place into a smaller application. If he dropped the playback feature, the lesson would travel with him. For someone building personal tools, this offers another place to locate the satisfaction of finishing, in being able to explain the need more precisely, with an experience that shows why the explanation changed. ^{1, 2}

The same question travels into marketing research. Imagine a team showing customers a prototype that its members have spent weeks refining. A positive reaction could reflect useful fit, the appeal of the presentation, or the way the demonstration frames the task. The IKEA study gives a reason to examine the makers’ own valuation as well. Their enthusiasm is part of the situation the researcher needs to understand. A working artifact makes an idea easier to discuss, while also giving its advocates something tangible to defend. ^{1, 2, 3}

If the prototype disappeared tomorrow, what would you know that you did not know before building it? Perhaps which task matters, which assumption failed, or why a much smaller feature would be enough. Being able to name that learning gives an experiment value that survives its implementation. As making becomes easier, that may be a more revealing question than whether we can afford one more version. ^{1, 2, 3}