About¶

I started in banking and financial software engineering and spent seventeen years moving toward the same problem from different directions: how large organisations turn the data they already have into something they can act on with confidence.

That path ran through data migration and modernisation in commodity trading, retail, industrial and financial services, and through delivery leadership on teams from three people to seventy. For the last several years it has been enterprise data platforms and, most recently, governed AI systems — semantic layers, retrieval architectures and agentic applications built to survive contact with an enterprise's actual governance.

The engagement that changed direction¶

One project moved me out of general software engineering and into data, and it did it by succeeding.

We built an end-to-end machine-learning product for a large information business — ingestion through labelling, training, prediction pipelines and deployment — without a data engineer on the team. It worked. It went to production. By most measures it was a good outcome.

What I took from it was the opposite of reassurance. We had treated the data layer as something to get past on the way to the model, and every hard problem we hit late was a data problem wearing a different costume: provenance we could not reconstruct, labels whose meaning drifted, pipelines nobody could reason about six months on. The model was never the difficult part. The data pipeline is what makes a system genuinely end-to-end, and a team that lacks that skill does not discover the gap until it is expensive.

So I went and learned that half deliberately, and it became the work.

That lesson has aged well. The generative-AI wave produces the same pattern at larger scale: teams reach for a model, ship something impressive, and then meet retrieval quality, lineage, definitional drift and provenance as if they were surprises. They are the same problems. The interface changed; the constraint did not.

I am unusual in one specific way, and it is the thing worth knowing: I still build. I can design an architecture and implement it, which means the design tends to survive first contact with the code, and the estimates tend to be real. On the most recent engagement I contributed roughly 60% of the platform's commits while also owning the delivery narrative to client leadership. I do not think that combination will stay unusual for much longer, but at the moment it is.

Based in Kyiv, Ukraine. Currently a Delivery Manager and hands-on AI engineer at EPAM.

What I care about in the work¶

Honest maturity claims. A prototype called a prototype is more useful to a client than a prototype called a platform, and vastly cheaper for everyone six months later.

Ownership over documentation. Definitions without named owners drift, no matter how good the glossary is. Most knowledge platform failures are governance failures wearing a technical costume.

Naming the gap yourself. The most valuable thing I have delivered on a recent engagement was not the system. It was telling the client precisely what it could not yet do, before someone else discovered it in a security review.

Selected experience¶

Second place, EPAM Data Analytics Hackathon, November 2025.

The full CV has the complete record, and the skills summary breaks down the technical surface.

About this site¶

It is built as a system rather than a page, and the system is described in the Lab: a confidentiality firewall enforced in CI, specs before content, status metadata on everything. The changelog records what has substantively changed.