When I started the Pseudo Markets project back in 2020, I was a recent college grad who just started working as a software engineer in the financial services industry. Even though I had prior software engineering experience at smaller companies, I never worked at the scale of a Fortune 500. This was reflected in the earliest versions of the project where monolithic structures prevailed, and scalability was an afterthought. As I gained additional experience on the job, I slowly started to refine my approach to the project, which introduced better design patterns and a more modular structure. Despite my efforts to keep the project moving, life and work got in the way, and it became dormant for several years.
Fast forward to today, where I am still working for the same financial services firm, but as a Technical Product Manager. Throughout my time as an engineer, I grew more interested in the products I was building rather than how they were being built. This led me to my current role, where I drive the product direction for very large scale trading systems. I wanted to revisit the project because I not only have significantly more domain knowledge, but also because I no longer write code as part of my day to day work. This project allows me to keep my engineering skills sharp, while also experimenting with the biggest thing in tech right now: AI.
I’ve been using AI coding tools such as GitHub Copilot and OpenAI Codex for over a year at this point. My usage has gone from just writing simple unit tests to building entire features, reverse engineering legacy applications, and more. With Pseudo Markets Next Gen, I’ve been heavily leveraging OpenAI Codex to write most of the code, so I can focus more on system design and business rules. This approach has allowed me to rewrite the entire “legacy” platform in just a few days, along with enhancements that were stuck in my backlog for years. While the generated code is far from perfect in the first iteration, the speed at which I can build is simply unmatched. I’ve learned a lot of things that work, and don’t work, along the way which I will be sharing through this series. I also followed several approaches to using Codex: building on top of boilerplate code, re-building from a legacy solution, and building from scratch using a Product Requirements Document (PRD). Today, I’ll be focusing on building on top of boilerplate code.
The first component I wanted to rewrite was the authentication and authorization subsystem in the previous Unified API solution. It was clunky to say the least, and I wanted the authentication and authorization flows to live in their own microservice. Rather than starting completely from scratch, I put together some boilerplate code for what I wanted the authorization service to look like. I wrote all of the initial scaffolding, entities, contracts, and the like. From there, I engaged with Codex in an interactive session to iteratively build out the service. I provided some forward thinking context to make sure that design decisions were mindful of how services would use the authentication and authorization later down the road, but I didn’t want to muddy the water by providing too much context at this stage. At the time, GPT 5.4 was the top model from OpenAI, and I found that it worked pretty well throughout each iteration. Reviewing the code was a challenge, due to the sheer amount of it at the end of the cycle. I quickly learned that I should also be engaged in code review more frequently, rather than deferring the detailed review towards the end of building out the feature (or in this case, an entire application). Code review skills are only going to become more important for every software engineer that works with AI tooling.
It took me about 8 hours to develop the application from boilerplate structure to full functionality. I reckon I could have cut that time down with better usage of plan mode, requirements docs, SME skill files, and other tricks to push more of the coding workflow into Codex. These are all techniques I used to develop other components of the platform, which I will go into additional detail in the next few posts. This is just the beginning, and I am confident that I can launch the full platform within the next few months, which is something I’ve been wanting to do for the past 6 years.
Pseudo Markets Blog 