IFS and AI Coding Assistants: A Practical Guide for Developers

AI coding assistants have become fixtures in modern development workflows. GitHub Copilot, ChatGPT, and Claude promise faster code generation, fewer typos, and less time on boilerplate. For IFS developers—especially those navigating the complexity of Marble scripting, PL/SQL Oracle integration, and IFS-specific business logic—these tools offer genuine productivity gains. But they also come with real limitations and hidden risks.

This guide cuts through the hype. We'll explore where AI assistants genuinely help IFS development, show you proven prompt patterns that work, walk you through a quality assurance workflow, and be honest about where they fall short. The goal: use these tools to amplify your skill, not replace it.

Where AI Assistants Help IFS Development

1. Boilerplate and Scaffolding

AI excels at generating structural code—the repetitive, predictable kind. For IFS developers, this includes:

• PL/SQL procedure templates: Creating cursor loops, exception handling, and standard utility procedures.
• IFS model scaffolding: Drafting projection, client, fragment, entity and enumeration structures when you provide a real target-release example. There is no generic C#-style Marble event-handler syntax.
• REST API clients: Drafting OAuth-aware request/response handling for a customer-owned integration service. Secrets, endpoint discovery, retries and IFS projection contracts still need environment-specific engineering.

Real example: Instead of typing out a standard Oracle procedure skeleton from memory, ask Claude or ChatGPT to generate it. You'll have a working foundation in seconds, which you can then customize for your specific logic.

Prompt: "Using the attached customer-layer `.plsql` example from our target IFS Cloud
release, draft a procedure that accepts `company_` and `supplier_id_`. Use the public
supplier APIs listed below; do not query or update `_TAB` objects, do not commit, and
preserve the IFS parameter/name conventions. Add an exception handler only if it adds
context, always re-raising the original failure and backtrace."

The assistant will produce syntactically correct boilerplate, freeing you to focus on the business logic.

2. SQL Query Drafting and Optimization

ChatGPT and Claude are surprisingly competent at writing SQL queries, especially when given table schemas and clear requirements. For IFS, this means:

• Reporting-query drafts: SELECT statements over documented views in Apps 10 or an approved customer-controlled database. For managed IFS Cloud, prefer projection APIs or the contracted analytics/data service rather than assuming SQL access.
• Data validation scripts: Identifying missing or inconsistent records.
• Performance tuning suggestions: Explaining why an index might help or where a join could be reordered.

Caveat: AI-generated SQL often lacks IFS-specific table relationships and custom views. You must validate against your actual schema and test before deployment.

3. Documentation and Code Comments

AI assistants are excellent at generating documentation from code, or vice versa. For IFS teams managing legacy code or large refactoring efforts:

• Ask the tool to explain what a Marble method does.
• Request concise inline comments for complex PL/SQL logic.
• Generate README sections for custom modules or integrations.

This saves substantial manual time and ensures consistency.

4. Rapid Prototyping

When designing a new integration or testing a concept, AI can help you prototype quickly. Generate a skeleton, test it in a sandbox, and iterate. This exploratory approach is where AI shines—when you're not yet committed to a production path.

Prompt Patterns That Work for IFS Code

Effective prompting requires precision. Generic queries like "write a SQL query" yield generic results. IFS-specific prompts yield better code.

Pattern 1: Context-Heavy with Examples

Include the minimum necessary metadata, approved object names, expected outputs, and version context. Do not paste production rows, credentials, personal data, proprietary source, or an unrestricted schema dump into a service that your organisation has not approved.

Prompt: "In our target IFS release, the approved public supplier/contact views expose
these columns: [paste exact view and column metadata]. Draft a read-only query that
returns at most one primary contact email for `supplier_id_`. State how ties are resolved
and distinguish an unknown supplier from a supplier with no primary contact. Do not
invent object names."

This works because the model has concrete context. It knows your table structure and can generate code aligned with your schema.

Pattern 2: Persona-Based Prompting

Ask the AI to adopt the role of an expert in your domain.

Prompt: "Act as a senior IFS Cloud developer with 10 years of experience.
I need to validate a customer order before release. First compare standard availability,
credit-control, workflow and projection-action options in the attached target-release
documentation. Identify the real extension point; only then outline the entity,
projection, client and PL/SQL artefacts required. Do not invent a generic event hook."

Persona prompts nudge the model toward more thoughtful, expert-level answers. You'll get not just code, but reasoning about design patterns and gotchas.

Pattern 3: Iterative Refinement

Start with a basic request, then refine.

Initial prompt: "Write a SQL query to list all overdue purchase orders in IFS Cloud."

Follow-up: "Now modify it to exclude orders marked as on-hold and add a column
showing the number of days overdue. Also, order by days overdue descending."

Next: "Convert this to a PL/SQL procedure that accepts a p_days_threshold parameter.
Only return orders overdue by more than that number of days."

Iterative refinement lets you build complexity step-by-step, keeping the conversation context alive. The model remembers the initial structure and builds on it logically.

Pattern 4: Reference Material Integration

Provide IFS documentation snippets or your own code standards, then ask the model to follow them.

Prompt: "Here is our IFS development standard for error handling:
[paste your error handling template]

Now design a durable exchange-rate integration. Keep the remote HTTP call outside the
IFS database transaction, use our OAuth/retry/idempotency standard, and show which IFS
projection action or supported import operation the worker calls."

By anchoring the request in your standards, you ensure consistency and reduce the risk of generated code conflicting with your architecture.

Pattern 5: Ask for Review and Refinement

Once the AI generates code, ask it to review itself.

Follow-up: "Review the code above for potential issues. What could break if
the supplier_id doesn't exist? What about NULL values in the contact fields?
Provide an improved version."

This "self-review" prompt often catches logical gaps and produces more robust code.

Quality Assurance Workflow: Treating AI as a Junior Developer

The best mental model: treat AI-generated code like code from a competent junior developer—useful, but requiring careful review.

Step 1: Static Analysis

• Validate model sources with the target IFS Developer Studio/generator and compile PL/SQL in an authorised build environment. Use compatible static analysis for additional rules; SQL*Plus executes compilation scripts but is not itself a linter.
• Check for obvious issues: unused variables, undefined tables, missing exception handlers.

Step 2: Logic Verification

• Does the code do what you asked? Trace through it mentally.
• Are assumptions baked in? (e.g., "this assumes the table has a primary key—does it?")
• Does it handle edge cases? (empty result sets, NULL values, duplicate rows)

Step 3: Schema and Context Validation

• For SQL: verify all table and column names exist in your IFS instance.
• For IFS source: ensure file types, annotations, generated signatures, entity/action contracts and client syntax align with the target release.
• Run against a dev or sandbox environment first, never production.

Step 4: Performance Testing

• For SQL: check query plans. Does it use indexes efficiently?
• For projections and PL/SQL: inspect generated SQL, pagination, row counts, call frequency and transaction duration; client models do not contain arbitrary database loops whose “memory leak” can be profiled like application code.

Step 5: Security Review

• SQL Injection: Is user input properly parameterized? (The model sometimes forgets this.)
• Privilege escalation: Does the code assume permissions you don't have?
• Data exposure: Does it leak sensitive info (API keys, passwords, PII)?

Step 6: Team Review

• Code review isn't optional. Show AI-generated code to a peer before merging.
• Peer reviewers catch context the AI missed and spot downstream issues.

Where AI Coding Assistants Fall Short in IFS Development

1. IFS-Specific Context and Business Logic

AI models are trained on public code. IFS-specific knowledge—especially your custom module configurations, non-standard table layouts, and business rules unique to your enterprise—isn't in that training data.

Real problem: ChatGPT suggests using a standard IFS table that doesn't exist in your version, or recommends an approach that conflicts with your customizations.

Solution: Be explicit about your context. Share relevant schema details and architecture decisions. The more specific you are, the better the output.

2. Hallucinations and Silent Failures

AI sometimes generates code that looks syntactically correct but doesn't work. Worse, it doesn't warn you—it confidently produces incorrect code.

Common failures in IFS/SQL contexts:

• Suggesting deprecated PL/SQL syntax or Oracle functions.
• Referencing IFS tables that exist in newer versions but not yours.
• Writing SQL that runs without error but returns wrong results.

How to mitigate: Test generated SQL in your actual environment before trusting it. For Marble, compile and run in a sandbox.

3. Complex Interdependencies and Legacy Systems

IFS implementations often involve:

• Legacy code with non-standard patterns.
• Complex table relationships and custom views.
• Performance-critical queries where a small logic change causes slowdowns.

AI struggles with these holistic, systemic concerns. It can write syntactically correct code that creates technical debt or performance nightmares.

Real example: The AI generates row-by-row PL/SQL that appears correct on 1,000 records but is too slow at production volume. The answer is not automatically an index hint: measure the SQL plan and call profile, use set-based work or bounded batches where safe, check statistics and existing indexes, and route any new-index proposal through the IFS source/update process.

4. Architectural and Design Decisions

"How should I design this feature?" is a question AI can partially answer, but often lacks the deep context of your IFS deployment. It might suggest an approach that's theoretically sound but practically incompatible with your infrastructure, governance, or technical debt.

5. Understanding Implicit Requirements

IFS development usually involves implicit requirements—things "everyone knows" but aren't explicitly stated in a ticket. AI knows only what you tell it.

Example prompt failure:

"Write a SQL query to get customer sales data."

(The AI generates a basic SELECT. But your implicit requirement was:
exclude test/demo customers, use fiscal year logic specific to your region,
aggregate by product family, and flag records where data quality flags exist.)

The model produced technically correct code that's useless in context.

Solution: Be exhaustive in your prompts. Mention constraints, exclusions, and domain-specific rules upfront.

A Real IFS Exercise: Designing Order Validation Before Generating Code

Let's walk through a realistic scenario using these patterns.

The Ask

"Design validation for a customer order before the business action that needs the control. It should check:

1. Customer exists and is active.
2. Inventory exists for all ordered items.
3. No duplicate orders within the last 24 hours.
4. Customer credit limit is not exceeded."

The Prompt (Refined)

Act as a senior IFS Cloud developer. I am designing order validation for the exact
release [YOUR_RELEASE_AND_SERVICE_UPDATE]. I have attached the relevant projection
metadata, generated server signature and our approved extension standards.

Requirements:
- First identify whether standard credit control, availability checking, duplicate-PO
  controls or workflow already meet each rule.
- Identify the actual state/action and supported server extension point. Do not invent
  BeforeCreate, an OrderData class, or C#-style Marble code.
- Keep one atomic IFS validation inside the server action; do not call a remote system
  while holding the database transaction.
- Use standard APIs for customer, credit, inventory and order data. Do not query or
  update _TAB objects directly and do not commit.
- Return or raise errors using the target release's generated action and Error_SYS pattern.

Business rules:
- A customer is "active" if status = 'A' and credit_limit > 0
- Check inventory using the real site/location/availability rules; do not assume a
  universal numeric warehouse_id = 1
- Consider an order a duplicate if same customer_id and same total item count
  placed within 24 hours
- Credit check: sum(item_price * quantity) must not exceed
  (customer.credit_limit - outstanding_balance)

Include null/concurrency handling, permission and company/site access tests, a test
matrix, and an Update Analyzer review step. Treat diagnostic trace and business audit
as separate requirements."

Initial AI Output (Conceptual)

The useful first output is a gap list and artefact map, not a guessed “Marble method.” A weak answer will often:

• Uses a generic inventory check (might not account for your warehouse setup).
• Invent event hooks, entity classes, fields, or API signatures that do not exist.
• Assumes a simple credit balance calculation (doesn't account for pending invoices).

Refinement Loop

Follow-up: "The credit calculation should also subtract pending invoices,
not just posted invoices. Show me the updated query logic."

Next: "Separate durable business-audit evidence from temporary diagnostic tracing."

Then: "What edge cases might I have missed? Review the code above and suggest improvements."

After a few rounds, you should have a design that can be checked against actual metadata before asking for code. Iteration improves an answer; it does not prove that invented IFS objects are real.

QA Checklist

• ✅ Syntax: Do all model files validate and does the customer solution build in the target IFS toolchain?
• ✅ Schema: Do all referenced tables and columns exist?
• ✅ Logic: Walk through with sample data (active customer, insufficient inventory, etc.).
• ✅ Performance: Are expected order sizes, generated SQL, API-call counts, locks, and transaction duration acceptable?
• ✅ Security: Are SQL queries parameterized? (No injection risks.)
• ✅ Edge cases: What if an item doesn't exist? What if the customer is NULL?
• ✅ Team review: Show a senior IFS dev before deploying.

Key Takeaways

1. AI is a force multiplier, not a replacement. Use it to accelerate routine tasks—boilerplate, basic queries, documentation. Don't abdicate architectural thinking to a model.

2. Context is everything. The better your prompt, the better the code. Be explicit about schemas, business rules, and constraints. Generic prompts yield generic (often wrong) code.

3. Treat AI-generated code like junior code. Review rigorously. Test in non-production environments. Validate against your actual IFS schema and business logic.

4. Prompt engineering is a skill. Good prompts combine context, examples, and iterative refinement. Persona-based and reference-heavy prompting often outperform basic requests.

5. Know the limits. AI struggles with IFS-specific customizations, complex architecture, and implicit requirements. Use it for parts of the problem, not the whole solution.

6. Security and performance require human judgment. Code that's syntactically correct isn't automatically secure or performant. SQL injection, N+1 query problems, and unindexed searches are all areas where AI can confidently produce dangerous code.

7. Maintain code ownership and accountability. Even if AI generated it, you're responsible for what goes into production. This means thorough testing, peer review, and a clear understanding of what the code does.

The Path Forward

AI coding assistants are genuinely useful for IFS developers today. They accelerate routine work and reduce cognitive load. But they're best used as collaborators in a human-led process: you define the problem, prompt the AI, review the output, refine, test, and validate. The developer remains the architect; the AI is the implementation assistant.

As these tools improve—especially as they develop better domain knowledge of ERP systems like IFS—their value will grow. For now, the discipline lies in knowing where to apply them and where to trust your own expertise.

Start small. Use AI on lower-risk tasks: documentation, simple queries, boilerplate generation. Build confidence. As you refine your prompting technique and learn the model's strengths and weaknesses, you'll naturally find more valuable use cases.

The best IFS developers won't be those who use AI the most. They'll be those who use it most wisely—amplifying their skill without becoming dependent on it. That balance is where productivity gains come from.