DevSecOps Engineer, Author, and Mentor

In the first two parts of this series, I explored a question that began in an unexpected place. What initially appeared to be a discussion about artificial intelligence gradually became a discussion about consent. What began as concerns about security, data stewardship, and information governance eventually led to something deeper: the realization that many debates about AI are not really about technology at all. They are about people. More specifically, they are about the obligations that arise when one person benefits from the labor, creativity, likeness, voice, experiences, or identity of another. Once that connection becomes visible, the conversation changes. We are no longer talking merely about data, artifacts, or outputs. We are talking about the people whose lives made those things possible.

Along the way, I found myself returning to a simple but increasingly important observation. Artificial intelligence has a remarkable ability to separate artifacts from the human beings connected to them. A photograph becomes image data, a voice recording becomes a sample, a body of writing becomes a statistical pattern, and a lifetime of experience becomes a dataset. None of these descriptions are technically incorrect. However, as the artifact becomes easier to analyze, store, reproduce, and transform, the person behind it becomes easier to overlook. The central question of consent emerges precisely at that point:

When does our desire to benefit from another person begin to eclipse our obligation to respect them?

Read More

In the first part of this essay, I argued that many conversations about artificial intelligence become more understandable when we stop focusing exclusively on artifacts and begin focusing on the people connected to them. A photograph is not merely image data. A voice recording is not merely a sample. A body of writing is not merely a statistical pattern. Each artifact derives its significance from its connection to a human being. Once that connection is forgotten, it becomes remarkably easy to view people as resources rather than persons.

That observation naturally leads to a difficult question. If consent exists, what exactly is it protecting? At first glance, the answer appears straightforward. Consent protects privacy. Consent protects ownership. Consent protects information. While each of those answers contains some truth, they seem incomplete. The deeper I explored the subject, the more convinced I became that consent protects something even more fundamental: human dignity. Consent reminds us that another person's likeness, labor, voice, creativity, and identity are not ours to use simply because doing so would be useful, profitable, convenient, or technologically possible.

Artificial intelligence places unusual pressure on that principle because it dramatically expands what can be done with the artifacts people leave behind. A photograph can be transformed into thousands of new images. A voice recording can become synthetic speech. Years of writing can be analyzed, modeled, and reproduced in seconds. As these capabilities continue to improve, the central question shifts from what is possible to what is permissible. More importantly, it forces us to confront the uncomfortable reality that those two categories are not always the same.

That is where many of the most important consent questions begin. They emerge in the space between legality and ethics, between capability and stewardship, and between what we are allowed to do and what we ought to do.

Read More

In a post on Documentation and AI , I advocated for the use of Doxygen-style comments when developing and maintaining shell scripts to preserve intent, contracts, interfaces, edge-cases, and context information. An AI wouldn't need to reinterpret how a block of Bash shell script code worked every time it ran. Doing so would provide a pathway by which subtle changes in understanding could be introduced, much like what happens in a telephone game.

Another benefit of that structured documentation technique is the ability to generate usage information for shell scripts. This allows you to automatically generate what is displayed when someone runs your_script.bash --help without having to maintain that help screen yourself.

So, I put together a tool that can accept one or more Bash shell scripts as inputs, generate the help text, and then inject that help text back into the script. Along the way, the incoming Bash shell scripts are minimized so that the finished version is tighter and no longer carries the full volume of inline documentation.

Read More