Building an AI Investment Strategy Platform Across Three Markets: Lessons from AI, Investing, and Challenging Assumptions

Over the past year, one of the personal projects that has consumed considerably more time than I originally expected has been my Share Investment Strategy Model.

What started as a relatively simple experiment around stock market prediction gradually evolved into something much larger. Along the way, the project expanded into dedicated implementations for the Australian, Taiwanese, and United States markets, incorporated multiple forecasting and machine learning methodologies, and became an unexpectedly useful laboratory for experimenting with both quantitative investing and AI-assisted software development.

Looking back, the most valuable outcome was not a particular model, a backtesting result, or a portfolio simulation.

Instead, the most valuable outcome was learning how many assumptions I held without realizing it.

Almost every meaningful improvement came from discovering that one of those assumptions was wrong.


It Started as a Machine Learning Project

Like many personal quantitative investing projects, the original idea sounded relatively straightforward.

Build several machine learning models.

Feed historical stock market data into them.

Generate signals.

Evaluate performance.

Refine the methodology.

Repeat.

My initial focus was heavily model-centric.

Questions such as these dominated my thinking:

  • Is Random Forest better than CatBoost?
  • Can Prophet predict market movements effectively?
  • Does LSTM contribute meaningful predictive power?
  • Is NGBoost useful for investment decision-making?
  • Which model produces the highest return?

At that stage, I viewed the machine learning models themselves as the centrepiece of the platform.

If the model improved, surely the strategy would improve too.

At least, that was the assumption.

The reality turned out to be quite different.

The longer I worked on the project, the more obvious it became that the most difficult problems had very little to do with machine learning itself.

The difficult problems were about markets.


Markets Are Not Universal

One of the biggest architectural changes during the project was splitting the repository into dedicated branches for different markets:

  • ASX (Australia)
  • TWN (Taiwan)
  • USA (United States)

Initially, I resisted this idea.

From a software engineering perspective, maintaining a single implementation is always attractive.

Less duplication.

Less maintenance.

Less complexity.

The problem was that financial markets are not interchangeable.

The more I investigated market behaviour, data availability, trading rules, and investment practices, the more obvious it became that a single market-agnostic framework would force unrealistic assumptions onto fundamentally different environments.

Eventually, I stopped trying to build one universal solution and started building separate market-aware implementations instead.

That decision increased complexity considerably.

But it also made the platform far more realistic.


Taiwan Changed My Thinking

Among all three implementations, Taiwan probably had the greatest influence on how I think about investment systems.

When I first started the Taiwan branch, I assumed most approaches developed for US markets would transfer reasonably well.

That assumption didn’t last long.

Monthly Revenue Matters

One of the earliest surprises was the importance of monthly revenue disclosures.

Investors in many Western markets tend to focus heavily on quarterly earnings announcements.

Taiwan operates differently.

Monthly revenue announcements can become meaningful signals that influence investor sentiment and market expectations before quarterly earnings are released.

Ignoring them felt increasingly difficult to justify.

The Taiwan implementation gradually evolved to include information sources and indicators that would not naturally appear in a purely US-focused investment framework.

Institutional Activity Matters

Another observation was the importance of institutional and foreign capital participation.

For many Taiwanese technology and semiconductor companies, institutional behaviour can exert significant influence on market movements.

As a result, the platform gradually expanded to incorporate information beyond standard price and volume datasets.

Again, the lesson was not that Taiwan is unusual.

The lesson was that every market contains its own characteristics, and those characteristics matter.

Market Rules Matter

Perhaps the most important lesson was much simpler:

Reality matters.

Transaction costs matter.

Taxes matter.

Settlement rules matter.

Liquidity matters.

Market restrictions matter.

Many strategies appear highly profitable when friction is ignored.

Their attractiveness diminishes considerably once reality is introduced.

The more realistic the simulations became, the more obvious it became that investment performance depends on much more than prediction accuracy.


The United States Taught Different Lessons

The United States implementation introduced an entirely different set of challenges.

Compared with Taiwan, the US market provides:

  • Greater liquidity
  • Larger market capitalization
  • Broader sector diversity
  • Larger institutional participation
  • Richer publicly accessible datasets

Some techniques that performed well elsewhere became less useful.

Other approaches became surprisingly effective.

One observation that repeatedly emerged was that opportunities often appeared in unexpected sectors.

Technology was not always the winner.

Financial institutions periodically dominated.

Industrial businesses occasionally produced stronger results than many market favourites.

The more analysis I performed, the more sceptical I became of simplistic narratives.

That scepticism ultimately improved the platform.


Developing in the Era of AI

One unexpected aspect of this project was how deeply AI became embedded in the development process itself.

When the project began, I primarily viewed Large Language Models as productivity tools. They could accelerate coding, explain unfamiliar concepts, help with documentation, and occasionally suggest implementation approaches.

Over time, that relationship changed.

Rather than asking AI systems to provide answers, I increasingly found myself using them to challenge answers.

Many development decisions did not follow a straight path from idea to implementation. An observation from market analysis might evolve into a proposed solution, which would then be questioned, refined, redesigned, or sometimes completely discarded after exploring alternative viewpoints.

Quite often, the final implementation looked very different from the original idea.

The most valuable outcome was rarely the generated code itself.

It was the thinking process that emerged around it.


When AI Systems Disagreed

One of the more interesting observations throughout development was how frequently different AI systems disagreed with each other.

The same requirement could produce several reasonable but fundamentally different solutions.

Early on, I spent a considerable amount of time trying to determine which answer was correct.

Eventually, I realised that was often the wrong question.

A more useful question became:

Why are the answers different?

Sometimes the differences highlighted hidden assumptions within the requirements.

Sometimes they exposed implementation risks.

Sometimes they reflected different engineering philosophies.

And occasionally, they simply demonstrated that there was more than one reasonable solution.

Those moments of disagreement often proved more valuable than receiving a single answer immediately.

The discussion itself became part of the design process.


AI Became a Thinking Partner Rather Than a Coding Assistant

Looking back through the project’s evolution, AI contributed to much more than writing code.

It became involved in discussions around:

  • Investment methodologies
  • Market-specific adaptations
  • Data acquisition approaches
  • Strategy evaluation techniques
  • Portfolio simulation logic
  • Dashboard and user experience design
  • Documentation and knowledge sharing
  • Feature prioritisation
  • System architecture decisions

The role constantly shifted.

Sometimes AI accelerated implementation.

Sometimes it challenged assumptions.

Sometimes it identified edge cases that had been overlooked.

And in many situations, its greatest value came from helping explore several possible directions before committing to one.

As the project grew, I became less interested in treating AI as a system that generates answers and more interested in treating it as a tool for structured exploration.

Perhaps the most important lesson was that AI works best when it improves thinking rather than replaces thinking.


From Model Benchmarking to Algorithm Consensus

One of the biggest methodological changes in the platform was moving away from the idea that a single algorithm should dominate investment decisions.

Early versions focused heavily on model benchmarking.

Random Forest, CatBoost, Prophet, NGBoost, LSTM, and other approaches were evaluated independently through backtesting and portfolio simulations.

The objective appeared straightforward:

Find the best-performing model.

The problem was that there never seemed to be a permanent winner.

Different market environments favoured different algorithms.

Different sectors produced different outcomes.

Different time periods produced different rankings.

A model that performed exceptionally well under one set of conditions might struggle under another.

Over time, I became less interested in identifying a universal winner and more interested in understanding where different analytical approaches independently arrived at similar conclusions.

That shift in thinking became one of the most important changes in the project.


Treating Models as Algorithm Experts

Rather than viewing algorithms as competitors, I gradually started viewing them as specialised analytical experts.

Each algorithm examines the market through a different lens.

Some are particularly effective at identifying historical patterns.

Some excel at structured tabular analysis.

Some provide stronger forecasting capabilities.

Others are better suited to modelling probabilities or sequential behaviour.

None of them are consistently correct.

None of them are consistently wrong.

And none of them dominate every scenario.

The objective therefore shifted from selecting the “best” algorithm to understanding where multiple independent analytical approaches converged.

Those areas of agreement often became significantly more interesting than the performance of any individual model.


The AI Committee

This philosophy eventually became the foundation of the AI Committee capability within the platform.

Despite its name, the AI Committee does not consist of Large Language Models.

Instead, it represents the collective viewpoints of multiple forecasting and machine learning algorithms evaluating the same investment opportunity.

The committee is best thought of as a panel of Algorithm Experts.

Each expert contributes its own assessment based on its methodology, assumptions, and strengths.

The user interface allows investors to observe where these experts agree, where they disagree, and how their opinions combine within the broader evaluation framework.

The purpose is not to automate investment decisions.

The purpose is to provide greater visibility into how different analytical approaches interpret the same opportunity.

Where multiple experts independently reach similar conclusions, confidence may increase.

Where significant disagreement exists, further investigation may be warranted.

Much like real-world investing, the differing viewpoints are often just as valuable as the consensus itself.


The Birth of Super Stars

The AI Committee concept eventually led to one of my favourite features within the platform.

Initially, most evaluations focused on algorithm performance.

Questions typically sounded like:

Which model generated the best ROI?

Investors rarely care which algorithm wins.

Investors care which investments perform well.

That shift in perspective eventually led to the creation of the Super Stars framework.

Instead of ranking algorithms, the platform ranks opportunities.


Hall of Fame: Super Stars

The Super Stars analysis evaluates securities using results generated by multiple algorithm experts.

Trades are simulated.

Performance is measured.

Outcomes are ranked.

The result is a Hall of Fame style leaderboard highlighting securities that delivered strong performance across the platform’s evaluation framework.

One particularly interesting run within the Taiwan market highlighted several stocks that consistently appeared across multiple algorithm evaluations. More recently, the US market implementation produced equally fascinating results through the Dow Jones analysis, surfacing names that traditional narratives might not immediately consider market leaders.

What fascinated me was not the rankings themselves.

It was the diversity.

Technology appeared.

Industrials appeared.

Financial institutions appeared.

Energy companies appeared.

The strongest candidates emerged from multiple sectors and business models.

The platform was not pursuing a specific narrative.

Instead, it was surfacing opportunities identified through multiple analytical perspectives.

That felt significantly more robust than relying on a single algorithm’s opinion.

The feature also revealed something unexpected.

Sometimes the most valuable outcome was not discovering the highest-ranked stock.

It was understanding why multiple algorithms independently reached similar conclusions despite using completely different methodologies.


Accuracy Is Overrated

One lesson repeatedly reinforced throughout the project is that prediction accuracy can be a misleading metric.

Higher accuracy does not automatically translate into better investment performance.

Investors cannot spend accuracy.

Investors spend returns.

A model with lower prediction accuracy may still outperform if it captures larger profitable movements and avoids significant losses.

As a result, the project gradually shifted toward evaluating:

  • Portfolio growth
  • Risk-adjusted returns
  • Drawdowns
  • Trade performance
  • Investment outcomes

Less emphasis on prediction.

More emphasis on decision quality.


Backtesting Is Both Useful and Dangerous

I enjoy backtesting.

I also distrust backtesting.

Both statements are true.

Backtesting provides evidence.

Backtesting also creates confidence.

Sometimes too much confidence.

The market has no obligation to repeat historical behaviour.

As a result, some of the most important questions became:

Why did this work?

And:

Under what conditions would this stop working?

Those questions frequently produced more valuable insights than impressive performance statistics.

Over time, I became increasingly sceptical of strategies that looked too good.

Experience has taught me that exceptionally strong results are often worth investigating more carefully rather than celebrating immediately.

Sometimes they reveal genuine insights.

Sometimes they reveal flaws in assumptions.

Sometimes they reveal flaws in the data itself.


Building the Platform Was More Than Building Models

As the project evolved, I realised I wasn’t just building machine learning models.

I was building a research platform.

A considerable amount of effort eventually went into areas that had little to do with forecasting:

  • Interactive dashboards
  • Market-specific visualisations
  • Portfolio comparisons
  • Ranking frameworks
  • Strategy evaluation workflows
  • User experience improvements
  • Reporting capabilities

The screenshots generated from both the Taiwan and US implementations reinforced how important visualisation had become.

The ability to explore results interactively often produced insights that would have been easy to miss by simply reviewing model outputs or spreadsheets.

In many ways, the platform became less about prediction and more about helping investors think systematically about opportunities, risks, and trade-offs.


What Went Wrong

No meaningful project progresses without mistakes.

This one certainly didn’t.

Trusting Data Too Easily

Several early results appeared promising until data quality issues were discovered.

Correcting the underlying datasets often changed conclusions dramatically.

Data quality repeatedly proved more important than model sophistication.

Over-Optimising Models

There were periods where significant effort was spent chasing marginal improvements in algorithm performance.

Later I discovered much larger gains often came from improving assumptions, datasets, or market understanding.

Trusting AI Too Much

Large language models are remarkably capable.

They are also capable of producing highly convincing mistakes.

The most dangerous outputs were rarely obviously wrong.

They sounded reasonable.

That reality reinforced the importance of validation, testing, and independent verification.

Underestimating Market Differences

This was probably the biggest mistake of all.

The establishment of separate ASX, Taiwan, and USA implementations was not simply a feature enhancement.

It was a correction to an early misunderstanding.

Markets are different.

And those differences matter.


What I Still Want to Improve

Although the platform has evolved considerably, there is still plenty of room for improvement.

Better Market-Specific Signals

The more I work on the project, the more convinced I become that market-specific information matters.

There are undoubtedly additional datasets, indicators, and signals that could further improve market-aware analysis.

Improving Backtest Realism

Backtesting remains both useful and dangerous.

Continued improvements will likely focus on making simulations as realistic as possible without losing practicality.

Expanding Market Coverage

The transition from one implementation to three demonstrated the value of market-specific approaches.

Future expansion will likely continue following the same philosophy.

Adapt the framework to the market.

Do not force the market to adapt to the framework.

Refining Algorithm Expert Collaboration

The interaction between different algorithm experts remains one of the most interesting areas of the platform.

There is still significant opportunity to improve how consensus, disagreement, and confidence are interpreted and presented.

The objective is not finding a perfect model.

It is making better decisions from multiple imperfect perspectives.

Continuing the Experiment

Most importantly, the project remains an experiment.

New data.

New market conditions.

New methodologies.

New assumptions to challenge.

And that is exactly what makes it interesting.


Final Reflections

When I started this project, I thought I was building a machine learning investment platform.

Looking back, that description feels incomplete.

The project became an exercise in understanding uncertainty.

It taught me about market structures.

It taught me about data quality.

It taught me about evaluation methodology.

It taught me about software engineering.

It taught me about AI-assisted development.

Most importantly, it taught me how dangerous assumptions can be.

The separation into ASX, Taiwan, and USA implementations emerged because markets behave differently.

The Algorithm Expert methodology emerged because different algorithms see the market differently.

The multi-LLM development workflow emerged because different AI systems think differently.

All three lessons ultimately point toward the same conclusion:

No single market, algorithm, dataset, or AI system has a monopoly on good ideas.

The strongest outcomes usually emerge from comparing perspectives, challenging assumptions, and remaining willing to change direction when evidence suggests you should.

The repository will continue evolving.

The algorithms will continue changing.

The markets will continue surprising investors.

And that is probably the biggest lesson this project has taught me.

The goal was never to build a perfect investment strategy.

The goal was to keep learning.

Everything else was simply a by-product of that journey.

Hermes, a Mac Mini M4, and the Quest to Organise 197,000 Photos

Sometimes the most interesting AI projects begin with a problem nobody wants to solve manually.

Mine started with roughly 197,000 image files occupying around 44GB of storage.

The collection had grown over many years from publicly available websites, forums, social media platforms, blogs and news sites. Images were scattered across 65 folders, many named after domains, some with nothing more meaningful than a serial number.

Finding anything had become increasingly difficult.

The obvious question was:

Could an AI agent organise the collection for me?

What followed became a useful lesson about what AI agents can do today, and what they still struggle to do.

The Goal

The initial objective sounded straightforward.

Take thousands of photos, group them by person, determine who that person is, and rename the folders accordingly.

The naming logic was relatively simple:

  1. Use the original native-language name whenever possible.
  2. Fall back to a Chinese translation if one exists.
  3. Otherwise use the English name.

For example, if a public figure’s original Japanese, Korean or Chinese name could be identified, that name would be preferred over an English transliteration.

The challenge was that almost none of the photos came with reliable metadata.

Humans could solve this eventually.

I simply didn’t want to spend months doing it.


The Setup

The infrastructure was deliberately minimal.

Hardware:

  • Mac Mini M4
  • External storage
  • Hermes running locally

LLM access:

  • OpenRouter
  • USD$10 prepaid credit

Remote interface:

  • Telegram Bot

Security was intentionally restricted.

Only messages originating from my own Telegram Application ID were allowed to issue commands. Nobody else could interact with the agent.

This effectively turned Telegram into a secure remote terminal for my Mac Mini.

I could initiate jobs, monitor progress and review results directly from my phone.


The Models

Like many people, I started with free models.

On paper they seemed impressive.

In practice they frequently misunderstood instructions, lost context, ignored constraints or produced inconsistent decisions.

Many could discuss the work.

Far fewer could reliably perform it.

After numerous tests, OpenAI 5.6 Luna proved to be the most reliable option available through OpenRouter.

Even then, “reliable” did not mean perfect.

My own observation was that the model understood approximately 99% of what I intended.

That sounds excellent.

Until thousands of automated actions are involved.

At scale, a 1% misunderstanding rate becomes surprisingly visible.


The Pipeline Grew Much Larger Than Expected

What started as a renaming exercise evolved into a multi-stage workflow.

Hermes first performed face extraction and clustering.

The initial pass produced:

  • 232,850 detected faces
  • 7,014 clusters
  • 143,048 images identified as noise

The naming phase then relied on external services.

The workflow eventually became:

Face Clustering
        ↓
Representative Images
        ↓
Upload to ImgBB
        ↓
Google Lens via SerpDev
        ↓
Confidence Analysis
        ↓
If uncertain
        ↓
Queue for Yandex Search
        ↓
Additional Validation
        ↓
Folder Renaming

The idea sounded reasonable.

The reality proved much harder.


Hermes Was Surprisingly Good at Self-Correction

One unexpected discovery was how often Hermes reviewed its own work.

Rather than simply executing commands, it frequently reported problems.

The Telegram chat looked less like a chatbot and more like a junior engineer providing status updates:

  • clustering completed
  • worker restarted
  • validation failed
  • confidence too low
  • manual review required
  • schedule misconfigured
  • progress reporting restored

Sometimes I would simply respond:

Do what you think improves the result quality.

Hermes would patch scripts, modify workflows, restart workers and verify outputs.

It wasn’t autonomous in the science-fiction sense.

But it was surprisingly capable of identifying weaknesses in the process.


The Project Never Finished

The original target was roughly 840 high-priority clusters.

The plan was:

  • Top tier (150 groups)
    • Google Lens
    • Yandex verification
  • Middle tier (300 groups)
    • Google Lens
    • Yandex as needed
  • Lower tier
    • Process later

In practice, reality intervened.

The top 150 groups completed two-stage scanning.

Only around three quarters of the middle-tier groups finished Google Lens processing.

The Yandex stage never reached meaningful scale.

Costs increased.

Runtime increased.

Complexity increased.

Progress slowed dramatically.


The Disappointing Part

Eventually I reviewed the rename results.

And honestly?

I wasn’t impressed.

Some folders were excellent.

Some recovered original Japanese names.

Some recovered Korean names.

Some recovered Chinese names.

Many looked promising.

But many others were messy.

A significant number resembled search-result titles rather than identities.

Others inherited fragments from websites, article headlines or unrelated metadata.

Overall, I would estimate only about half of the renamed folders felt genuinely useful.

Not wrong enough to call a failure.

Not good enough to trust.

That was the point where I stopped.

Not because Hermes couldn’t continue.

Because I no longer believed additional spending and fine-tuning would produce proportionally better outcomes.

After roughly three to five days of experimentation, I had learned what I wanted to know.


What I Learned

The lesson wasn’t that AI agents are useless.

Quite the opposite.

Hermes successfully automated weeks of tedious work.

The lesson was that identifying a face and identifying a person are fundamentally different problems.

AI vision can group similar images remarkably well.

Recovering an accurate human identity is much harder.

It requires:

  • search engines
  • reverse image lookup
  • public web information
  • metadata analysis
  • language translation
  • confidence validation
  • human judgement

And despite all the recent advances, AI still struggles with that last part.

The technology worked.

The workflow worked.

The economics were reasonable.

The accuracy simply wasn’t high enough.

For me, that was the most interesting outcome.

The experiment didn’t end because the AI failed.

It ended because I finally discovered where its practical limits currently are.

And honestly, that answer was worth far more than the USD$10 I started with.

Honing the Engine: January 2026 Progress on flask‑records‑management

Following the progress recorded in my earlier post last November (https://blog.yannicklin.net/diary/2025/11/5813), where I outlined the initial structure of the project and several early-stage concerns, this month’s work focused on consolidating the system and resolving the issues that have accumulated since then. January has been about tightening the fundamentals — removing outdated components, correcting inconsistencies, and strengthening both code and documentation to support future development.

Below is a structured summary of the main updates applied throughout January 2026.


OpenCode Format Migration

The previously mentioned Gemini-based workflow has now been fully replaced with the OpenCode format. This shift addresses several of the limitations highlighted in the earlier post, particularly around predictability and maintenance overhead.

Key changes

  • Complete removal of Gemini-specific parsing logic
  • Unified and simplified ingestion and validation behaviour
  • Cleaned and updated record structure handling
  • Elimination of redundant or outdated sample files
  • Consistent naming and file-processing rules across modules

This transition provides a more stable base for upcoming features and aligns the internal workflow with the direction outlined last November.


Documentation Restructuring

In the previous post, I noted that documentation at the time was fragmented and partially experimental. This cycle focused on addressing exactly that problem.

Improvements

  • Rewrote several sections to eliminate conflicting explanations
  • Normalised formatting and structure across all documents
  • Removed partial drafts and legacy artifacts
  • Clarified what is implemented, what remains open, and what is intentionally out of scope
  • Performed consistency checks to ensure terminology does not drift

The documentation now reflects the actual state of the system, without speculative or leftover content.


UI, Responsiveness, and Behavioural Improvements

Some of the UI issues mentioned earlier — especially inconsistent rendering and mobile behaviour — were addressed in a dedicated cleanup effort.

Updates

  • Improved mobile responsiveness
  • Corrected layout inconsistencies
  • Streamlined template behaviour
  • Refined search logic for more predictable results
  • Updated Excel/PDF export functionality and removed outdated placeholder documents

These changes make the application feel more stable and predictable, regardless of device or workflow.


Code Cleanup and Minor Fixes

The accumulated debris of earlier development phases has now been cleared out.

Cleanup actions

  • Removed obsolete debugging comments
  • Eliminated unused or duplicated code blocks
  • Corrected a small lingering logic bug
  • Standardised comment style so explanations describe intent, not history

This cleanup helps maintain clarity and reduces friction for future development.


Development Environment Improvements

A notable upgrade this month was the addition of pre‑commit hooks, which enforce:

  • automatic linting,
  • code formatting,
  • and basic static security checks.

This directly addresses workflow issues I hinted at in the previous post, where consistency and code cleanliness were recurring concerns.

With this change, low‑quality or inconsistent commits are automatically blocked, improving the reliability of the codebase.


Ongoing Work

Current work continues in the areas of:

  • additional refinement of search behaviour,
  • validation logic improvements,
  • deeper integration of the OpenCode pipeline,
  • and incremental documentation corrections where necessary.

These updates extend the foundation built this month and will support the next functional steps of the project.


Notes on Spec‑Kits and Developer Tools

As mentioned previously, I have been working alongside AI‑assisted documentation tools. Recent observations reinforce earlier concerns:

  1. unreliable work‑hour estimations,
  2. unnecessary creation of supplementary documents,
  3. inconsistent formatting between outputs,
  4. internally contradictory messages,
  5. corruption caused by partial updates,
  6. and GitHub Copilot’s inability to perform proper research or maintain global consistency across documentation.

These limitations continue to highlight the gap between code-level assistance (where AI tools perform well) and specification‑level consistency (where significant manual intervention remains unavoidable).


Conclusion

Building on the direction outlined in my previous post, January 2026 delivered consistent and meaningful progress for flask-records-management. The system now has:

  • a unified data format (OpenCode),
  • cleaner and more accurate documentation,
  • improved UI behaviour,
  • better export reliability,
  • code cleanup across the board,
  • and pre‑commit hook enforcement for long‑term maintainability.

With these fundamentals in place, the next iterations can shift back toward feature expansion instead of infrastructure correction.

From Chaos to Clarity: My Journey Combining Vibe Coding, Specs, and AI (And Why It’s Just the Beginning)

When It All Started

When I started this project, the idea sounded simple: build a web application to manage personal accounts and records. The data was already there—an Excel file with three worksheets: Generic, Systems, and Finance. This wasn’t random; it was intentional. I wanted the web app to treat these three sheets as separate tabs, each with its own logic and presentation. That was part of the design from day one.

I also had a principle in mind: combine vibe coding with Spec-Driven Development (SDD). Vibe coding is fast and creative—it lets you jump in and start building without overthinking. SDD, on the other hand, is structured and disciplined. It forces you to define specifications before writing code. Most developers pick one approach and stick with it. I wanted to see what happens when you mix them. Could I keep the flexibility of vibe coding while enjoying the clarity of specs? That was the experiment.

Choosing GitHub SPEC-Kit was deliberate. I didn’t have private access to AWS Kiro, which was one option for spec management. SPEC-Kit, on the other hand, is open-license and widely shared among communities as a solid starting point. That openness mattered to me—it felt like building on something trusted and collaborative. Plus, it aligned with my principle: start with specs, but don’t lose the creative flow.


The AI Experiment: Gemini vs Claude

Then came the twist: I decided to mix AI tools. On my private laptop, I had Gemini CLI, while my work laptop had GitHub Copilot with an enterprise license. I wanted to see how these two could work together—or if they even could. It turned out to be one of the most interesting parts of the journey.

Gemini and Claude felt like two very different personalities. Gemini 2.5 was like an old gentleman—slow, stubborn, and obsessed with correctness. It followed instructions religiously, always trying to update the spec before moving forward. If something wasn’t documented, Gemini would stop and insist on fixing the spec first. Claude 4, powering Copilot, was the opposite: quick, action-oriented, and well-organized. Claude wanted to get things done. Sometimes it respected the rule of “update the spec before coding,” but other times—maybe 50-50—it ignored the instructions and dove straight into implementation.

Watching them interact was fascinating. When Gemini looked at Claude’s work, it always tried to “correct” it, sticking strictly to the specs. Claude, meanwhile, prioritized completing tasks. Specs were evolving, and Gemini wanted everything perfect before moving on. Claude just wanted to ship features. Managing that tension felt like managing two developers with completely different work styles. It taught me something unexpected: AI tools aren’t just technical helpers—they have tendencies, almost like personalities. Understanding those tendencies can make collaboration smoother.


The Human Role in AI Development

Here’s where my added challenge comes in: it’s not an easy job for me to present as a not-so-experienced engineer with design skills, while acting like a project manager or product ideator. I had to guide AI without sounding overly technical, using language that was clear and actionable. Especially for UI changes, basic tech stack decisions, and security issues, I couldn’t just throw jargon at the AI and hope for the best.

This balancing act—between technical precision and accessible language—was harder than I expected. AI doesn’t “think” like us; it interprets patterns. If I said, “Make the UI more intuitive,” that was too vague. If I said, “Apply responsive design principles with Tailwind CSS and ensure accessibility compliance,” that was too rigid and sometimes misinterpreted. I had to find the sweet spot: simple, structured prompts that conveyed intent without overwhelming detail.


The Tech Stack and Deployment Vision

From the beginning, I wanted this app to feel modern and scalable. The stack I chose was Flask for the backend, Vue.js for the frontend, and Tailwind CSS for styling. Why this combination? Flask is lightweight and flexible, perfect for rapid prototyping. Vue.js gives me reactive components without the complexity of heavier frameworks. Tailwind CSS makes styling efficient and consistent.

The long-term vision is to deploy the app as a Docker container on Portainer, making it easy to manage and scale. That’s why I started thinking about containerization early—even though it added complexity to local development.


The Database Journey: From TinyDB to MontyDB

Here’s where things got messy. My initial choice for the database was TinyDB. It’s simple, lightweight, and great for quick setups. But then I realized something critical: TinyDB stores everything as clear text in JSON. For an app that manages personal records—including login credentials for multiple websites—that’s a huge security risk. I couldn’t ignore that.

So I switched to MongoDB, the most popular NoSQL database. It felt like the right move for scalability and security. But this switch wasn’t easy. MongoDB in my setup was pure Docker-based, which made local development and testing a burden. Setting up the environment, configuring containers, and ensuring connectivity took more than two full days. And even after that, the workflow felt heavy for a project that was still in its early stages.

Finally, I decided to switch again—this time to MontyDB, a lightweight fork of MongoDB designed for local development. It gave me the MongoDB-like API without the overhead of running full Docker containers. But even this switch wasn’t painless. Migrating data caused duplicates and corruption issues, and fixing them took another full day. These database transitions taught me a hard lesson: choosing the right tools early matters, but flexibility matters even more.


The App So Far: 50–60% Complete

The app itself is still only about 50–60% complete, but it already has some core features in place. The first thing you see is a login screen with predefined account/email and password. After a successful login, the first screen is a dashboard. From there, you can navigate to the three main tabs: Generic, Systems, and Finance. Each tab presents its data in different columns but shares common fields like title, account, and password.

For usability, the password field has a toggle to show or hide the value, while other fields include a “copy to clipboard” tool. These small details matter because they make the app feel practical and user-friendly. Each category also supports search by title, and export functions to PDF or Excel. That was important to me—if you’re managing records, you need easy ways to share or back them up.

There’s also a Settings tab, which handles overall theme (dark, light, or system default), category color customization, and password reset/modify. These features might sound minor, but they add a layer of personalization that makes the app feel polished. I wanted users to feel like they could make the app their own.


The Hardest Part: PDF Generation and Non-English Text

One of the last major hurdles was PDF generation. It sounded simple at first—just export the records into a clean PDF format. But the reality was far from easy. Many of the records contained non-English characters, including CJK (Chinese, Japanese, Korean) text. When I tried to generate PDFs, the output was a mess: mojibake, question marks, or solid black boxes instead of readable text.

The root of the problem? Fonts. Embedding CJK fonts in PDFs is not straightforward. Many fonts you download aren’t “true” TTF (TrueType Font) files, and libraries like ReportLab have limitations when it comes to handling complex scripts and font embedding. Even when I thought I had the right font, the rendering failed because the font wasn’t fully compatible or lacked proper glyph support.

Explaining this issue to AI tools was another challenge. How do you tell an AI that the font rendering is wrong when it doesn’t “see” the output the way we do? I tried different libraries, custom font paths, and encoding tweaks, but it was a frustrating process. This part reminded me of something critical: AI accelerates development, but it doesn’t replace human judgment—especially for nuanced issues like multilingual text rendering and font embedding.


Additional Pain Points

There were other challenges that made this journey even more interesting:

  • Stability issues: Both AI models were prone to hanging. Gemini almost never ran stably for more than an hour without needing a terminal restart. Claude was better, but still had occasional freezes.
  • Memory loss and oversight: Claude’s tendency to forget context was not limited to rules in the instructions. Sometimes it even forgot or misled itself about the agent to-do list it had set minutes earlier. This meant I couldn’t simply “set and forget.” I had to continuously monitor and intervene, making sure its operations didn’t drift too far from the original scope. Without human oversight, the risk of over-designing or introducing unnecessary complexity was high.
  • Bug fixing reality: Drafting the application with AI was exciting—the speed and completeness were beyond expectations. But once I moved to bug fixes and UI enhancements, the story changed. With SDD in place, resolving issues became harder because the AI struggled to adapt to evolving specs without breaking something else.

Reflections on AI Collaboration

This project taught me something important about AI-human collaboration. AI tools are powerful, but they’re not magic. They need guidance. Gemini and Claude didn’t just follow my commands—they interpreted them, sometimes in ways I didn’t expect. Gemini stuck to the rules like a perfectionist. Claude bent the rules when it thought speed mattered more. Neither was wrong, but both needed context.

And here’s the human side: I had to act as a translator between ideas and implementation. Sometimes I felt like a designer, other times like a product manager, and occasionally like a security consultant. All while trying to keep my language simple enough for AI to understand. That’s not easy when you’re still growing as an engineer. But it’s necessary. Because AI doesn’t just need instructions—it needs clarity, intent, and sometimes empathy.

Mixing AI tools also showed me that diversity matters—even in software development. Gemini’s strictness kept me from cutting corners. Claude’s speed kept me from getting stuck in planning forever. Together, they balanced each other out. It wasn’t always smooth, but it was productive.


Why This Is Just the Beginning

The app isn’t finished yet, and that’s okay. It’s about 50–60% complete, and the next steps include refining the UI, adding more customization options, and improving export features. I also want to explore how AI can help with testing and optimization. Claude is great at generating code, but can it write meaningful tests? Gemini is good at specs, but can it help with performance tuning? These are questions I’m excited to answer.

Would I do it again? Absolutely. But next time, I’ll start with specs from day one—and maybe keep experimenting with AI personalities. Because building with clarity and a little help from two very different “assistants” turned out to be more interesting than I expected.

This isn’t the end of the story. It’s just a pause—a checkpoint before the next sprint. There’s more to build, more to learn, and more to share. And honestly? I can’t wait to see where this journey goes next.