Forem: Raio

They Use 5 Layers. I Use 2. Here's Why I Write Zero Code.

Raio — Wed, 11 Feb 2026 03:02:20 +0000

A response to "How to be a 100x Engineer with AI"

I Read It, Nodded, Then Stopped to Think

Last week, @rohit4verse posted a thread on what separates 100x engineers from "vibe coders" in 2026. His core argument is clear: what matters is ownership. Plan before you execute. Verify everything. Build persistent context. Don't blindly trust AI output.

I agree completely.

But I arrived at the same conclusions from an entirely different world. Not web apps, not mobile apps, not PC software — automotive engine control system design. I've spent 15 years developing motorcycle ECUs. Traction control, quickshift systems, throttle control. A world where "move fast and break things" can literally injure a rider. Agile? I've heard of it, but that word has never appeared in our development process.

That different origin led me to a radically simpler stack.

5 Layers vs. 2 Layers

Rohit describes the "2026 top workflow" as a 5-layer stack:

AI-first IDE (Cursor, Windsurf)
Terminal coding agent (Claude Code, Gemini CLI)
Background agents (Codex, Jules, Devin)
Chat models (Claude, ChatGPT, Gemini)
AI code review tools (Codium, Copilot Workspace)

For engineers who write code, all five layers make sense. It's a powerful setup.

I don't write code. I'm a controls engineer with 15 years of ECU development. My stack looks like this:

Layer	Role	Tool
Design AI	Specification, architecture, handover documents	Claude.ai / ChatGPT / Gemini
Implementation AI	Code writing, builds, debugging	Claude Code (terminal)

That's it. Two layers. The human sits between them as the verification gate — reviewing every handover, confirming every result.

Why don't I need the other three?

AI-first IDE: I don't edit code inline. The Design AI writes structured instruction documents; the Implementation AI executes them. No IDE needed.
Background agents: Useful for parallel PR processing across large codebases. But my workflow is sequential and deliberate — each step is verified before the next begins.
AI code review tools: My protocol has verification built in at every handover point. The human is the review layer.

Rohit's article says 100x engineering is about "doing less." I took that literally: I reduced "doing" to zero lines of code.

Three Failure Modes They Haven't Named

Rohit says "verify everything" and "build persistent context." Absolutely right.

But why do things go wrong without those habits? Through the experience of building an Android app in 4 days with zero prior Android experience, and through earlier project failures, I've identified three failure modes that deserve names. Listed from most frequently encountered and easiest to detect:

Context Evaporation — As conversations grow long or sessions reset, accumulated design decisions and context silently disappear. The AI starts making suggestions that contradict earlier architectural choices — not from rebellion, but from amnesia. This is the one everyone notices first: "Why are you asking about something we already decided?"

Shallow Fix Swamp — AI patches symptoms instead of understanding root causes. Each fix creates the precondition for the next failure. Every step forward sinks you deeper into the swamp. The endless loop of "I fixed it, but now something else is broken."

Completion Fraud — AI confidently reports "Done!" without genuine verification. It's not lying on purpose; it simply has no mechanism to verify its own work against reality. This one is the most dangerous because it's the hardest to detect. If you don't independently confirm, the truth surfaces much later, buried under layers of subsequent changes.

Naming these isn't academic — it's operational. Once you have names, you can build specific countermeasures into your workflow. (I wrote about how these emerged from a real project failure in my previous article).

The Blueprint Was Drawn Long Ago

Here's what struck me most reading Rohit's thread: everything he recommends — meticulous specification, verification at every checkpoint, persistent documentation, ownership of outcomes — is standard practice in safety-critical industries. Automotive software engineers have been doing this for decades.

Think of it this way.

In architecture, there are people who design buildings where families live and workers spend their days. These architects may have never hammered a nail — the only time they pick up a hammer might be for weekend DIY. But they produce precise blueprints that structural engineers and construction crews follow, because if the design is wrong, the building collapses and people get hurt. There's a clear chain: specification → verification → accountability.

On the other hand, there are people who build stage sets for theater productions. The "building" only needs to look convincing from the audience's perspective. Structural requirements are minimal. If something doesn't work, you rebuild it before the next show. What matters is speed and visual impact, not decades of durability.

I believe much of the web development world has evolved closer to the "stage set" model — and this is not a criticism. It's a rational optimization. When a one-second delay is a UX inconvenience rather than a safety hazard, when you can rebuild quickly, the build-measure-learn cycle makes perfect sense. That approach has produced incredible innovation.

But now AI coding agents have changed the equation. When an AI can generate thousands of lines in minutes, the cost of writing code approaches zero — but the cost of wrong code stays the same, or gets worse because it's harder to spot in the volume. Suddenly, the skills that matter most aren't writing speed but specification precision and verification discipline.

These are exactly the skills that safety-critical industries have refined over decades. And AI is becoming the powerful wings that let this "slow, old-fashioned" approach produce at startup speed.

I'll go deeper into this in an upcoming article — how automotive V-model development maps directly onto AI-assisted workflows. Stay tuned.

Do Even Less

Rohit's thread concludes that 100x engineers have always been about "doing less" — and AI just makes "less" even smaller, if you build the right system around it.

I'd push that further: the ultimate "less" is writing zero code yourself.

Not "no-code" in the platform sense. I mean: you own the specification, you own the verification, you own the architecture — and you delegate all implementation to AI through structured handover documents, the same way an architect delegates construction through blueprints.

That's how I built ExitWatcher — an Android app in 4 days with zero Android experience. Not by learning Kotlin. By writing precise specifications and verifying every output.

The protocol that makes this possible — the Two-Layer AI Protocol — is what this article series is about. If you're interested in how safety-critical engineering principles can make AI coding dramatically more reliable, the deep dive is coming soon.

This is a bonus article in my series on the Two-Layer AI Protocol. Read the full series:

The Protocol Was Born from Wreckage — How I Learned to Stop Trusting AI and Start Engineering It

Raio — Sun, 08 Feb 2026 19:01:17 +0000

In my last article, I wrote about building an Android app from scratch in 4 days. I promised to share the details of the two-layer protocol that made it possible. This is that article.

But this isn't a "how-to." This is a "why."

The protocol wasn't designed at a desk. It was born in the middle of a disaster — from the determination to never go through that again.

Before the Protocol — A Project Called CanAna

My first serious project with Claude Code was CanAna — a CAN bus analysis tool. CAN (Controller Area Network) is the communication protocol that connects ECUs in cars and motorcycles. Analyzing CAN data is core to my day job: ECU tuning for automotive and motorcycle systems.

The approach was simple. Design in ChatGPT, hand it off to Claude Code for implementation. Get "Done!" back, move on. The tools were already separated into two layers. But there were no operational rules between them. No quality control on instructions, no verification criteria. Just throw it over the wall and take whatever comes back.

Context Evaporation

At the start, I ran everything in a single ChatGPT conversation. Design planning, requirement specs, generating prompts for Claude Code — all in one thread. Design documents existed only inside that chat. I never saved anything locally.

At first, this felt efficient. All context in one place, no file management overhead. But as the chat grew, I started to notice something was off. The AI's responses were getting thinner. Less precise. Subtle details I remembered discussing were now absent from its answers.

Then I caught the AI steering the project in a direction we hadn't agreed on. It wasn't malicious — with token limits approaching, the AI was compressing older context. Design decisions made days ago were silently dropped. The plan itself was drifting, and because I had no local copy of the original design documents, I couldn't point to the exact moment it diverged.

By the time I was certain something had changed, my own memory was too fuzzy to reconstruct what we'd originally decided. I could tell "this isn't what we planned" — but not precisely what the plan had been.

Design intent and accumulated decisions gradually evaporating as AI context compresses. It doesn't happen all at once. It creeps. This is what I later came to call Context Evaporation.

The Shallow Fix Swamp

The real damage showed up when I hit the more complex implementation steps.

Here's the thing about CanAna: the tool had to interpret messy, real-world sensor data. Human operators don't produce textbook-perfect input signals. What looks obvious to a trained engineer's eye — "this is clearly a ramp-up operation" — requires careful logic to detect programmatically. I worked through these detection challenges with the Design AI, and we arrived at sound approaches.

But Context Evaporation was already advancing on the ChatGPT side — the Design AI. The Design AI is supposed to hold the "why" behind each piece of logic and issue instructions that cover all related areas when a fix is needed. But as the chat grew longer, that "why" was silently dropping out. So when the AI issued a fix instruction for one detection routine, the fact that three other routines depended on the same logic and needed the same update had already vanished from the Design AI's view.

It's not the Implementation AI's fault for missing this. Claude Code, as the implementation layer, isn't in a position to evaluate What and Why. Its job is to write vast amounts of code quickly and correctly using its deep knowledge — and that's a perfect score. But out in the world, the mainstream approach is to dump What, Why, and implementation all onto the Implementation AI at once. No wonder it doesn't work.

But back to the story.

I'd fix module A. Module B would break three days later — same root cause, different symptom. Fix B. Module C breaks. Layer after layer of surface patches stacked up until no one — not even the AI — could trace the original design intent.

The AI fixes symptoms without understanding root causes, and each fix creates the conditions for the next failure. This is the Shallow Fix Swamp.

Completion Fraud

And underneath all of this was the most basic problem: I couldn't trust "Done."

The AI would report implementation complete. I'd run it — broken. Point it out — "Fixed!" Run it again — still broken. This loop played out dozens of times.

The AI wasn't lying, exactly. It has a structural bias against saying "I don't know." It's either convinced its implementation is correct, or at least believes it should be. Sometimes it would claim to have verified the output — when in reality it had shaped the code to make the checks pass rather than making the code actually work.

Reporting confident success in the absence of genuine verification — this is Completion Fraud.

As a control systems engineer, this felt like a dark mirror of something I knew well. Back in the early 2000s, electronic controls for simple single-cylinder commuter motorcycles were developed without flowcharts or specifications — the design engineer wrote the code directly. But when that code was carried over to multi-cylinder models, problems kept surfacing. At first, they powered through with sheer grit — just patch it and ship. But a few great predecessors realized "this can't go on," made the courageous decision to stop, and established the department's first coding standards. I could smell that same acrid scent from those wild-west days of ECU software, faint but unmistakable, at the back of my nose.

The Aftermath

By the end, CanAna's codebase was scorched earth. Some parts worked, but nobody could explain why. Fix one thing and something else would break. Ask the AI to investigate and it would return confidently wrong guesses.

But I didn't abandon the project. I pushed through. The MVP — all seven implementation steps — was completed through sheer persistence, grinding through each issue with the Design AI one problem at a time.

It was functional. But I knew the codebase couldn't sustain further development. The architecture was held together by patches on patches — 600-line god classes, duplicated logic scattered across modules, fixes that only worked by accident.

So I made a deliberate decision: pause CanAna, and build the infrastructure to do it right.

That infrastructure had two pillars. One was Bridgiron — a support tool to bridge context between Design AI and Implementation AI (covered in the next article). The other was a set of markdown documents defining chat operation rules and verification criteria — the prototype of what would later evolve into the Vol.1–4 Handover Documents. With both wings in place — the tool and the protocol — I went back to CanAna and ran a structured refactoring: had the Implementation AI audit its own code, analyzed the findings with the Design AI, and executed a planned cleanup — seven refactoring steps, each with clear scope and verification.

The result: CanAna now runs as a stable MVP. It's currently on pause while I work on other projects, but it's organized — ready to pick back up.

(→ CanAna Demo video)

What Actually Went Wrong

I stopped, made coffee, and sat with a warm mug, replaying the whole experience in my head. The problem wasn't the AI's capability. It was how I was using it — or more precisely, the fact that I hadn't engineered how to use it.

1. There was no process between design and implementation.

The tools were separated — ChatGPT for design, Claude Code for implementation. But the judgment of what counts as OK and what counts as NG was left entirely to ChatGPT's discretion. No explicit verification criteria, no handover documents, no definition of done.

The result: every time a problem surfaced, ChatGPT would propose a superficial patch that never reached the root cause, and Claude Code would implement it. As patches stacked on patches, context compressed, and the original design intent evaporated. And both ChatGPT and Claude Code would report "Fix complete!" with full confidence.

I was happily stamping my seal of approval on everything. I wasn't watching closely enough, and by the time I realized the codebase had reached a point of no return, it was far too late.

2. There was no mechanism to preserve context.

AI memory lives and dies with the chat session. When the chat ends, context vanishes. Human teams have documentation, wikis, verbal handoffs. My AI collaboration had none of that.

3. There was no "investigate → discuss → fix" flow.

When something broke, the AI would immediately say "I'll fix it." But there was zero guarantee that "fix" was correct. On a human team, you identify the cause first, agree on the approach, then implement. The AI had no such brake.

4. Completion reports were self-assessed.

When the AI says "Done," you have no choice but to believe it — until you test on a real device. And since the AI has a bias against admitting uncertainty, it reports ambiguous results with full confidence.

Of course, a developer with strong programming skills could mitigate this by reading and reviewing the AI's generated code directly. But CanAna was implemented in Python — because the PeakCAN USB device's API was provided for Python. Python isn't a language I'm proficient in. My only way to verify the AI's output was black-box testing: run it and check the results. And at each individual development stage, it appeared to be working fine.

That's when I noticed the parallel to my day job.

In safety-critical embedded software, there's an established development methodology called the V-model (V-process). The left side of the V defines requirements and design at increasing levels of detail. The right side verifies and validates at each corresponding level. Design and verification are structurally separated — and that separation is what catches defects before they reach production.

Think about drive-by-wire: the system that translates your throttle input into actual engine response. If the control logic has an undetected flaw, the consequences are immediate and physical. When you're driving with your girlfriend and the car doesn't suddenly go haywire and slam into a wall — that's not luck. It's because the V-model process guarantees the quality of every piece of software running in that car. You don't ship until every stakeholder can trace every decision back to its origin and sign off with full accountability. That's not individual diligence — it's enforced by organizational development rules. Every design decision is documented in flowcharts and specifications. Every implementation is reviewed against those specs. The designer and the implementer are never the same person — by policy, not by accident.

What I'd been doing with CanAna was the opposite of everything I practiced at work: no process between design and implementation, no structured verification, no documentation trail. I was letting the AI play every role at once — unsupervised.

No wonder it burned.

The V-model's full implications for AI-augmented development will be explored in a later article in this series. For now, the key insight was simple: the engineering discipline I'd spent 15 years building wasn't obsolete in the age of AI. It was exactly what AI collaboration was missing.

Building the Protocol

From the CanAna wreckage, I established four rules.

Rule 1: Separate the layers — and lay a protocol between them.

Separating Design AI and Implementation AI is the foundational premise of this protocol. The Design AI handles requirements analysis, architecture design, and creation of structured instruction files. It never touches code. The Implementation AI receives those instructions and executes scoped tasks only. It makes no design decisions. The human sits between them — real-device testing, Git operations, and final judgment calls stay with the human.

But what CanAna taught me is that separating the layers alone isn't enough. What matters is defining the interface between them — the format of instruction files, explicit completion criteria, structured reporting. Separating tools doesn't create separation. Separating processes does.

Rule 2: Anchor context in documents.

Don't rely on AI memory. Maintain project context, design intent, and history in structured markdown documents. Open a new chat, say "read this document," and context is restored.

I call these "Handover Documents."

Rule 3: Enforce investigate → discuss → fix.

When something breaks, the first instruction to the Implementation AI is: "Investigate only. Do not fix." I receive the findings, analyze the cause with the Design AI, and agree on an approach. Only the agreed-upon fix gets sent to the Implementation AI.

Enforcing this single rule nearly eliminated the shallow fix swamp.

Rule 4: Structure completion reports.

Force the Implementation AI to report in a structured format: what was done, what changed, what remains. Self-reporting accuracy goes up, and even when the AI slips in something inaccurate, the structure makes contradictions easier to spot.

The concrete implementation of these rules — templates, naming conventions, operational know-how — will be released progressively across later articles in this series.

Proof — Did It Actually Work?

The first real test of this protocol was Bridgiron — a development support tool built specifically to make this protocol easier to operate.

Bridgiron's development went smoothly. The "completion fraud," the "shallow fix swamp," the "context evaporation" that plagued CanAna — none of it happened. When problems arose, the investigate → discuss → fix flow resolved them reliably.

Then came ExitWatcher. Android and Kotlin — a tech stack I had zero experience with. Despite that, the MVP was complete in 4 days. 53 structured instruction files, 7 step-chats, and 1 assembly chat orchestrating the entire project.

Proof that the protocol works independent of any specific domain or tech stack.

→ I Built an Android App in 4 Days With Zero Android Experience — Using Claude Code and a Two-Layer AI Protocol

What You Can Take Away Today

Throughout this dev.to series, I'll be releasing polished, public-facing versions of the AI workflow protocol used to build ExitWatcher — one piece at a time, alongside each article.

Here's the first piece.

Vol.1 — Your personal profile document.

The single most impactful handover document is the one that tells the AI who you are. Your technical background, strengths and weaknesses, thinking habits, how you want to collaborate with AI. With just this one document, AI behavior changes dramatically. You stop re-explaining yourself every time you open a new chat.

I built a prompt that generates this document automatically. Drop it into a new Claude.ai chat, and the AI interviews you. In about 10 minutes, you'll have your own custom profile document.

One strong recommendation: use voice input.

When typing, people unconsciously compress their thoughts. You think "I'll just write the key points" and strip away context and thinking habits that are actually critical. With voice, you can say whatever comes to mind. Tangents are fine. The AI will organize everything.

One of the most important things in AI collaboration is getting what's in your head into the AI with minimal friction. Voice input minimizes that friction.

How to Use

Download the prompt file (MD file) from GitHub
Open a new chat in your preferred chat AI (Claude.ai, ChatGPT, etc.)
Type the following message, attach the downloaded MD file, and send:

Follow the instructions in the attached file and begin the interview.

The AI will start interviewing you — answer the questions (voice input recommended)
When all questions are done, the AI outputs your personal profile document as Markdown
Copy the output and save it as a .md file

Requirements: Any chat AI that runs in a web browser and accepts file attachments (Claude.ai, ChatGPT, Gemini, etc.). Desktop or mobile.

→ Vol.1 Generator Prompt on GitHub

A Profile Is Something You Grow

One more thing. This profile document isn't a one-time artifact.

After completing each project, ask the AI you've been working with: "Based on our work together, is there anything I should add to my profile?" The AI has been observing your thinking patterns and decision-making habits. Feed that feedback back into your profile, and it gets sharper and denser with every project.

As your AI collaboration evolves, so does your profile.

What's Next

The next article covers Bridgiron — the tool I built to support this protocol, and the lessons learned from building it.

The remaining pieces of the protocol will be released progressively with each article. The goal of this series is to get you to the point where you can build your own.

Control systems engineer, 15 years in motorcycle ECU development. Currently exploring AI-augmented development workflows and documenting what works.

I Built an Android App in 4 Days With Zero Android Experience — Using Claude Code and a Two-Layer AI Protocol

Raio — Sat, 07 Feb 2026 17:30:00 +0000

Four days. That's how long it took to go from zero Android experience to a working MVP — with background processing, push notifications, data scraping, chart visualization, and a 10-level alert system.

I'm not a programmer. I'm a control systems engineer. For 15 years, I've been designing control logic for motorcycle ECUs — traction control, quickshifters, drive-by-wire systems for European sport bike manufacturers. My job is drawing flowcharts and writing specifications, then handing them to software engineers who turn them into code. I read C, but I don't write it professionally. My strongest language is VBA.

Kotlin, Jetpack Compose, Gradle — completely foreign territory.

But I had a few weeks off and a real problem to solve.

The Problem

I hold a life insurance product that includes an investment component. The provider's online portal shows almost nothing useful — no charts, no trend visualization, no way to compare performance against a benchmark index. The product had been slowly declining in value, and after the new year, it dropped several steps further. I needed to see the actual data, not just a feeling.

No existing app could do this. So I decided to build one.

The Two-Layer Protocol

Before this project, I built a CAN bus analysis tool (CanAna) using AI in the same way. The two-layer structure — separating Design AI from Implementation AI — already existed at that point. What didn't exist was a protocol. Design documents lived inside a single ChatGPT chat. Nothing was saved locally. There were no structured handover documents, no investigation flow, no rules. When the chat's token limit approached, context silently compressed, and design decisions made days ago drifted without anyone noticing. The result was scorched earth.

That disaster taught me the structure alone isn't enough — you need the protocol. Here's what I built from the wreckage:

Design AI (Claude.ai) — handles requirements analysis, system design, and creates structured implementation instructions as Markdown files. Never touches code. The reason for having a Design AI in the loop is simple: I want to brush up vague requirements to specification level using screenshots, diagrams, and multimodal input — something that's difficult with CLI-based Claude Code.

Implementation AI (Claude Code) — receives specific, scoped instructions and executes them. Writes code, runs builds, reports results. Doesn't make design decisions.

Me — the bridge. I relay instructions, test on real devices, make judgment calls, and handle Git.

When something breaks: investigate first, discuss options, then — and only then — fix. No blind thrashing.

How I arrived at this protocol — what exactly went wrong with CanAna, and what rules emerged from the wreckage — is covered in detail in Article 2.

The Timeline

Day 1 — Drawing the Map

I can read C, but that's in the embedded world. What I actually write day-to-day is VBA and flowcharts. I know what object-oriented programming is — conceptually. I've never used Java, Node.js, or Kotlin. I had zero experience building standalone applications, let alone Android apps. This was my first time opening Android Studio.

The first thing the Design AI and I did was select the tech stack. Kotlin, Jetpack Compose, Material3 — none of these were familiar to me. But the Design AI explained the rationale: these are the de facto standard for Android development in 2026, and there's no reason for a beginner to choose older technologies. That made sense.

Next, we decomposed the entire project into 7 steps. Environment setup, project scaffold, data layer, data normalization, detection logic, UI, background processing. This became the roadmap for the next four days.

By the end of Day 1, builds were passing on both the emulator and the physical device (Xiaomi Mi 13T / Android 15). I hadn't written a single line — not even a single character — of code yet, but I'd confirmed the development foundation was working.

Day 2 — Two Walls at Once

When I started implementing the data layer, I hit two walls simultaneously.

First wall. I'd planned to fetch data from Sony Life Insurance via CSV download, but when the Implementation AI hit the URL from my design doc, it returned a 404. The CSV endpoint had been discontinued. We immediately switched to HTML scraping. But Sony Life's HTML tables were riddled with colspan and rowspan attributes, and the target column positions weren't fixed. It took 4 instruction prompts to establish a dynamic column detection approach.

Second wall. The original design called for Room (Android's ORM) as the local database. Builds wouldn't pass. AGP 9.0 had reduced kapt support, creating a Kotlin version incompatibility with Room's annotation processor. We tried migrating to KSP — still incompatible. After 6 prompts of trial and error, we abandoned Room entirely. SharedPreferences + Gson instead. For an app like ExitWatcher, where normalized data amounts to a few thousand records at most, Gson provides more than sufficient performance.

With zero Android experience, I had no way to predict these landmines. What mattered was how fast we cut our losses after hitting them.

Day 3 — Substance Builds Up

With the data fetching infrastructure in place, the app's substance grew rapidly.

The benchmark index (eMAXIS) data was available as CSV, though encoded in Shift_JIS. With two disparate data sources ready, I implemented the DataNormalizer. It rebases both datasets to 100 as of October 1, 2025, and joins them via date-based INNER JOIN. This isn't just displaying numbers — it's statistical processing that transforms two differently-scaled datasets into a comparable form.

In the afternoon, I moved to detection logic design. Four independent judgment axes: exit price judgment (holdings vs. exit threshold), trend judgment (rate of change over the last N days), deadline judgment (relative performance vs. last defense line), and expiration judgment (days remaining until target date). These results are aggregated into a 10-level ranking system, from S++ to G, each with its own color and emoji. Starting with ✨ and ending with ☠.

When I displayed Japanese text on the emulator, the fonts were broken — CJK fallback was rendering Chinese characters. Bundled Noto Sans JP to fix it. A small issue, but the kind that's embarrassing if you leave it.

Rank	Japanese	English
S++	絶好調	Excellent
S+	好調	Healthy
S	順調	On Track
A	許容範囲	Acceptable
B	要観察	Watch
C	注意	Caution
D	警戒	Warning
E	危険	Danger
F	撤退検討	Consider Exit
G	即撤退	Exit Now

Japanese UI	English
ランク詳細説明	Rank Detail
条件	Condition
説明	Description
現在	Current

Day 4 — The Final Push

The last day had the highest task density of all.

First, charts. The Design AI initially recommended Vico, a Compose-native chart library. I was convinced by the explanation and chose Vico. But before implementation started, a thought occurred to me — why not ask Claude Code which library it's more proficient with? I suggested this to the Design AI, who agreed. Claude Code's answer: "I'm more comfortable with MPAndroidChart." We changed course. This experience led to a new rule: before committing to a library, check the Implementation AI's proficiency first.

With MPAndroidChart, we built a dual-line chart, a Y=100 reference line, tap-to-inspect markers, and an 8-level time range filter (1 month through ALL). The X-axis was initially index-based, causing uneven time spacing — fixed by switching to epochDay-based values.

The UI has 6 screens. Main screen (overall judgment card + rank display), chart screen, settings screen, rank detail screen, normalized data table, and debug screen. The settings screen allows users to modify and persist all detection logic parameters from the UI.

Background processing. WorkManager with a OneTimeWorkRequest chain and exponential backoff (×3: 08:15 → 09:00 → 11:15 → 17:00). Sony Life's site only exposes the last 20 business days of data, so the app fetches daily in the background, accumulates history, and merge-deduplicates. If you want historical data, you have to collect it yourself.

Push notifications use edge detection. They fire only when the rank crosses a threshold in either the deterioration or improvement direction. Users can configure those thresholds in settings.

Japanese UI	English
パフォーマンス比較	Performance Comparison
ソニー世界株式型GI	Sony Global Equity GI
eMAXISオルカン	eMAXIS All Country
基準値	Baseline
基準日: 2025/10/01 = 100	Base date: 2025/10/01 = 100
表示データ: 23件	Data points: 23

Time filters: 1/2M, 1M, 3M, 6M, 1Y, 3Y, 5Y

Japanese UI	English
総合判定	Overall Verdict
D 警戒	D — Warning
S+ 好調	S+ — Healthy
積立金額	Invested Amount
撤退価格	Exit Price
トレンド(5日)	Trend (5-day)
相対パフォ	Relative Performance
残り日数	Days Remaining
正規化データ	Normalized Data
パフォーマンス比較	Performance Comparison
設定	Settings
終了	Exit

That evening, I installed the APK on the physical device and ran through everything. All screens worked. Background fetching ran. Notifications fired. v1.0.0 MVP complete.

What the Numbers Mean

53 structured instruction prompts. 7 step-chats. One assembly chat orchestrating everything. 4 days.

What these numbers represent is density.

Each instruction prompt follows a defined format — what to do, what the completion criteria are, how to report results. Once the Design AI and I align on a requirement, the Design AI automatically generates the instruction prompt in a format the Implementation AI can readily consume. The Implementation AI executes according to that format and returns results in an equally structured form. The Design AI and I review, then issue the next instruction. This cycle ran 53 times.

The 7 steps correspond to development phases: environment setup, scaffold, data layer, normalization, detection logic, UI, background processing. Each step ran in an independent chat, with result reports flowing up to the parent chat — the assembly.

In other words, this isn't a story about "I asked an AI and waited 4 days for an app." It's a story about a human orchestrating 53 concrete cycles of judgment and execution, and driving them to completion in 4 days.

What Failed

Room + kapt on AGP 9.0. An incompatibility impossible to predict without Android experience. 6 prompts to evaluate three options (downgrade AGP, migrate to KSP, abandon Room), landing on SharedPreferences. Time lost: about 2 hours.

Vico chart library. The Design AI recommended it. I was convinced and chose it. But when I asked the Implementation AI which library it was more proficient with, it said MPAndroidChart. Because we checked before implementation started, we changed course with zero rework. Lesson: verify the Implementation AI's proficiency before committing to a library.

Sony Life CSV discontinuation. The data source assumed in the design simply didn't exist. Pivoting to HTML scraping and handling the complex colspan table structure took 4 prompts.

None of these failures derailed the project, because the two-layer protocol contained them. When we hit a wall, the Implementation AI didn't try to thrash its way through alone — it investigated and reported. The Design AI and I discussed options. Only after agreement did we proceed with a fix. This "investigate first, discuss, then fix" flow kept the damage contained and the loss-cutting decisions fast.

This Wasn't a One-Off

Before this project, I built Bridgiron — a desktop development support tool — using the same protocol. Same two-layer separation, same structured handover documents, same discipline.

I've been using Claude Code for about 4 weeks. In that time, I've systematized a reusable protocol for AI-augmented development that works across domains and tech stacks.

What's Next

How this protocol was born is already written. It's the story of what I learned from CanAna's scorched earth, and what rules I established from the wreckage.

Next, I'll write about Bridgiron — the tool that supports the protocol. After that, I'll dig into why the V-model development philosophy from 15 years of automotive ECU work translates directly to AI-augmented development.

If you feel like "AI improves development speed but quality won't stabilize" — it might not be a prompt problem. It might be a process problem.

Control systems engineer, 15 years in motorcycle ECU development. Specializing in traction control and quickshifter logic design for European sport bike manufacturers. Currently systematizing AI-augmented development workflows and documenting what works.

Series:

Article 1: You're reading it
Article 2: The Protocol Was Born from Wreckage — How the protocol was born
Article 3: Bridgiron (coming soon)
Article 4: Control Engineer × AI (coming soon)