Managing the whole forest

Written in May 2023, when code assistants and chat models were new to my daily work. Lightly edited and illustrated in September 2026; a note at the end records what has changed since.

For most of my career, the limiting resource has been hours. A day spent on a frontend interaction was a day not spent on the backend, the deployment, or the security review. I understood how those areas connected, and I could often see a problem forming in one of them from where I stood in another. Seeing it was not the same as having the time to address it.

Over the past year, code assistants and conversational models have changed the cost of that first step. I can explore an unfamiliar API, draft a data model, or work through a UI flow without treating each move into another discipline as a week-long detour. I still need to understand the work well enough to judge it. What has changed is how quickly I can reach a candidate worth judging.

Breadth used to be expensive

My work has spanned interface design, frontend and backend code, deployment, product decisions, and the occasional security question. That range is useful mainly for recognizing dependencies: the screen that looks simple but needs awkward data, the feature that works until a deployment fails, the automation that saves time by skipping the check that made the process trustworthy.

Acting on that recognition was another matter. I usually had to pick one part of the stack and defer the rest, or bring in someone else. Learning a new area meant assembling documentation, forum answers, and edge cases whose context was not always clear.

Now I can ask a narrower question, check the answer against the actual system, and reach an experiment sooner. When a generated solution looks plausible, I can run it and read the failure rather than searching for another hour. This does not replace documentation or specialist review. It makes both easier to reach at the moment they are needed.

A small change can cross the whole stack

Consider something that looks trivial: publishing one article on a statically generated site. The article is a single Markdown file, but that file participates in several contracts at once.

Its front matter supplies the title, description, and date that the index page and link previews depend on. A publication flag decides whether the build includes it. The filename becomes the URL, so a rename silently breaks every existing link. The page template reads the metadata and renders the body. Any figures are separate assets, embedded through a component that sets their dimensions, adds a caption, and decides how a wide diagram behaves on a phone.

None of these pieces is difficult. The point is that a correct paragraph, valid metadata, and a well-formed image can each pass inspection on their own while the page a reader opens is still wrong: an asset path that does not resolve, a label clipped at the edge of a narrow screen, a caption that describes something the figure does not show. Whether the work is finished is a property of the joined-up result, not of the individual files.

Swipe diagram to explore →

Faster output creates more decisions

Much of my effort has moved from producing first drafts to framing and evaluating them. I decide what the work must do, what would count as failure, and what evidence I need before trusting it. A tool produces a candidate. I inspect it, then accept it or return it with a sharper question.

The evidence differs by discipline. A frontend change is judged partly by how it feels in use. An API change needs a clear contract and tests. Security asks what an attacker, or an accidental misuse, could do. Copy has to be accurate as well as readable. A visual direction calls for a different kind of criticism again. I can move between these questions faster than before, but each switch still costs attention.

Swipe diagram to explore →

The harder problem is volume. When candidates are cheap, it is easy to have five of them open at once: a component refactor, a draft section, two diagrams, and a configuration change, each plausible, none yet checked against the others. All of them wait on the same resource, which is my judgment. A prototype can be excellent and still wrong for the product. Code can pass a build while misunderstanding the business rule. Accepting output because it looks finished saves keystrokes and discards the reason I was involved.

Where I stop

So I keep each task bounded. I would rather have one small change exercised end to end, rendered on a real page, read on a phone, and checked against what it claims, than several persuasive drafts of things that might work.

Breadth tells me where to look. It does not make me a specialist in everything I can now reach. When the work touches payments, security boundaries, accessibility beyond what I can test myself, or anything where a quiet mistake would hurt someone, I ask for review from a person who knows that ground better than I do.

These tools have changed how much of a product I can move forward. They have not changed who answers for the result.

---

September 2026. Three years on, the tools have moved from completing lines to carrying out multi-step tasks, and the volume problem described above has grown with them. The conclusion has held: cheaper candidates raise the value of a clear definition of done, and of someone willing to check the joined-up result before calling it finished.