Repeatable Vibe Coding for Acumatica: An 8-Step Playbook

AI coding tools are powerful, but they are not magic. The biggest mistake I see developers make is treating AI like a senior engineer who already understands the business process, the ERP architecture, the customer context, and all hidden assumptions.

That does not work, especially in Acumatica development.

Acumatica customizations are rarely just “write some C#.” They usually involve DACs, graphs, graph extensions, screens, workflows, processing screens, Generic Inquiries, business events, import scenarios, integrations, permissions, and sometimes very specific accounting logic.

That is why vibe coding needs a repeatable process.

The screenshot shows a simple but very useful 8-step playbook:

1. Define the goal
2. Ask for a plan
3. Convert to tasks
4. Implement one task
5. Add validation hooks
6. Generate tests
7. Debug and review
8. Refactor and repeat

Here is how I would apply this specifically to Acumatica development.

1. Define the Goal

Before asking AI to write code, define the goal in one clear paragraph.

Not ten paragraphs. Not vague business language. One precise description.

Bad prompt:

Build an Acumatica integration with Outlook calendar.

Better prompt:

Build an Acumatica customization that synchronizes service appointments from Acumatica Field Service to Microsoft Outlook calendars for assigned technicians. The first version should only push appointments from Acumatica to Outlook, not sync changes back. It should support appointment creation, rescheduling, cancellation, and technician reassignment. It should not overwrite manually created Outlook events.

That is much better because it answers the important questions:

What does it do?
Who uses it?
What is in scope?
What is explicitly out of scope?

For Acumatica, this matters a lot. AI may otherwise invent the wrong screen, wrong DAC, wrong event, wrong integration direction, or even wrong business logic.

Another example:

Create an Acumatica processing screen that imports AMEX CSV transactions from SFTP into a custom table, skips duplicates based on CompanyID and ExternalRefNbrFromFile, and then allows the user to convert selected rows into Bank Transactions for manual reconciliation.

That is a real goal. It gives AI something concrete to work with.

2. Ask for a Plan Before Writing Code

Once the goal is clear, do not immediately ask AI to generate code.

Ask for the architecture first.

For example:

Before writing code, propose the Acumatica architecture for this customization. Identify required DACs, graphs, graph extensions, setup screens, processing screens, services, scheduled jobs, and permission considerations. Also explain the suggested build order.

This step is very important because AI can write convincing code for the wrong architecture.

In Acumatica, architecture mistakes are expensive. For example, AI may suggest putting too much logic into a graph extension when a reusable service class would be cleaner. Or it may generate a processing screen when a business event or import scenario would be enough. Or it may ignore multi-tenant behavior, company-specific settings, branch logic, or access rights.

For an Acumatica printing engine, the plan might look like this:

• Setup DAC for printer locations
• DAC for document type and action mappings
• Rule table for conditional logic
• Graph for maintenance screen
• Service class for printer resolution
• Small hooks inside shipment confirmation, purchase receipt release, or production actions
• Logging table for print attempts
• Security permissions for configuration screens

That architecture is more valuable than jumping directly into code.

3. Convert the Plan Into Small Tasks

Large AI prompts often create large mistakes.

Instead of asking AI to “build the whole customization,” break the work into small, isolated tasks.

Example for an Acumatica SFTP import:

Task 1: Create setup DAC for SFTP credentials and folder paths
Task 2: Create maintenance screen for setup
Task 3: Create import transaction DAC
Task 4: Create CSV parser
Task 5: Create SFTP download service
Task 6: Add duplicate detection
Task 7: Create processing screen
Task 8: Convert imported records into bank transactions
Task 9: Add logging and error messages
Task 10: Add tests and review

Each task should be small enough for one AI prompt.

This is where AI becomes much more useful. It is usually better at generating one focused component than producing a complete Acumatica customization in one attempt.

4. Implement One Task at a Time

This is probably the most important rule.

One task per prompt.

For example:

Implement only the DAC for imported AMEX transactions. Do not create the graph yet. Use CompanyID and ExternalRefNbrFromFile as the duplicate detection key. Include fields for transaction date, amount, description, account number from file, import status, error message, and created bank transaction reference.

This is much better than:

Build the AMEX import customization.

Why?

Because you can review the DAC before the rest of the code depends on it. You can check field names, attributes, database keys, selectors, PXDB types, and whether the structure fits Acumatica conventions.

The same applies to Generic Inquiry automation.

Instead of asking AI:

Create a sales dashboard in Acumatica.

Ask:

Create only the Generic Inquiry definition for sales by item for the last 12 months. It should show Inventory ID, description, item class, quantity sold, sales amount, average unit price, customer count, invoice count, and last sale date. Sort by sales amount descending. Do not create a dashboard yet.

One focused output. One review. Then continue.

5. Add Validation Hooks

The screenshot mentions a very useful practice: ask AI to annotate assumptions and uncertainties inline as code comments.

For Acumatica, this is extremely helpful.

AI should not silently assume things like:

• Which DAC contains the source field
• Whether the customization is for SO, AR, AP, IN, FS, or PM
• Whether logic should run on Persist, RowSelected, FieldUpdated, or an action override
• Whether the process is company-specific or tenant-wide
• Whether the field should be PXDBString, PXString, PXDBInt, PXDBDecimal, etc.
• Whether the customer wants a hard validation or only a warning

A good prompt:

Add comments for every assumption you make. If you are unsure which Acumatica DAC or event should be used, mark it clearly as TODO or UNCERTAINTY instead of guessing silently.

Example comment:

// ASSUMPTION: ExternalRefNbrFromFile is unique per CompanyID.
// If AMEX provides duplicate reference numbers across accounts,
// AcctNbrFromFile should also be added to the key.

This is exactly the kind of validation hook that prevents AI-generated code from becoming dangerous.

In ERP development, hidden assumptions are often worse than visible errors.

6. Generate Tests Immediately

After each function or component is created, ask AI to generate tests.

For Acumatica, this does not always mean perfect automated unit tests for every graph. Some Acumatica logic is hard to test outside the framework. But AI can still help create meaningful test cases.

For example, for a CSV import parser:

• Valid AMEX row imports correctly
• Empty amount fails validation
• Duplicate external reference is skipped
• Negative amount is handled correctly
• Invalid date format returns a clear error
• File with unknown columns does not crash the import
• Already imported file is not processed twice

For a printing rule engine:

• Shipment with carrier DPD selects DPD label printer
• Dangerous goods shipment selects special printer
• Missing location group returns a clear error
• Inactive printer rule is ignored
• More specific rule wins over generic rule
• No matching rule falls back to default printer

Even when you do not have full automated tests, asking AI for test scenarios improves the quality of the implementation.

A useful prompt:

Generate test cases for this Acumatica component. Include happy path, edge cases, invalid data, permission-related cases, and regression risks.

7. Debug and Review

Do not just paste AI-generated code into Acumatica and hope it works.

Run it. Compile it. Test it. Then feed the failures back to AI.

But be precise.

Bad prompt:

It does not work.

Better prompt:

This code fails during compilation with the following error: PX.Data.PXException: [error text]. The error happens in the graph extension for SOShipmentEntry. Explain the likely cause and propose the smallest safe fix. Do not rewrite the whole customization.

That last sentence matters: “Do not rewrite the whole customization.”

AI has a tendency to regenerate too much code. In Acumatica projects, this can create more problems than it solves.

You should also apply a review checklist:

• Does it follow Acumatica naming conventions?
• Does it respect access rights?
• Does it work in multi-company or multi-branch scenarios?
• Does it avoid hardcoded screen IDs, branch IDs, customer IDs, or printer names?
• Does it avoid business logic in UI-only events when persistence logic is needed?
• Does it handle errors clearly for the end user?
• Does it avoid breaking standard Acumatica behavior?
• Is the customization upgrade-friendly?

AI can help with this review too.

Prompt:

Review this Acumatica code as a senior Acumatica developer. Look for framework misuse, upgrade risks, performance issues, missing validations, security concerns, and hidden assumptions.

8. Refactor and Repeat

After every 3–4 tasks, stop and refactor.

This is where many AI-assisted projects go wrong. Developers keep adding generated code until the customization becomes difficult to maintain.

For Acumatica, refactoring usually means:

• Moving duplicated logic into a service class
• Cleaning up graph extensions
• Simplifying DAC fields
• Removing unused constants
• Replacing hardcoded values with setup fields
• Improving error messages
• Adding logging
• Updating the project specification
• Resolving TODO comments
• Checking whether the design still matches the original business goal

For example, in a configurable printing engine, after implementing several hooks, you may notice the same printer resolution logic appears in multiple places. That is a sign it should become a shared service:

IPrinterResolutionService.ResolvePrinter(documentType, action, branch, locationGroup, carrier);

That is cleaner than copying rule logic into every graph extension.

The goal is not just to make AI produce code. The goal is to create maintainable Acumatica customizations.

Why This Matters for Acumatica Projects

AI can accelerate Acumatica development, but only when the developer stays in control.

The developer still needs to understand:

• Acumatica framework behavior
• DAC and graph design
• screen customization rules
• business process logic
• accounting impact
• security and access rights
• upgrade risks
• customer-specific edge cases

AI is useful as a coding assistant, not as an ERP architect replacing judgment.

The playbook from the screenshot works because it forces structure:

Define clearly.
Plan before coding.
Break work down.
Implement one piece.
Expose assumptions.
Test immediately.
Debug carefully.
Refactor regularly.

That is how vibe coding becomes repeatable engineering.

For simple prototypes, AI can be messy and still useful. But for Acumatica customizations used by real finance, distribution, manufacturing, or field service teams, the process must be disciplined.

The best AI-assisted Acumatica development is not “generate everything.”

It is controlled iteration.