Forem: 4484-ho

Bypassing the Human Brain: How I Built a Full-Stack Prototype in 60 Minutes

4484-ho — Tue, 06 Jan 2026 11:31:38 +0000

We always try our best to explain things, but we never really know if we're getting through. And customers are always worried: "Do they really understand what I need?"

This is a story about fighting back against that hopeless situation.

"Can you reorganize this complex business logic from scratch?"

That's the request I got recently. At first, I thought about using NotebookLM to organize existing documents and create materials. But that would take time, and I wasn't sure if it would really meet the requirements.

So I tried combining these three tools:

My plan was to quickly build a prototype and get everyone on the same page.

Tools I Used

NotebookLM Skill for Claude Code

I used notebooklm-skill to enable Claude Code to directly access NotebookLM notebooks. I created a .claude/skill directory in the project root and cloned the repository there.

mkdir -p .claude/skill
cd .claude/skill
git clone https://github.com/PleasePrompto/notebooklm-skill notebooklm

Now I could get answers from Claude Code based on documents I'd uploaded to NotebookLM. Honestly, I was surprised.

Before this, I couldn't download materials from NotebookLM, and I thought of it as a separate tool from Agentic Coding. The workflow was: organize requirements and designs in ClaudeCode, then feed them to NotebookLM. That was my mental model.

Since it operates through browser automation internally, it seemed like a simpler structure compared to MCP and similar tools.

Anyway, now I could easily get the information I needed—including all the sources and notes I'd built up with customers over time.

cc-sdd

cc-sdd is a tool that supports Specification-Driven Development. I used it with the standard workflow this time.

The Actual Process

As a prerequisite, I'd already registered our product's requirements documents and business logic materials as sources in NotebookLM.

1. Organizing Specifications with NotebookLM

I asked NotebookLM via Claude Code to create data models needed for the business logic in markdown format
I had it organize the necessary business logic, formulas, data models, and table/column elements for success patterns, then output them in markdown format
Since I'd also placed existing product specifications in NotebookLM, I sent a request asking for a minimal prototype that took all of those into account, and got the results

By this point, I had pretty well-organized specifications.

2. Deciding on the Tech Stack

Once the specifications were organized, I decided on the tech stack first:

Database: PostgreSQL
Container: Build PostgreSQL with Docker
Frontend/Backend: Next.js (configured as BFF architecture)

Since it's a minimal prototype, I kept it simple. With Next.js, I can handle both server-side and frontend with API Routes and Server Components, and database connections are straightforward.

3. Starting Specification-Driven Development with cc-sdd

Once the tech stack was decided, I ran cc-sdd init to initialize the project. Then I followed the standard workflow:

Create requirements (from here on, I had cc-sdd commands directly ask NotebookLM questions while creating requirements)
Create Steering (with the decided tech stack specified)
Specify design
Present tasks
Implement the application

cc-sdd proceeds with implementation based on the specifications.

I think the key point is telling it to query NotebookLM, like this:

/kiro/spec-requirements <spec-name>
I want to create requirements for a minimal setup that can test business logic for customer demos
Please use the Skill to ask NotebookLM questions
Also incorporate the data model and business logic materials I have locally

ultrathink

I told ClaudeCode to build PostgreSQL with Docker containers and implement it as a BFF architecture with Next.js in the Steering. I also had it create table definitions based on the data models I'd obtained earlier.

It's smarter and faster than I am.

All of this took one hour. Honestly, I was surprised myself. Normally, just organizing requirements would take several hours, and building a prototype would take a full day.

Summary

This combination is really useful. Especially the flow of organizing specifications with NotebookLM and then implementing with cc-sdd—it was super helpful for clarifying requirements and maintaining consistency in implementation. I also didn't have to deal with ClaudeCode asking me a bunch of questions. There's something to be said for being clear and fast without going through a human brain.

By the way, the app details are secret, so I won't go into them here (lol). But this tool combination itself is pretty versatile, so I hope you'll give it a try.

And here I am, writing this post after finishing the work so quickly. Don't tell anyone, but it took me the same amount of time to write this post as it did to build the prototype.

Deploy Next.js to GCP for FREE: Serverless Setup with SQLite

4484-ho — Mon, 05 Jan 2026 03:55:01 +0000

Introduction

When deploying personal projects or small-scale applications to GCP (Google Cloud Platform), you want to keep costs low while avoiding complex configurations. This article introduces a simple and practical GCP deployment setup that runs for $0-5/month (effectively $0 when using the free tier).

This article explains how to achieve a cost-effective, maintenance-free setup using the Next.js BFF pattern combined with SQLite + Cloud Storage. Throughout this guide, we'll use a vocabulary learning web application as a practical example to demonstrate the concepts and implementation.

Features of This Setup

✅ Single Container Architecture: Frontend and backend run in one container
✅ SQLite Database: No additional DB server required, reducing costs
✅ No Maintenance Required: Serverless operation with Cloud Run
✅ Auto-scaling: Automatically scales based on traffic (can scale down to 0)
✅ TypeScript Throughout: Type safety between frontend and backend
✅ Generous Free Tier: Free up to 2 million requests per month

Architecture Overview

┌─────────────────────────────────────┐
│   Cloud Run Service                 │
│                                     │
│   ┌─────────────────────────────┐  │
│   │  Next.js Container (BFF)    │  │
│   │  - Frontend (React)         │  │
│   │  - API Routes (Backend)     │  │
│   └─────────────────────────────┘  │
│            │                        │
│            ▼                        │
│   ┌─────────────────────────────┐  │
│   │  Cloud Storage              │  │
│   │  └─ vocabulary.db (SQLite)   │  │
│   │     (Download on startup /   │  │
│   │      Upload on shutdown)     │  │
│   └─────────────────────────────┘  │
└─────────────────────────────────────┘

What is the BFF (Backend for Frontend) Pattern?

This pattern leverages Next.js's App Router to integrate the frontend and API routes within the same application.

Benefits:

Simple deployment with everything in one container
Type safety between frontend and backend (unified TypeScript)
No need for additional API gateways or load balancers

Structure Example:

/app
  ├── page.tsx          # Home page
  ├── register/page.tsx # Registration page
  ├── exercise/page.tsx # Exercise page
  └── api/
      ├── cards/route.ts    # Card CRUD API
      └── reviews/route.ts  # Learning history API

Technology Stack Selection Rationale

Next.js (App Router)

Why Next.js:

Can integrate frontend and API (BFF pattern)
Supports Server-Side Rendering (SSR) and Static Site Generation (SSG)
Can leverage TypeScript's type safety
Rich ecosystem

SQLite

Why SQLite:

No Additional DB Server: No need for managed DB services like Cloud SQL
File-based: Easy to set up
Cost Reduction: No DB server fees
Unified with Local Development: Can use the same DB in both development and production

Considerations:

Constraints on concurrent writes from multiple instances
Not suitable for large-scale data or multi-user scenarios
Consider migrating to PostgreSQL (Cloud SQL) in such cases

Cloud Run

Why Cloud Run:

Serverless: No server management required
Auto-scaling: Automatically scales based on traffic (can scale down to 0)
Request-based Billing: No charges when there are no requests
Generous Free Tier: Free up to 2 million requests per month
CI/CD Integration: Can automate deployment with Cloud Build or GitHub Actions

GCP Deployment Configuration Comparison

Recommended: Cloud Run + Cloud Storage

Configuration:

Cloud Run service (container-based, serverless)
Store SQLite database file in Cloud Storage
Download from Cloud Storage on startup, upload on shutdown

Cost Estimate:

Cloud Run: $0 within free tier, approximately $0.40 per million requests when exceeded
Cloud Storage: Approximately $0.020/GB/month (storage)
Total: Effectively $0/month within free tier, approximately $0-5/month when exceeded

Benefits:

No maintenance required
Request-based billing (no charges when there are no requests)
Auto-scaling support (can scale down to 0)
Generous free tier

Alternative 1: Compute Engine e2-micro (Free Tier)

Configuration:

Compute Engine e2-micro (using free tier)
Run container with Docker
Persist SQLite data with persistent disk

Cost Estimate:

Using Free Tier: Effectively $0/month (up to 750 hours per month)
After free tier expires: Approximately $6-7/month
Persistent Disk: Approximately $0.04/GB/month

Benefits:

Lowest cost (when using free tier)
Full control possible
Can run continuously

Drawbacks:

Maintenance required (OS patches, etc.)
Scaling is manual configuration
Free tier is up to 750 hours per month (about one month of continuous operation)

Alternative 2: Cloud Run + Cloud SQL

Cost Estimate: Approximately $10-15/month (minimum configuration)

Benefits:

Multi-user support
Data sharing possible between multiple instances
Automatic backups

Drawbacks:

Higher cost
Overkill for small projects

Alternative 3: Cloud Run + Cloud Filestore

Cost Estimate: Approximately $20-30/month (minimum configuration)

Benefits:

NFS-compatible file system
Data sharing possible between multiple instances

Drawbacks:

Higher cost
Cannot mount directly from Cloud Run (requires Compute Engine)

Implementation Points for SQLite + Cloud Storage

Data Persistence Mechanism

Since Cloud Run is stateless, it cannot directly save SQLite files. Therefore, we adopt a method of storing SQLite files in Cloud Storage, downloading them on startup and uploading them on shutdown.

Cloud Run Container (on startup)
  └─ Download SQLite file from Cloud Storage
  └─ Save to /tmp/vocabulary.db
  └─ Run application

Cloud Run Container (on shutdown)
  └─ Upload /tmp/vocabulary.db to Cloud Storage

Implementation Points

1. Cloud Storage Configuration

Bucket Creation:

Create a Cloud Storage bucket in the GCP console
Select a region (recommended: same region as Cloud Run)
Configure access control (grant read/write permissions to Cloud Run service account)

2. Database Connection Implementation

// lib/db/index.ts
import Database from 'better-sqlite3';
import { Storage } from '@google-cloud/storage';
import fs from 'fs';
import path from 'path';

const storage = new Storage();
const bucketName = process.env.GCS_BUCKET_NAME || 'vocabulary-app-db';
const dbFileName = 'vocabulary.db';
const localDbPath = `/tmp/${dbFileName}`;
const gcsDbPath = `data/${dbFileName}`;

// Download SQLite file from Cloud Storage
async function downloadDatabase() {
  try {
    const bucket = storage.bucket(bucketName);
    const file = bucket.file(gcsDbPath);

    // Check if file exists
    const [exists] = await file.exists();
    if (exists) {
      await file.download({ destination: localDbPath });
      console.log('Database downloaded from Cloud Storage');
    } else {
      // Create empty database on first startup
      console.log('Creating new database');
    }
  } catch (error) {
    console.error('Error downloading database:', error);
    // Create empty database on error
  }
}

// Upload SQLite file to Cloud Storage
async function uploadDatabase() {
  try {
    const bucket = storage.bucket(bucketName);
    const file = bucket.file(gcsDbPath);

    if (fs.existsSync(localDbPath)) {
      await file.save(fs.readFileSync(localDbPath), {
        metadata: { contentType: 'application/x-sqlite3' },
      });
      console.log('Database uploaded to Cloud Storage');
    }
  } catch (error) {
    console.error('Error uploading database:', error);
  }
}

// Download database on application startup
await downloadDatabase();

// Database connection
export const db = new Database(localDbPath);

// Upload database on process termination
process.on('SIGTERM', async () => {
  await uploadDatabase();
  process.exit(0);
});

process.on('SIGINT', async () => {
  await uploadDatabase();
  process.exit(0);
});

// Periodic backup (optional)
setInterval(async () => {
  await uploadDatabase();
}, 5 * 60 * 1000); // Every 5 minutes

3. Local Development Environment

For local development, use the local file system instead of Cloud Storage:

// lib/db/index.ts (for local development)
const isProduction = process.env.NODE_ENV === 'production';
const dbPath = isProduction 
  ? `/tmp/vocabulary.db`
  : './data/vocabulary.db';

export const db = new Database(dbPath);

4. Environment Variable Configuration

# .env.local (local development)
DATABASE_PATH=./data/vocabulary.db

# Cloud Run environment variables
GCS_BUCKET_NAME=vocabulary-app-db
GOOGLE_APPLICATION_CREDENTIALS=/path/to/service-account.json

Important Considerations

Concurrent Writes with Multiple Instances
- SQLite has constraints on concurrent writes from multiple processes
- Cloud Run may start multiple instances
- Solutions:
  - Set Cloud Run's maximum instances to 1
  - Or migrate to Cloud SQL (PostgreSQL)
Increased Startup Time
- Downloading from Cloud Storage takes time (several seconds)
- May increase response time for the first request
Data Loss Risk
- If the process terminates abnormally, the latest data may not be uploaded
- Solution: Implement periodic backups (e.g., every 5 minutes)
Performance
- SQLite is optimal for small-scale data
- Consider migrating to PostgreSQL for large-scale data or high traffic

Cost Calculation (Specific Examples)

Scenario 1: Within Free Tier (Personal Development / Small Projects)

Configuration: Cloud Run + Cloud Storage

Item	Monthly Cost
Cloud Run (up to 2 million requests)	$0
Cloud Storage (1GB)	$0.02
Total	Approximately $0.02/month (effectively $0)

Scenario 2: Exceeding Free Tier (Medium Traffic)

Configuration: Cloud Run + Cloud Storage

Item	Monthly Cost
Cloud Run (5 million requests)	$1.20
Cloud Storage (5GB)	$0.10
Total	Approximately $1.30/month

Scenario 3: Using Compute Engine Free Tier

Configuration: Compute Engine e2-micro (Free Tier) + Persistent Disk

Item	Monthly Cost
Compute Engine e2-micro (Free Tier)	$0
Persistent Disk (20GB)	$0.80
Total	Approximately $0.80/month (approximately $6.80/month after free tier expires)

Implementation Flow

1. Project Setup

# Create Next.js project
npx create-next-app@latest vocabulary-app --typescript

# Install required packages
npm install better-sqlite3 drizzle-orm @google-cloud/storage
npm install -D drizzle-kit @types/better-sqlite3

2. Database Schema Definition

// lib/db/schema.ts
import { sqliteTable, text, integer } from 'drizzle-orm/sqlite-core';

export const cards = sqliteTable('cards', {
  id: text('id').primaryKey(),
  content: text('content').notNull(),
  description: text('description').notNull(),
  createdAt: integer('created_at', { mode: 'timestamp' }).notNull(),
});

export const reviewHistory = sqliteTable('review_history', {
  id: text('id').primaryKey(),
  cardId: text('card_id').notNull().references(() => cards.id),
  answer: text('answer').notNull(), // 'ok' or 'ng'
  answeredAt: integer('answered_at', { mode: 'timestamp' }).notNull(),
  nextReviewAt: integer('next_review_at', { mode: 'timestamp' }).notNull(),
});

3. API Routes Implementation

// app/api/cards/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { db } from '@/lib/db';
import { cards } from '@/lib/db/schema';
import { z } from 'zod';

const createCardSchema = z.object({
  content: z.string().min(1),
  description: z.string(),
});

export async function POST(request: NextRequest) {
  try {
    const body = await request.json();
    const { content, description } = createCardSchema.parse(body);

    const card = await db.insert(cards).values({
      id: crypto.randomUUID(),
      content,
      description,
      createdAt: new Date(),
    }).returning();

    return NextResponse.json(card[0], { status: 201 });
  } catch (error) {
    return NextResponse.json(
      { error: 'Failed to create card' },
      { status: 500 }
    );
  }
}

4. Dockerfile

FROM node:20-alpine AS base

# Install dependencies
FROM base AS deps
WORKDIR /app
COPY package.json package-lock.json* ./
RUN npm ci

# Build
FROM base AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

# Production
FROM base AS runner
WORKDIR /app

ENV NODE_ENV=production

COPY --from=builder /app/public ./public
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static

# Create temporary directory (for SQLite file)
RUN mkdir -p /tmp

EXPOSE 8080

ENV PORT=8080

CMD ["node", "server.js"]

5. Cloud Run Deployment

cloudbuild.yaml:

steps:
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'gcr.io/$PROJECT_ID/vocabulary-app', '.']
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/$PROJECT_ID/vocabulary-app']
  - name: 'gcr.io/cloud-builders/gcloud'
    args:
      - 'run'
      - 'deploy'
      - 'vocabulary-app'
      - '--image'
      - 'gcr.io/$PROJECT_ID/vocabulary-app'
      - '--region'
      - 'asia-northeast1'
      - '--platform'
      - 'managed'
      - '--allow-unauthenticated'
      - '--set-env-vars'
      - 'GCS_BUCKET_NAME=vocabulary-app-db'
      - '--max-instances'
      - '1'

Deployment Command:

# Deploy with Cloud Build
gcloud builds submit --config cloudbuild.yaml

# Or deploy directly
gcloud run deploy vocabulary-app \
  --source . \
  --region asia-northeast1 \
  --platform managed \
  --allow-unauthenticated \
  --set-env-vars GCS_BUCKET_NAME=vocabulary-app-db \
  --max-instances 1

Frequently Asked Questions

Q: Is SQLite okay?

A: It's sufficient for small projects or personal development. Consider migrating to PostgreSQL (Cloud SQL) in the following cases:

Multi-user support is required
Large-scale data (several GB or more)
High traffic (100+ requests per second)
Complex queries or transactions

Q: What about data consistency with multiple instances?

A: Cloud Run may start multiple instances. Since SQLite has constraints on concurrent writes from multiple processes, we recommend the following measures:

Set maximum instances to 1: --max-instances 1
Migrate to Cloud SQL: When multi-user support is needed

Q: Will startup time be slower?

A: Downloading from Cloud Storage takes several seconds. The response time for the first request may increase, but it's usually within acceptable limits.

Q: What about backups?

A: The following methods are available:

Periodic uploads: Upload to Cloud Storage every 5 minutes
Cloud Storage versioning: Enable file version management
Migrate to Cloud SQL: Use automatic backup features

Q: What about security?

A: We recommend the following measures:

Properly configure Cloud Storage bucket access control
Grant minimum permissions to Cloud Run service account
HTTPS required (Cloud Run handles this automatically)
Manage secrets with environment variables (Secret Manager)

Summary

The benefits of this configuration:

✅ Cost Efficiency: Effectively $0 within free tier, approximately $0-5/month when exceeded

✅ Simple: Single container architecture, no maintenance required

✅ Scalable: Auto-scaling based on traffic (can scale down to 0)

✅ Type Safe: Improved development efficiency with unified TypeScript

✅ Practical: Suitable for personal development to small projects

Projects Suitable for This Configuration:

Personal development / Portfolio
Small-scale web applications
Prototype / MVP development
Learning projects

Future Extensions:

Multi-user support → Migrate to PostgreSQL (Cloud SQL)
High traffic → Adjust Cloud Run scaling settings
Global expansion → Cloud CDN + Multiple regions

Even beginners can achieve ultra-low-cost GCP deployment with this configuration. Especially when leveraging Cloud Run's generous free tier, you can operate for effectively $0. Give it a try!

Reference Links

Demystifying ReAct: Why Reasoning and Acting is the Standard for LLM Agents

4484-ho — Sat, 03 Jan 2026 12:19:24 +0000

The ReAct (Reasoning and Acting) framework has become the de facto standard for building LLM agents in recent years.

ReAct: Synergizing Reasoning and Acting in Language Models

Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, Yuan Cao

Since the paper was published in 2022, it has been abstracted by libraries like LangChain and is increasingly used as a black box.

This is a summary I put together as part of my LangChain studies.

Rough Summary of the Paper

Abstract

Proposes the synergy between reasoning and acting. Summarizes how the ReAct framework, which defines LLMs generating thought traces and task-specific actions alternately, achieved suppression of reasoning errors and reduction of hallucinations through interaction with external environments (such as Wikipedia).

1. Introduction

Identifies the separation of "Reasoning" (CoT, etc.) and "Acting" (WebShop, etc.) in existing language models as problematic.

Deficiencies in Reasoning
- Factual errors due to lack of external knowledge, and static reasoning processes
Deficiencies in Acting
- Wandering due to lack of abstract goals

By integrating these, the paper describes the motivation for introducing a loop that resembles human cognitive processes:
"Formulating action plans through reasoning"
and
"Correcting reasoning based on action results"

2. ReAct: Synergizing Reasoning and Acting in Language Models

Environment definition
- A Markov Decision Process (MDP)-like environment consisting of state s in S, action a in A, and observation o in O
Input sequence (Trajectory) construction
- Defines context c(t) at time t as:
```
c(t) = (x, r(1), a(1), o(1), ..., r(t-1), a(t-1), o(t-1))
```
Output structure
- Models a probability distribution p(r(t), a(t) | c(t)) that takes c(t) as input and generates thought r(t) or action a(t)

3. Knowledge-Intensive Reasoning Tasks (HotpotQA, FEVER)

Evaluation experiments on knowledge-intensive tasks.

Method
- Uses Wikipedia API as the external environment and defines three actions: Search, Lookup, Finish
Results
- Compared to CoT alone (reasoning only), accuracy of factual information improved. Compared to Action alone, confirmed more efficient information exploration
Analysis
- Qualitatively evaluated that ReAct has the ability to self-correct hallucinations

4. Decision Making Tasks (ALFWorld, WebShop)

Evaluation experiments on decision-making and manipulation tasks.

Environment
- Physical room manipulation (ALFWorld) and online shopping (WebShop)
Findings
- Demonstrated that by interposing language-based "Thought," tasks can be completed without losing sight of long-term goals even under sparse reward settings

5. Related Work

Chain-of-Thought (CoT)
- Differences from prior research focused solely on reasoning
Modular Deep RL
- Advantages of flexibility through few-shot learning of LLMs over reinforcement learning approaches

6. Conclusion

Concludes that ReAct is effective for both knowledge-intensive tasks and decision-making tasks. As future challenges, presents addressing context length limitations and few-shot dependency through model fine-tuning.

Content I Organized Out of Interest

Problems Under Sparse Reward Settings

Problems and Challenges

Sparse reward setting refers to a state in reinforcement learning or decision-making tasks where an agent only receives positive rewards (feedback) at the final stage when the goal is completely achieved, and during the intermediate process, rewards remain at "0 (zero)" or a constant value.

Under these conditions, the following phenomena occur, making it difficult for simple action models (acting only) to complete tasks.

Delayed evaluation
- It's not immediately clear whether the results of actions are heading in the "right direction"
Exploration difficulty
- Since no useful signals are obtained until accidentally reaching the goal, the efficiency of trial and error (exploration) becomes extremely low

ReAct's Solution

Shows that it can be overcome by the LLM's "Thought" playing the following roles.

Self-generation of intermediate goals
- In processes where final rewards are not obtained, the LLM generates logical intermediate steps within the context, such as "I should check XX next"
Substitution for internal reward function
- Even when physical rewards are not obtained, by linguistically evaluating whether Observations align with its own Thought (plan), it forms a de facto self-feedback loop

What Observation Specifically Is

Conclusion

It's the "physical data processing that synchronizes and maps external outputs to working memory called context."

Refers to a series of data processing steps that integrate outputs returned from the external environment into the input sequence (c(t+1)) for the agent's (LLM's) next reasoning cycle.

In More Detail

Data reception and serialization (Input)
- After external tool execution completes, synchronously receives its return value
  - Data flow
    - Structured data (JSON, Binary, etc.) is transferred from external processes (API, DB, Interpreter, etc.) to the system side (agent control program)
    - Memory structure
      - Received data is held in a temporary buffer and serialized into UTF-8 format text data that the LLM can interpret
Context token appending (State Transition)
- Physically concatenates serialized text to the end of the existing token sequence (Trajectory) held within the LLM's context window
  - State transition
    - Transition from state S(t) = (x, r(1), a(1), o(1), ..., r(t), a(t)) to state S(t') = (x, r(1), a(1), o(1), ..., r(t), a(t), o(t)). (x: instruction, r: Thought, a: Action, o: Observation)
  - Formatting
    - A token identifier defined by the system (e.g., \nObservation: ) is added as a prefix so the LLM can recognize it as a boundary for "external input"
Context window integrity control
- Logic intervenes to calculate token length after concatenation and control so it doesn't exceed the LLM's maximum context window
  - Internal mechanism
    - Token counting
      - Calculates the token count of the entire sequence including serialized o(t)
    - Truncation/summarization (when necessary)
      - When exceeding the limit is anticipated, deletes or compresses part of preceding o(1...t-1) or r(1...t-1) to secure memory space needed for reasoning at current time t
Trigger to reasoning phase (Output)
- Sends (requests) updated context S(t') as payload to the LLM's reasoning endpoint
  - Data flow
    - The entire updated sequence is transferred from the control program to the LLM engine
  - Purpose
    - Presents the result o(t) for the immediately preceding a(t) to the LLM as established fact (grounding) and induces generation of the next step r(t+1)

CoT vs ReAct

Chain-of-Thought (CoT) and ReAct are different frameworks in LLM reasoning processes, and their main difference lies in "interaction with external environments (closed system or open system)."

From an engineering perspective,

ReAct extends CoT and
defines a control loop
to incorporate external I/O (Observation)

can be interpreted this way.

Chain-of-Thought (CoT)

Definition
- A method where LLMs generate logical intermediate steps to reach an answer using only their own internal parameters (learned knowledge)
Data flow
- A linear process that generates a thought process for input and outputs a final answer
System boundary
- Closed system. Does not receive inputs (Observations) from external environments, and reasoning is internally self-contained within the LLM

ReAct

Definition
- A framework that integrates "reasoning (Thought)" like CoT with "action (Action)" that operates external tools and its result "observation (Observation)"
Data flow
- A dynamic process that repeats the Thought → Action → Observation cycle
System boundary
- Open system. Incorporates dynamic feedback from external environments into context and modifies next-step reasoning based on it

ReAct Flow Summary Based on the Above

1. Initial State (t=0)

Input
- User command (Query: x) and few-shot prompt (p) that defines ReAct's operating rules.
State (c(0))
```
c(0) = (p, x)
```
Memory structure
- A static instruction set is placed at the beginning of the LLM's context window

2. Reasoning Cycle (t=n)

Step A: Thought Generation

Process
- p(r(t) | c(t-1))
Processing
- The LLM references current context c(t-1) and verbalizes (r(t)) the validity of the next action
Internal mechanism
- Does not interfere with external environments and formulates intermediate goals in the LLM's internal logical space

Step B: Action Generation

Process
- p(a(t) | c(t-1), r(t))
Processing
- The LLM outputs an identifier and arguments (a(t)) to invoke external tools according to a specific format (e.g., search[query]).
System output
- Generated a(t) is sent from the LLM engine to the agent control program

Step C: Execution

Processing
- The control program parses a(t) and drives the corresponding external tool (API, DB, etc.).
Note
- This phase occurs outside the LLM, and LLM reasoning is in a suspended state

Step D: Observation Integration

Input
- Return value (Raw Data) from external tools.
Processing
- The system converts data to text, adds an identifier, and makes it o(t).
State transition
```
c(t) = (c(t-1), r(t), a(t), o(t))
```
Memory update
- Concatenates o(t) to the end of the context and determines the next request payload to the LLM

3. Termination Judgment and Final Output

Condition
- When the LLM recognizes "task completion" during reasoning, it outputs a specific action (e.g., Finish[answer])
Output
- Returns the final answer (y) to the user and terminates the process

Important Properties in the Sequence

Synchrony
- r(t+1) is not generated until o(t) is concatenated to the context.
Accumulation
- Since all r, a, o from each cycle accumulate in the context, computational cost (token count) increases proportionally with the number of steps.
Recursive correction
- When the content of o(t) diverges from predictions in r(t), plan reconstruction (Dynamic Replanning) occurs in r(t+1) of the next cycle

Deploy calculation game app

4484-ho — Sat, 27 Dec 2025 01:48:15 +0000

I deployed my calculation game app to Vercel—specifically designed for Japanese kids who aren't fond of math! (Haha!) https://flush-calc.vercel.app/

It's incredible that it took only 1 minute to deploy after setting up my Vercel account. This is a great example of how modern DX (Developer Experience) accelerates shipping products.

This is currently an MVP (Minimum Viable Product) version. I'm gathering feedback from my daughter and her friends before expanding the features and refining the UX.

🛠️ Development & Methodology
I treated this project not just as a hobby, but as a mini-product to test my current workflow:

Methodology: Used BMAD-Method for requirement definition, PRD creation, and implementation.
Editor: Cursor (The AI-powered coding experience is a game-changer).
E2E Testing: Antigravity to ensure reliable user flows.

I’m excited to continue exploring the modern tech stack and sharing my journey!