Last episode I left you with a question that wasn't really a coding question. We built a room that watches and listens and answers, and at some point the room made a choice I hadn't explicitly typed out. So whose work is that? Mine, the model's, the people moving around in front of the camera? I said we'd come back to it, and here we are.
This is the one episode in the whole ML arc with almost no new technique in it. No model to load, no new ml5 trick. Instead we sit down and talk about the awkward stuff: where the training data came from, who gets to call themselves the artist, whether you have to tell people a machine helped, and how to keep your own fingerprints on work that a network partly made. I've been chewing on these questions for years at this point, and I don't have clean answers - but I do have a way of thinking about them that keeps me honest, and that's what I want to share.
Fair warning: there's no right answer at the end. What there is, is a considered position. By the time you finish this you should be able to say out loud why you use ML the way you do, and defend it. That's worth more than any code snippet, honestly :-).
First thing to get straight - "AI art" isn't one thing. The machine can sit at very different depths inside your work, and lumping them all together is where most of the bad arguments start. I find it useful to lay them out as a little ladder.
// the machine can sit at four different depths in your process
const aiRoles = {
tool: "fills in a job you defined (content-aware fill, upscaling)",
medium: "the material itself (style transfer, GAN latent space)",
collaborator:"responds to you in real time (our pose installation, ep103)",
creator: "generates whole outputs from a prompt (text-to-image)"
};
// the deeper the machine sits, the more of YOUR judgement
// it replaces - and the more carefully you have to defend it
When the machine is a tool, almost nobody blinks - we've used content-aware fill in Photoshop for over a decade and called the result our own. When it's a medium, like the latent space we walked through in episode 99, you're still steering hard. When it's a collaborator, like last episode's installation, you designed the whole stage it performs on. And when it's a creator - you type "beautiful sunset" and press go - that's where the real fights happen, because you handed over the most decisions.
Creative coding with ML lives mostly in those middle two rungs. That matters, and we'll come back to why.
Okay, the big one. When a GAN spits out an image, who is the artist? The people who built the model? The thousands of painters whose work trained it? The person who picked the parameters? The person who scrolled through 500 outputs and saved one?
Here's the thing - art has dealt with this exact problem long before computers. Sol LeWitt, back in the 60s, wrote instructions for wall drawings and had other people execute them. The drawings are unmistakably his art. A composer writes a score; the orchestra plays it; the symphony is still the composer's piece. Architecture, choreography, conceptual art - the field figured out a while ago that the creative decisions are the work, not the physical act of making the marks.
So I think about authorship as a ledger of decisions, not a question of who moved the mouse.
// authorship lives in the decisions, not the execution
// if you can fill this honestly, the work is yours
const decisionLedger = {
concept: "what is this piece even about?", // you
dataset: "what did the model learn from?", // you chose / curated
mapping: "how does model output become visual?",// you (this is the art)
parameters: "which knobs, set to what?", // you
selection: "which outputs survive, which die?", // you
composition: "how is the final thing arranged?", // you
execution: "the actual pixel-pushing math" // the machine
};
// notice the machine owns exactly ONE row.
// you own the other six. that's authorship.
If the only row you can claim is "I typed a sentence and the rest is the model's defaults", the ledger is mostly empty and the authorship is thin. If you curated the dataset, designed a novel mapping, tuned the parameters, and curated hard on the output - the ledger is full of you, and the work is yours no matter how much math the machine did. Makes sense, right?
Now the uncomfortable bit. Models learn from human-made images. Mostly, those humans were never asked, never told, and never paid. A style-transfer model that paints in someone's manner learned that manner from their actual paintings. Scrape a living illustrator's portfolio, train on it, generate "in their style" - that lands very differently from learning from work that's centuries old and in the public domain.
I'm not going to pretend there's a law that settles this, because there mostly isn't yet - it's being fought in courts right now. But I can give you a habit: know your training data. Before you build on a model, find out what it ate.
// a provenance note you keep for every model you use
// you can't always answer all of it - but you should TRY
const modelProvenance = {
name: "mobilenet",
trainedOn: "ImageNet (public research dataset)",
consent: "research license, not artist opt-in",
livingArtists: false, // does it reproduce a named living style?
publicDomain: false, // is the source mostly out of copyright?
notes: "fine for classification; I would NOT use it to mimic a person"
};
The line I personally draw: I'm comfortable with models trained broadly on public or research data for recognition tasks - pose, classification, the stuff we did all arc. I get much more careful the moment a model is built to reproduce a specific living person's style on demand. That's not a legal opinion, it's a "would I want this done to my work?" opinion. At work we shipped a feature once that technically passed legal review and still felt gross to half the team - and "technically allowed" and "okay" are not the same word.
// the gut-check I actually run before training on a source
function shouldITrainOnThis(source) {
if (source.isMine) return true; // your own work, always fine
if (source.licenseAllows && source.publicDomain) return true;
if (source.namedLivingArtist && !source.gaveConsent) {
return false; // mimicking a living person without a yes = no
}
return source.licenseAllows; // otherwise, respect the license
}
Short version: increasingly, yes, and on Hive specifically you really should pay attention. Communities here have policies. Some ban undisclosed AI work outright. Some require a clear label. Some art communities will quietly stop curating you if they feel misled. The norm across the platform is sliding firmly toward "disclose it", and being on the wrong side of that costs you trust you can't easily buy back.
I treat disclosure as just another piece of metadata I attach to the work, same as I'd credit a font or a library.
// disclosure metadata - ship it WITH the piece, don't bury it
const disclosure = {
aiInvolved: true,
role: "medium", // from our ladder above
models: ["custom GAN (self-trained)", "p5.js for rendering"],
humanDid: ["concept", "dataset curation", "mapping", "final selection"],
machineDid: ["image synthesis from latent vectors"]
};
// honest, specific, and frankly it makes you look MORE skilled,
// not less - it shows you know exactly what you did
Notice that being specific actually helps you. "Made with AI" sounds like you typed a prompt. "Self-trained GAN, hand-curated dataset, custom latent-space mapping, rendered in p5" tells people you did real work. Disclosure done well is a flex, not a confession.
Here's a question that stings a little. If you load the same popular model everyone uses, leave the parameters on default, and render with the built-in settings - is the result yours in any meaningful sense? Or did you just run the same recipe as ten thousand other people and get a predictably similar dish?
I run a blunt self-audit on my own ML pieces. The more boxes I leave on "default", the less the work is actually mine.
// originality self-audit: count how much is DEFAULT vs YOURS
function originalityScore(piece) {
let mine = 0;
if (piece.dataset === "custom") mine++; // your own images
if (piece.mapping === "custom") mine++; // your output->visual rule
if (piece.parameters !== "default") mine++; // you tuned the knobs
if (piece.interaction === "designed") mine++; // novel way to engage
if (piece.curation === "heavy") mine++; // you killed most outputs
return mine; // 0 = anyone could have made this. 5 = unmistakably you.
}
A custom dataset is the single biggest lever, by the way. Train Teachable Machine (episode 100) on poses you invented, or a tiny GAN on a photo set only you would ever shoot, and suddenly the output can't look like anyone else's, because nobody else fed it what you fed it. The model is generic; the data is personal; the result is the data wearing the model's clothes.
// the cheapest route to genuine originality:
// don't change the model - change what it learns from
const genericModel = loadModel("everyone-uses-this");
const personalDataset = [
"photos only I would take",
"marks only I would draw",
"gestures only I would invent"
];
// generic engine + personal fuel = output that's recognisably yours
This one isn't optional and it isn't philosophical - it's a bug you can actually measure. ML models soak up the biases in their training data. Face detection that works great on light skin and loses people with dark skin. Classifiers that lean on stereotypes. Generators that default to a narrow, usually-Western idea of "a person". If you put one of these in a public installation and it just... fails to see half your visitors, that's not a neutral glitch. That's the piece telling some people they don't count.
So I test for it. Same way you'd test any other part of your code that could silently break.
// don't assume the model sees everyone equally - measure it
async function auditDetector(detector, testGroups) {
const results = {};
for (let group of testGroups) {
let hits = 0;
for (let sample of group.samples) {
const found = await detector.detect(sample);
if (found.length > 0) hits++;
}
// detection rate for THIS group
results[group.label] = hits / group.samples.length;
}
return results;
}
Then I look at the gap between the best-served group and the worst-served one. A small gap I can live with. A big gap means the piece is broken for real people, and I either fix it or I don't ship it.
// the number that actually matters: the worst-case gap
function fairnessGap(rates) {
const values = Object.values(rates);
const best = Math.max(...values);
const worst = Math.min(...values);
const gap = best - worst;
// e.g. 0.98 for one group, 0.61 for another = 0.37 gap. not okay.
if (gap > 0.15) {
console.warn("big detection gap - this piece excludes people");
}
return gap;
}
You won't always be able to fix the underlying model - you didn't train MobileNet. But you can choose a better model, add fallbacks, design the piece so a missed detection degrades gently (remember graceful degradation from last episode?), or be honest in your disclosure about who it works for. What you don't get to do is shrug and pretend you didn't know.
Let me say the quiet part out loud, because people love to collapse these two into one thing. Typing "epic dragon, trending, 8k" into a text-to-image box and building a real-time pose-driven generative system with a dataset you shot yourself are not the same activity. They're not even close.
// prompt-only workflow: most decisions live inside the model
const promptWorkflow = {
yourInput: "one sentence",
yourControl: "low",
understanding: "you don't need to know how it works",
authorshipDepth: "thin - you described, the model decided"
};
// creative-coding workflow: decisions live at every layer, in YOUR code
const codeWorkflow = {
yourInput: "dataset + mapping + parameters + interaction + render loop",
yourControl: "high",
understanding: "you built every layer and can explain each one",
authorshipDepth: "deep - the model is one component you orchestrate"
};
I want to be careful here - I'm not dunking on people who enjoy prompting. It's fun, it's accessible, and a thoughtful prompt artist who curates ruthlessly is doing real creative work too. But this whole series has been about understanding the machine, not just summoning it. When you can read the math, write the mapping, and debug the pipeline, the AI stops being an oracle you beg and becomes an instrument you play. That's the whole difference, and it's the thing nobody can take away from you once you've learned it.
Here's my honest read on the future, and it's weirdly reassuring. Models are going to get easier, more powerful, more everywhere. The technical execution - the part the machine does - is becoming a commodity. Anyone will be able to generate a competent-looking image in seconds.
And that's exactly why the human part gets more valuable, not less. When execution is free, the only scarce things left are vision, taste, concept, and judgement. The artist's job shifts up the ladder: away from "can you make the marks" and toward "do you have something worth making, and the judgement to know when it's right". The decision ledger from earlier becomes the whole game.
// as the machine gets better, value migrates UP this stack
const valueOverTime = [
"execution <- the machine eats this first",
"technique <- then this",
"----------------------------------", // commodity below, scarce above
"judgement / taste",
"conceptual intent",
"a point of view nobody else has"
];
// learn the bottom so you can stand on the top
No code this time. Your homework is to write a 500-word artist statement about your relationship with AI tools in your creative coding. I know, I know - artist statements have a reputation for being insufferable. Do it anyway, because the act of writing it forces you to actually have a position instead of vibing your way through the question.
Use this as a skeleton if a blank page scares you (it scares me, every time):
// scaffold for your statement - fill each one with a real sentence or two
const artistStatement = {
roleOfML: "what does the machine actually DO in my work?",
whyML: "why this, instead of doing it by hand?",
whatsMine: "which rows of the decision ledger do I own?",
onData: "where does my training data come from, and is that okay?",
onBias: "how do I check the model treats people fairly?",
onDisclosure:"how and where do I tell people AI was involved?",
limits: "what can't the machine do that I still have to?"
};
There's no grade and no right answer. But a person who can answer these is going to make better, braver, more defensible work than someone who never stopped to think about it. And when someone inevitably says "pfft, the computer made that, not you" - you'll have a real answer instead of a defensive shrug. Allez, go write it. Future-you will be glad you did.
And that closes the machine-learning arc. Eleven episodes, from teaching a network to watch all the way to asking who owns what it makes. Notice that we ended not on a technique but on a question, which feels right - the tech is the easy part, the judgement is the hard part. We've also spent this entire series trapped behind glass, every single thing happening inside a screen. Pixels, shaders, canvases, webcams feeding back into more pixels. I think it's high time we let the work out. Next episode we put down the screen and pick up a pen - real ink, real paper, code that moves a physical machine. The output is going to be something you can hold in your hand, and I'm genuinly excited about it.
Sallukes! Thanks for reading.
X
@femdev