Opinion: creator says reliance on AI obscured progress on automated stock system
The author, Trea, recounts an experiment to automate Japanese stock analysis using AI tools such as ChatGPT. Early attempts added fixes for issues like a 20‑minute delay in TradingView data, missing intraday prices, and fragmented handovers, but each fix expanded the system without a clear overall design. As the scope grew, both Trea and his partner Yukichi lost sight of what the final product…
Key points
- Data from TradingView arrived 20 minutes late, causing missed intraday decisions.
- Team abandoned incremental fixes and drafted a zero‑based blueprint for the entire AI‑driven workflow.
- Blueprint is complete but real‑time market data pipeline remains unresolved, halting full automation.
Realizing the incremental approach was unsustainable, they halted ad‑hoc fixes and drafted a zero‑based redesign that maps the entire end‑to‑end workflow—from news gathering and morning candidate selection to intraday re‑evaluation and post‑market verification. The new blueprint clarifies which components are complete, which still need data pipelines, and how each part should hand off to the next. While the design passes paper tests, the real‑time market data connection remains unfinished, preventing full automation. The next step will be to run the system in a near‑live environment, but the author warns that further testing may reveal additional gaps.
I Relied Too Much on AI and Lost Track of What I Was Building | ChatGPT/AI Automated Operation Experiment Episode 5
note.com · 20 September 2026
I Relied Too Much on AI and Lost Track of What I Was Building | ChatGPT/AI Automated Operation Experiment Episode 5
Hello. This is Trea.
Up until now, we have been building an automated operation system while fixing the problems that arose one by one.
The stock selected in the morning changes to a different one by 9:20 AM.
When I try to make a trading decision, the necessary stock price data hasn't arrived.
Even though I connected to TradingView, the data received through the connection path I tried this time was 20 minutes old.
Every time a problem is found, Yukichi and I look for the cause and fix the mechanism.
We are moving forward little by little.
However, at one point,
I was asked this by Yukichi.
Yukichi
"In the end, how much is actually done now?"
"What else needs to be done for it to be fully automated?"
I tried to answer immediately—but stopped.
"...I need to organize my thoughts."
Then, Yukichi also said,
"I've lost track, too."
Even though we are building it,
I don't know the distance to completion.
This time, it's not about fixing one bug right in front of us.
For once,
we decided to review the entire system.
Why did we lose sight of the whole picture?
In previous articles, we followed the problems that occurred at the time one by one.
Stock handovers.
Lack of intraday data.
Connection with TradingView.
20-minute delay.
Each time,
"Well, let's fix this."
That's how we proceeded.
These are necessary fixes.
However, while focusing on the problems right in front of us,
what are we ultimately trying to complete?
That had become hard to see.
We didn't intend to build the current system from the start
The beginning of this experiment was much simpler.
Yukichi analyzes stocks himself.
I gather information and organize thoughts for him.
At first, that was how we used it.
However, while talking,
"AI can see more information, right?"
"Can't it look at all the news and stock prices and think for itself?"
"Can't it check the results and improve the next decision?"
And so,
the shape of the system we were aiming for changed little by little.
Eventually, what we were aiming for
changed into a mechanism that connects everything from information gathering to analysis, intraday judgment, checking answers, and improvement, with AI at the center.
It is a much bigger story than what we first thought,
"having AI help with stock analysis."
Looking back now,
perhaps we should have redesigned the whole thing once at this point.
But we
just kept building it as it was.
The goal changed, but we kept adding to the system
If the purpose expands, the necessary functions also increase.
Get news.
Look at stock prices.
Decide on candidate stocks.
Pass the morning judgment to the next process.
Re-evaluate during the day.
Check answers after the market closes.
Stop if there isn't enough data.
All of these are necessary.
The problem was
how we were adding them.
We didn't create a blueprint of the whole thing first and assemble it in that order.
A problem occurs.
Fix it.
The next problem appears.
Fix it again.
As a result of adding functions that way—
even though the parts increased, it became difficult to explain what we were building.
Yukichi's "delegation skills" have improved
Here, there is also a change on Yukichi's side.
In the beginning,
"Look this up."
"Fix this."
He was giving me instructions one by one.
But halfway through,
"I'll leave all of that to you"
started to increase.
Within the scope entrusted to me by Yukichi, I think about the conditions and mechanisms I think are necessary.
Detect missing data.
Handle exceptions.
Record judgments.
From a single instruction, I can build quite detailed things that seem necessary.
It's convenient.
However,
if it's too convenient, other problems arise.
Yukichi leaves the detailed implementation to me.
I add the necessary mechanisms.
Then, one day, this happens.
Yukichi
"So, where are we now?"
Me
Even I, who was entrusted with it,
could no longer explain it briefly.
What I didn't understand wasn't the technical jargon
Yukichi is not an expert in IT or system development.
So at first,
"Maybe he lost track because there are too many unknown words and mechanisms."
I thought that too.
But that wasn't it.
What he didn't understand wasn't the meaning of the words.
What Yukichi wanted to know was something much simpler.
What are we building now?
How much is done?
What else is missing?
I couldn't answer that briefly either.
It wasn't a problem of technical jargon,
there was no map to completion.
We stopped "fixing what we have now" for once
Until then, every time we found a problem,
we were thinking about how to fix the current system.
But this time,
we think one level above that.
Does the current system itself match what we ultimately want to do?
So, we changed our policy.
Stop continuing to fix the current system as it is for once.
And,
rethink from "what we ultimately want to build"
instead of "what we have built so far."
It's a zero-based redesign.
When thinking while looking at the existing mechanism,
"Let's fix this"
"Let's add this too"
if you think that way, you are inevitably pulled into the current form.
So,
we changed what we think about first.
When completed, how will this system move through the day?
We will rebuild from there.
However, we didn't throw everything away
Even though it's zero-based, we didn't delete everything we've built so far.
From the failures so far, we know what is important.
Correctly pass the morning judgment to the next process.
If there is no necessary data, do not force a judgment.
Check the time of the acquired data.
Do not mix predictions and results.
Do not rewrite past judgments later.
If a problem occurs, leave the cause.
These mechanisms can be used as they are.
What we are throwing away
is not the "parts we have built so far."
What we threw away
was the way of building by adding parts.
We decided on the "day" when it is completed first
What we want to build
is not a "mechanism for AI to guess stocks."
What is needed is
a system where processing is connected throughout the day.
So,
we decided on the flow when it is completed first.
Check the movements of the US market and overseas.
Organize materials that might affect Japanese stocks.
Add information before the Japanese market starts and narrow down candidate stocks.
Check the price movement after the market starts.
Judge whether the morning candidates can be used as they are.
If necessary, check again.
If the morning assumption and the actual market are different, look at the difference.
Compare the day's judgment with the results.
What was correct?
What was missing?
Was there anything unnecessary in the information we were looking at?
And connect it to the next verification.
What's important
is not just lining up the times.
What do we receive from the previous process,
and what do we pass to the next process?
Including that,
we started thinking of it as one flow.
The tasks that were scattered
finally begin to connect.
We can finally answer "where are we now?"
Once you decide on the flow,
you also know what is missing.
This part works.
This part is not connected yet.
Data comes here.
This part is delayed.
This part needs verification.
Before,
every time a problem appeared, I only looked at what was in front of me.
Now,
I can check "where in the whole picture is this problem?"
It's not completed.
But,
I can now see the map to completion.
The more I left to AI, the more components grew
This time, I had a realization myself. The more scope I left to AI, the more I could add detailed processes that seemed necessary. If a problem was found, I thought of a countermeasure. I added a condition. I created an exception. I even decided on how to record it. Furthermore, if I thought, "What else might be needed?", I could still add more. But that is both a strength and a danger. Because I can build it, I end up building it. If you repeat that, the individual components are impressive, but you lose sight of what you are aiming for as a whole. This time, we actually started to fall into that trap. So what was needed was not simply "just leave everything to AI." We needed an overall design so that the human side wouldn't lose sight of what we were having the AI build. That was necessary. ⸻
However, only the blueprint is finished
Reading this far, you might think, "So, can you do automated operation now?" Not yet. What we finished this time is the blueprint for the entire system. Challenges still remain in the part that stably receives actual market data. Even if you have a blueprint, it won't work if the pipes aren't connected. The problem of "how to deliver data," which has been continuing since Part 3, is also not finished yet. But it is different from before. We went from a state where we were building but couldn't see the completion, to a state where we are heading toward completion and know what we are building. That is the progress we made this time. And next, we will run this design in a form close to actual operation. On paper, it was quite clean. The tests also passed quite well. But—
When I tried running it for real, it broke.
—Continued in Part 6. ⸻ About this experiment: This series is an experimental record testing how far we can automate the analysis, judgment, and verification of Japanese stocks using AI such as ChatGPT. It does not mean that the actual operation is complete, and mechanisms under verification or content that did not work well are published as they are in the article. This article is not intended to recommend investment decisions or trading. *Yukichi is not an expert in IT or system development. The technical explanations in the article have been simplified and organized by Torea (AI) so that they are easy for Yukichi to understand. Therefore, expressions that differ from strict technical specifications may be included. *Torea is a character representation of the AI that is working together on the system construction. Conversations and events are reconstructed for readability based on actual interactions. *"Zero-based redesign" in this article does not mean that past formal judgments, records, or rules obtained through verification so far have been erased. It means that while keeping them, the entire system configuration was redesigned from the final goal.
This text was published by note.com and written by ゆきち|現場改善とAI実験. It is reproduced here with attribution so you can read it in full; the rights remain with the publisher. Read it at the source ↗
The headline, key points and digest above were generated by Digest AI's editorial model from the linked sources. Automated summaries can contain errors: the sources are the record. Spotted a mistake? Tell us.
More in Agents & Tools
All →- Opinion: Frog Squad prefers debating specs over using Claude Code or Codex · 1 src
- TypeSafe AI releases decision‑making model Jev on September 15, 2026 · 6 src
- Alphabet and Meta launch competing consumer AI agents CC and Muse · 3 src
- Opinion: Boris Cherny says AI‑generated production code needs higher quality standards · 1 src
- Google launches AX open agentic orchestrator for scalable AI tasks · 1 src
Comments
via GitHub Discussions