I Tried to Work Like I Used To. AI Had Already Changed the Job

A few days ago, I decided to redesign my personal site from the ground up.

The change was large enough that starting a new project and carrying over only the content seemed reasonable. The less reasonable part was the constraint I added: I wanted to build it without AI tools.

Not because I had stopped trusting them. And not because I needed to prove that I could still write a div without emotional support.

I wanted the practice.

After months of working with agents and assistants—workflows where a meaningful share of the implementation can be delegated—I felt the need to build something the old way. Scaffold the project, install dependencies, configure the pieces, write the components, and do the integration with my own hands.

I ran the framework command. Added dependencies. Configured the database. Started assembling the structure.

A couple of hours later, I had… the skeleton.

Nothing was blocked. I had not run into a particularly hard problem. I was simply moving at the normal speed of one person putting an application together.

For years, that speed would have felt perfectly reasonable.

Now it felt strangely expensive.

The design already existed

A few days earlier, I had used Stitch to experiment with the redesign. I mostly wanted to test the tool, but the result surprised me enough that I decided to take it seriously.

That left me with two things:

• a fairly clear visual reference for what I wanted;
• a fresh project where I was still rebuilding the foundations step by step.

The next stretch was not especially creative. Translate visual decisions into a theme. Identify typography, surfaces, spacing, and colors. Turn patterns into components. Apply those components across the site.

It was real work. It was also exactly the kind of work an agent could traverse much faster if I gave it the reference and enough project context.

So I opened Claude through OpenCode and asked it to create the theme from the design.

It did it in minutes.

Then it offered to apply the system to the existing pages.

I said yes.

My little “I’ll build this the old way to stay sharp” experiment had lasted less time than the initial project setup.

The obvious takeaway would be speed: a few hours versus a few minutes. That was not the part that bothered me most.

The interesting part was realizing that I could no longer work the old way while pretending the rest of the process had stayed the same.

AI did not merely speed up the same job

The comfortable picture of AI-assisted programming is that the developer keeps doing the same work while a model helps type some of it faster.

Autocomplete with better marketing.

In that model, turning the tool off only means moving a little more slowly. It is like disabling editor completion to prove you still remember the syntax.

The redesign did not feel like that.

The visual direction was defined well enough. The framework had conventions. The expected result could be described and compared. Most of the first pass was a transformation from one representation into another.

In that context, manually writing every piece was not necessarily where I contributed the most judgment. It was where I spent the most time.

That changes the question.

It is no longer just:

How much faster can I write this code with AI?

It becomes:

If the first implementation can arrive in minutes, where does my job begin now?

The easy answer is “in the prompt.”

The real answer is considerably less comfortable.

When the code appears, review begins

I once wrote about a Python proof of concept that worked exactly as requested and was still designed badly. I was thinking in TypeScript patterns; the AI complied and produced a solution full of metaclasses, introspection, and magic—a NestJS project wearing a Python costume.

The lesson then was that engineering starts when the code works.

With agents capable of producing an entire integration, that boundary arrives earlier and occupies much more of the process.

An agent can translate a visual reference into components. I still have to determine whether it understood the interface hierarchy, created a useful abstraction instead of hiding duplication behind an elegant name, followed the project’s conventions, behaved well on mobile, preserved contrast in dark mode, and left the site feeling like the same product.

I also have to catch something more dangerous: a technically correct implementation of the wrong problem.

That kind of failure does not always show up in a green build.

A page can render, its buttons can work, and every type can be satisfied while the navigation breaks a structure established everywhere else in the product. An agent can fulfill the local request while introducing an exception nobody wanted.

Generation speed does not remove those decisions. It compresses them.

Before, I might discover a bad direction while writing the third screen. Now I can receive all three screens before I have fully articulated why the first one feels wrong.

The new skill is not just asking better. It is evaluating before speed turns an assumption into a system.

Was I still programming?

That was the anxiety behind my no-AI constraint.

If I delegated the theme and page adaptation, what exactly was I practicing? Reading diffs? Writing instructions? Can you preserve the craft while directly producing fewer lines?

Part of the problem is that we use “programming” to describe too many different activities.

Programming can mean recalling an API, writing a component, modeling state, finding a race condition, designing a contract, debugging an integration, recognizing the wrong abstraction, or deciding that the sophisticated solution should not exist at all.

AI is dramatically reducing the cost of some of those activities. It is not reducing all of them equally.

For this redesign, mechanically converting a visual reference into a first version of the theme stopped being the bottleneck. In exchange, decisions that could once remain in my head while I implemented slowly had to become explicit:

• which elements belong to the visual system and which are exceptions;
• where one responsibility ends and another begins;
• what deserves to be a reusable component;
• which behavior belongs to the page;
• what acceptance means beyond “it looks like the screenshot”;
• which parts still require human inspection because they depend on taste, intent, or context.

That is programming too, even when it produces fewer keystrokes per hour.

I do not want to romanticize review. Generated code does not automatically turn reviewing it into a higher intellectual pursuit. You can approve everything without understanding it and become the operator of an extraordinarily fast technical-debt machine.

But typing every line does not guarantee understanding either. You can spend an afternoon copying patterns, adjusting utility classes, and connecting components without questioning a single important decision.

The keyboard was never a perfect measure of judgment. It was simply a very visible measure of activity.

Practice still matters, but it needs its own space

None of this means we should abandon manual implementation.

I still need to write code to retain an intuition for costs, constraints, and possibilities. If I never build anything directly, my ability to evaluate generated work will eventually decay. I cannot recognize an unnecessary abstraction if I have forgotten the problem it was supposed to solve.

What changed for me was separating two goals I had mixed together:

1. I want to finish this product;
2. I want to train a skill.

A real project can do both, but it does not always make sense to impose every constraint of the second goal on the first.

If I want to practice CSS, I can rebuild one section without help and compare the result afterward. If I want to understand the content system, I can implement a small component, inspect its output, and deliberately break it. If I want to learn an API, I can create a bounded experiment where slowness is part of the exercise.

Using the entire site redesign as a gym was possible. It was also an expensive way to pretend the primary objective was not to finish the site.

It would be like deciding that, to keep your database skills sharp, you will write SQL by hand—and also implement the driver, the wire protocol, and perhaps a tiny version of PostgreSQL over the weekend. At some point, the exercise stops training the skill you wanted and starts defending a ceremony.

Deliberate practice needs friction.

Production does not need friction for nostalgia’s sake.

The bottleneck moved

The work did not disappear after the theme was integrated. It changed shape.

I had to read what had been produced, understand how the agent interpreted the reference, find decisions that did not fit, align the result with the project’s conventions, and choose what to keep. The first implementation no longer occupied the center of the process. Intent and evaluation did.

I keep seeing the same shift elsewhere in my work.

When an agent can traverse a repository, propose an architecture, change several files, and run checks, my contribution cannot be limited to writing a request and waiting for an attractive result. I have to build the environment in which the tool can act without reinventing the project’s organization every session.

It needs sources of truth. Boundaries. Conventions. Verifiable criteria. Ways to surface uncertainty. And a person capable of noticing when the output follows the wording of an instruction while betraying its intent.

AI did not make my previous experience irrelevant. It turned that experience into the filter through which more decisions pass in less time.

There is an uncomfortable consequence: if I could once compensate for a mediocre idea with many hours of implementation, mediocrity now scales faster too.

But there is a much more interesting one: I can spend less energy proving that I know how to assemble the pieces and more time deciding which pieces are worth assembling.

I cannot quite go back

I could finish the site without opening another agent. Nothing technically prevents it.

But I would know the opportunity cost.

Every hour spent on an integration I could delegate would be a conscious choice, not the unavoidable way software gets made. Sometimes that choice will be worthwhile because I want to learn, explore, or simply enjoy the implementation. Other times I would only be confusing effort with value.

That is what truly changed.

AI did not take away my ability to work the old way. It took away the innocence of believing that doing so was neutral.

Now I have to choose when to write, when to delegate, what to review, where to preserve friction, and which part of the craft I want to practice deliberately.

I did not conclude that I should stop programming.

I concluded that “keep programming” can no longer mean “keep doing everything by hand.”

I tried to build the site the old way so I would not lose the practice.

What I discovered was that the practice I needed most was learning how to work after code stopped being the slow part.