May 19, 2026

Friction Devices

After a 30-minute drive down a rough dirt road in a truck that felt too wide, we made it to a secluded lake...well it was called a lake, but it was maybe 15 feet at its deepest, and you could easily walk around it in 20 minutes or so. My family, my friend, and I were there to do some fishing, and we didn't realize we were in for the coolest fishing trip ever.

Shortly after setting up our campsite for the day, my dad hiked around to the North side of the lake to scout out good fishing spots. He called me over to come see something: a few logs floating together; it was the remains of a raft, probably from some Boy Scouts. The raft was definitely not usable, yet, but there were enough logs that it could fit a few teenagers.

Repairing the log raft in the water. After securing the first taut-line hitch on one end, I had to pull the twine over and under the logs and secure it with a final taut-line hitch.

We dug through the stuff we had in the truck under seats, in our packs, in little boxes and put together a small pile of twine and rope. Just enough to repair this little raft.

I didn't have enough rope to lash the logs like you're supposed to—but it's not like there was any danger of rapids or even large waves on this pond—so I instead tied taut-line hitches at the ends and wove the twine around the logs. The taut-line hitch is my favorite knot, because it anchors down really well, but you can also push or pull the knot to shorten or lengthen the line. That means if you have a rope with a taut-line hitch on both ends, you can continuously cinch or loosen without redoing the "lashing" in between. So if a log started to get loose, a quick pull would get it back into place, even on the water. (Obviously, don't do this on a real lake.)

After a couple hours of repairs, we were ready to launch our vessel to the open water. I shakily got on the raft, suddenly wondering if my knots would hold, put my fly fishing rod across these old logs, and used a long stick to push off from shore.

Pushing our raft through the lake with thinner, longer logs.

In a magical moment, the sun hit just the right angle and I could see all the way to the bottom of the shallow lake. Little fish swirled around me. It was surreal to be able to push my way around the water on a raft I had helped make and see the wildlife I would never be able to see from shore.

Knotty Technology

"A good knot has four virtues: It's easy to tie, it is stable (under load and through jerks), it reduces the strength of the line only a little, and it is easy to untie."
String: Tying It Up, Tying It Down, by Jan Adkins (1992), page 19

In the digital world, code is a knot. It's something that we rely on and expect to be stable. Businesses love to see code being written; we celebrate how many lines of code we have in our codebases, we laud AI for being able to write working code in minutes, we expect to see code supporting us all the way to the bank and back. But code is a liability. Code requires maintenance. Code is never perfect. Code built on code built on code built on code can get fragile.

If, as Adkins describes, a knot needs to reduce the strength of a [system] only a little, this implies that a knot always reduces the strength of its system (the line). Code is the exact same way in my experience. We can't do much without knots or code, but that doesn't mean that more knots and more code contribute to more strength of a system. If anything, the system is always reduced in strength as we add to it—developers just do their best to add code that doesn't reduce the strength beyond the needed capacity.

For example, if I'm coding a website, there are a lot of ways I can make it brittle and rigid: it could be hard to update content or the design; it could be fraught with exploitable bugs; it could disrespect or exploit visitor privacy; it could be inaccessible to people with disabilities. The more code I add, the more it might break down as updates are made or as I introduce one-offs and shortcuts.

Code also frequently fails the virtues of "easy to tie/untie." Removal of code is never celebrated in LinkedIn posts or news releases, and yet it's one of the most important things I can do. The more buried our code gets under other code or other processes, the harder it is to detangle and maintain. Eventually, we end up in the age-old conundrum of "we know it works, so we can't touch it."

Maintenance is critical to any system, and particularly coded systems, since we have moved so much of our most important daily functions to rely on code. While I was out on the lake, I was very grateful for my strategic choice of knot, because it allowed me to "make repairs" to my raft while I was in the middle of the water. However, these knots would not be the right choice in other situations, such as a river or a large body of water.

The problem is that right now, we keep rushing to make AI replace other more stable systems of code, whether by having AI write the code for us or by integrating it deeply where it may not actually be helping. It's like using the taut-line hitch to build a log raft that will carry people down the Colorado River—it's not a good choice for the context.

If we want good software—good meaning safe(r), reliable, useful, and consistent—then we have to start adding in some friction again, or our "knots" will become harmfully slippery.

Cyborg

"Knots are friction devices. The friction of turns and angles within a knot keeps it stable. Some knots use friction more efficiently than others, but every knot reduces the strength of the line it's tied in, as much as 60 percent for a poor knot."
String, page 19

It's ironic to think of friction as a virtue, because as a designer, I was taught to reduce friction as much as possible by always trying to reduce cognitive load, make communication optimized, make interfaces as simple as possible given the user needs and tasks. Developers similarly look to reduce friction by automating repetition, finding better/faster implementation techniques, and optimizing processes. Businesses always want to reduce friction: ship products faster, get more done with less resources, attract more.

AI is the supposed gold standard for removing friction by getting rid of jobs, getting more done, getting rid of that awful hard work of thinking through something. And yet, there is a massive convergence to the awful average right now. The ads I see seem to all say the same thing: "Use our AI so you can focus on what matters most." The software I use seems to shove that sparkly AI summary button into every corner of the interfaces. The code I write is more and more AI-generated.

What if we're all just getting stuck thinking that since we know the fancy taut-line hitch, it must work for everything? What kind of rafts are we actually building? Have we bothered to consider the security risks? Have we bothered to think through the right strategy before we click "Generate"? Do we have the expertise to make a good determination of what we are reviewing? Are we even reviewing what we push to the live site/product?

Friction means slowing down and it means things will be difficult. That is in direct conflict with the system of Capitalism that we've built and with the AI-easy-buttons we've integrated into everything. So, as AI tends to accelerate systems, is it actually the inefficient knot that drastically reduces the strength of the entire system?

Maybe getting rid of all of the friction was a short-sighted decision, and it's self-reinforcing, because now the friction is so much greater on the side of choosing to slow down. The longer we ride the seemingly smooth rut that AI carves out, the harder it will be to pull ourselves up and out of that rut. It's not too late to put some friction back into the system—through regulations and global cooperation. It's not too late to keep hold of and design more friction devices that can keep us grounded and stable.