GS interviews Lightrun's Ilan Peleg on AI coding tools

As AI-powered coding assistants gain traction across enterprise technology teams, financial institutions are weighing their productivity benefits against the unique risks of deploying them in highly regulated, high-stakes environments. In banking and payments, where milliseconds matter and even minor errors can ripple across millions of transactions, the margin for experimentation is slim.

Ilan Peleg, CEO and co-founder of Lightrun, shares his perspective on where AI coding tools deliver real value, where they introduce hidden vulnerabilities, and what banks and fintechs must evaluate before allowing them anywhere near production systems.

The Green Sheet: What are the strengths of AI-powered coding assistants, and when do they fall short in banking, payments and fintech?

Ilan Peleg: AI coding assistants are valuable in financial engineering because they reduce friction in routine work like generating code, scaffolding services and navigating large legacy codebases. They can take hours of repetitive plumbing work and cut it down to minutes, freeing engineers to focus on more complex problems.

Where they fall short is reliability and operational awareness. An AI assistant can generate syntactically correct code while missing real constraints like authentication policies, network rules, or dependency behavior in staging and production. What looks right in an IDE can fail under concurrency, partial failures or other conditions common in financial systems.

GS: Why can seemingly small AI coding errors have outsized consequences in financial systems?

IP: In financial systems, there is no such thing as a trivial error. These platforms process millions of transactions daily and have little tolerance for partial failure. A few milliseconds of added latency can cascade under load, a wrong assumption can cause duplicate charges, and a missing circuit breaker can degrade an entire payment rail.

What makes this harder is that AI-generated code often passes initial tests and static analysis but fails under real traffic and distributed conditions. The real cost is often not just the bug itself, but the time it takes to detect and diagnose it. The real damage is often not just the mistake itself, but the delay and uncertainty before engineers can pinpoint where it went wrong. For systems that move money, lost time means lost revenue and critically harmed trust.

GS: What makes real-world banking and payments environments especially difficult for AI coding tools to navigate safely?

IP: Banking and payment environments are especially challenging for AI coding tools, because they combine complex architecture with regulatory and zero-trust network policies, scoped authentication, and hardware security module constraints that cannot be inferred from a local file.

A modern financial stack spans mainframes, microservices, third-party APIs and strict security boundaries. AI-generated code that is built on the assumptions of software behaving in an expected manner will break in systems shaped by retries and network variance. And because these systems handle sensitive data, an AI-logged debug variable can become a privacy or compliance incident if it includes PII.

This risk is a daily operational concern, which is why teams invest heavily in runtime guards and auditability.

GS: What should banks and fintechs evaluate before allowing AI coding assistants into production systems?

IP: Financial institutions should treat AI coding assistants like any other critical engineering dependency. They need to understand what context the tool actually has. Can it see live telemetry and environment constraints, or is it blind to them? How are sensitive data policies enforced beyond the IDE?

Just as important is whether engineers can validate behavior in staging and production quickly and confidently. The goal should be measurable outcomes like change failure rate and MTTR, not just velocity. Only when an assistant can be governed, audited and paired with strong runtime validation should it touch sensitive production paths.

GS: What does full visibility into how code behaves after deployment mean, and why is it so critical for AI-driven development?

IP: Full visibility means understanding how code actually runs when real traffic flows through it. That includes inputs, execution paths, timeouts and behavior under real failure modes like retries and partial outages.

Traditional telemetry leaves teams guessing through logs and redeploys. As AI increases the volume of code changes, that approach doesn't scale. Runtime visibility lets engineers confirm assumptions, isolate faults quickly, and validate fixes without days of trial and error.

GS: How do you see AI coding assistants evolving for financial services over the next few years, and what safeguards will matter most?

IP: AI coding assistants are evolving into active participants in code design and remediation. But today, they still can't see how the code actually behaves after deployment. Lightrun is focused on closing that capability gap. With Runtime Context model context protocol, AI coding assistants can safely inspect how their code behaves in deployment without changing code or impacting users, which is especially critical during code freezes.

Once equipped with Runtime Context, AI assistants can understand dependencies, latency, and distributed behavior and propose designs that are resilient by default. That visibility has to be safe. In finance, runtime data often includes sensitive information, so safeguards like automatic PII redaction are essential. In payments systems, where failures propagate instantly across rails, that feedback loop is critical.

Notice to readers: These are archived articles. Contact information, links and other details may be out of date. We regret any inconvenience.