slowlp
← Blog
Method 2026.06.11 · 9 min read

What I Learned Building a Stock Portfolio App with AI Agents

Worktree pipelines, multi-agent experiments, KIS API pitfalls, and getting blocked by regulations after nearly finishing the whole thing

Method

What I Learned Building a Stock Portfolio App with AI Agents

Worktree pipelines, multi-agent experiments, KIS API pitfalls, and getting blocked by regulations after nearly finishing the whole thing


Part 1. A Worktree-Based AI Development Pipeline

Building trading_mvp solo, I started out running AI agents off a single branch. That worked fine until I had multiple features going in parallel — then things got messy. When you don’t break work into segments, you end up in a situation where one agent is working on a feature branch and you want to build something else at the same time.

That’s what pushed me toward a git worktree pipeline. I’d create a worktree per feature with names like wt-<feature-name>, run agents independently in each one, and when a feature was done, a finalize-worktree.py script would auto-merge it into dev and clean up the worktree.

At one point I broke this rule — I manually checked out a folder and ran docker compose up in it. The containers collided and I burned a solid chunk of time debugging. After that I banned direct container launches outside of worktrees entirely.

I also ran a multi-agent experiment. On May 25, 2026, I split work across manager, worker, planner, tester, reviewer, and refactorer roles. Once a worker finished implementing a feature, a Tester agent would automatically spawn and verify the results. Tasks were passed between agents through a work inbox/feed system.

What I learned doing this: context handoff between agents and feed management is everything. The overall quality wasn’t determined by how accurately each individual agent worked — it was about how well the previous agent’s output got passed to the next one. I’ve carried this pattern forward into the Hermes/Claude Code split workflow as well.


Part 2. KIS API Field Notes — Rate Limits and Testing Traps

There were quite a few things I didn’t expect from the KIS Open API until I actually used it.

The rate limit error (EGW00201) first hit me on May 22, 2026, when I tried to bulk-sell 12 stocks at once. It fires when you exceed the per-second request limit. I added auto-retry logic to _arequest — 1-second intervals, up to 3 attempts — and also set different sleep times between chunks: 1.0s in PAPER mode, 50ms in LIVE. Simple in hindsight, but I didn’t know these numbers until it blew up in a real sell flow.

PAPER vs. LIVE mode differences were another thing I had to discover the hard way. In PAPER mode I kept getting a 40100000 error — “not a simulated trading business day” — and spent a while convinced it was a bug in my code. Turned out it’s a PAPER-only error. In LIVE it shows up as APBK0919 (“trade date does not match order date”), which is a completely different message. Same story with balance queries: D+0 balance (dnca_tot_amt) and D+2 settled balance (prvs_rcdl_excc_amt) are entirely different things, and mixing them up makes your numbers go sideways.

There was also a testing environment trap. On June 1, 2026, I ran pytest with AUTH_EMAIL_ALLOWLIST set in my environment. The test JWTs didn’t have an email claim, so everything came back 403. You have to unset that env var before running tests. Tests that should have passed all failed, and I initially assumed it was a code problem. I ran into similar stuff during the build-plan workflow too — small environment mismatches have a way of exploding somewhere unexpected.


Part 3. Why I Can’t Launch After Building Almost Everything

On May 31, 2026, near the end of a session, I actually sat down and read the KIS Open API terms of service. Up to that point I’d been focused on building features and hadn’t thought to look carefully at the terms.

What I found there was pretty clear. Calling the API for your own personal account? Fine. But “providing order execution and account-linked services to multiple users”? That requires being a licensed financial institution — a corporation with a financial advisory license. Fintech partnerships were explicitly prohibited, and even having an investment advisory registration doesn’t help because Korea Investment & Securities blocks fintech tie-ups on their end anyway.

This conclusion landed after I had already built a FastAPI backend, Expo mobile app, CI/CD, security hardening, and live order processing — the full MVP. Honestly, it was deflating.

But thinking it through, it wasn’t a waste. Everything I built is still there. I run it as a personal automated trading bot on my home server right now, and the codebase lives on as a portfolio asset. There are also three directions I’m considering going forward: turning it into a rebalancing suggestion tool (no direct orders), B2B licensing, and keeping it as a portfolio piece. I’m tracking this in trading_mvp.

One lesson, if nothing else: check regulations and external API constraints before you build. Changing direction at 70% complete is a lot more painful than finding out at the start. I did it backwards — but at least I got this post series out of it.


← Prev: I Read the Terms of Service After Building the Whole Thing · Next →: Home Server Deployment Struggles Method: Agent Role Split Workflow · Method: Cutting Dev Time with Build Plans

Related
All posts →
COMMENTS