Scaling AI Coding in Finance: 13 Hard Lessons from POC to Production

Q1: What Can POC Actually Validate?

ITPUB: POC phase can pick simple, clean samples for demo, but once pushed to full production, complex business, edge exceptions, and historical dirty data all surface, and effectiveness may drop off a cliff. Many enterprises equate POC success rate with scaled landing capability. From a practical perspective, what should POC validate? What content can POC fundamentally not validate but may determine project life or death?

Li Weining: The core of POC is not to prove "whether AI can write code", but to verify whether it can continuously and stably generate value under real enterprise constraints. The following are exactly what POC cannot validate yet decide project survival:

Engineering capability of requirements. Taking SDD (Specification-Driven Development) as example: does each requirement clearly define Who, What, Why? Are acceptance criteria quantifiable and testable? If requirements themselves are ambiguous, AI will only generate wrong results faster.

Continuous quality system. When requirements change, can specs, code, and tests update synchronously? This needs version management, automated testing, security scanning, and quality gates, plus folding eval sets into CI — regress immediately when model or prompt changes. POC's short cycle cannot exercise this system at all.

Organization and governance. Have engineers built the habit of reviewing AI output? Is process responsibility clear? Demo success relies on core people's manual lifting; scale relies on systems.

Summary: POC validates whether a single scenario can run through; what truly decides scaled landing is turning requirements, standards, and governance mechanisms into an executable, testable, traceable engineering system. Also, POC must not only look at single demo effect but also validate non-functional items — eval pass thresholds, token cost, whether permissions and audit can integrate into existing SDLC.

Q2: How to Trade Off Agent Capability Boundary vs Permission Boundary?

ITPUB: After Agent connects Jira, codebase, test platform, it gains ability to read requirements, view code, generate test cases, even submit changes. Stronger capability, greater risk. In strongly regulated financial environment, how to trade off between "capability boundary" and "permission boundary"? Will you proactively cut tempting capabilities for safety?

Li Weining: This is a trade-off mandatory for scaled landing: Agent's capability boundary must not be decided by what model "can do", but by business risk and governance requirements.

Basic principle: least privilege, tiered authorization, full traceability. Reading requirements, querying code, generating suggestions vs modifying code, submitting changes, operating production belong to different risk levels, must adopt different permission strategies. High-risk operations cannot be defaulted to Agent autonomous execution just because technically possible; must add human confirmation, approval flow, and quality gates. We do proactively cut some capabilities — e.g., letting Agent directly modify production config, auto-merge code to mainline; we sacrifice efficiency rather than open them.

Account design: If Agent reuses employee personal accounts, permissions must be explicitly defined inside Agent before issuance. Then every invocation links to specific Agent, specific task, specific initiator, satisfying financial audit "behavior attributable" requirement.

Four-layer security defense: ① Agent layer — permission tiering + human confirmation for high-risk ops; ② Sandbox layer — Agent execution in isolated sandbox, file and network access restricted; ③ Network layer — network isolation and egress control, prevent privilege escalation and data leakage; ④ Model layer — input/output content safety filtering, desensitization, hallucination protection. Each layer does its job; any single layer failure still has fallback. Meanwhile retain full replayable trace of Agent ops for regulatory forensics.

Q3: Will AI Coding's Incremental Risk Exceed Efficiency Gains?

ITPUB: AI Coding may rapidly implement wrong business logic and rapidly go live, amplifying speed and blast radius of business incidents. Internally assessed whether risk increment may exceed efficiency gains? What underlying yardstick does enterprise use to weigh?

Li Weining: We are very cautious on AI Coding risk control, but cautious ≠ no risk; rather pursue controllable, acceptable risk balanced with efficiency.

Underlying yardstick is two dimensions: Business Complexity × System Lifecycle, dividing system development into four quadrants, each adopting different AI participation depth. (See Table 1: Four-Quadrant Risk Yardstick & AI Participation Depth).

So risk increment and efficiency gains are not abstract comparison but concretely measured per quadrant: AI-amplified risks must be offset by upgraded verification means (automated testing, quality gates, production monitoring) within same quadrant. Where verification means lag, lower AI participation depth.

Q4: AI Era Effectiveness Evaluation System

ITPUB: AI Coding's efficiency gains hard to measure by lines of code. What effectiveness evaluation system established to simultaneously measure efficiency, quality, risk, and business value?

Li Weining: AI Coding applied to software development is like electricity applied to product manufacturing — we don't measure "how much electricity used", but look at final product output. So we measure from final deliverables.

Industry already has mature DevOps indicator system directly reusable: deployment frequency, lead time for changes, change failure rate, mean time to recovery (MTTR), naturally covering efficiency, quality, risk three dimensions simultaneously; no need to invent new metrics for AI.

Also, metrics are just numbers; cross-team comparison limited — business attributes differ too much. We care more about each team comparing against itself, watching whether trend continuously improves . Before/after AI introduction, same team's deployment frequency, failure rate, recovery time changes are the real effectiveness signals.

Output metrics like lines of code we basically don't use, because they measure "generation volume" not "value volume". Of course, AI-specific process metrics like suggestion acceptance rate, manual modification rate, review rework rate can serve as auxiliary signals, but always with DORA-type outcome metrics as primary.

Section 02: Agent Skills — Empowering Full SDLC

Q5: How to Prevent Skill "Silent Failure" After Passing Launch Review?

ITPUB: One Agent Skill depends on multiple external layers: MCP services, tool interfaces, knowledge base slices, LLM base version, enterprise internal context data. Any layer change causes Skill behavior drift, but Skill code/config unchanged. How to establish continuous validity verification mechanism?

Li Weining: Core idea: treat Skill as a mini App — a versioned asset — to govern, not a prompt fragment.

Concrete practice: build a Skill internal marketplace : everyone can contribute, comment, download Skills; platform runs automated evaluation on each Skill and maintains leaderboard. Leaderboard lets excellent Skills surface; user feedback drives continuous iteration — complaints rising and scores dropping are the earliest signals of Skill "silent failure".

But the risk pointed out indeed exists and is hidden: Skill itself unchanged, yet may silently fail due to runtime environment changes. Therefore version management must cover not only Skill itself, but must treat model base version, MCP services, tool interfaces, knowledge base, and context data as Skill's runtime dependencies , forming complete version baseline and dependency manifest — similar to dependency lockfile in software engineering. Any layer dependency change should auto-trigger impact analysis and regression verification: e.g., model upgrade or MCP interface change must first pass that Skill's eval set before rolling out.

Thus forming two defense lines overlay: leaderboard score trend provides continuous failure perception from real users; dependency-change-triggered auto-regression intercepts before problem reaches users. Combined, basically achieve Skill failure "perceivable, locatable".

Q6: High-Risk Skill Quality Evaluation System

ITPUB: Some Skills participate in code risk identification, compliance check, review opinion output, test case generation — high-risk actions whose output directly affects R&D decisions. Reality has "correct reasoning but wrong conclusion" or "wrong reasoning but accidentally correct conclusion" — true/false positives mixed. How to build quality evaluation system for Skill itself? What benchmark test sets for continuous evaluation?

Li Weining: Our Skill quality evaluation system and Agent safety control are designed as one, summarized as "Four-Layer Safety Control + Tiered Evaluation".

Four-layer safety control: Agent layer controls permission tiering and human confirmation; sandbox layer isolates execution env; network layer does access control and anti-leakage; model layer does content filtering, desensitization, hallucination protection. Any high-risk Skill output must pass these four constraints before influencing R&D decisions.

Build annotated benchmark test set per Skill category. E.g., code risk identification Skill uses historically real vulnerabilities and false positive samples as benchmark; compliance check Skill uses positive/negative cases of regulatory rules as benchmark.

Continuous evaluation focuses on three metrics: Accuracy — is conclusion correct; Reasoning Consistency — is conclusion self-consistent with reasoning, specifically identifying "accidentally correct" cases; Stability — result variance across multiple runs on same input. Evaluating reasoning and conclusion separately is key to identifying mixed true/false positives.

Evaluation embedded in continuous pipeline: Skill version change, dependency change, periodic (e.g., monthly) all re-run benchmark set; results fed back to internal marketplace leaderboard; Skills with evaluation degradation get demoted or removed.

Human sampling calibration: Sampling results used to revise benchmark set, forming closed loop.

Q7: Multi-Skill Orchestration Observability & Audit

ITPUB: Multiple Skills orchestrated into workflows; faults may propagate along call chain, upstream tiny deviations amplified level by level. Financial environment needs what observability? What chain info to record to satisfy fault diagnosis and regulatory audit?

Li Weining: First reduce error propagation probability at architecture level, then talk observability.

Skill design: Single responsibility + limited dependency depth. Skills analogous to software functional modules, insist on single responsibility; when collaboration needed, dependency levels controlled within 1–2 layers. Example: UI Skill, Backend Dev Skill, Unit Test Skill, Auto Regression Test Skill each do their job; Backend Dev Skill can depend on Unit Test Skill but not nest deeper. Deeper dependency = longer chain = higher risk of error amplification layer by layer.

Orchestration mode: Agent + SubAgent layered verification. For more complex workflows, use Agent + SubAgent orchestration pattern (consistent with Anthropic's Orchestrator-Worker, Plan-Execute patterns): main Agent plans, SubAgents execute in independent contexts, naturally achieving error isolation. Each Agent has independent context and input/output schema validation (gate) — equivalent to contract testing in microservices, effectively intercepting "upstream drift", and can run/test independently.

Why must do this? Because error is multiplicative decay : 0.99 × 0.99 × 0.99 ... ten steps later only ~90% left; longer chain = worse reliability. Using gated Agent boundaries to cut long chain into short segments is most effective means to control error amplification — errors don't silently propagate, but intercepted at nearest boundary.

Runtime protection: Confidence monitoring & escalation. For multi-step workflows, record confidence or validation result per step; once deviation exceeds preset threshold, immediately interrupt execution and escalate to human, preventing error propagating downstream.

Observability: Replayable full execution record. Treat each orchestration as a replayable execution, fully record: call chain (which Agent called which Skill, depended on which MCP service); input/output snapshot per step; model version & tool version (ensure reproducibility); human confirmation nodes & final decision basis. Fault diagnosis can replay layer by layer, precisely locate where deviation introduced; regulatory audit can fully reconstruct "who in what context, based on what info, made what decision".

Section 03: Internal Open Source Driving R&D Effectiveness Reconstruction

Q8: Gray Reuse & Risk Circuit Breaker

ITPUB: Internal open source amplifies "error diffusion effect": one Skill with hidden defect reused company-wide, defect batch-copied to multiple business lines. Need mechanisms like "gray reuse, risk circuit breaker"? Biggest resistance in practice?

Li Weining: Internal open source core philosophy is open collaboration — develop new features together via internal collaboration. Open collaboration has key prerequisite: technical and quality standardization, unification . We extended this philosophy to AI Coding era: operate Skill sharing platform via internal open source way, with supporting tech frameworks, APIs, databases, auth, UI, automated testing full standard suite. Because of this standardized base, even as developers flow and new features continuously added, product evolution speed and quality always held.

So for "error diffusion", our answer: Need governance, and mechanisms are ready-made.

Gray reuse: Skill marketplace comes with scoring leaderboard and automated evaluation. New Skills first small-scope trial; only after scores and eval pass are they promoted at scale — filter layer before diffusion.

Risk circuit breaker: Eval drops below threshold or concentrated complaints → auto-demote, remove. Skill defined lifecycle states (draft / trial / certified / deprecated); only certified state can be referenced by production flows; deprecated auto-notifies consumers to migrate. Marketplace removal is governance side; runtime side equally has technical handles — certified Skills get caller-side health checks, error rate spike auto-alerts, achieving "stop bleeding first, then remove".

Standard as defense: High reuse itself is double-edged sword — one bad Skill reused wider, impact larger; precisely why gray and circuit breaker guard entry and exit. Unified standards and eval let problems be identified and intercepted before diffusion, not after long-distance spread then investigate one by one.

Biggest resistance in rollout is not technical, but incentives . Contributor teams bear extra eval, Q&A, maintenance cost but no corresponding performance recognition; consumers tend "grab and use", unwilling to actively feedback issues. Therefore key step is fold Skill contribution and maintenance into R&D effectiveness performance caliber — let "maintaining public assets" and "delivering business features" be equally assessed and visible. That's the fundamental for this mechanism to run long-term.

Q9: Structural Imbalance of "Upstream Efficiency, Downstream Bottleneck"

ITPUB: AI coding boosts output speed, plus internal open source massive Skill reuse, but review, test, compliance headcount not expanded synchronously. Ever encountered "upstream efficiency, downstream bottleneck"? How should R&D effectiveness system respond?

Li Weining: Encountered, and we early clarified a stance: We pursue high-quality software fast delivery, not pure speed.

Review went through three phases: started with single-person review, expanded to multi-person cross-review, now evolved to multiple Agent auto-review primary, human gatekeeping secondary .

Analogy: AI makes coding engine more powerful, but review, test, compliance are car's steering, brakes, tires — engine stronger, if steering and brakes not upgraded, only crash faster into wall. To arrive fast and safe, entire engineering system must iterate in sync.

Our response: Downstream synchronized intelligentization, automation :

Review intelligentization: AI pre-review + human final review. AI handles spec, security, style initial screening; humans focus on business logic and architecture decisions.

Test automation: Test case design, writing, execution more generated and auto-maintained by AI, letting test assets keep pace with code output rhythm.

Verification system upgrade: Pre-release auto compliance check; pre-release final gate runs internal open source community crowd-test — let wider real users expose issues before release; then small-traffic canary, then full rollout; runtime with real-time monitoring and production incident rapid handling.

Essentially this is a Theory of Constraints (TOC) problem : system throughput determined by slowest bottleneck. Upstream sped up but downstream not upgraded, bottleneck just moved from coding to review and verification; overall effectiveness not improved. So effectiveness system's correct opening: continuously identify current bottleneck, pour automation and AI onto bottleneck, repeat — bottleneck keeps shifting, but continuous governance of bottleneck itself is effectiveness system's daily routine.

Q10: Community-Level Technical Debt Governance

ITPUB: Engineers heavily fork community Skills for secondary development; technical debt spreads from single project to community-level, scattered in public assets and various Fork branches. Essential difference from traditional project-internal technical debt? How must governance means change?

Li Weining: Community-level technical debt vs traditional debt has two essential differences:

Responsible entity blurred. Project-internal debt has clear owner; debt scattered in public assets and Forks — everyone affected, yet no one claims.

Repayment mechanism fails. Project-internal debt can be gradually digested via iterative refactoring; community-level debt needs cross-team coordination, high cost, weak drive, often long-term stranded.

Our governance approach: Classify internal open source into three modes by open risk , each mode's debt boundary completely different. (See Table 2: Three Internal Open Modes' Debt Ownership).

Pattern: more conservative mode → debt more centralized controllable; more open mode → must pre-agree debt ownership upfront. Therefore traditional "post-hoc refactoring" governance thinking doesn't work on community-level debt — must front-load debt ownership into reuse protocol.

Simultaneously, via Skill categorization and download rankings, let excellent Skills surface.

Section 04: Financial Digital Transformation

Q11: Will AI Become Technical Debt Amplifier?

ITPUB: Financial legacy systems old architecture, business logic tangled; LLM writes new features fast but can't understand decades of accumulated legacy logic. Will AI Coding just amplify existing technical debt? How to avoid AI becoming "accelerated leverage" amplifier?

Li Weining: Concern very real; we treat legacy systems with categorized strategies :

Business-critical legacy systems: Upgrade or replace. Under new architecture, let AI combine business docs and code for system functional analysis, test case design, then use AI Coding to accelerate legacy system upgrade/replacement — AI here is precisely debt-repayment tool, not leverage amplifier.

Legacy systems that must maintain status quo: AI Coding only does partial "scalpel-style" changes: keep existing system architecture, tech framework, code standards, test standards unchanged.

To avoid AI accelerating debt, key is one sentence: Maintain existing standards and quality gates unchanged, upgrade automated verification means. Standards not lowered, gates not removed; AI's speed dividend converts to safe value; conversely, if because AI fast we relax verification, AI generates faster, debt accumulates faster. So essence never "will AI amplify debt", but "has gate system kept up with generation speed".

Q12: MCP — Cure or Another Layer of Technical Packaging?

ITPUB: MCP highly expected to connect all tools via one protocol for free Agent orchestration. But financial internal systems complex, old systems lack standardized interfaces. Is MCP truly solving enterprise Agent integration hard problem, or another technical packaging? In real financial env, what hard limits can't MCP bypass?

Li Weining: Frankly, our MCP integration cases not many, mainly concentrated on Jira, Confluence, and some internal high-frequency tools; not every system MCP-enabled. Not doing full MCP-ization, mainly three real constraints:

Permission management mechanism needs improvement — MCP's auth, key management, data permission granularity still can't meet financial requirements;

Call frequency problem — must avoid Agent concurrency crashing existing systems; old systems never designed for high-concurrency machine calls;

Token cost — MCP tool definitions consume large tokens; more tools, context cost and selection precision both degrade.

Deeper reason: Agent must balance between deterministic (certainty) and dynamic (dynamism) . Precisely because Agent has dynamic planning capability, we must be especially careful handling MCP's auth & key management, permission management, data permissions, sandbox config. Like API keys such sensitive info, we keep outside sandbox; API permissions reuse existing permission management mechanism, not handed to Agent to freely hold.

So for relatively deterministic workflows — e.g., analyze and fix code vulns per vuln library — we prefer Agent + Skill + API integration way: deterministic steps walk deterministic API calls.

MCP is a good protocol, but it solves tool access standardization problem , not enterprise hard constraints like permissions, capacity, cost. Protocol is necessary condition, not sufficient condition.

Q13: Three Pieces of Advice for Resource-Constrained Teams

ITPUB: If only three pieces of advice for resource-limited, budget-tight fintech teams advancing digital transformation and planning AI Coding intro, which three? What can be parked for now?

Li Weining: Three advices boil down to one sentence: Be an engineer, not a programmer. Engineer needs three capabilities: Insight, Execution, Judgment.

Insight. Proactively discover which places in your business scenarios most suitable for AI Coding landing — whether requirements analysis, system design, or production incident handling. Enter from highest-value, risk-controllable scenarios, not follow tool hype.

Execution. After finding landing scenario, formulate plan, do PoC verification, persuade stakeholders to approve implementation. AI landing is an engineering transformation project, not just installing a plugin; needs ability to drive organizational change.

Judgment. AI Coding execution speed very fast, but if unable to judge whether AI did right, speed becomes burden. Therefore must establish quality standards, automated testing, verification methods before starting. Judgment standards before generation speed, to achieve overall efficiency gain.

Finally, few things can park first: no need to rush full-process Agent platform rollout, no need to rush all systems MCP-ized, no need to chase latest models. First run one scenario's " Generate — Verify — Measure " closed loop solid; that's far more valuable than spreading thin. Suggest write " Every scenario must have tests and metrics configured before running " into team's AI landing admission checklist.