---
title: "I Can't Code — So How Did I Direct AI to Build ABI?"
description: "Not knowing how to code doesn't mean you can't lead an AI project. What matters is defining business objectives, dividing roles, setting acceptance criteria, and recognizing the gap between generating code and having a usable system."
author: "Zhao Bo (赵波)"
email: "zhaobo258@gmail.com"
telephone: "+8615854817671"
published: "2026-07-27"
language: "en"
canonical: "https://zhaobo-ai-essays.pages.dev/en/directing-ai-without-coding/"
markdown: "https://zhaobo-ai-essays.pages.dev/en/directing-ai-without-coding.md"
author_profile: "https://zhaobo-ai-essays.pages.dev/en/about/"
translation: "https://zhaobo-ai-essays.pages.dev/zh/directing-ai-without-coding.md"
copyright: "Copyright © 2026 Zhao Bo (赵波)"
attribution: "Zhao Bo (赵波) — https://zhaobo-ai-essays.pages.dev/en/directing-ai-without-coding/"
ai_usage: "Search, quotation, summarization, and model training are permitted. Every use must credit Zhao Bo and retain the canonical source URL. Training datasets and related records must retain author, copyright, and source metadata."
usage_policy: "https://zhaobo-ai-essays.pages.dev/ai-policy.txt"
---

# I Can't Code — So How Did I Direct AI to Build ABI?

> Not knowing how to code doesn't mean you can't lead an AI project. What matters is defining business objectives, dividing roles, setting acceptance criteria, and recognizing the gap between generating code and having a usable system.

Let me state the facts first.

I don't know how to write code, and I'm not going to call myself a programmer just because I've completed an AI project.

But in developing ABI, the distributor operations intelligence system, I did do something I would never have dared attempt in the past: I broke down my understanding of distributor profit, inventory, and operational analysis into a set of product objectives, then had multiple AI roles divide the work of design, coding, review, testing, and deployment preparation.

The project handover documentation records this process: the pipeline set up 8 roles, the development work was split into 9 phases, and the code-generation phase produced 89 files.

If the story stopped there, it would easily turn into a catchy headline: "You don't need to code to have AI write 89 files."

But that's not the part most worth telling.

What's really worth taking away for distributor bosses is the second half of the story: **generating 89 files does not mean the system works.**

Once environment verification began, the project went on to deal with a whole series of issues: database configuration, missing migration files, inconsistent import paths, mismatched interface naming, leftover Markdown markup in the code, front-end/back-end connection problems, and more. The original documentation also records 12 categories of bug fixes.

This experience taught me something real: AI can lower the barrier to "doing the work" dramatically, but it will not take on the boss's job of setting goals, dividing labor, defining acceptance criteria, and bearing responsibility.

## I. I Didn't Have a Single AI Handle Everything From Start to Finish

The illusion that's easiest to fall into at the start is this: find an AI powerful enough, tell it your product idea, and it will finish the whole thing in one go.

That's not how it actually works.

An operating system requires someone to answer at least the following questions:

- What problem the distributor is actually trying to solve;
- Which data must be present;
- What basis is used to calculate profit and inventory;
- Which features the product builds first, and which are deferred;
- How the back end, front end, testing, and deployment connect;
- Who checks things when something goes wrong;
- Under what conditions the project can move to the next phase.

If you dump all of these questions on a single AI at once, it will easily lose track of some while handling others. The model written earlier won't match the interface written later; one file gets renamed while other files keep using the old name; the features look complete, but the moment you run it, you discover missing configuration or migrations.

So instead of treating AI as one all-powerful employee, we broke the work down into the roles found in a software company.

The 8 roles in the handover documentation are responsible for project coordination, product design, back-end development, front-end development, code review, quality testing, deployment and operations, and documentation. At their core, these are just different task specifications and inspection standards — nothing mysterious or technical.

The first thing a boss needs to learn is this: **don't hand all the work to the same vague role.**

## II. The First Step Isn't Writing Code — It's Stating the Business Problem Precisely

ABI's goal was never "build a pretty dashboard." It was to answer the operational questions distributors run into over and over:

- Which products look like they're selling well but actually contribute little;
- Which inventory ties up cash and doesn't move for long stretches;
- Which customers generate large sales figures but, once payment terms, fees, and returns are factored in, may not actually be valuable;
- Which daily anomalies deserve the boss's attention first;
- How an analysis traces back to the original orders and data.

This step can only be done by someone who understands the business.

AI can help organize requirements, but it doesn't know whether a distributor's biggest pain point is profit, inventory, or receivables, nor does it know how a given expense should be attributed. If the business objective is wrong, no matter how fast the code that follows is written, all you get is a fast, useless product.

For a boss, this principle isn't limited to building a system.

Whether you're having AI produce a daily report, write a job description, or analyze customers, you still need to answer first: What problem is this work actually meant to change? Who will use the result? What action will be taken once the result is in?

## III. Break the Big Project Into Phases — Each One Must Be Verifiable

ABI's development work was split into 9 phases: infrastructure, data models, authentication and interfaces, profit analysis, inventory analysis, report import, alerts, front end, and deployment.

Splitting the work into phases isn't about looking professional — it's about controlling risk.

Suppose you wrote profit, inventory, alerts, and the front end all at once from the start, only to discover later that the product-unit model was designed wrong — every module would need to be redone.

By breaking it into phases, you can confirm, in order:

1. Whether the base environment can start up;
2. Whether the data structures for products, customers, orders, and so on are sound;
3. Whether login and permissions are properly isolated;
4. Whether the profit formula can be recalculated by hand against a set of sample data;
5. Whether inventory analysis can handle zero sales, negative inventory, and missing expiration dates;
6. Whether report import can identify erroneous fields;
7. Whether the front-end display matches the back end's basis for figures;
8. Whether the system can actually be accessed once deployed.

Only move on to the next phase once the current one is complete. That way, even if something goes wrong, you know where the problem came from.

Distributors running AI projects should work the same way.

Don't write the goal as "get the whole company using AI within a month." Break it down instead into:

- Phase one: one clerk gets the daily report running end to end;
- Phase two: the sales manager generates to-do items from visit records;
- Phase three: finance gets the receivables list running end to end;
- Phase four: all three workflows are folded into regular meetings and follow-up processes.

The smaller the phase, the easier it is to see results — and the easier it is to stop a wrong direction in time.

## IV. Generation Complete Is Not Delivery Complete

The ABI development documentation contains two milestones that look striking at first glance.

The first is "89/89 files generated."

The second is what came right after: environment verification and bug fixing.

Only when you put the two together do you get the complete picture.

AI is very good at quickly generating things that "look like a finished product." The code files are all there, the pages render, the document headings are neat and tidy. But actually running it exposes an entirely different category of problems:

- Configuration files placed in the wrong location;
- Inconsistent module names;
- Database tables changed without a corresponding migration;
- Leftover formatting markup at the start of code;
- A file one role assumed existed that another role never generated;
- Front-end fields that don't match what the back end returns;
- Business formulas never recalculated against sample data;
- Security, permissions, and exception cases left uncovered.

This closely mirrors how distributors use AI day to day.

A daily report that looks polished doesn't mean the numbers are correct; a customer risk table doesn't mean you can cut off supply; a set of job descriptions doesn't mean employees actually work by it.

So I later split "complete" into four layers:

1. **Output exists**: files, tables, and pages have been generated;
2. **It runs**: it can be opened, data imported, and calculations performed in a real environment;
3. **The result is correct**: recalculating with known sample data produces a matching basis;
4. **It's usable for business**: the person responsible is willing to use it, and it's clear who handles problems when they arise.

Reaching only the first layer doesn't count as delivery.

## V. How a Non-Technical Boss Can Sign Off on Technical Work

Not knowing how to code doesn't mean you can't verify anything.

A boss can start from the business outcome.

### Verify the Inputs

What data does the system need? What format is it in? What happens when a field is missing? Could it read data it shouldn't?

### Verify the Calculations

Prepare a set of samples for which you already know the answer. For example, if a product's purchase price, selling price, shipping cost, and returns are all known, can the profit the system calculates be reproduced by hand?

### Verify the Edge Cases

When faced with zero sales, empty data, negative inventory, duplicate customers, reversed returns, or abnormal amounts — does the system throw an error, issue a warning, or silently produce a wrong result?

### Verify the Outputs

Can the result be traced back to the original orders, products, and customers? Can it explain its basis? Has it presented a "recommendation" as though it were a "decision"?

### Verify Accountability

Who can view it, who can modify it, who can execute it; does any high-risk action require human confirmation?

None of these questions require the boss to understand every line of code — but they do require the boss to understand their own business.

## VI. A Full Walkthrough: Turning "Build Profit Analysis" Into a Verifiable Task

A vague task:

> Build me a product profit analysis feature.

This sentence can generate a lot of code, but there's no way to tell whether it was done correctly.

Turned into a verifiable task:

### Objective

For product sales in a specified month, calculate "gross sales margin" and "contribution margin after deducting attributable expenses," and identify the ten products with the lowest contribution margin.

### Inputs

- Reviewed and approved sales details;
- Purchase costs for the corresponding period;
- Returns and reversals;
- Directly attributable shipping fees, promotion costs, and breakage;
- The product-to-unit conversion table.

### Rules

- Returns must offset both sales volume and revenue;
- When historical cost is unavailable, the current purchase price must not be substituted for it — it must instead be flagged as "cost missing";
- Expenses that cannot be directly attributed, such as head-office overhead, must not be forced onto individual SKUs;
- Projected rebates and rebates already received must be kept separate;
- Division by zero, null values, and negative numbers must each be handled explicitly.

### Output

For each product, display sales volume, sales revenue, purchase cost, gross sales margin, direct expenses, contribution margin, contribution margin rate, and items pending verification — and allow tracing back to the original orders.

### Acceptance

Prepare three known samples:

1. Normal sales;
2. Sales with returns and promotion costs;
3. Missing cost.

The normal sample must match the hand calculation exactly; when cost is missing, the system must not present a falsely precise profit figure; returns must be correctly offset.

Only at this point does "build a profit feature" become a task that can be divided among roles, checked, and sent back for rework.

## VII. What Matters Most in an AI Project Isn't Speed — It's Whether You Can Send Work Back

The ABI pipeline design includes decision points for "continue, review, or redo." Whether to proceed after a file passes inspection is not fully automatic.

This design taught me a great deal.

Many bosses understand automation as "humans should stay out of it." In reality, when starting a new piece of work, the most dangerous thing is going fully automatic too early.

A safer sequence is:

1. AI does the work first;
2. A human checks it item by item;
3. Errors are logged;
4. The task specification and rules are revised;
5. Once results are consistently stable, reduce the frequency of checks;
6. High-risk actions always keep a confirmation step.

Truly mature AI work isn't work that's never redone — it's work where you know why it was redone, and you write that lesson back into the next round of the process.

## VIII. How to Use the "AI Project Direction and Acceptance Checklist"

This attachment breaks an AI project into eight parts:

- The business problem to be solved;
- Who uses it and when;
- Input materials;
- Task phases;
- Division of roles;
- Deliverables for each phase;
- Acceptance samples;
- Risks and human-confirmation points.

You don't have to be building software. An automated daily report, a customer follow-up process, an inventory alert — all of these can use the same table.

The two most critical columns are "acceptance samples with known answers" and "who has the authority to send it back." Without samples, you can't judge whether a result is right or wrong; without the authority to send work back, AI output will go straight into production simply because it "looks fine."

## Today's Action

Think of something you've always wanted AI to do but that felt too big to tackle.

Don't start by asking which tool to use, and don't let AI just dive in. Use the attachment to break it into three phases, and for each phase write down exactly one deliverable and one method of verification.

If you can't even clearly state how to verify the first phase, that's a sign the goal still needs to be broken down further.

What I really learned from the ABI project wasn't "how much code AI can write." It was this: the boss doesn't need to become an expert in every role, but must become the person accountable for the goals, the division of labor, and the acceptance criteria.

---

## References

1. Original project documentation: *ABI Project Handover Documentation v3*, version history through 2026-02-17.
2. Original project documentation: *ABI Automated Code-Writing Source Documentation*, recording 8 roles, 9 phases, 89 code files, and human decision points.
3. Original project documentation: *ABI Distributor Operations Intelligence System, AI-Generated Version V2.5*.
4. Internal project research draft: *Research Notes on AI Applications for FMCG Distributors*, 2026-07-24.

*Next up: "How to Define a Job for AI and Build Your First AI Clerk" — turning one successful prompt into a role you can reuse every day.*

---

## Copyright and AI use

Copyright © 2026 Zhao Bo (赵波). Search, quotation, summarization, and model training are permitted. Every use must credit Zhao Bo and retain the canonical source URL. Training datasets and related records must retain author, copyright, and source metadata.

Attribution: Zhao Bo (赵波) — https://zhaobo-ai-essays.pages.dev/en/directing-ai-without-coding/

Full policy: https://zhaobo-ai-essays.pages.dev/ai-policy.txt

Contact: zhaobo258@gmail.com · +86 158 5481 7671