While integrating a legacy payment provider, we ran into one of those classic “legacy fintech” hurdles such as, sparse documentation, slow vendor response, and plenty of trial-and-error. What started as a straightforward Python-to-NodeJS port became a deep dive into cryptography, networking, and the nuances of legacy software. Yes, it's frustrating, but it was also a great opportunity to lean on first-principles thinking and solid engineering fundamentals.‍

Knowledge capture as a by-product (The industrial waste analogy)

‍This whole process reflected how we often treat “side outputs” of our daily engineering work, debug logs, design docs, internal retros, technical rants as industrial by-products which are sometimes useful and often wasted. In manufacturing, companies have famously turned waste into new product streams (for instance, how 3M built businesses out of manufacturing offcuts, or how breweries monetize spent grain). Something similar can be done in tech by treating our “knowledge by-products” as raw material for content, documentation, and even marketing copies.‍

AI-first with Single Source Principle (SSP)

By capturing raw engineering knowledge in structured or semi-structured formats (even Slack threads or ChatGPT chat threads), we can leverage AI to remix, summarize, or transform this “waste” into high-value resources. This aligns directly with the Single Source Principle, the idea that a single, well-maintained source of truth (be it a doc, code comment, or debug artifact) can power multiple outputs like blog posts, knowledge base entries, customer-facing docs, even LinkedIn campaigns.‍

AI-first workforce

‍Ultimately, this is about staying consistent with Prodigal's vision of being an AI-first engineering organization. Instead of relying solely on manually curated docs or top-down knowledge transfer, we’re experimenting with making everyday engineering output fuel for AI-driven content generation, onboarding, and even marketing. As we scale, this approach will give us significant leverage, both internally (for onboarding, incident retros, and culture) and externally (for branding, DevRel, and sales enablement).

Last time, something like this was for our Apps team’s RCA (Root Cause Analysis) process. Back then, the goal was mostly product-focused as we wanted to create better RCA docs so our team could learn from mistakes and improve our product thinking, which would help reduce future incidents.

This new approach is different. It’s less about following a process and more about capturing and sharing knowledge in a way that’s AI-driven. The aim is to make it easy for us (and our AI tools) to learn from everything we do. Not just fix issues, but build up a smarter, more connected internal knowledge base over time. For instance, there are developers who are obsessed with joining Meta or Google simply because of the vast internal knowledge (research papers, company decks, case studies, community notes) these companies have curated over the years which they won't get access to anywhere else.

Largely, AI-first and AI-readiness is about using AI to get that extra leverage on your daily work and being able to see the effects of that AI-first approach as tangible outputs, and later, even measure the impact to "prove" (for ourselves) that we're truly aligned with the AI-first vision.

"If we can measure AI-readiness or AI-first action, the former will improve" and we'll have a more clear, repeatable path on how we can amplify our AI-first approach to full potential across engineering functions.