AI-assisted Smart Contract Engineering - From Acceleration to Assurance

AI can generate smart contract code quickly. The real differentiator is whether that code is produced through tested patterns, specialised agents, plus engineering discipline that makes quality repeatable.

Smart contracts are executable product architecture

At Ikigai, we have always treated Vault Core smart contracts as more than product implementation code. They are executable product architecture.

In a thin-core architecture, smart contracts carry much of the product logic that would traditionally be buried inside a core banking system. They define how financial products behave through time: how balances move, how schedules fire, how fees are charged, how postings are generated, how lifecycle events are handled, plus how customer outcomes are produced.

That is powerful, but it also creates responsibility.

A smart contract estate cannot be judged only by whether each product works in isolation. It also depends on whether product logic is structured deliberately: whether features are reusable, whether schedules follow consistent patterns, whether tests prove behaviour directly, whether features can be composed safely, plus whether future change can happen without rediscovering the same engineering problems.

The temptation in any individual product delivery is to optimise for local speed. But in a real core banking programme, the same concerns appear repeatedly across products: schedules, accruals, fees, due amount calculation, date handling, posting rules, notifications, lifecycle events, test setup, plus migration paths.

If every product solves these concerns differently, the codebase becomes expensive very quickly. The problem is not only duplication. The deeper problem is accidental architecture.

A product can pass its tests, go live, then still create long-term cost if its patterns cannot be reused, reasoned about, or safely changed. Every future product then inherits hidden work: developers have to rediscover the same patterns, avoid the same timing problems, wire the same configuration, then rebuild confidence from scratch.

That is not the model we want.

Smart contract delivery should be built around reusable architecture, strong behavioural tests, plus intentional engineering patterns that can be applied consistently across products, not heroics product by product.

Reuse needs more than shared code

Reuse in smart contract engineering is often misunderstood as a code extraction problem. Extract a few helper functions, create a few reusable feature modules, reduce duplication, job done.

That is useful, but it is not enough.

Real reuse means designing product behaviour so it can be composed safely across products, tested consistently, plus evolved without rebuilding confidence from scratch every time.

Schedules are a good example. From the outside, they look simple: something needs to run daily, monthly, at end of month, or on a specific date.

But the real complexity sits in the details: execution ordering, lifecycle interactions, date offsetting, skipped runs, special one-off runs, end-of-month behaviour, timezone behaviour, parameter wiring, account schedule tags, simulation coverage, BDD data setup, plus notification mapping.

This is why reusable templates matter. The point is not just to save time. The point is to make the architecture explicit.

A schedule register gives the product a single place where schedule timing plus execution ordering can be understood. Schedule modules give each event a clear boundary. Catalogue templates allow common behaviours such as skipping, offsetting, special runs, or end-of-month handling to be composed deliberately instead of copied manually.

That turns schedule engineering from project-specific plumbing into a reusable product architecture capability.

The same principle applies to the product contract itself. Product hooks should stay thin.

Hooks are runtime entry points. They should make the product lifecycle visible: what happens at activation, what happens on a scheduled event, what happens when postings are generated, what happens when parameters change.

They should not become the place where every calculation, parameter lookup, posting rule, schedule decision, validation, edge case, plus cross-feature interaction is implemented inline.

The product contract should compose the product. It should declare which features exist, wire them into the relevant lifecycle events, then delegate the feature behaviour itself to bounded modules. Some composition belongs directly in the product contract. Some belongs in dedicated orchestrators, especially where multiple features combine into a reusable product behaviour.

That separation keeps the product readable. It also makes reuse more realistic, because the team is not just sharing code fragments. It is building tested product capabilities that can be assembled deliberately across products.

AI turns pattern libraries into assurance systems

Ikigai has always taken the view that writing smart contracts is not the hardest part.

Writing smart contract code is relatively easy. Proving that behaviour is correct is where the rare experience sits.

In this context, quality means more than clean code. It means deterministic financial behaviour, correct postings, safe lifecycle execution, readable product intent, strong regression protection, plus evidence that future change has not broken the product.

The real effort is the engineering discipline around the code: making sure schedules fire at the right time every time, postings are correct, lifecycle events happen in the right order, edge cases are covered, race conditions are avoided, date handling is safe, tests prove intended behaviour, expose unintended behaviour during development, plus future change does not quietly break existing products.

AI makes this more important, not less.

An AI agent can generate code quickly. But without the right architecture around it, it can generate inconsistency just as quickly. It is extremely good at repeating patterns, which is powerful when the patterns are strong, but dangerous when they are weak. It can put logic in the wrong layer, miss lifecycle interactions, duplicate product concepts, bypass test obligations, or produce code that looks reasonable while weakening the long-term quality of the estate, all within seconds.

Historically, pattern libraries, templates, plus accelerators were often positioned around delivery speed. They reduced repeated effort. They helped teams move faster. That still matters, but as AI makes raw code generation increasingly available, speed alone is no longer the most interesting differentiator.

The stronger differentiator is quality by design.

A mature pattern library does not just give AI something to copy. It gives AI a tested path to follow. The pattern already encodes implementation structure, known edge cases, schedule behaviour, posting expectations, lifecycle ordering, product configuration choices, plus regression coverage.

But the library is only one part of the system. The way AI applies the library matters just as much.

That is why Ikigai has invested not only in reusable smart contract templates, but also in specialised AI agents plus skills that are native to those templates. That includes agents for smart contract build, testing, refactoring existing contracts into the defined feature architecture, version uplift such as v3 to v4, plus review against hundreds of Ikigai lessons learned from real smart contract engineering work.

Those lessons cover areas such as schedule timing, posting construction, hook design, parameter handling, simulation setup, feature composition, plus common Vault Core failure modes.

The point is not to leave a general-purpose AI agent to guess how a Vault Core smart contract should be structured. The intended application of the pattern has to be explicit: which pattern is being used, how it should be applied, where the feature logic should live, how it should be tested, how it should be reviewed, plus which known failure modes it needs to avoid.

That changes the role of AI.

It is no longer just faster code generation. It becomes guided composition from tested product architecture, supported by specialised agents that apply the patterns methodically.

Specialist agents improve consistency, but they do not remove engineering accountability. They make expert review more focused by bringing the code closer to the intended architecture before a human reviews it.

That is where AI-assisted smart contract engineering becomes credible: reusable patterns, deep behavioural coverage, specialised agents, plus a lessons-learned review loop that keeps the AI aligned with proven engineering practice.

Behavioural proof is the credibility layer

Reusable smart contract architecture is only credible if it is backed by strong behavioural proof.

Tests are not a quality afterthought. They are an input: the main way to prove that expected financial behaviour is met exactly. This matters even more when logic is reused across products, because code that worked in one product does not automatically work in another. Product shape, parameters, timings, posting expectations, boundary cases, customer journeys, plus feature interactions can all change.

The goal is therefore not just reusable code. It is reusable code backed by reusable proof.

Shared code without behavioural proof is dangerous, because financial product logic often fails at the edges: schedule timing, lifecycle transitions, date boundaries, fee interactions, early closure paths, skipped events, plus product-specific parameter combinations. A reusable schedule template is only valuable if it comes with a way to prove it behaves correctly. The same is true for fee features, lifecycle patterns, posting builders, or any other reusable product capability.

That means simulation tests, BDD scenarios, generated expectations, plus test structures that can prove the same core behaviour under different product configurations.

Good tests also prove behaviour directly.

If a schedule is expected to fire on a specific date, checking a resulting balance is only an indirect proof. The balance may be correct for the wrong reason. Another event may have posted the amount. A later correction may mask the earlier failure. A stronger test asserts the schedule execution itself: whether it ran, when it ran, plus how many times it ran.

The same principle applies across the product lifecycle. A loan can have the correct final balance while still accruing incorrectly during the term. A product can close correctly at maturity while still behaving incorrectly at the first repayment date. Financial products are lifecycle products, so the test suite needs to prove the lifecycle: origination, first due date, month-end, mid-life behaviour, rate changes, fee events, overdue paths, early closure, maturity, plus the points where multiple rules interact.

Unit tests have a different job from BDD tests. Unit tests prove the parts: calculation rules, edge cases, parameter combinations, small pieces of feature logic. BDD proves the product: end-to-end behaviour through time, especially where multiple features interact. We explored that testing discipline in more detail in our earlier article on smart contract testing with BDD/Gherkin.

When those layers are blurred, unit tests can become slow simulations in disguise, while BDD scenarios can become overloaded with implementation detail.

For AI-assisted delivery, this kind of coverage is not optional governance. It is the feedback system that tells the agent, plus the engineer reviewing it, whether the product still behaves correctly.

Example: timezone-agnostic BDD notation

UTC timestamps are precise, but not always business-readable. In Pacific/Auckland, this timestamp:

2022-01-30T11:00:08Z

means local midnight plus 8 seconds on 31 January.

That is technically correct, but it forces every reader to translate UTC back into business time. A better scenario says the timezone explicitly:

Given the account operates in timezone "Pacific/Auckland"

Then local timestamps can be written directly:

2022-01-31T00:00:08

UTC timestamps with Z can still be used where needed, so the notation remains backward-compatible.

The point is not the timestamp format itself. The point is that good test architecture makes product behaviour easier to read, easier to review, plus easier to reuse across timezone contexts.

Quality by design

Reuse in smart contract engineering is possible, but it does not happen by accident.

It needs deliberate seams, stable module boundaries, clear ownership of schedule lifecycle, business logic, posting generation, parameters, notifications, plus test setup. It needs patterns that are small enough to compose, but complete enough to be useful. It needs tests that prove behaviour, not just implementation.

That is what turns reusable code into reusable product capability.

AI makes this discipline more valuable, not less. The faster code generation becomes, the more important it is to control the patterns being repeated, the tests proving them, plus the review loops keeping them honest.

The future of AI-assisted smart contract engineering is not just better prompting.

It is quality by design.

‍