Large language models (LLMs), the AI systems that write text and code from plain-language instructions, let a technology team produce a working operations workflow in an afternoon. Everysk uses the same LLMs to build its own prototypes. This article explains what a prototype contains, what it cannot tell you, and the hardening phases that every Everysk workflow passes through before an institution relies on it.

Allan Brik  ·  October 2026

The question every technology leader is asking

A chief technology officer at a fund, a bank or a loan servicer can open an LLM-based coding assistant and describe a process: read our transactions, apply these monitoring rules, write the alerts to a table. Within a few hours the assistant returns code that runs on sample data and produces sensible output. It is natural to conclude that the build is done and that a platform is no longer necessary.

The prototype answers one question: can this logic be written down? An institution has to answer several more before that logic touches client money or a regulatory filing. Will it finish on time at full volume? Will it give the same answer if the same day is run again next week? If a step fails, will anyone know? Where are the credentials kept, and who is allowed to change a threshold? Answering those questions is most of the work, and an LLM cannot answer them from a single conversation, because the answers depend on how real data and real infrastructure behave.

What a prototype on Everysk looks like

The hardening phases described later act on specific parts of a prototype, so it helps to name those parts first. Everysk runs operations processes as workflows. These are the terms used in the rest of the article.

Workflow - A process broken into separate steps, such as reading data, applying rules and writing results. Each step does one job, so each can be tested, replaced or rerun on its own.

DAG - A directed acyclic graph: the map of which step feeds which. The arrows only point forward, so the process has a clear start and end, and a step runs only when every step it depends on has finished. Steps that do not depend on each other can run at the same time.

Worker - One step in the graph. Everysk provides a library of ready-made workers, which it calls robots: one retrieves a stored table, one reads a file from a client's server, one converts a report to PDF, one sends a notification. A Starter worker begins each run and an Ender worker closes it.

For Developer worker - A worker whose contents are Python code. This is where client-specific logic lives: a monitoring rule, a risk score, an allocation method. It is also the part an LLM writes most easily.

Runtime - The computing container a worker runs in: how much memory and how many processors it has, and which software libraries are installed. A light step runs in a standard container; a heavy one is assigned a larger runtime, for example one with more memory and a data warehouse connector installed.

Datastore - A table stored on the platform, with a name, a date and tags. Steps read their inputs from datastores and write their results to them, and the platform keeps each dated version.

Handshake - The agreed format in which one step passes data to the next. On Everysk this is usually a table written as a list of rows with the column names first, which any Python step can turn into a dataframe and back.

Connectivity - The connection between the workflow and the client's own systems: a data warehouse such as Snowflake, a secure file server, an order management system, a custodian or a prime broker.

Secret - An encrypted store for passwords and keys. A worker asks for a credential by reference when it runs, so the credential never appears in code, in a log or in the workflow definition.

Everysk has packaged its knowledge of these parts into skills: sets of instructions, code libraries and checks that an LLM loads before it starts work. The workflow builder skill takes a specification or a sample spreadsheet and does what a platform engineer would do. It decides how to split the process into steps, writes each Python step with the correct handshake, generates sample datastores, wires the graph, lays it out so that a reviewer can read it, validates it, deploys it, runs it and reads back the results. A first version of a thirty-step workflow can be running in a day

This is a genuine artifact. It runs, it can be demonstrated, and its business logic is often correct. It also carries assumptions that sample data never tests: that the data is small, that every step succeeds, that the server's clock gives the business date, that a matching row count proves a load was correct, and that the person running it is the person who wrote it.

What sample data cannot show

Each of the following problems is common in LLM-written and hand-written prototypes alike. None of them is visible on a sample of a few thousand records, and most would pass a careful reading of the code. They appear only at real volume, on real data, or when the same day is run twice.

The hardening phases

Every Everysk workflow is built in two stages: a prototype that proves the logic, followed by a fixed sequence of hardening phases that make it fit for production. The prototype has always been the short part. The order of the phases matters: measurement comes before optimisation, and an equivalence test exists before any code is changed, so that every later change can be proved harmless.

1 - Measure

Each part of each step gets a timer: reading data, evaluating rules, matching names, writing results. Memory use is recorded too. The step is then run on one month and on three months of data. If the time grows about three times, the step scales with the data. If it grows about nine times, some part of it scales with the square of the data, and the timers show which part.

2 - Freeze the answer

Before anything is optimised, the current output is recorded as a fingerprint: a hash computed from every alert or every cell of every result table. Any change in the output, however small, changes the fingerprint. Every later phase must reproduce it exactly, which turns "this change should not affect results" from an opinion into a test.

3 - Remove quadratic behaviour

Loops that compare every item with every other item are replaced with sorted searches and indexed lookups, whose cost grows in proportion to the data. For name screening, each name is first compared only with list entries that share a sufficiently rare word, which reduces millions of comparisons per day to a handful per person. The fingerprint confirms that the alerts are unchanged.

4 - Reduce cyclomatic complexity

Cyclomatic complexity is a count of the separate routes a piece of code can take. Each if, else, loop or exception adds a route. A function with no decisions has a complexity of 1. A function that checks the asset class, then the currency, then whether the account is restricted already has several routes, and each one is a case that a test must cover and a place where a later change can break something unnoticed. Prototypes tend to grow one long main function that does everything, often with a complexity of 50 or more. In this phase every such function is broken into smaller ones, each doing one part of the process, with a target of 10 or less. The result is code that a reviewer can read in one sitting and a test suite can cover completely.

5 - Review the design against the SOLID principles

Low complexity makes each function readable. SOLID is about how the functions fit together, so that the system can change without breaking. It is a set of five design principles widely used in professional software engineering. In plain terms:

• Single responsibility. Each component has one reason to change. The code that reads payments should not also decide which payments are suspicious, because a change of data source should never touch the monitoring logic.

• Open for extension, closed for modification. Adding something new should not require editing what already works. A new rule type is added by registering it, not by inserting another branch into a long chain of conditions that every existing rule passes through.

• Substitutable parts. Any component that claims to do a job must be usable wherever that job is needed. A reader for a test file and a reader for the client's warehouse must return the same shape of table, so the engine cannot tell them apart.

• Narrow interfaces. A component should depend only on what it uses. A scoring step that needs three columns should not require the whole customer record.

• Depend on agreements, not on specific systems. The monitoring engine is given a function that reads a table; it does not know whether the table comes from a datastore, a file or Snowflake. That is what allows the same tested engine to move from sample data to the client's systems without any change to its logic.

The review is done against the code, principle by principle, and each finding is fixed and re-verified against the fingerprint.

6 - Split the work where the logic allows it

Work that would still exceed the time limit for one step is divided across parallel workers. The division is chosen from the logic, not for convenience. If every rule looks at one customer at a time, splitting by customer gives identical results. Splitting by date would not, because a rule that counts payments over thirty days can cross the boundary. A planning step records the plan, each slice writes to a staging table, and a merge step publishes nothing unless every slice reports complete under the same plan and the combined result matches the fingerprint.

7 - Make every failure loud

Each step writes a record of what it wrote and then stops if anything failed, so a failure is both recorded and fatal. Each stage writes a completion marker as its last action, and the next stage starts by checking that the marker exists and that every table it lists has the declared number of rows. Independent checks recompute key totals from the source instead of trusting the step that produced them, and the run fails if any write anywhere failed.

8 - Connect to the client's data and secure it

Sample datastores are replaced by direct reads from the client's systems, most often a data warehouse. Queries carry an explicit sort order so that results are reproducible, number formats are taken from the warehouse's own column definitions, and the amount of history read is derived from the rules' own look-back settings. Loads are verified value by value, never by row count alone. Credentials are held in Secrets and contain only what must be secret; addresses and settings are ordinary, versioned configuration. The database role is reduced to the minimum the process needs.

9 - Turn policy into governed data

Thresholds, severities, limits and matching cut-offs move out of the code into parameter tables with effective dates. A change needs approval from a second person, and each run records which version of every parameter it used. A check confirms that every configured parameter is actually read by the code. Worked examples with known answers are stored as acceptance cases, and every run grades itself against them.

10 - Operate it

The workflow is scheduled against business dates rather than server time, can resume a split job from where it stopped, publishes a status that operations staff can read, and keeps dated results under a stated retention rule. A runbook explains what each failure message means and what to do about it.

What changes between the two

The table sets a prototype and its production form side by side. The first row is the part an LLM writes in an afternoon. The rest of the table is the work of the hardening phases.

Why this matters for a build or buy decision

None of the problems above is exotic, and none needs unusual skill to fix once it is found. The difficulty is finding them. They surface when a system runs at real volume, on real data, more than once, and the answers are compared. Several depend on facts about specific infrastructure that are not written down anywhere: where a memory limit sits, how large a table a storage layer will accept, what a calling process reports when the process it called fails, how a particular loading method treats a date column.

An LLM accelerates the first ten percent. The other ninety percent is accumulated knowledge of where real systems break.

At Everysk that knowledge is not kept in people's heads. It lives in the skills, the shared code libraries and the automatic checks that every workflow inherits. Each production deployment adds to them, so the next prototype starts from the lessons of every earlier one and reaches production faster.

An in-house team can follow the same path, and some should. The fair comparison, though, is not between a platform and an afternoon with an LLM. It is between a platform and the months of measurement, failure and correction that turn the afternoon's output into something a regulator, an auditor and a client can depend on, followed by the years of maintenance that keep it that way.