Why coding agents still need expert interviews

Consider an illustrative requirement: discounts above 20% need Finance approval. It names a threshold and an approver. An implementation can follow directly.

A domain expert might add that an overdue invoice places the entire request on hold, including requests with an approved discount. Another might describe a legacy screen that permits an override. Neither statement alone tells engineering whether the new application should preserve that override.

The useful follow-up is specific: when Finance approves the discount but the account is on hold, can the request proceed? If an override exists, who is authorized to use it? An answer can establish precedence, reveal a restricted exception, or identify a decision that still has no owner.

This is a constructed example, not a customer result or a measured RuleFoundry accuracy claim.

Kiro's requirements analysis checks for conflicting constraints, ambiguities, unstated assumptions and missing edge cases. It presents clarifying questions and updates requirements as the user resolves them. Generating specifications or asking questions alone is not a distinctive capability.

AWS Transform's mainframe workflow includes business-logic extraction from code. That helps establish implemented behavior. A policy document, manual workaround and the desired replacement behavior can still disagree with that implementation.

These tools belong in the workflow. The question is whether they already have the information needed for this particular decision, and who can supply or authorize what is missing.

• Kiro: Analyze Requirements
• AWS Transform: mainframe workflow

An experienced operator may remember the account that was blocked, the exception Finance rejected, or the month-end workaround. Organizing those experiences into a complete specification is a separate task. A focused conversation gives that person concrete situations to react to without first preparing a polished document.

Ask what changes the outcome, what happens at the boundary, which rule takes priority, and what remains undecided. Screen context can help someone explain the work. A screen sequence alone does not establish why a decision was made or whether it should be preserved.

Read the interpretation back. An expert must be able to correct it, identify a different decision owner, or say they do not know. Agreement with a fluent summary is weaker evidence than checking it against a concrete case.

RuleFoundry is a business logic extraction platform. Its guided Extractions focus on expert explanation, follow-up questions and outputs that people can review and reuse. The reusable representation of captured knowledge is the Logic Twin.

The useful result is a clearer account of conditions, exceptions, precedence and open questions. Voice is an interface; a finished conversation or a polished artifact does not prove that every rule is correct. Review the result before building from it.

Recordings and existing documents can provide useful context. Automatic recording/document ingestion and project-wide reconciliation are development work, not capabilities this article promises from the current interview experience. Check the current product workflow and available integrations before planning a rollout.

• Current RuleFoundry outputs
• Integration availability and access

In a supported, authorized integration, the coding-agent user confirms the exact topic, description and participant for one scoped Extraction request. The participant can be the user or another expert. The person follows the RuleFoundry app link and completes the conversation there; the integration does not conduct the live interview inside the coding agent. After completion, it can read finalized artifacts the user is authorized to access.

The engineer can then ask the agent to propose an implementation and tests from those artifacts. Finalized does not mean every decision is settled: preserve partial status, review requirements and unresolved questions instead of filling gaps with invented rules. If a material answer is still missing, propose a new targeted Extraction request for the user to confirm. Review the expert's answer and the resulting code before relying on either.

• Supported integrations and permission boundaries

If the answer is already in a reliable document, a document assistant may be sufficient. If the task is understanding implemented legacy behavior, code-analysis tools belong in the workflow. If an engineer already knows the requirements, a coding agent may be able to proceed directly.

When the missing input is someone's operational judgment, a focused expert Extraction is worth testing. Begin with the engineering question, review the resulting logic with the knowledgeable person, and keep unresolved decisions visible in the handoff.

A general assistant can also help conduct an interview. RuleFoundry's case must be demonstrated through the complete experience: expert effort, useful rules recovered, unsupported claims avoided, and the next team's ability to use the result. This article describes a workflow and a product hypothesis, not a comparative benchmark.

Choose a pricing rule, eligibility decision, approval path or operational exception your team needs to understand. Explain it yourself or ask the person who handles it. Judge the result by whether it helps the next implementation decision.