Managing the whole forest

I used to decide what kind of developer I could be on a given day. If I had a limited number of hours to write and review code, spending them on a frontend interaction meant I wasn't spending them on infrastructure, security or the backend. A design exploration and a production fix competed for the same attention. I knew enough across those areas to see how they connected, but there was a limit to how many of them I could move forward myself.

AI tools have loosened that constraint. I can investigate an unfamiliar API, sketch a data model or work through a UI flow without treating each move into another discipline as a week-long detour. I still have to understand the work well enough to judge it. What has changed is the cost of reaching a first pass I can test.

Breadth used to be expensive

I've worked across interface design, frontend and backend code, deployment, product decisions and the occasional security problem. That range taught me to recognize 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.

Recognizing a problem wasn't the same as having time to address it. I often had to pick one part of the stack and leave the rest for later, or find someone else to take it on. Learning a new area meant piecing together documentation, old forum answers and edge cases whose context wasn't always clear.

Now I can ask a narrower question, check the answer against the actual system and get to an experiment sooner. When a generated solution looks plausible, I can run it and read the failure instead of browsing for another hour. That doesn't replace documentation or specialist review. It makes both easier to reach at the moment I need them.

A small change can cross the whole stack

The articles on this site are a useful example because they look like the simplest thing in the codebase. Each one is a single MDX file. But that file carries several contracts at once.

Its metadata supplies the title, description and date that the index page and link previews use. A published flag decides whether the loader includes it at all; files that start with an underscore, like the template I copy from, are skipped entirely. The filename becomes the URL, so renaming a file quietly breaks every existing link to it. The article page reads that metadata, estimates reading time from the word count and renders the body. Figures are static SVG files in a separate folder, embedded through a shared component that sets their dimensions, adds a caption and lets a wide diagram scroll sideways inside its own frame on a phone instead of shrinking its labels until they can't be read.

None of those pieces is hard. The point is that a correct paragraph, valid metadata and a well-formed SVG can each pass inspection on their own while the page a reader opens is still wrong: a figure path that doesn't resolve, a label clipped at the edge of a narrow screen, a caption that says something the drawing doesn't show. Whether the work is done is a property of the joined-up result.

Swipe diagram to explore →

Faster output creates more decisions

A lot of my effort has moved from producing first passes 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. Then I inspect it, and either accept it or send it back with a sharper question.

The evidence changes with the kind of work. A frontend change is judged partly by how it feels in the hand. An API change needs a clear contract and tests. Security asks what an attacker, or an accidental misuse, could do. Copy has to be true as well as readable. A visual direction needs a different kind of criticism again. I can move between these 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 config change, each plausible, none yet checked against the others. Every one is waiting on the same resource, which is my judgment. A quick prototype can be excellent and still wrong for the product. Code can pass a build while misunderstanding the business rule. If I accept output because it looks finished, I've saved keystrokes and lost the reason I was involved.

Where I stop

So I keep the 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 doesn't 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 hurts someone, I ask for review from a person who knows that ground better than I do.

The tools have changed how much of a product I can move forward. They haven't changed who answers for the result. I decide what ships, and when it's wrong, that's mine too.