I Didn’t Learn to Code. I Learned How to Work with AI.
I am not a professional software developer.
I have worked as a photographer for 36 years, spending most of that time inside real photo studios. My work has involved cameras, lighting, Photoshop, photo printers, customer orders, and the countless small problems that appear in everyday studio operations.
Over the years, I often imagined programs that could make this work easier.
I wanted a better photo ordering system. I wanted print jobs to be organized automatically. I wanted software that could check orders, prepare images, manage printers, and reduce repetitive work. I also had ideas for photo-retouching tools and stock-trading applications.
The ideas were there, but turning them into working software was another matter.
I Started by Explaining the Work
When AI coding tools became capable enough to work with real projects, I did not begin by studying programming from the beginning.
Instead, I began by explaining my work.
I described what happens when a customer places a photo order. I explained how images move through a studio, how print sizes are selected, how files are corrected, and where mistakes usually occur. I described what photographers actually need from retouching software and why many automated corrections do not work well in real production.
AI could write code, but it did not automatically understand the work.
That became one of my first important lessons.
Knowing how to generate code is not the same as understanding why a program should exist. AI often proposed technically reasonable solutions that did not fit the actual workflow. Sometimes it solved the wrong problem very efficiently. At other times, it added complexity where a simple operational rule would have been better.
My role was not only to ask for features. I had to provide context, review decisions, identify misunderstandings, and keep the project connected to the real environment in which it would be used.
In other words, I was learning how to work with AI.
From One AI Session to a Small Development Team
As the projects grew, a single AI session was no longer enough.
I began using multiple sessions with different responsibilities. One session might work on the main application, while another examined a specific technical problem. Another could review documentation, investigate hardware behavior, or organize the current state of the project.
This gradually began to feel less like using a chatbot and more like managing a small development team.
But AI sessions also have limitations. They can lose context, misunderstand earlier decisions, repeat solved problems, or make changes that conflict with another part of the system. Giving them more freedom does not always produce better results.
The quality of the work depends heavily on how clearly responsibilities, constraints, and project history are communicated.
I learned that working with AI requires judgment, not just instructions.
Building Software for Real Work
The programs I am developing are not imaginary demonstrations.
They come from real needs inside a working photo studio.
My projects include photo-ordering and print-management systems, automated workflow tools, photo-retouching software, printer-related utilities, server monitoring, and stock-market analysis applications.
Some features work well. Some have been redesigned many times. Some ideas looked promising at first but failed when tested against actual photographs, printers, customers, or market data.
Those failures are part of the development process, and they are also part of what I want to record here.
This blog will not be a collection of perfect success stories. It will include wrong assumptions, abandoned approaches, difficult decisions, unexpected solutions, and the moments when a conversation with AI led to an idea I had not considered before.
Why I Am Keeping This Journal
AI-assisted development is changing quickly. Tools improve, models change, and methods that work today may look primitive a few years from now.
That is exactly why I want to leave a record.
I want to document what it was like for someone without a traditional software-development career to build practical applications with AI. I also want to preserve the reasoning behind the programs—not only the final code.
Code can show what a program does. It does not always show why a particular decision was made, what failed before it, or what problem existed in the real world.
Those stories matter.
This journal will follow my continuing work with AI coding agents: how I explain problems, organize multiple sessions, evaluate their decisions, correct mistakes, and turn ideas from a photo studio into working software.
I did not begin this journey by learning how to write every line of code myself.
I began by learning how to describe real work clearly, make decisions, and collaborate with AI.
That has become a different kind of programming—and this is where I will record what happens next.