Vibe Coding

 

M 917 536 3378 maksim_kozyarchuk@yahoo.com What is Vibe Coding? Recently, I came across the term vibe coding, and it immediately resonated. The work I’ve been doing with Kupala-Nich over the past nine months fits that description perfectly. I started this project because I wanted to build a feature-rich valuation and risk platform—something robust, extensible, and available to everyone. There’s something deeply satisfying about having an idea for how something should work and then seeing it become real. Whether it’s a concept I came up with, a recommendation from a friend, or a request from a client, the act of turning an abstract idea into a working feature is what drives me. This is why I code,  it’s where I find joy and fulfillment in the creative process. But vibe coding is more than just building features. It’s also about how you build. It’s about working in a rhythm that feels natural, balancing creativity and engineering discipline. For me, it also means investing in everything that makes the platform not just functional, but sustainable over the long term. In the sections that follow, I’ll explore the other practices refactoring, research, testing, automation, and platform engineering that complete the picture and make this a holistic experience. Technical Research: Staying Curious One of the greatest benefits of working without externally imposed deadlines is the freedom to pause feature work and explore new ideas, practices, or technologies. Recently, I’ve found myself diving into something new almost every other week—not because I have to, but because I genuinely want to understand how these innovations might fit into the future of Kupala-Nich. Some of these explorations remain curiosities with no immediate application (like the Cursor editor or AWS API Marketplace). Others quickly become valuable tools I use every day—such as VS Code Insiders with GitHub Copilot, or CloudWatch-based monitoring and alerting. Some even lead to unexpected and interesting new connections (like Matalogica AADC). And occasionally, an exploration ends up playing a pivotal role in the platform’s evolution—DynamoDB, PyCaret, and AWS CDK are great examples. It’s hard to assign a precise ROI to this type of research, but I’ve noticed a consistent pattern: I spend less than 20% of my time on technical exploration, yet it contributes more than 20% to the long-term capability and sustainability of the platform Refactoring: Clearing the Path Refactoring is not my favorite activity. Pair that with the fact that it often gets in the way of shipping a feature on time, and it’s easy to see why it’s so frequently postponed. But over time, I’ve come to see refactoring as something like cleaning or reorganizing your living space: you can avoid it for a while, but eventually it starts affecting your mood. You begin tripping over things, or you end up buying replacements for items you already own but can’t find. The same chaos can creep into a codebase. With Kupala-Nich, I’ve learned to treat refactoring as part of the natural rhythm of development. Sometimes I do it because I wake up with a better idea for how something should be structured. Sometimes it’s a promise I made to myself—“I’ll refactor this once the feature is done.” But more often, it happens when I start building a new feature and realize the current structure is holding me back. At that point, deadlines take a back seat, and I’ll spend a few days redesigning or reorganizing the codebase so the new functionality can live in a better place. The best part of refactoring is how it makes you feel afterwards. There’s this lightness, like a weight has been lifted. Code that felt messy or claustrophobic is suddenly clean and breathable. And features that once seemed intimidating start to feel exciting again. It’s a reboot—not just for the project, but for your motivation. Automated Testing: Reducing Coding Anxiety I write tests because I don’t like the uncertainty that comes with changing code. Introducing a new feature shouldn't feel like a risk, and a good test suite makes development feel safer and more predictable. Tests also improve speed, especially when working with AWS serverless infrastructure, where deploying and debugging can take time. Writing quick, focused tests is often more efficient than deploying just to verify behavior. My test coverage isn’t exhaustive, nor do I aim for 100%. Instead, I focus on writing low-level tests that cover important functionality without being brittle. This balance ensures that even large structural changes typically impact only a small number of tests, usually less than 2%. I put effort into making tests reliable, isolated, and consistent so they continue to add value over time. Maintaining tests is just as important as writing them. When APIs evolve, I regularly revisit, refactor, or remove tests to keep the suite clean and relevant. I prefer using stubs over mocks for stability, and I like validating real data interactions wherever possible. For AWS-specific components, I rely on the Moto library to simulate aws behavior. While it doesn’t fully support every service, like API Gateway, it’s proven to be effective for the majority of my testing needs. Security, Automation, and Platform Engineering Building scalable and robust applications involves a level of complexity that goes far beyond individual features or algorithms. It requires provisioning infrastructure, installing the right operating systems and dependencies, configuring middleware such as databases, API gateways, and message buses, and ensuring that every component is secure, available, and correctly integrated. Security brings its own set of responsibilities: setting up user authentication, managing access controls, provisioning certificates, and defining permissions for each resource. Frankly, managing these configurations, especially through web UIs, is rarely the highlight of my day. Manual processes are error-prone and difficult to maintain, which is why I’ve leaned heavily on infrastructure-as-code solutions. Docker, GitLab, AWS CloudFormation, CDK have been essential tools in addressing this complexity. They allow me to automate nearly all aspects of infrastructure and security configuration, using Python or YAML definitions. This approach ensures repeatability, clarity, and version control for the platform’s architecture. Learning these tools has been its own ongoing research project. Fortunately, with resources like ChatGPT and strong documentation from AWS, it’s easier than ever to navigate the many options and best practices available. While the configuration layer of platform engineering can be daunting, it becomes much more manageable, and even enjoyable, when approached with the right tools and mindset

FX Forward Valuation

  

M 917 536 3378 maksim_kozyarchuk@yahoo.com

Introduction I am delighted to announce that the Kupala-Nich platform now supports FX Forward valuation. OTC valuation within the Kupala-Nich platform is primarily built on top of QuantLib. However, while integrating FX Forward support, I was surprised to discover that QuantLib does not natively support FX Forward products. Consequently, introducing FX Forward valuation into Kupala-Nich required additional considerations, particularly around designing modeling APIs for accurately defining FX Forward positions. If anyone has insights into why QuantLib lacks direct support for FX Forwards, I would greatly appreciate being pointed toward any relevant discussions or documentation.

Defining FX Forward Products in Kupala-Nich Clear and precise definitions of FX Forward terms are fundamental to accurate valuation. Kupala Nich uses the following six fields to define FX Forward: currency_pair: Identifies the currencies traded and establishes the quoting convention for the forward rate. traded_currency: Specifies the currency used for expressing the trade's notional and direction. For example, stating "buying 100K EUR at 1.1" differs from "buying 100K USD at 1.1," as each scenario represents unique trading exposures. direction: Denotes the trade direction as either Buy or Sell relative to the traded currency. notional: Represents the notional amount traded in traded currency. forward_rate: Defines the agreed FX rate at the maturity date according to the currency pair convention. maturity_date: Specifies when the FX Forward contract reaches maturity. Implementation of FX Forward Valuation FX Forward valuation involves decomposing the forward contract into two separate cashflows based on the forward exchange rate. Each cashflow is then discounted to the spot date using appropriate discount curves for each currency. Subsequently, these discounted cashflows are converted into the traded currency using the spot rate and discounted again to the valuation date. Kupala-Nich calculates additional analytical measures alongside the NPV, including: FX Spot rate used in valuation. NPV provided in both traded and base currencies. FX Delta for each currency, reflecting the discounted value. Detailed Cashflows breakdown including discount factors and present values. Bucketed DV01 analysis, highlighting sensitivity to shifts in benchmark curves. Below code snippet demonstrates FX Forward valuation using QuantLib. joint_calendar = ql.JointCalendar(curve1.calendar, curve2.calendar, ql.JoinHolidays) spot_date = joint_calendar.advance(valuation_date, ql.Period(spot_days, ql.Days)) df1 = curve1.discount_factor( matrity_date, spot_date) df2 = curve2.discount_factor( matrity_date, spot_date) df1_spot = curve2.discount_factor( spot_date) fx_delta1 = df1 * notional1 fx_delta2 = df2 * notional2 fx_delta2_in_curr1 = convert_to_ccy(fx_delta2, curr2, curr1) npv_local = df1_spot * ( fx_delta1 + fx_delta2_in_curr1 ) Handling Joint Calendars Proper date management, considering the calendar differences and holidays of both currencies involved, is important. Kupala-Nich employs QuantLib's ql.JointCalendar(curve1.calendar, curve2.calendar, ql.JoinHolidays) method, creating a combined calendar to accurately determine spot or maturity dates, critical for precise FX valuation. Curves: OIS vs FX Curves Currently, Kupala-Nich employs Overnight Indexed Swap (OIS) curves for FX Forward valuation. However, a significant basis exists within FX markets due to short-term dynamics, underscoring the limitations of using OIS curves exclusively. Recognizing this, future enhancements will introduce FX-specific curves, providing more accurate valuations, particularly beneficial for short-dated FX Forward contracts. For further insights, reference CME Group’s detailed analysis on FX year-end dynamics here.

Speeding Up QuantLib with Matlogica’s AADC Library

  

M 917 536 3378 maksim_kozyarchuk@yahoo.com

I recently had the opportunity to connect with Dmitry Goloubentsev from Matlogica and explore their AADC (Adjoint Algorithmic Differentiation Compiler) library. I’m amazed by the speedups they’re achieving on top of QuantLib. For instance, doing 100 revals for a 10K OIS swap portfolio takes around 60 seconds with QuantLib on my machine. Once compiled into an AADC Kernel, doing 100 revals on the same portfolio takes only 200 ms. This makes it completely feasible to calculate VaR for large portfolios in seconds, even with minimal hardware. Below is an example of how you can compile your QuantLib-based Python code into an AADC Kernel and run multiple revaluations..

Simple VaR example Suppose you have a function price_portfolio to compute NPV of a portfolio that uses QuantLib and looks as follows: def price_portfolio(swaps, curves, curve_rates):     npv = 0.     for curve, rates in zip(curves, curve_rates):         for quote, rate in zip(curve.quotes, rates):             quote.setValue(rate)     for swap in swaps:         npv += swap.NPV()     return npv This function assumes that relevant curves and swap objects are already built and it simply modifies the quote objects linked to the relevant curve objects.  As such it’s quite efficient and takes ~0.6 seconds on my desktop for a portfolio of 10,000 OIS Swaps.  To calculate Historical VaR from this function you may want to call this function 100 times with various historical curves, which would take ~60 seconds Applying AADC AADC can yield significant amazing speedups with this above example, but before jumping into the details, let first walk through core  library function ( for deepeer understanding refer to https://matlogica.com/Implicit-Function-Theorem-Live-Risk-Practice-QuantLib.php)  Compiling: One can think of AADC as a ‘just in time’ compiler, that takes your python and quantlib code along with relevant curve and trade setup and converts into an executable that will accept updated rates values.  Below is a code sample of how one would ‘compile’ the call to above function.  def compile_kernel(swaps, curves):     kernel = aadc.Kernel()     kernel.start_recording()     curve_rates = []     curve_args  = []     for curve in curves:         zero_rates = aadc.array(np.zeros(len(curve.tenors)))         curve_rates.append(zero_rates)         curve_args.append(zero_rates.mark_as_input())     res = price_portfolio(swaps, curves, curve_rates)     res_aadc = res.mark_as_output()     request = { res_aadc: [] }     kernel.stop_recording()     return (kernel, request, curve_args) A few things to note about this function It marks inputs to this function that can change as well as tags output Inputs and outputs need to be of special data types aadc.array in this example but could be aadc.float as well curve_rate values passed to the price_portfolio method during the recording do not really matter and are initialized to zero values in this example This function returns three output kernel, request and curve_args, these will be needed to later call the compiled kernel Running the function: To evaluate the compiled function you need three things.  The kernel that was acquired earlier, an input structure that provides a value for expected inputs and results structure defining expected result fields.  Below example demonstrates how one can invoke above with new curve_rates.  Note construction of a dictionary of tagged input arguments with provided curved_rates.  The first element of the return list contains a dictionary, with the same keys as the request dictionary with calculated values returned as an array of one element.   Running this compiled function yields 10-20x speedup over original execution. def call_kernel(kernel, request, curve_args, curve_rates):     inputs = {}     for curve_arg, rates in zip(curve_args, curve_rates):         for arg_point, rate in zip( curve_arg, rates ):             inputs[arg_point] = rate     r = aadc.evaluate(kernel, request, inputs)     res_aadc = list(request.keys())[0]     return r[0][res_aadc][0] Running a batch:  To compute VaR as stated in earlier example, it’s possible to call the above function 100 times and achieve 10-20x speedup, however aadc.evaluate also allows you to pass an array of 100 notes for each of the curve points.  It will then evaluate all 100 calls internally and you will see per call speedups of over 100x.  Though you would need to modify the above call_kernel function to return the full list of results rather than just the first element.  Below example demonstrates how to calculate npvs for 100 random rates, this function will then also return a list of 100 nvs curve_rates = [] for curve in curves:     rates = []     for _ in curve.tenors:         rates.append(np.random.randint(0, 99, 100) *0.005 * 0.02 +  0.0025 )     curve_rates.append(rates) npvs = call_kernel(kernel, request, curve_args, curve_rates) If that’s not fast enough, aadc.evaluate allows you to distribute calculations across local threads further speeding up runtimes. It’s also not too hard to create a python decorator that hides the complexity of compiling and calling the kernel away from an API user.   Below decorator can be applied to the price_portfolio function. def with_aadc_kernel(func):     _cache = {}     def wrapper(swaps, curves, curve_rates):         key = func.__name__         if key not in _cache:             kernel = aadc.Kernel()             kernel.start_recording()             curve_rates = []             curve_args  = []             for curve in curves:                 zero_rates = aadc.array(np.zeros(len(curve.tenors)))                 curve_rates.append(zero_rates)                 curve_args.append(zero_rates.mark_as_input())             res = func(swaps, curves, curve_rates)             res_aadc = res.mark_as_output()             request = { res_aadc: [] }             kernel.stop_recording()             _cache[key] = (kernel, request, curve_args)         # Subsequent calls: use cached kernel         kernel, request, curve_args = _cache[key]         inputs = {}         for curve_arg, rates in zip(curve_args, curve_rates):             for arg_point, rate in zip( curve_arg, rates ):                 inputs[arg_point] = rate         r = aadc.evaluate(kernel, request, inputs, aadc.ThreadPool(1))         res_aadc = list(request.keys())[0]         result  = r[0][res_aadc]         if len(result) == 1:             result = float(result[0])         return result         return wrapper Compile Time and Serialization As mentioned earlier kernel compile time incurs minimal overhead. So even if you include compilation time, you can compute 100 scenarios with AADC in roughly the same time it would take you to compute 10 iterations using plain QuantLib. Furthermore, the compiled kernel is fully serializable, meaning you can save time on swap and curve construction during subsequent runs. It also lets you precisely reproduce results on a different machine if needed. Additional Resources In addition to calculating the results of your function, AADC can automatically calculate gradients with respect to the inputs. For an explanation of this and more examples, check out: AADC GitHub Project: https://github.com/matlogica/AADC-Python Matlogica: https://matlogica.com/ You can also see my full code sample here: https://github.com/kozyarchuk/aadc_demo/blob/main/aadc_demo.py