I Built a Quantitative Trading Program with Vibe Coding

9 min readMay 24, 2025

Yes, you read that right — I did use Vibe Coding to write a quantitative trading program. If you clicked on this title and are now reading this, you might be thinking, “Who gave you the courage to write a quantitative trading program?”

First, let me clarify: this is not a “serious” quantitative trading program but a simple one developed for a company AI programming Hackathon.

The day before the registration deadline, I was pulled into a programming team. Initially, I joined the competition on a whim, not expecting that work and personal matters would keep me so busy that I missed both the briefing and the practice round. By the day before the competition, I hadn’t contributed a single line of code to the team and was still unclear about the competition details.

Perhaps by coincidence, I woke up at 5 a.m. on the day of the elimination round. Since I was awake, I decided to check out the competition instructions. After reading them, I realized that Vibe Coding was a good choice. Given the limited time, Vibe Coding allowed me to focus more on the problem itself rather than the implementation details.

In the end, I spent just over two hours completing this quantitative trading program, and I think the results were pretty good. Although our team didn’t advance for various reasons, the entire process was incredibly rewarding.

Here, I want to share the thought process and methods behind implementing this quantitative trading program.

Vibe Coding

Let’s first understand what Vibe Coding is. After reading this introduction, you’ll understand what gave me the courage to write a quantitative trading program.

What is Vibe Coding?

This concept was first proposed by computer scientist Andrej Karpathy (co-founder of OpenAI) in February 2025. The core idea of Vibe Coding is to generate code through natural language descriptions rather than traditional programming languages. It is a natural language-based programming method that allows users to describe their needs in natural language and leverage large model tools to generate code. Its goal is to make programming simpler and more intuitive, especially for people without programming experience.

Let’s take a look at the traditional programming process for comparison.

Traditional Programming

Traditional programming usually follows a structured process that includes the following key steps:

Requirement Analysis: Programmers need to understand the problem and user requirements, including functionality, inputs and outputs, boundary conditions, and constraints. This stage often results in requirement documents or user stories.
Program Design: Design the program’s structure and architecture, choose programming languages, frameworks, and tools, design data structures and algorithms, and plan module interactions. This stage often produces design documents, flowcharts, or UML diagrams.
Coding: Programmers start writing the actual code based on the design, following syntax rules, implementing functionality, and ensuring code readability and maintainability.
Testing: Through unit testing, integration testing, system testing, and other levels, bugs are identified and fixed, and the program’s correctness and performance are verified.
Deployment: After thorough testing, the program can be released for user use, including preparing installation packages, writing user documentation, and deploying to production environments.

This process is often iterative. As requirements change or new issues are discovered, programmers may need to revisit earlier steps and start over.

In contrast, Vibe Coding simplifies this process, making programming more intuitive and efficient.

Advantages of Vibe Coding

The advantages of Vibe Coding include:

Simplified Programming Process: By describing requirements in natural language, large model tools can automatically analyze and generate documentation, designs, and code.
Lower Learning Curve: Enables people without programming experience to participate in programming by simply describing their needs in natural language.
Enhanced Readability: The generated code is based on natural language descriptions, making it easier to understand the intent and logic of the code.
Support for Multiple Programming Languages: Can generate code in various programming languages, allowing users to choose the most suitable one.
Ease of Debugging and Maintenance: The generated code is easier to debug and maintain, and tools can automatically fix bugs or even optimize the code.

Another benefit is that you can continuously adjust and optimize your requirements, and the tools will automatically analyze and modify the code. In contrast, a real programmer might get frustrated with constant changes.

Imagine: A programmer’s real reaction when business requirements keep changing…

Vibe Coding Tools

There are many tools for Vibe Coding, with the most commonly used ones including:

Cursor
Windsurf
Claude
Whisper
GitHub Copilot
Trae
CodeBuddy

These tools help us realize the Vibe Coding philosophy, making programming simpler and more efficient. However, I haven’t used all of them, so I can’t provide objective recommendations. If you have good tool suggestions, feel free to leave a comment.

After introducing the tools, let’s see how I used Vibe Coding to write a quantitative trading program.

Practical Development of the Quantitative Trading Program

Background

Using the provided resources, develop a quantitative trading program in any language.

The competition consisted of three trading rounds, each starting with 100 shares of the Hang Seng Index.

Each round lasted 12 minutes and was divided into three phases:

Phase 1: The first minute, no trading allowed.
Phase 2: From the 2nd to the 11th minute, trading allowed.
Phase 3: The last minute, no trading allowed.

The final profit was the combined cash value after selling in each round.

The organizers provided two interfaces:

Index Information: A WebSocket interface providing real-time index information, including current price, percentage change, etc., updated every 2 seconds.
Trading Interface: An HTTP interface for trading, requiring only the quantity to sell for each transaction.

Additionally, the organizers provided the past month’s index information and a basic codebase that included WebSocket and HTTP access implementations. Participants could build upon this foundation.

Tool Selection

I chose VSCode + the Cline extension + the GitHub Copilot API for Vibe Coding, using the GPT-4o model. This wasn’t because I particularly liked this setup but because it was the best combination available under the circumstances.

It’s worth mentioning that Cline offers two modes: Plan and Act:

Plan: Focuses on conversational interaction, emphasizing problem analysis and solution design without immediately generating code. In this mode, it helps you clarify goals and requirements, break down complex problems, develop implementation strategies, and analyze potential challenges and solutions. This mode is particularly suitable for brainstorming and structured thinking in the early stages of a project, ensuring you have a clear plan before writing any code.
Act: In this mode, it generates code based on your instructions. You can directly provide requirements, and it will automatically analyze and generate code. This mode is ideal for specific coding tasks, especially when you already have a clear idea and design.

In complex scenarios, I first use the Plan mode for requirement analysis and design, then switch to Act mode for coding. This ensures the generated code meets my needs and design.

Development

During development, I adhered to the Vibe Coding philosophy, describing requirements in natural language as much as possible, allowing the large model tools to analyze and generate code automatically.

1. Initialization

First, as a matter of convention, I “brainwashed” the large model: You are a quantitative trading programmer developing a quantitative trading program. You possess excellent programming skills and knowledge of quantitative trading. You need to complete this program through steps like requirement analysis, design, coding, and testing.

2. Building a Knowledge Base

Due to limited time and the program’s low complexity, I built a local knowledge base using text files.

I first had the large model analyze the available resources, recording the analysis results in text files. The first step was to analyze the interfaces, providing the interface documentation and all field descriptions to the large model for analysis, understanding, and recording in text files.

After analyzing the interfaces, I had the large model analyze the past month’s index information, recording the analysis results in text files. Additionally, I asked the large model to suggest how this data could be used in the quantitative program based on its analysis.

This step is crucial as it impacts subsequent design and coding. Even the most advanced algorithms require data to support them. If the data is insufficient or misunderstood, even the best algorithms are useless.

3. Checking Existing Code

Having a basic codebase saves a lot of time. The first step is to check the usability of the existing code. I directly had the large model compile the code and check the compilation results.

Usability not only requires successful compilation but also compatibility between the code and the data. By comparing the interface documentation and data analysis results in the knowledge base, I checked whether the existing code met the requirements. If it didn’t, I had the large model modify it. After modification, I recompiled and checked the results. If the compilation failed, it continued modifying the code until it successfully compiled.

This step is crucial as it saves a lot of time and effort. Automating the usability check avoids the tedium and errors of manual checks.

In this step, the large model made significant modifications to the code. The original code only used the price from the index information, ignoring important data like the highest index, lowest index, and total turnover (which I, lacking quantitative knowledge, would have struggled to notice). Without this step, the subsequent algorithm design and implementation might have encountered issues.

4. Requirement Analysis

With a basic knowledge base in place, I began describing my requirements: to create a quantitative trading program. Admittedly, my requirement description was very vague. But that’s okay — this step was conducted in Plan mode. Starting from a broad scope avoids omissions, then gradually refines the requirements and narrows the scope.

Since I didn’t know what features a quantitative trading program should have or its design and implementation, I needed the large model to provide suggestions: What capabilities should an excellent quantitative trading program have?

The large model’s suggestions included (partial content):

Clear logic and quantifiable signals, such as moving averages, multi-factors, and multi-periods.
Risk control mechanisms: stop-loss and take-profit strategies, position management, and risk exposure control.
Backtesting, evaluation, and optimization: backtesting historical data, evaluating strategy performance, and optimizing parameters.
Scalability and modularity.
Automation and live trading adaptation.

This step raised the starting point significantly. Next, I could proceed with requirement analysis based on this foundation. I shared the competition rules and requirements with the large model, asking it to analyze and propose a design and implementation plan for a quantitative trading program.

Combining the large model’s suggestions, I focused the program’s implementation goals on developing quantitative factor logic and backtesting evaluation optimization.

Next, I had the large model filter suitable quantitative factors from all available options based on the competition scenario and rank them by influence. This process is crucial as it helps determine which factors are most important and which are secondary.

At this point, the large model also suggested implementation methods.

Next, we switched to Act mode to have the large model directly generate code. The large model automatically generated code based on the requirement analysis results, compiled and ran it. This process was automated, requiring only attention to the results. It continuously modified the code until the program ran successfully.

During this process, I occasionally asked the large model code-level questions, such as the length of data queues or why certain variables were unused.

The final sell strategy covered factors like momentum, volatility, and extremes, all with adjustable thresholds.

5. Optimization and Testing

After developing the strategy, I began writing the backtesting engine. Remember to switch to Plan mode and describe the backtesting engine’s requirements to the large model: design a parameter grid, record the backtesting results for each parameter set, and compare metrics like return rate and maximum drawdown.

After completing the design, switch to Act mode to have the large model generate code. This process remained automated, requiring only attention to the results. It continuously modified the code until the program ran successfully.

Once the program ran successfully, we could start backtesting. Using the backtesting engine and historical index data, we performed parameter grid searches to find the optimal parameter combination.

Conclusion

Through this experience of developing a quantitative trading program, I once again realized the power of Vibe Coding. Throughout the development process, I only needed to describe my requirements and ideas in natural language, and the large model automatically analyzed and generated high-quality code. From requirement analysis to parameter optimization, the entire process was exceptionally smooth, far more efficient than traditional programming methods.

The advantages of Vibe Coding were fully demonstrated in this project:

I could focus on the requirements themselves rather than the implementation details of the code.
Even with limited knowledge of quantitative trading, I could quickly build a fully functional program.
Code adjustments and iterations became simple and efficient, requiring only a description of the modification needs.
The large model’s suggestions and analysis filled gaps in my knowledge.

However, it’s worth noting that Vibe Coding does not mean a lack of thought. On the contrary, it requires us to think more clearly about the essence of the problem and express our requirements accurately. In this new paradigm, programming skills are shifting from “how to implement” to “how to define problems” and “how to evaluate solutions.”

No matter how technology evolves, the ability to understand problems, think logically, and evaluate results remains indispensable. Vibe Coding makes programming more accessible and efficient but will never replace human creativity and judgment.