AI Writes the Code, I Make the Decisions: My Actual Product Workflow

One of the easiest mistakes in AI-assisted software development is to confuse fast implementation with a finished product. An assistant can return hundreds of lines of convincing code in minutes. It does not follow that the right problem was solved, the right data was used, or the result should be released.

Working across ecommerce, website design and specialist software has made me more interested in who makes the decisions than in which model generates the first version of a component. Here is how I think about that responsibility, using practical constraints and observable examples rather than invented productivity statistics.

What I mean when I say AI writes the code

The phrase “AI writes the code” can make software development sound almost automatic. It is not. Code generation is one step inside a longer sequence of decisions: which problem deserves a product, what the system must do, which data it can access, what happens when something goes wrong, and whether the result is safe to release.

My role is not to compete with an assistant over who can type a component faster. It is to hold the definition of a useful product. I decide which workflows matter, what can be simplified and which compromises are unacceptable. AI can propose implementations and help investigate failures; it cannot take responsibility for an incorrect business rule, an inaccessible checkout or an exposed customer record.

This article is about decision ownership in an AI coding workflow, rather than a roundup of coding tools. In an earlier Journal article I described the wider path from an idea to a working deployment. Here I am narrowing the focus to the human checkpoints that make that path credible.

1. I choose the customer problem before choosing the technology

A product brief should begin with a user action, not a list of features. “Build a modern CRM with AI” is too broad to guide good engineering. “A site manager needs to record a visit, attach evidence and produce a report that another person can review” gives you a workflow you can describe and test.

Before implementation, I try to make four decisions explicit: who uses the feature, what starts the action, what a successful result looks like, and what must happen when the action fails. That immediately forces questions which visual mockups tend to hide. Can a report be edited after submission? Who is permitted to see it? Is an attachment required or optional? What counts as complete?

AI is useful in this phase as a challenger. I can ask it to identify missing states, contradictory rules and alternative approaches. But a generated list of fifty plausible features is not evidence that fifty features should be built. A product earns its scope by solving a real problem, not by demonstrating what the model can generate.

2. I write down the rules that must not change

There is a difference between giving an AI assistant a prompt and giving it an executable specification. A robust instruction includes the existing architecture, allowed files, design constraints, data assumptions, expected behavior and the acceptance checks that will prove completion.

For example, when updating a website, “make the Journal support a new article” could invite an unnecessary redesign or an entirely new content system. A stronger instruction is: use the current Journal markup and CSS, add one article page, register it in the listing, update the sitemap, preserve all older entries and confirm the route on production. The second version makes success observable.

I separate hard constraints from preferences. A mobile layout must remain usable; existing published links must continue to work; secrets must not be committed; product and payment rules must not silently change. Typography refinements and optional animation can be discussed. If the assistant produces an attractive result that violates a hard constraint, it is not an acceptable result.

3. I split the work into changes I can actually review

Large AI-generated rewrites are difficult to evaluate. A file can look polished while hiding altered behavior elsewhere. Smaller changes create a clearer question: did this specific edit satisfy the requirement without harming something that already worked?

My preferred decision sequence is to inspect first, define the edit boundary, implement only the required files, review the diff and test the affected journey. If a change has several dependencies, I want them identified before code is written. A component that depends on a new route or data shape should not quietly invent that route or schema.

This is also a practical way to control the economics of AI development. The fastest generated output is not necessarily the cheapest final product. A broad rewrite that creates hours of debugging can cost more than a disciplined sequence of narrow edits. Addy Osmani's account of his LLM coding workflow independently makes the case for detailed planning, relevant context and small iterations. I agree with that engineering principle, while applying it to product ownership and release decisions.

4. An actual example: the Journal you are reading

There is a useful, inspectable example on this very website. The Journal uses individual article HTML files, a styled archive page and an XML sitemap. It is not enough to generate an article page and find that its direct URL loads. The archive must also link to it; its metadata must identify the correct canonical URL; the sitemap must describe a real route.

Those are separate acceptance conditions. They can fail independently. An article page might return HTTP 200 but be invisible to someone browsing the Journal. A listing might exist but point to a path that does not resolve. A sitemap entry might be updated before the page is deployed. Nothing about those failures is fixed by more fluent prose or nicer code.

For this site's existing architecture, the relevant review boundary is therefore concrete: one new article directory, the existing Journal listing, the sitemap and any directly required asset. The shared stylesheet, homepage and previous articles should not be rewritten just to publish another post. This is a verified example of the current site's structure, not a claim that every step of its previous development history was recorded or independently audited.

5. Another example: a Shopify import that looks correct until it fails

The same principle appears in ecommerce data work. A product CSV may contain convincing names, prices, descriptions and images, yet still fail Shopify's variant rules. In catalog work, I have dealt with import validation that reported a missing option value for product variants. The visible spreadsheet could appear complete, but the platform's data contract was not satisfied.

That changes the question I ask an assistant. I do not merely ask it to “fix the CSV.” I want the actual validation message interpreted, the affected rows isolated, the option columns mapped to the required structure, and the final output checked against Shopify's import expectations. I also want to preserve product handles, collection tags and the rest of the catalog unless the correction genuinely requires a change.

The commercial lesson is straightforward: successful generation is not successful transfer. For a store owner, usable product data is the outcome; text that looks finished in a spreadsheet is only an intermediate artifact. I am not presenting a measured import success rate or a client case study here. The example illustrates the importance of validating the real system contract.

6. What I delegate to AI, and what I retain

Delegation becomes clearer when the tasks are separated. AI can accelerate repetitive markup, draft a utility, explain an error, propose test cases, or compare implementation options. It can also be wrong about a framework API, a requirement or a security boundary. I retain responsibility for what is worth building and whether the evidence supports release.

This is not an argument that AI cannot make decisions in a technical sense. Agents can choose tools and carry out multi-step tasks. It is an argument about accountability: the person operating the business must still understand the consequential decisions and have a way to verify them.

7. I review behavior, not the assistant's confidence

An assistant's statement that a feature is “complete” is not a test result. Neither is a successful build. I distinguish several layers of evidence: source inspection, syntax and type checks, automated tests, rendered-page review, an end-to-end user journey, and the final production response. Each layer tells me something different.

For a subscription product, a happy-path screenshot does not prove that cancellation, permission boundaries, duplicate submissions or billing failures behave correctly. For a store, a beautiful product page does not prove a purchase can be completed. For a Journal article, a working direct URL does not prove that a visitor can discover it through navigation.

GitHub's documentation on pull-request reviews describes the mechanics for evaluating changes before merge. Vercel's deployment environments documentation distinguishes preview and production contexts. Both are useful tools, but neither substitutes for explicit product acceptance criteria.

My minimum release question is: which observable evidence demonstrates the particular behavior I promised? If I cannot answer that, the work may be a draft or a prototype, not a finished feature.

8. I treat security and data access as product decisions

AI-generated code deserves the same security discipline as code written by a person. Access to private records, authentication, user roles, file uploads, third-party integrations and credentials cannot be treated as decorative implementation details. A feature can appear to work perfectly for one account while exposing information across accounts.

My first questions are simple: who is allowed to do this, which data can they see, what inputs can they supply, what happens when they are not authorized, and where do credentials live? I do not put live secrets or private customer records into a public article or an unrestricted prompt. When an agent can modify files or run commands, its permissions also need a clear boundary.

The OWASP guidance on risks in LLM applications is a useful source for understanding the security implications of systems involving models and agents. Ordinary web-application security checks still matter too. I would rather postpone a feature than guess about customer access controls or payment correctness.

9. I decide when a simpler implementation is the better product

AI lowers the cost of producing interfaces. That can create a temptation to add functionality merely because it is now easy to generate. In a specialist software product, the hard problem is usually not the number of available screens; it is whether the workflow accurately captures work people need to complete.

I weigh the smallest coherent version against the proposed larger build. Does a dashboard need ten charts or one reliable exception list? Does an early quoting tool need elaborate predictions or a traceable pricing calculation? Does a brochure site need a custom backend when static pages would meet its requirements? These are design and operating decisions, not measures of coding ambition.

The answer is sometimes to build more. A data export, audit trail or access-control check may look invisible in a demo yet be essential to a real buyer. Conversely, an animated control may look impressive and create maintenance cost without improving the user journey. Good product judgment is deciding which side of that line each feature belongs on.

10. My acceptance checklist before I call something finished

For a narrowly scoped AI-assisted change, I use the following questions as a release framework. They are not a claim that every historical product has passed an identical audit; they are the checks I want a responsible workflow to answer.

1. Need: Is the problem and intended user action stated clearly?
2. Scope: Are allowed changes and explicitly excluded changes documented?
3. Rules: Do data, permission and business calculations match requirements?
4. Review: Have changed files and dependencies been inspected?
5. Tests: Is there observable evidence for critical success and failure paths?
6. Experience: Does the real interface work at mobile and desktop sizes, including keyboard use where applicable?
7. Release: Do the actual route, metadata and production environment behave correctly?
8. Recovery: Can the change be corrected or rolled back without losing important data?

Where a check is incomplete, I record the limitation instead of declaring victory. The checklist is intentionally smaller than an enterprise release process, but it is more demanding than trusting a completion message. Its purpose is to make one change verifiable.

The trade-off: AI makes iteration cheaper, not judgment optional

There is a strong argument against overengineering the process: if the project is an internal sketch, a disposable experiment or a low-risk prototype, extensive documentation and release ceremony can consume more value than they protect. I agree. The checks should be proportional to the consequences of failure.

But when real customers, payments, operational records or search traffic are involved, skipping validation has a cost. Small teams do not have the luxury of discovering every fundamental assumption after launch. The useful balance is lightweight specification, narrow implementation, automated checks where they genuinely help and a deliberate decision about what to ship.

The reason I am interested in AI-directed development is not that it lets me claim to have written more code. It lets a founder spend more attention on the questions that determine whether a product is useful: who needs it, how it should behave, what can break and what evidence makes it ready. AI can supply speed. It should not be allowed to supply unearned certainty.

← RETURN TO THE JOURNAL