沒有指定開發團隊，營運經理以智能體編碼工具交付客戶正式軟件

I am not a developer by title. I run operations for an IT services firm. Yet in the last year I have taken several client briefs to deployed, paying, production software without a development team assigned to them. Not prototypes: systems with payments, encryption, QA cycles and clients using them daily.

In one line: An operations manager with an agentic coding tool can take a client brief to a paying production system, but only with a fixed process that puts payments and security first.

The tool is an agentic coding assistant. The tool is not the point. The process is the point, and it is repeatable.

The shape of the process

Every build runs through the same eight stages. "Agent" is the coding assistant; "me" is the human in the loop. The gates are the points where nothing moves until a person has looked.

1. Brief to decisions. The agent reads the statement of work and lists every question a careful engineer would ask. I get the answers from the client: what happens when payment fails, who sees which fields, what "done" means for the first release. Gate: no code until the page of decisions is signed off.
2. Slice plan. The product is cut into vertical slices, each one a thing a user can do end to end. One form saved. Then payment. Then the admin view.
3. Build one slice. The agent builds it against the decisions page, in its own run.
4. Read the diff. I read every change before it is committed. Not to write it, to understand it. Gate: human review. A diff I cannot explain does not merge.
5. Test in a real browser, commit, record. The slice is exercised by hand on the running app, committed, and the tracker gets an entry with the measured time.
6. Security pass before the first real data. The five non-negotiables below are checked, and the deploy script's leak check runs. Gate: security testing. Personal data does not enter the system until this passes.
7. QA cycle. Test, file, fix, deploy, verify, close. Every bug is filed, even the ones fixed in the same breath, because the record is what the client is paying for.
8. Deploy and verify, then hand over. After each production deploy: the live URL is smoke-tested, the payment reconciliation job is watched through one real cycle, and the rollback path is tried once. Gate: deployment verification. Then the runbook, admin panel, environment notes and rollback steps go to the client, so their next developer can pick it up from the repository alone.

Stages 3 to 5 repeat per slice. Stage 6 happens once before real data and again whenever a slice touches personal data or money. Stage 8 happens on every release, not only the first.

What a travel platform taught me about payment-first design

The first product I built this way was a travel entry platform: travellers fill in the right government form for their destination and pay for the service. The obvious design records the application, then takes payment. That design produces orphaned applications, angry refunds, and support tickets.

The design that worked is payment-first and idempotent:

• Nothing is recorded as an application until the payment provider confirms the money cleared.
• Confirmation can arrive three ways: the provider's webhook, the customer returning to the success page, and a cron job that reconciles anything the first two missed. All three paths create the same record once, keyed on the payment reference, so it does not matter which arrives first or twice.
• Every state change is logged with a source. When a customer says "I paid and nothing happened", the answer is in the log within a minute.

This pattern is not specific to travel. Any product that takes money before doing work should be built this way, and an agent will not do it unless you ask.

Security defaults I no longer negotiate

Because the platform handled passport-level personal data, a few things became fixed rules for every build since:

• Personal data encrypted at rest with a modern authenticated cipher, keys outside the database.
• Documents behind short-lived signed links, never a public URL that works forever.
• Uploads checked by content, reading the file's magic bytes, not trusting the extension the browser sent.
• Secrets in environment files, never in the repository, and a check in the deploy script that refuses to ship if one leaks.
• Admin actions behind a real login with rate limiting, not a shared link.

None of these are hard. All of them are skipped by default in a demo, and demos have a way of becoming production.

Forty prototypes, and a colleague who now runs the process

The same process, with the security rules relaxed and mock data instead of real, is how our sales team gets prototypes. In six months we built more than forty for prospects across government, finance, healthcare and consumer businesses: secure messaging for a state agency, a fraud-detection demo, scheme portals, clinical dashboards. A prospect who can click through a working screen behaves very differently from one reading a proposal. Several of those prototypes went into investor pitches and converted into paid projects.

Once the process was stable I wrote it down as a standard operating procedure and trained a colleague to run it. That is the real test of a process: it works when you are not the one running it.

Results so far

• Production systems shipped this way: several, each with payments, encryption, a QA record and clients using it daily.
• Travel entry platform: six destination workflows live in production, payment-first and idempotent.
• Prototypes for sales: more than 40 in six months, across government, finance, healthcare and consumer businesses. Several went into investor pitches and converted into paid projects.
• Process handed over: written up as a standard operating procedure and run by a trained colleague without me in the loop.
• Security defaults applied on every build since: encryption at rest with keys outside the database, short-lived signed links for documents, uploads checked by content, secrets kept out of the repository with a deploy-time check, admin actions behind a rate-limited login.

What the numbers do not show is the shape of the work: most of the time goes into the decisions page and reading diffs, not into typing code. That is the part the agent cannot do for you.

Where it breaks

• When the brief keeps moving. Agents amplify indecision. Ten changes of mind cost ten rebuilds, fast but not free.
• When nobody reads the code. I read every diff. Not to write it, to understand it. The day I stop is the day something ships that nobody can explain.
• When "it works on the demo path" is accepted as done. The QA cycle exists to make that unacceptable.

If you run operations, product, or a small business, and you have a brief that has been waiting for a free developer for three months: the wait may be over. Just do not skip the page of decisions, the vertical slices, or the payment-first rule.

Originally published at kalpakkale.com, where I write Dispatches, field notes on putting AI to work.