About Oleg Bond

My first paid job as a developer came while I was still at school, when I knew almost nothing. I joined a small group of enthusiasts building desktop programs and understood maybe half of what I was doing. I wanted to learn the other half too: how the pieces talked to each other, where the data actually lived, and what was really broken when an application started throwing strange errors. College brought mainframes and late nights writing not in assembler but straight in machine code, just to squeeze out a little more speed. Those were the good old days, when memory was precious and every byte had to justify its existence.

Oleg Bond in 1998

My first full-time job was in ERP and accounting systems, and the architecture of that era now looks like a museum exhibit. Two tier applications, then three. A central server humming in a locked room. Deployments that meant a stack of disks and a prayer. For a while I also worked in the IT department of a large oil and gas company. Those years were hard and fascinating. Two sleepless nights chasing an application that behaved differently every time taught me what “non-functional requirements” really means. Another night hunting for missing data taught me how a database works under the hood, which is not quite how the manual describes it.

Then came consulting. As a principal architect, I worked on content and case management platforms, helping clients move from big multi-tier monoliths to service-based applications and portals, both on premises and in the cloud. Some weeks went past 100 hours. I was sometimes on two conference calls at once, occasionally three, and I learned a new industry every few months. Most of all, I learned to explain architecture in the language clients actually speak: time, risk, and money. Fast, cheap, or good: pick two.

Five engineers in white lab coats gathered around vintage electronics equipment in a laboratory
Oleg Bond seated at a desk in a modern office in 2010

That was also when AI went from curiosity to actual work. My first projects classified things, grouped them, and predicted time series. Later ones got more ambitious. Some early models were far more confident than they had any right to be, and a few projects ate much more time and money than planned, while delivering results that seemed to change with the weather. I like to think those taught me more than the successes did.

Today I lead a team of architects who work alongside developers on microservice and micro-frontend applications, taking solutions fromrequirements through architecture to detailed design. On-premises servers arenow relics. Nearly everything lives in the cloud, where the old questionsabout parts and data still apply, just with far more moving pieces. These days I get genuinely excited about things my younger self would have found suspiciously boring: good documentation, clear processes, predictableoutcomes, and consistency across the company. AI is part of my daily toolkitfor drafting, reviewing, and testing designs and code. I still check itsconfidence against reality, because I’ve met overconfident models before.