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.
• Marble module scaffolding: Setting up event handlers, method signatures, and property definitions.
• REST API wrappers: Generating the connection strings, headers, and request/response mappings for integrating with external services.

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: "Create a PL/SQL procedure template for IFS Cloud that accepts two parameters
(p_company_id and p_supplier_id), declares a local cursor to fetch supplier details,
loops through results, and includes a WHEN OTHERS exception handler."

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 queries: Complex SELECT statements joining IFS Cloud tables.
• 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 schema details, IFS table names, and expected outputs.

Prompt: "I have an IFS Cloud instance with the following tables:
- suppliers (supplier_id, supplier_name, country_code, is_active)
- supplier_contacts (contact_id, supplier_id, email, phone, primary_contact)

Write a PL/SQL procedure that accepts a supplier_id and returns the primary contact
email address. If no primary contact exists, return NULL. Include error handling for
invalid supplier IDs."

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 write a Marble script that validates a customer PO against inventory levels
before allowing order creation. What is the best approach, and generate a code outline."

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 write a Marble method that calls an external API to fetch exchange rates.
Use our standard error handling pattern, and include logging for debugging."

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

• Run your code through a linter (SonarQube, SQL*Plus validation, Marble syntax checker).
• 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 Marble: ensure method signatures and event types align with your IFS version.
• 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 Marble: profile for memory leaks or infinite loops if the code involves large datasets.

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 a PL/SQL procedure that works correctly for 1,000 records but times out at 100,000. The problem is a missing index hint or an inefficient loop design—something a human expert would catch immediately, but the AI doesn't consider at scale.

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 Example: Generating an Order Validation Marble Script

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

The Ask

"Write a Marble script that validates a customer order before allowing creation. 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'm building an order validation module
in Marble for IFS version [YOUR_VERSION].

Requirements:
- Method name: ValidateOrderBeforeCreation
- Input: OrderData object containing customer_id, items[] (with item_id, quantity)
- Output: ValidationResult with isValid (bool) and errorMessages (string array)
- Side effects: Log validation steps for audit trail

Business rules:
- A customer is "active" if status = 'A' and credit_limit > 0
- Check inventory in the main warehouse only (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)

Return structure:
isValid: true/false
errorMessages: ["Customer inactive", "Insufficient inventory for item X", ...]

Include error handling for null inputs and database connection failures."

Initial AI Output (Conceptual)

The model generates a Marble method skeleton with the right structure, but it:

• Uses a generic inventory check (might not account for your warehouse setup).
• Doesn't include logging code (you specified it, but the model may not prioritize it).
• 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: "Add detailed logging at each validation step. Log both successes and failures."

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

After a few rounds, you have code that's substantially better than the initial output.

QA Checklist

• ✅ Syntax: Does it compile in Marble editor?
• ✅ Schema: Do all referenced tables and columns exist?
• ✅ Logic: Walk through with sample data (active customer, insufficient inventory, etc.).
• ✅ Performance: Does the inventory check scale for 10,000+ items?
• ✅ 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.