Sawing, coding, prompting — part 1 of 3
I open my notebook and write my thoughts — what I think about a book I read yesterday, a reflection upon a conversation I had recently, a spark of curiosity that sends me down a rabbit hole. Then I write down what I plan to do that day, which tasks elicit resistance and which elicit excitement. Close the notebook — turn on my computer — spin up the AI agent.
I have an idea for how I want to tackle a work problem, and I want to bounce some ideas around. I first write a description of it in words; then I doodle a rough sketch of an algorithm in my notebook. I want to see if it's feasible and what the different ways of doing it are. I also want to know if I'm missing something. I ask the AI, are there blind spots in my reasoning? That's the nature of blind spots; one is, by definition, unaware of them. To see what I can’t see, I need to expose that thinking to another "pair of eyes." I could ask a colleague… but bringing them up to speed on the context takes too long and they have their own stuff to deal with anyway. The AI is, for better or worse, always available and doesn’t seem to get tired of me. I'll reserve that colleague chat for when I hit a wall; a real other mind is better at catching the stuff I can't even imagine asking.
The AI tells me to consider adding a third step to the algorithm. I get my notebook again and draw a new sketch of the algorithm with the suggested architecture, and add a few notes on what that gives me that the previous design didn’t. Sure, it does seem better. It’s clear to me now. This third step also reminds me of something else, back from my biology days, and I have a back and forth with the AI about whether incorporating an element of a genetic algorithm makes sense here. It says yes, and I’m glad. Then I write a lengthy, detailed prompt of what I want it to build, how, and what the end result should look like. I give it some criteria for "success" and "done." I ask: "Do you need any clarifications from me?" Then I hit enter.
The AI sets off to do its thing. I switch windows, start writing a report I want to deliver at the end of a long project. I go back some fifteen minutes later to check the status. It’s done with what I asked it to do, and I check if it has done a good job. I pass a file it is supposed to process in a certain way, but the output isn’t great. I know what needs fixing, and give the agent a new prompt describing the output better, giving it some suggestions of the intermediary steps in processing the data, and hit enter. Same thing, I go back to writing that report. The agent eventually builds the algorithm for me within a few iterations of this back and forth, me refining its work conceptually and letting it do the implementation, until the output looks good enough for the moment. Further improvements will have to wait until I get feedback from a colleague who will use it.
Parallels — and their absence
In his essay “Walking the plank: meditations on a process of skill”, Tim Ingold reflects on technical skill and tool use. As I am reading it, I am contemplating the parallels between his example of technical skill and tool use — the sawing of a wood plank — to the technical skill and tool use I myself employ at my job as a data scientist in pharmacovigilance. I have been lately very interested in the topic of skill, performance, and deskilling, as the promise — or, to others, the threat — of AI automation hovers over every knowledge worker’s field.
Ingold says that tool use in the process of employing a technical skill, like that of an artisan or craftsman, has a processional quality. Processional, from procession — walking in ceremonious manner — as against successional, discrete steps in a sequence. Sawing a plank has a beginning and an end, and phases in between. He distinguishes the phases of getting ready, setting out, carrying on, and finishing off. But when does sawing begin? When does building an algorithm begin? [1] And when does it end? Only once a phase is done do we know it is done, the same with a project as a whole. The phases, he says, are not sharply demarcated and one does not reach clear milestones — only hindsight can see them.
Getting ready
For instance, do I start building the algorithm when I sit in front of the computer and start to code (or, lately, prompt an AI agent)? Or does it start when I am doodling my conception of it in my notebook? Maybe it starts when I have the first idea spark for how to even think about it and go grab both a pencil and notebook. This is the getting ready phase, and it involves, as anthropologist Charles Keller says, an umbrella plan, “an idiosyncratic constellation – peculiar to each practitioner – of stylistic, functional, procedural and economic considerations assembled specifically for the task at hand” (Keller 2001: 35). In my case, that involves my notebook, my four-colored bic pen, my computer, my subscription to Claude, a whiteboard, some markers — and non-trivially, me. Significantly, the plan guides rather than determines: everything is erasable, changeable, moveable, the plan does not commit me — or the carpenter — irrevocably to anything.
Setting out
Until now the parallel holds well between sawing a plank and making an algorithm. But once the plans are all laid out, there is a moment when the carpenter makes a first nick in the plank, after which there is no turning back. This is the setting out phase. He references the classical scholar Jean-Pierre Vernant saying that the artisan must seize the kairos (Greek word meaning 'the exact or critical time'), when conditions are ripe to set out with their work and movement is only forward, otherwise the moment passes and the work is spoiled. But the same does not hold for me. I have no kairos. The nature of the medium in which I work — code in a computer — is endlessly malleable [2]: I can write and delete and move around chunks as much as I want, especially in the beginning (once a structure is built, the shuffling becomes more difficult, but not impossible). It’s all reversible, which means there is no risk. There is no clear moment after which an initial piece of code commits me to the next bit, unlike the nick in the plank, which, once made, commits the carpenter to either continuing there or, if made incorrectly, incorporating the nick as a design element some other way. I can make a zillion false starts and begin again. Planks don’t grow back into one uncut piece; code does.
However, there’s a stranger difference between me writing code and me operating an AI agent that Ingold, writing in 2011, has no frame for, one irreversibility hiding in an unsuspected place. If I am operating the AI agent, I see its plan, and I can’t unsee it. Ingold’s carpenter can erase the line made on the plank, but I cannot erase from my memory the knowledge that the AI suggested a 3 phase architecture; the indelible mark now lives in biological material rather than cellulose.
It is in the concentration with which the carpenter makes the initial strokes that the split appears between me writing code and me using an AI agent; a split between a road where there is a correlate and another where there isn’t one: if I am writing it, I need to pay close attention to what it is I am writing, whereas if I am delegating the task to an AI agent, I am in fact waiting — an interval of time in which I am “free” to do something else. Ingold, in a section further in the chapter, makes the distinction between the craftsman and the machine operator. In the first case, I am more like a craftsman; in the second, I am a machine operator. This is a distinction with interesting implications, which I will come back to in more detail in a later essay.
Carrying on
In the carrying on phase, Ingold says the carpenter starts working with the instruments and materials, as opposed to the setting out phase, in which it seems that the wood is “resisting” the cut and the carpenter has to work against it. It is the most relaxed phase, and later in the chapter he argues that it is also a phase of high concentration — contrary to common belief that the manual laborer gets “into a flow” where they’re physically present but mentally disengaged. This is a point where there is a split between writing the code and delegating it to the AI agent: whereas in the former I am also relaxed yet concentrated and engaged, thinking of what needs to come next, in the latter case I am, again, waiting, and the wait is not relaxing but somewhat expectant. It is uncanny that the work continues elsewhere, and I am not in it. It is, in effect, a gap.
Actually, the boundary between setting out and carrying on, however fuzzy in the first case, gets completely abolished in the second, at least for me (how it is in fact for the agent is something I won’t speculate about here). I am a supervisor, not an executor. The AI agent returns something finished, I make the judgment of whether that is good enough or not. If it is, I call it finished, and looking back I cannot tell the boundary between carrying on and finishing off either; the AI did it all. If I judge it is not good enough, then I will give it another prompt, set it off to write another chunk of code while I wait, and repeat the judgment once it is done. So, we can say that an important distinction between employing of the coding skill in the task and operating an AI agent that performs the task is that for me, in relationship to the task, there are no boundaries except that between the umbrella plan and everything else. For the AI agent operator, there is only the umbrella plan.
While carrying on the sawing, the carpenter is constantly adjusting the saw, the plank, his body, his strokes, checking whether they follow the line, whether the cut is smooth, whether it fits with another piece it might be a part of. In the case of coding, I am also constantly adjusting — I am checking whether this block of code does what it’s supposed to do (which means I have an idea of the output it should give, meaning, I need to have some expertise), whether it works with the previous block, etc. But when the AI agent is carrying on, I am waiting.
This also brings to light another difference between sawing a plank and coding, on the one hand, and operating an AI agent, on the other. The former involves a much closer, continuous adjustment of the process, mediated by perception — the artisan senses the plank, the friction of the grain, adjusts their hands and body accordingly. But the AI agent operator corrects at discrete intervals, in bursts, in an on-off rhythm out of sync with the agent’s, interspersed with the wait.
Finishing off
According to Ingold, it is commonly believed that finishing off happens when the material at hand resembles what the artisan had in mind. But he contests that it is not a similarity to this mental image that governs the decision to finish off, but a host of other judgments such as what the material can still take, whether previous flaws have been corrected, accepted or incorporated — such that the artisan needs again to shift focus to these finer aspects of the work and exercise their discernment in what counts as being done. The speed of the work slows down until a definite decision to stop is made. The parallels here between manual work on the one hand, and coding myself versus using the AI agent on the other, have less to do with speed. In both cases of coding, finishing off is less of a slowing down; it is instead a series of tests. Does the unit made behave as I intended — does it give me the output I need? The difference is that, in the first case, I did the writing, in the second case, the agent did it. For the artisan, I imagine there is also a battery of tests the object needs to pass — is the cut straight? Smooth? Is the plank of the shape I intended? Does it fit another structure it is supposed to be a part of? As an artisan, a coder, or an AI agent operator, I must exercise judgment, discrimination, and connoisseurship.
Another aspect of finishing off is that movement always overshoots its destinations, that every ending is already a beginning. For the artisan, an element of finishing off is to place things — tools, materials, support — back where they should be. This also happens to be the preparation for a new setting out phase: putting things back where they belong enables the artisan to begin again the next labor. When I finish off, however, I write what I or the AI agent did, and some ideas of where to go next: do I need something else built? Do I need to improve what was built? What would the first next step be? In this sense, my finishing off is a cognitive accounting and mapping out of new task territory, the movement that overshoots is cognitive. The artisan may well also have such a system too, although I suspect it is less often externalized in a notebook than held as a plan living in the body.
Thinking about where the parallels between manual and knowledge labor hold and where they break is instructive because it gives us a frame for thinking by analogy. If a knowledge skill can be understood as subject to similar forces and figure in similar processes, then we have a richer set of cognitive models to understand our own work. What happens to the sawing skills of a carpenter who switches from a manual saw to a rotary saw? What happens to their body, their muscles, their dextrous gestures? What happens to their judgment of what counts as a good cut, a beautiful plank, a job done? The switch between coding and operating an AI agent entails questions not so different from those of the carpenter, and perhaps similar answers.
Notes
1. The thing I am building is, in David Pye’s terms, precisely an algorithm, a small instrument of the workmanship of certainty, a thing designed to run the same way every time without anyone attending to it — which makes the question of whether it is skillfully built a somewhat strange one..
2. Not endlessly malleable in an absolute sense, code in a computer is linear, sequential, and can produce a very limited number of “artifacts”. But within the task at hand, i.e. building an algorithm, the malleability and modularity of it is vast.