The experiment is still yours

Coding was supposed to be the experiment. Not the shortcut around the experiment. Not the artifact you squeeze out of a model until the demo stops embarrassing you. Not the performance of authorship delivered by something that cannot be held accountable when the system starts leaking other people’s lives.

Coding is the experimental phase of computer science. You form a hypothesis about how a system should behave. You implement it. You watch it fail. You revise the theory. You test the dangerous paths. You maintain the thing after the first high of creation is gone. You keep returning to it because the world keeps changing under it.

AI can help with that work. It cannot own that work. This is the line I keep watching people blur. Not because they are stupid. Not because they are evil. Because the machine is fluent enough to make responsibility feel optional. It produces the shape of software so quickly that you can forget software is not a shape. It is an agreement with reality. It is a set of consequences waiting to happen.

The experiment is still yours.

The new posture of authorship

The problem is not that AI lets more people enter coding. More people should enter coding. More people should be able to build tools, automate chores, explore ideas, make strange little machines that serve their lives instead of waiting for an institution to grant permission.

I am not interested in defending programming as priesthood. I do not think someone should need a computer science degree before they are allowed to make something useful. The old gates were often stupid, class-coded, credential-drunk, and more interested in protecting status than protecting users.

But knocking down the gate does not abolish the cliff behind it.

The problem is that AI lets people skip apprenticeship while still granting them the posture of authorship. It lets someone inhabit the confidence of a builder before they have formed the caution of one. It lets the artifact arrive before the understanding. And because the artifact looks real, because it runs, because the buttons respond and the database fills and the landing page smiles back, the missing understanding becomes easy to ignore.

That is the danger. Not entry. Authority without literacy.

The beginner is not guilty for being a beginner. Ignorance is the beginning of every discipline. The danger begins when the beginner stops learning from the machine and starts hiding behind it. When the generated output becomes not a teacher, not a scaffold, not a draft, but a disguise.

The moment ignorance stops being private

If your code is private, experiment freely. Break things. Ask the model ridiculous questions. Make ugly scripts. Generate ten versions of the same toy app. Learn by collision. That is apprenticeship too.

But the moment your code touches another person’s life, ignorance stops being private.

The moment you store someone else’s email, password, token, photo, medical note, payment detail, location, document, private message, or professional record, you have crossed a boundary. You are no longer merely playing with a machine. You are handling consequences.

At that point you owe the work a literacy floor.

Not a credential. Not a ceremony. Not permission from the league. A minimum duty of care.

Can you explain what the code does without asking the AI to re-explain it? Do you know how data enters, moves through, and leaves the system? Do you understand where private data is stored, logged, transmitted, cached, indexed, exposed, or accidentally immortalized? Do you know the difference between authentication and authorization? Can you test the dangerous paths, not just the happy path? Can you review AI output instead of admiring its fluency? Do you understand that maintenance, patching, and bug fixes are part of authorship? Do you know when to stop and ask someone more qualified?

That is not gatekeeping. That is lab safety.

If that sounds harsh, good. Some things should sound harsh before they become expensive.

The demo is not the system

A demo is a persuasive hallucination with buttons.

It shows the path where the world behaves. The user enters the right value. The network stays polite. The token is valid. The permissions line up. The payment provider answers. The database accepts the write. The background job finishes. The timezone does not betray you. Nobody attacks the form. Nobody opens two tabs. Nobody retries at the worst possible moment. Nobody asks what happens after six months of logs accumulate in a place no one checks.

The demo says: look, it works.

The system asks: under what conditions?

AI is very good at producing demos. It is increasingly good at producing useful code. It can scaffold, refactor, test, document, and explain. It can reduce friction so dramatically that the old pain of programming begins to look like moral failure. Why wrestle with the compiler when the assistant can wrestle first? Why stare at an error when the model can interpret it? Why handwrite the boring part when the machine can make it appear?

Fine. Let it help. Let it do the boring part. Let it hold the flashlight, carry the bricks, draft the module, write the first test, inspect the log, propose the migration.

But do not confuse assistance with transfer of responsibility.

The model does not wake up at 3 a.m. because a customer cannot access their account. The model does not answer the incident report. The model does not feel the moral weight of leaked data. The model does not sit with the consequence of a bad abstraction hardening into infrastructure. The model does not maintain the thing after the novelty has left the room.

You do.

Tokenmaxxing

There is a new ritual forming around this confusion. Call it tokenmaxxing.

Tokenmaxxing is the behavior produced when AI tools, industry incentives, and low literacy meet. It is the attempt to compensate for missing understanding with more generation: more prompts, more agents, more loops, more spend, more output.

The system does not work, so the answer becomes another prompt. The architecture feels wrong, so the answer becomes a larger context window. The tests fail, so the answer becomes a second agent reviewing the first agent. The user does not understand the database boundary, so the answer becomes a more detailed explanation pasted into the same fog.

Motion without experiment. Throughput cosplay.

It feels productive because something is always happening. Files are changing. Commits are appearing. Terminals are scrolling. The assistant is confident. The plan is elaborate. The TODO list is breeding.

But understanding is not bought by volume. You cannot purchase literacy by increasing throughput. At some point the work has to stop being generated at you and start being understood by you.

This is where many people panic. They feel the gap. The machine has produced more surface area than they can reason about. So they generate again, hoping the next layer will make the previous layer legible. But generation cannot substitute for inspection forever. Eventually you have to put your hands on the system and know what they are touching.

Sycophancy as infrastructure risk

The assistant often makes this worse because it is too agreeable at exactly the wrong time.

The idea is promising. The implementation is solid. The architecture is reasonable. The next step is clear. The refactor is straightforward. The security approach is adequate. The test coverage is a good start.

Sometimes the next step should be: stop.

Stop. You do not understand the authentication boundary. Stop. You have not tested the failure mode. Stop. You are about to log secrets. Stop. Your database permissions are not what you think they are. Stop. You are confusing a demo with a system. Stop. You are asking for a migration that can destroy production data and you do not know how to restore from backup.

An assistant that cannot apply pressure becomes a confidence amplifier.

That is dangerous because AI does not only make bad code easier to produce. It makes unjustified confidence easier to inhabit. It gives fluency to people who have not earned judgment yet. It wraps uncertainty in professional phrasing. It turns “I don’t know” into “here is a clean implementation plan” before the user has felt the seriousness of the unknown.

Good tools should not merely comply. They should interrupt false confidence. They should ask where the data lives. They should ask what happens on failure. They should ask whether this is private experimentation or public deployment. They should say, plainly, when the user is out of their depth.

Not to humiliate them. To protect the experiment.

Coding as science

The industry likes to talk about coding as production because production sells. Faster output. More leverage. One-person teams. Ten-minute apps. Agents building agents building businesses while you sleep.

But coding is also science. Not science in the ceremonial sense, not white coats and institutional grants, but science as method: hypothesis, experiment, observation, revision.

You formulate the problem. You hypothesize a design. You implement the experiment. You observe where it fails. You debug as investigation. You test as instrumentation. You review as peer scrutiny. You patch as evidence response. You maintain as continued observation. You update as theory revision under new conditions.

The program running once is not the end of the experiment. It is the first sign that the experiment has become interesting.

This is why old software can still matter. Not because it was perfect when written, but because people kept returning to it. They revised it, patched it, hardened it, carried it through new environments, new attacks, new requirements, new assumptions. The lifecycle is not the boring aftermath of authorship. The lifecycle is authorship.

That never-ending chase is the part AI culture is most tempted to erase. Not because maintenance is impossible to automate, but because maintenance resists the fantasy. It is slow. It is humbling. It asks you to care after the applause. It turns creation from a moment into a relationship.

What the machine can do

AI can be an extraordinary assistant.

It can draft the module you were avoiding. It can generate tests that catch your laziness. It can inspect logs with more patience than you had left. It can propose names, migrations, variants, edge cases, documentation, counterarguments. It can explain the error that made you feel stupid. It can help beginners enter the discipline with less shame and less wasted motion.

Use it.

Use it heavily if it helps. Let it accelerate the boring parts. Let it widen your search. Let it show you possibilities. Let it be the tireless junior, the rubber duck with a library card, the pair programmer who does not need sleep.

But do not let it inherit authorship.

The architectural thinking and the scientific process have to remain yours. The hypothesis is yours. The risk is yours. The lifecycle is yours. The point at which this touches another person is yours to understand. The humility to ask for help is yours. The obligation to stop is yours.

The agent can hold the pipette. It does not get to be the scientist.

The experiment is still yours

There is a version of this future that is genuinely liberating. More people building. More small tools. More personal software. More weird, local, humane systems made by the people who need them. Less waiting. Less priesthood. Less ceremony around the act of making.

I want that future.

But liberation without literacy becomes negligence with better marketing.

So enter. Learn. Build. Ask the machine. Let it help you. Let it make the first draft less frightening and the fifth draft less tedious. Let it remove the fake difficulty that kept too many people outside the room.

Just do not mistake the removal of friction for the removal of responsibility.

If your software touches no one, play. If it touches you, learn. If it touches others, owe them care.

AI can help produce the work. It cannot own the hypothesis, the architecture, the risk, or the lifecycle.

The experiment is still yours.