AI Can Write the Code. I Still Want It to Feel Like Mine. I want to love it

I needed to create a PowerPoint-style viewer for PDF files. I gave AI that basic description, and it did a great job getting me started.

I wanted the familiar arrangement: a large slide viewer with smaller thumbnail previews for navigation. But the thumbnail logic was buggy. Clicking one preview would drop other slides from the array and change their order. I was trying to select a slide, and the collection itself was changing.

Knowing how JavaScript arrays work helped me explain what was going wrong. That knowledge became part of how I worked with the agent to fix it. So did my ideas about the navigation, the appearance, and how a large slideshow should load.

There is a certain intimacy that comes with creating something. I feel protective of my code. I want to nurture it, care for it, and help it do what I intended it to do. To do that, I have to know it. I have to participate in its design.

That is what I’m trying to preserve as AI becomes part of how I build. I enjoy the help. I also want a relationship with what we make.

A click should select a slide, not rearrange the presentation

There is a difference between telling an agent “the thumbnails are broken” and being able to describe what happens to the underlying data when you click one.

My knowledge of arrays, their methods, and zero-based indexing gave me language for that conversation. The first item in a JavaScript array is at index zero; the slide a person calls “slide one” needs to be connected to the right item. Selecting it should not make other slides disappear or change their order.

I’m not claiming that knowing this made the fix automatic. It helped me explain the behavior more accurately and reason about what needed to remain true. Without that understanding, I would have had a harder time directing the investigation.

That is one answer to the question of why I still want to learn the details when AI can write the code. The details let me participate when something goes wrong.

There were decisions beyond the bug, too. For a large slideshow, I wanted thumbnails to load as needed rather than asking the viewer to load every preview upfront. I had to work through that experience with the agent, brick by brick. “Show me the slides” did not express everything I wanted the experience to be.

On the backend, the agent helped me compare tools and their tradeoffs. We chose LibreOffice because the alternative we tried didn’t work as well for this project or support all the features we needed. The agent could suggest options, but testing them against the experience I wanted helped us decide.

I’m not interested in pretending that typing every line myself makes the work more authentic. I found my way toward programming partly because I wanted to automate repetitive work. It would be strange to fall in love with automation and then object whenever it got closer to my own desk.

But I want to recognize the choices in what we build. I want to understand why it behaves the way it does, and to change it when that behavior no longer serves the person using it.

I use AI differently at different stages

During ideation, I give AI the problem and ask it to help me explore. What are the possibilities? What am I overlooking? What would I need to learn to make a good decision?

Sometimes I want to build something I don’t yet know how to build. That is part of the appeal. The conversation can help me discover an approach and learn enough to evaluate it. I don’t need to arrive knowing every answer, but I do need ways to check the answers I’m given.

For a larger project or an architectural change, I want us to plan before implementation. I ask the agent to explain the problem as it understands it, describe an approach, and surface its assumptions. I compare that understanding with mine. Agreeing on the name of a feature is not enough if we imagine different behavior underneath it.

Once we begin implementing, I tend to break the larger ideas into manageable components. That gives me a chance to review the code and understand how the parts fit together.

The size of a task is a choice, though. I can give an agent more room when the goal is clear and I have a credible way to check the result. I don’t need to supervise every keystroke to participate meaningfully. I do need to know what I’ve delegated and what would make the work acceptable.

That also means giving the agent more than a well-worded request. Relevant code, existing conventions, examples, and earlier decisions can all change what it understands. Anthropic describes this broader work as context engineering: managing the information available to an agent, beyond the prompt alone. ¹

OpenAI’s account of harness engineering takes that a step further, describing the tools, constraints, and feedback that let agents work with greater independence. I read that as another place for engineering judgment to live. Someone still has to decide what the environment should make possible and how results will be checked. ²

I review the code as we go. I try to.

I need to be honest about that last part.

There have been times when I caught myself giving vague instructions, running the result locally, and being satisfied because it worked. I hadn’t really put my eyes on the code. I couldn’t fully explain what it was doing. I could see the result, and the result was exciting.

It was magic.

I understand how easy it is to keep going when an idea becomes something you can click through so quickly. I’ve done it. Then I have to ask whether I know enough about what we made to take care of it.

That question brings me back to the code. Which part handles this behavior? What assumption is it making? What happens when the input changes? Can I explain the choice, or am I repeating an explanation I haven’t checked?

Sometimes the agent has done exactly what I asked, and the missing piece is something I never thought to specify. Sometimes its output is wrong despite a clear request. Better prompting helps, but it doesn’t make review unnecessary.

I want to use explanations to develop my understanding, then check them against the code, documentation, and actual behavior. A convincing explanation is not evidence by itself. A passing test can still test the wrong requirement.

This is one reason I want to keep learning the technical details. They give me more precise questions and more ways to recognize when an answer is incomplete. Anthropic’s research on Claude Code usage found an association between task-specific expertise and successful sessions. That is observational evidence, not a guarantee, and expertise in the problem can come from outside software engineering. ³

For me, the point is to keep developing the understanding that lets me contribute. Having started before coding agents became part of my workflow does not give me a permanent exemption from learning.

I had to describe how we would know it worked

Throughout the viewer project, I tested end to end. I wrote unit tests and Playwright tests, and used Playwright MCP with the agent to check the site through the browser. I followed the user journey and explained to the agent what it needed to demonstrate about the experience.

The thumbnail bug gives me a concrete way to explain what that means. Seeing a slide appear is only part of the check. Selecting a thumbnail should show the intended slide while preserving the rest of the presentation. The slide count and order matter, too. Those are properties I want the tests to check, rather than treating a successful click as sufficient evidence.

For the loading behavior, the question becomes whether someone can actually move through a large presentation comfortably. Unit tests and browser tests give me different ways to investigate the work. I also need to look at the experience they are meant to protect.

This is where my care for the thing becomes practical. If a choice I like makes it harder to use, I need to be willing to change that choice. Feeling attached to the work does not make it correct.

What the ticket might leave out

If I’m working from a Jira ticket, I want to compare the proposed plan with its acceptance criteria before implementation. Have we covered each requirement? Are we interpreting it the same way? What have we assumed?

Then I want to think about the person using the result. Beyond the behavior I’ve described building, a viewer raises other questions: can someone tell that a file is still loading? Can they navigate without a mouse? If the file cannot be opened, does the message help them recover? Does processing the document send it somewhere they would not expect?

These are questions to settle, not extra features to quietly add. They may need a conversation with the person responsible for the requirements. I want to bring them into planning while we can still decide what belongs in the work.

An instruction such as “make the viewer user-friendly” leaves all of that open. Describing the desired behavior—and how we will check it—gives the agent something more useful to work with. I still have to read the plan, question its assumptions, and decide whether we understand the same problem.

Conducting and composing

My background in music gives me a way to think about this collaboration. I can see myself as both conductor and co-composer: shaping an idea, listening to what comes back, and giving feedback that changes what we make next.

The agent can contribute an approach I hadn’t considered. I can learn from it, reject it, or develop it further. My contribution includes choosing what we are trying to express and noticing when the result doesn’t yet do that.

With the viewer, that meant bringing more than a request for working code. I brought an idea of how navigation should feel, enough knowledge to describe the array problem, and a way to check the user journey. The agent contributed suggestions and implementation. We developed the result through that exchange.

That participation lets me feel pride in a shared creation. I’m talking about my relationship to the work: the care and understanding I bring to something I helped make.

I don’t expect to know every detail immediately, and I’m still learning when to slow down and look more closely. But I want to know enough to maintain what we built, question it, and help it become better.

I want to open the project and remember why we made those choices. I want to notice when something isn’t working for the person using it, and care enough to return to it.

I want it to feel like mine. I want to love it.

Footnotes

1. Anthropic, Effective context engineering for AI agents, September 29, 2025. Practitioner guidance on the information available to agents. Accessed September 28, 2026. ↩

2. Ryan Lopopolo, OpenAI, Harness engineering: leveraging Codex in an agent-first world, February 11, 2026. An account of one team’s approach, not a prescription for every project. Accessed September 28, 2026. ↩

3. Anthropic, Agentic coding and persistent returns to expertise, June 16, 2026. Observational analysis of approximately 400,000 sessions; expertise and success are inferred from session evidence, not independently measured long-term production outcomes. Accessed September 28, 2026. ↩