Forem: GoodRelax

The End of the Era Where Software Has Value

GoodRelax — Fri, 27 Mar 2026 15:56:04 +0000

Are you starting to notice?

The era where software — forged through blood, sweat, and tears — loses its value is upon us.

Simply put.

What is value?

Something rare, and something everyone wants.

Put it in an equation:

Value = Scarcity × Demand

AI has made building software no longer "scarce."

For example, gr-sw-maker is achieving nearly full automation of the entire process — specs, design, implementation, testing, delivery, and operations — just from a concept description.

What loses its scarcity loses its value. The same goes for hardware designed by software.
The value of software and hardware is quietly, but surely, fading away.

So what holds value next?

Let's return to the definition.

Something rare, and something everyone wants.

The answer is simple.

Scarcity × Demand = Happiness

Who do we make happy, and how.
That is the only thing that truly matters from here on.

When the "how" becomes free, the "why" becomes everything...

So — what will you do?

How I Prevented Quality Collapse in AI-Driven Dev with AI Agents and SDD

GoodRelax — Wed, 25 Mar 2026 16:33:11 +0000

AI-driven development is fast (sometimes). But can you answer "is this code really OK?"
When bugs show up and you tell the AI to fix them, does the debugging ever actually end?
Are you quietly hand-fixing AI-generated code line by line?

...Yeah, that was me until last year (lol)

Hoping to save others from the same trap, here's a breakdown of SDD (Spec-Driven Development) and A-SDLC (Agentic SDLC) — the backbone of AIDD (AI-Driven Development).

Terminology

AIDD : AI-Driven Development. A development style where AI leads dev tasks and humans supervise and evaluate.

SDD : Spec-Driven Development. An approach where the spec drives design, implementation, and testing.

A-SDLC : Agentic SDLC. A development style where AI agents autonomously execute the entire Software Development Life Cycle.

Let's get straight to the point.

SDD lives or dies by its spec template and process — and the process can be automated by AI

Here's a bad flow vs. a good flow:

Before: humans test, tell AI to fix, test again... infinite loop.

After: a separate AI agent inspects quality before moving to the next phase.

I wrote "inspection" here, not "review." This is closer to inspection

— a formal examination with checklists, severity classifications, and pass/fail criteria defined (IEEE 1028).

That's what AI should be doing. There are check items, and the gate won't open unless Critical/High findings are zero.

Even in human team development, quality suffers when one person does everything. The same applies to AI-driven development.
In A-SDLC, the key is to clearly separate phases and roles across multiple AI agents.

A sample of AI Agent Team

Quality Gates = Inspection Criteria

Specifically, the inspection agent examines from 6 perspectives:

Perspective	What it checks	Example
R1	Spec quality	Requirements have IDs? No ambiguous wording? Edge cases covered?
R2	Design principles	Any SRP, OCP, DIP, DRY, KISS, YAGNI violations?
R3	Code quality	Error handling, null safety, defensive programming
R4	State transitions	Deadlocks, race conditions, missing state transitions
R5	Performance	Algorithm efficiency, memory, network
R6	Consistency	Spec ↔ design ↔ implementation ↔ tests — all connected?

If even one Critical/High issue remains, the next phase is blocked. That's the quality gate.

Using the OSS framework gr-sw-maker which implements this approach, I'll walk through a real example: building an earthquake map site in just 45 minutes (10 min hands-on).

① Have AI write the spec — incrementally, with inspections in between

The "S" in SDD. This is the foundation. If your AI-driven dev or SDD isn't producing results, this is where it's weak.

The spec "template" is everything

For human specs, IEEE 830 (SRS) is well-known, but it was designed for humans to read and write.
The chapter structure is too heavy, granularity varies... Hand this to an AI and it becomes a hallucination factory.

So I created ANMS (AI-Native Minimal Spec), a spec template designed for AI.
Clean Architecture's Stable Dependencies Principle is applied to the spec itself — upper layers (purpose, requirements) are stable, lower layers (design, tests) are easy to change.
...This is a unique design choice in gr-sw-maker.

Even with this spec, having AI write it all at once will fail.

First, have it write purpose and requirements (Ch1-2) and pass inspection.
Then proceed to design and test strategy (Ch3-6).

If the foundation is shaky and you proceed to design, you'll redo everything later. ...Sound familiar?

Natural language makes AI guess wrong

If you write:

Change marker color based on earthquake size

What's "size"? What are the thresholds? What colors? AI interprets freely, producing something different every time.

EARS notation eliminates ambiguity

The same requirement in EARS (Easy Approach to Requirements Syntax):

FR-05: The system SHALL display each earthquake marker with a color determined by magnitude: green for below 3.0, yellow for 3.0–5.0, orange for 5.0–7.0, red for 7.0 and above.

Subject, verb, conditions, thresholds — all there. No room for AI misinterpretation. (Actual spec Ch2)

EARS examples (most requirements can be written with these patterns)

Pattern	Syntax	Example (actual)
Ubiquitous	The system SHALL...	Display map with Leaflet.js
Event	When [event], the system SHALL...	Marker click → show popup
State	While [state], the system SHALL...	During data fetch → show loading
Unwanted	If [condition], then the system SHALL...	API failure → show error message
Constraint	The system SHALL NOT...	Reject future dates

After writing the spec, have it inspected

The completed spec is examined by a dedicated agent. Here's an actual finding:

F-002 (Medium): FR-05 mentions "color gradient" but thresholds are undefined. Cannot be tested.
Fix: Specify green for below 3.0, yellow for 3.0–5.0...

This kind of ambiguity is eliminated through AI-to-AI inspection before moving to the next phase.
A human would take ages, but AI finishes this inspection in seconds. That's the power of A-SDLC.
(Actual example)

② Have AI design — expressing Clean Architecture with colors

Once the spec is solid, the design agent creates the architecture.

A unique feature of ANMS is color-coding components by layer. This makes dependency direction violations instantly visible.

Critical: At the architecture design stage, separate means from ends and organize dependencies into a clean architecture. This makes the system resilient to bug fixes and spec changes.

The Domain layer (orange) is pure functions with zero external dependencies. Dependency direction flows UI → Adapter → Domain, never reversed.
If colors are mixed up, the design is wrong. The inspection agent checks this too.
(Actual design Ch3)

③ Derive test cases from the spec

This is the best part.

gr-sw-maker has test specifications written in Gherkin notation, so test code can be derived directly from the spec.

Scenario: SC-005 Marker color by magnitude (traces: FR-05)
  Given earthquake data has been successfully fetched
  Then markers for magnitude below 3.0 are displayed in green
  And markers for magnitude 3.0–5.0 are displayed in yellow
  And markers for magnitude 5.0–7.0 are displayed in orange
  And markers for magnitude 7.0 and above are displayed in red

Each line of Gherkin becomes a test case. (Actual spec Ch4)

Auto-generated test code

import { magnitudeToColor } from "../../src/domain/magnitude-scale.js";

describe("magnitudeToColor", () => {
  it("returns green (#00CC00) for magnitude below 3.0", () => {
    expect(magnitudeToColor(2.9)).toBe("#00CC00");
  });
  it("returns yellow (#CCCC00) for magnitude 3.0 to 4.9", () => {
    expect(magnitudeToColor(4.0)).toBe("#CCCC00");
  });
  it("returns orange (#FF8800) for magnitude 5.0 to 6.9", () => {
    expect(magnitudeToColor(6.0)).toBe("#FF8800");
  });
  it("returns red (#CC0000) for magnitude 7.0 and above", () => {
    expect(magnitudeToColor(7.5)).toBe("#CC0000");
  });
});

Similar to TDD (Test-Driven Development), gr-sw-maker creates test cases (acceptance criteria) before implementation.
The goal — what tests to pass — is defined before coding begins, minimizing rework.

What's also important here: the implementing agent and the testing agent are separate.
The problem of testing your own code is structurally eliminated. (Actual test code)

Statement coverage: 98.93% (domain + adapter layers, target was 80%). Since tests are derived from Gherkin scenarios, coverage structurally matches what's specified.

Implementation inspection results

Inspection results for the earthquake-map implementation:

Item	Result
Verdict	PASS
Critical	0
High	0
Medium	3
Low	3

Critical/High is 0, so it passes. Medium/Low are recorded and carried forward. (Actual inspection record)

④ The full run — results

So what actually happened? I built an earthquake map app from a 5-line memo.
Here's the summary.

Initial input (this is all):

Earthquake Map
I want to see where and when earthquakes happened in the world.
Runs in the browser only. No server.
I want to zoom into any area.
I want to specify a time span.

Two spec changes mid-development:

Add an Update button
Make it work on local PC

Output:

Item	Value
Functional requirements	20
Gherkin scenarios	21
Unit tests	32 (100% pass)
Code coverage	98.93%
Vulnerabilities	0
Total time	45 min

I didn't write a single line of code. Didn't even look at it (lol)

👉 Live app
📝 Introduction article (Zenn)
📄 Spec (with component & sequence diagrams)
💬 Full AI chat transcript
📊 Timeline & metrics

Sounds easy so far, but...

What this article covered is just part of the picture. Under the hood, multiple AI sub-agents are orchestrated in complex ways.

The full picture of gr-sw-maker

You don't need to read everything at these links, but at least look at the diagrams.

Component	Role
ANMS (spec template)	The quality pillar
Agent configuration (20+)	Agents and their coordination flow
Agent implementations	Prompts for each agent
Process rules	Discipline for agents
Review standards	Inspection criteria
Document management rules	Artifact types, naming, versioning

Binding AI agents with strict rules might seem harsh. But just like human projects, it's what prevents death marches and leads to happier development.

⑤ Have AI reflect — AI improving its own process

gr-sw-maker doesn't stop here.
After development, AI runs a retrospective.
...You do that in human projects too, right? (lol)

Improvement proposals from the earthquake-map retrospective:

ID	Problem	Improvement
IP-01	ES modules didn't work with file://, causing a full redo	Add compatibility check in early phases for "no server" projects
IP-02	Ambiguity between auto-fetch vs. button-triggered data loading	Add trigger method question to interview template
IP-03	Leaflet's async rendering caused screenshot verification timeouts	Document screenshot limitations for async UIs
IP-04	No procedure for closing inspection findings	Make finding closure an explicit orchestrator step

All of these were identified by AI itself. It even produced a gap analysis of the gr-sw-maker framework (4 SDD items + 6 A-SDLC items).
(The retrospective is recorded at the end of the chat transcript)

These findings feed back into the next project, and the framework itself improves over time.

Challenges ahead

The retrospective surfaced these honestly:

Cost: More agents means more token consumption. It's a speed-vs-quality tradeoff.
→ I accept this.
Process gaps: Like IP-04, the procedure for closing inspection findings is still weak.
→ Run more diverse projects, retrospect, and close the gaps.
...Humans hate this kind of grunt work, but AI doesn't complain.
Multi-language: Spec templates and prompts are written in both Japanese and English, so AI translation enables other languages.
I actually developed gr-sw-maker in Japanese and translated to English. The earthquake map was developed in English.
→ Next I'd like to try German or Chinese (whichever has better translation accuracy).
Beyond Claude Code: Designed to avoid vendor lock-in so it works with other AI tools, though porting is needed (~15%). Naturally, AI does the porting.
See the porting guide for details.
→ Maybe Cursor next?
Scaling up: Applying to complex, large-scale multi-service systems. A single spec won't suffice — multiple specs (ANPS) or graph specs (ANGS) will be needed.
→ This is where individual effort hits its limits. Both money and time.
Human judgment remains: Acceptance testing and final decisions are human. It's nearly fully automated, but not unmanned.
→ Critical: You need enough skill to review AI-inspected artifacts and make the AI say "you're absolutely right."

Summary

Quality collapses because you have AI write code immediately.
Separate agents for spec → SW design & test design → implementation → testing.
Set up quality gates between phases with inspection every time.

It's exactly what human development does. Just have AI do it faithfully.

Well, getting that to actually work is surprisingly tricky (lol)
When it is, try gr-sw-maker as a starting point.
I hope it makes your development easier and your products better.

Try it now

npm init gr-sw-maker

GitHub: gr-sw-maker — OSS MIT License, Japanese & English
→ GitHub (Japanese README)
GitHub: Examples
→ Example 1: Earthquake Map Site and dev records
→ Example 2: Mahjong Dice App and dev records

Standards and concepts referenced in this article

IEEE 830 (SRS) — Standard format for software requirements specifications
IEEE 1028 — Standard process for software reviews and inspections
RFC 2119 — Keywords for requirement levels (SHALL / SHOULD / MAY)
EARS (Easy Approach to Requirements Syntax) — Notation for writing requirements in structured natural language
Gherkin (Cucumber) — Scenario description language using Given/When/Then
Clean Architecture (Robert C. Martin) — Architecture pattern controlling dependency direction
ANMS (AI-Native Minimal Spec) — Spec template for AI-driven development
ANGS (AI-Native Graph Spec) — Graph spec for large-scale multi-service systems

SDD: AI Turned My 5-Line Memo into Specs and Software in 45 Minutes by gr-sw-maker

GoodRelax — Sun, 22 Mar 2026 10:26:48 +0000

First, take a look at this.
👉 Earthquake Map ← created using gr-sw-maker

Built from a 5-line memo in 45 minutes. With a spec and tests.
And my actual hands-on time was under 10 minutes. Spent the rest drinking beer.
This is SDD meets Agentic SDLC.
According to PwC's 2026 report, by 2027 more than half of all teams will develop this way.

Terminology

Agentic SDLC = A development style where AI agents autonomously execute the entire SDLC. Proposed by PwC, Microsoft, and others.
Agentic = Given a goal, the AI keeps acting autonomously to achieve it.
SDLC = Software Development Life Cycle (requirements → design → implementation → testing → operations).
SDD = Spec-Driven Development. Covers only the design → implementation portion. Narrower scope than SDLC.
PwC = PricewaterhouseCoopers (Big Four consultancy).

Why?

I wanted to test a simple question: can AI go from a vague idea to a production-quality app — with specs and tests — in under an hour?

So I built an open-source framework called gr-sw-maker and put it to the test.

What?

A single .html file app that reads open data (USGS Earthquake API) and draws a world earthquake map.

Zoomable world map
Time range selection (1 hour to 30 days, plus custom)
Minimum magnitude filter
No server — runs entirely in the browser

How?

1. Install gr-sw-maker via npm

Details → README

> npm init gr-sw-maker earthquake-map
> cd earthquake-map
> node setup.js
> 1 : # Develop in English using Claude Code

2. Write a 5-line memo (requirements doc) for gr-sw-maker

Earthquake Map
I want to see where and when earthquakes happened in the world.
Runs in the browser only. No server.
I want to zoom into any area.
I want to specify a time span.

Original memo → user-order.md

3. Answer the AI's interview questions and say "Do as you recommended!"

4. After that, I requested two spec changes (added an Update button, enabled file:// direct opening)

5. Also had it write a process improvement report

Time breakdown

Phase	Time
Install gr-sw-maker & write requirements memo	~5 min
Interview → software delivery	20 min 10 sec
Acceptance testing & 2 revisions → done	20 min 15 sec ← 45 min total
Retrospective & improvement proposal report	16 min 54 sec

Deliverables

Item	Count
Functional requirements	20
Gherkin scenarios	21
Unit tests	32 (100% pass)
Code coverage	98.93%
Vulnerabilities	0

Evidence

Spec ← includes component diagrams & sequence diagrams
Chat transcript
Timeline & metrics

So... is it any good?

Honestly... It's a common enough app — but that's the point. It was built from a 5-line memo in 45 minutes.

And it comes with a proper spec, test results, and even a process improvement report.

Naturally, I didn't write or even look at a single line of code.

"But is it just a toy?"

Fair question. Speed means nothing if the output is garbage. Here's what's actually going on under the hood:

21 AI agents working as a team — not a single model chatting with you. There's an architect, a security reviewer, a test engineer, a risk manager, and more. Each owns a specific responsibility, just like a real dev team.

6 quality gates (R1–R6) block phase transitions. Critical or High findings = 0, or the project doesn't move forward. No shortcuts.

8-phase workflow covering the full SDLC — from requirements interview through design, implementation, testing, delivery, and even post-delivery retrospectives.

Process rules

AI-native spec format (ANMS) — not a dumbed-down template. It uses EARS for requirements, Mermaid for architecture diagrams, and Gherkin for acceptance criteria. Purpose-built for LLMs to both write and consume.

ANMS format

Portable — built for Claude Code, but roughly 70% of the framework runs as-is on Gemini CLI, Cursor, Windsurf, and others.

Porting guide included.

That's how a 5-line memo produced 98.93% coverage and 0 vulnerabilities.

It's not magic — it's process.

A set of rules

Thoughts

I know what some of you are thinking: "Great, another tool that's going to replace me."

But let's be real — someone somewhere has already built something like this earthquake map. Are you really excited to reinvent that wheel for the hundredth time? I'm not.

What excites me is: what do you do with the time you get back?

There's the microplastic crisis, fusion power instead of fossil fuels — we've got real problems worth solving. The boring plumbing shouldn't be what eats your week.

This was a simple demo. Next, I'm going to throw something harder at it — multi-service architecture, real-time data pipelines — and see where it breaks. That's where things get interesting.

The world's going to shift a lot in the next few years. If gr-sw-maker helps even one person skip the boring parts, that's a win.

Try it yourself

You need Node.js and Claude Code. That's it.

npm init gr-sw-maker my-app
cd my-app
node setup.js

Write your own 5-line memo, answer the interview, and see what comes out. If you build something cool, open a PR to gr-sw-maker-examples — I'd love to see it.

Links

🛠️ gr-sw-maker ← OSS · MIT License · English + Japanese — contributors welcome.
🌍 Earthquake Map project

ANMS : A Spec Template Built for AI

GoodRelax — Sun, 08 Mar 2026 14:02:39 +0000

EARS + Gherkin + Mermaid, reorganized for AI-driven development.

Why I Made This

I build software with Claude Code, and it hit me:

AI coding is the same process as outsourcing. Spec → Build → Review → Accept. Whether the builder is a team overseas or an LLM on your machine — same flow, same failure modes.

The quality of outsourced software comes down to three things:

The vendor's capability
The development process
The spec

Number 1? Claude Code. No complaints.

Number 2? Working on it.

Number 3 is the problem. Too vague → the AI hallucinates features you never asked for. Too verbose → it drowns in context and loses sight of what matters.

IEEE 29148 specs are rigorous, but feed 200 pages to an LLM and it gets lost. A casual "make me a Todo app" works — until auth and state machines show up, then everything breaks.

What I learned after trying many formats: traditional spec templates weren't designed for AI.

So what does an AI need from a spec? That question led me to build…

ANMS — AI-Native Minimal Spec

A spec template that reorganizes existing notations — EARS, Gherkin, Mermaid — for AI-driven development.

Each notation is someone else's brilliant work. What I did: through months of near-full-auto development, I mapped out where AI gets confused, assigned the best notation to each layer, and structured the chapters using Clean Architecture principles.

Stable Top, Flexible Bottom

Not every part of a spec changes at the same rate.

Project goals and constraints → rarely change
Gherkin scenarios → change all the time

So why treat them with equal weight?

I applied Robert C. Martin's Stable Dependencies Principle (SDP) — depend on stable things, not unstable ones — to document structure instead of code.

Ch1  Foundation        ← Rigid: rarely changes
Ch2  Requirements
Ch3  Architecture
Ch4  Specification     ← Flexible: changes often
Ch5  Test Strategy
Ch6  Design Principles ← Becomes AI's code review criteria

Upper chapters constrain lower ones. Never the reverse.

Change a Gherkin scenario in Ch4 → Ch1 and Ch2 are untouched.
Change the Goal in Ch1 → everything below needs review.

Applying SDP to documents, not code — that's the key. It tells the AI which context takes priority, structurally.

The Right Notation for Each Layer

One notation can't cover everything. So I picked the best fit for each chapter — standing on the shoulders of giants.

Chapter	Notation	Why
Foundation	Natural language + tables	Humans define goals, scope, constraints
Requirements	EARS syntax	Structured patterns eliminate ambiguity
Architecture	Mermaid (color-coded)	Humans and AI sync on structure visually
Specification	Gherkin	AI generates test code directly from this

Ch1: Foundation — Natural Language + Tables

Goal (what to build), Scope (how far), Constraint (what to respect). Plain language and tables.

This is where you spend the most time — and it's worth it. The foundation is your intent, crystallized.

Ch2: Requirements — EARS

"The system shall handle errors appropriately."

…appropriately? Hand that to an AI and it'll do whatever it wants.

EARS (Mavin et al., 2009) fixes this:

When a collision with a forward obstacle is predicted within 1 second, the System shall activate emergency braking immediately.
While operating in autonomous mode, the System shall maintain lane center within ±15 cm.

Six patterns. Zero ambiguity. Originally from embedded systems — turns out it's a perfect fit for AI-driven development.

Ch3: Architecture — Mermaid

In AI-driven development, a Mermaid diagram is not an illustration — it's the design itself.

The AI reads component diagrams to determine file splits, import paths, and dependency direction. ANMS requires color-coding by architectural layer — Mermaid's layout engine does its own thing, so without color, you can't tell which box belongs where.

Ch4: Specification — Gherkin

Gherkin scenarios serve as acceptance tests — and in TDD, implementation specs. Each scenario traces back to a requirement via (traces: FR-xxx), so nothing falls through the cracks.

Example: "The Chauffeur Car"

Can't show the full spec here, but here's the concept-to-spec flow.

Foundation:

Goal: Provide the "just tell me where to go" experience — 24/7, no human driver.
Constraint: Emergency brake response ≤ 100 ms (ISO 22737).

Requirements (EARS):

When a collision with a forward obstacle is predicted within 1 second, the System shall activate emergency braking immediately.

Sequence Diagram to Explain Architecture (Mermaid):

Specification (Gherkin):

Feature: Chauffeur Mode

  Scenario: SC-002 Emergency stop on forward obstacle (traces: FR-003)
    Given the vehicle is in chauffeur mode driving at 40 km/h
    When a collision with a pedestrian ahead is predicted within 1 second
    Then the system activates emergency braking within 100 ms
    And the vehicle comes to a safe stop

Four steps. Concept to testable spec. The AI knows what to build, what to test, and what constraints to obey.

What Humans Still Do

Even in near-full-auto development, three things stay human:

Decide the concept
Make the critical calls
Review the output

Everything else? Let the AI handle it. You review what matters.

Resources

The template and essay (explaining why this structure) are on GitHub.

👉 ANMS Template & Essay

File	Contents
`anms-essay-ja.md`	Full essay (Japanese)
`spec-template-ja.md`	Spec template (Japanese)
`anms-essay-en.md`	Full essay (English) — rationale & comparison with existing formats
`spec-template-en.md`	Spec template (English)

Try it in your next AI-driven project. If you find improvements or different combos that work, I'd love to hear about them.

I prefer building in the open — more fun that way.

GRSMD: Markdown Viewer to Keep You in the Zone

GoodRelax — Sun, 08 Mar 2026 12:03:32 +0000

Just press [R] to update AI result

Why?

I have AI rewrite my docs all the time.
VS Code preview works fine for a single file
— but once you're juggling multiple .md files,
it gets sluggish with Mermaid diagrams, math blocks, and long files

That little lag — just enough to break the flow.

With GRSMD, each file just opens in a new browser tab. No friction, no slowdown.

What I built

GRSMD is a Markdown viewer that runs entirely in your browser — no install, no backend.
(Previous article: GRSMD: Instant Markdown Viewer — Local & Private)

I just added a reload feature so you never have to re-drag a file again.

How it works

Drop a .md onto GRSMD
Have AI update the file (review comments, rewrites, whatever)
Press [R] on GRSMD (or click the [Re-load] button) → The updated content re-renders — scroll position preserved

Who is this for?

You use AI to draft or edit Markdown (docs, READMEs, blog posts)
You want to preview multiple files without leaving your browser
You care about privacy — no data leaves your machine

👉 https://goodrelax.github.io/gr-simple-md-renderer/

Workflow

Bonus — code files too

Drop .py, .js, .json, or any non-.md text file

— you get syntax highlighting with line numbers. R key reloads these as well.

Quietly useful for code review.

Shortcuts

Key	Action
R	Reload file
L	Light mode
D	Dark mode
N	New tab
C	Clear
↑ ↓	Smooth scroll

What hasn't changed

No backend. No data collection.
PlantUML is the only external call — always asks for consent first.
Single HTML file. Zero install.
Free. No ads. OSS.

Try it

👉 https://goodrelax.github.io/gr-simple-md-renderer/

Samples:
👉 https://goodrelax.github.io/gr-simple-md-renderer/sample-data.md
👉 https://goodrelax.github.io/gr-simple-md-renderer/sample-data-2.md

GitHub:
👉 https://github.com/GoodRelax/gr-simple-md-renderer

Previous article:
GRSMD: Instant Markdown Viewer — Local & Private

GRSMD: Instant Markdown Viewer — Local & Private

GoodRelax — Sun, 01 Mar 2026 02:38:01 +0000

Update

New features have been added.
See the follow-up article: GRSMD: Markdown Viewer to Keep You in the Zone

VS Code's Ctrl+Shift+V works.

But you can't keep rendered previews open in separate browser tabs, and you can't view multiple documents side by side without splitting editor windows.

GRSMD (GoodRelax Simple Markdown Renderer & Viewer) is a single index.html file that opens in your browser.

Just drop a `.md` file onto it or paste with `Ctrl+V`

— it renders immediately.

Live: https://goodrelax.github.io/gr-simple-md-renderer/
Source: https://github.com/GoodRelax/gr-simple-md-renderer

Press `[New Tab]` for multiple documents.

What it renders

Feature	Library	Processed locally?
Markdown	marked.js 17.0.1	Yes
Mermaid diagrams	Mermaid.js 11.12.2	Yes
Syntax highlighting	highlight.js 11.11.1	Yes
LaTeX math	KaTeX 0.16.25	Yes
PlantUML	plantuml.com	Consent required

All rendering exept for PlantUML happens in your local browser.

No npm. No build. Just load libraries from CDN.

Why it works better than VS Code preview for some workflows

Multiple tabs — open several documents at once in separate browser tabs
Drag and drop — drop .md files directly onto the editor or preview area
Paste — Ctrl+V drops Markdown straight into the editor
New Tab button — clones the renderer into a fresh browser tab in one click
Zoom and pan — Ctrl+Scroll to zoom any diagram (0.5x to 5.0x), drag to pan, double-click to reset
Scroll preserved — re-rendering does not jump you back to the top
Copy diagrams to clipboard — press [Copy SVG] / [Copy PNG] and paste it into PowerPoint etc.

Privacy model

Nothing leaves your browser unless you allow it.
Here's how the security model works:

PlantUML is the only exception — it requires the official PlantUML server to render.

A confirmation dialog appears before any data is sent.

Cancel it and everything else renders fine.

Special tip

Long press the [?] button to improve your productivity with AI.

Try it

Live: https://goodrelax.github.io/gr-simple-md-renderer/
Quick sample: https://goodrelax.github.io/gr-simple-md-renderer/sample-data.txt
Full sample (Mermaid + PlantUML + LaTeX): https://goodrelax.github.io/gr-simple-md-renderer/sample-data-2.md

Drop one of the sample files onto the live page.

Hide Any File in Two Images — Browser-Only, No Server

GoodRelax — Sun, 22 Feb 2026 04:52:15 +0000

GRTM2CD 🗺️🐈🐕

GoodRelax Treasure Map to Cat and Dog

The Story

What if you found a treasure map?
You could ask a cat and a dog to each keep a piece.
When you need the map, just call them both.

I built a tool that does exactly that.

👉 Try it now

What It Does

This is a browser-only steganography tool.

It takes any file — PDF, ZIP,

whatever — and hides it across two ordinary PNG images.

You need both images to recover the file. Either one alone is useless.

How It Works

The process in one line:

Compress → Encrypt (AES-256-GCM) → Split across two images → Embed in LSBs → Fill remaining capacity with noise

The result:

Each image looks like a normal PNG
LSBs are indistinguishable from white noise
Neither image alone reveals anything
Both together reconstruct the original file perfectly

Why Two Images?

Capacity — each image only needs to hold half the payload
Deniability — no ciphertext continuity in either image
Security — the AES key, IV, and ciphertext are all fragmented across both

One image found? Just a photo. Two images found? Still just two photos — unless you know what to look for.

Why Browser-Only?

No server means nothing can leak.

No uploads, no installation, no build tools
Works offline — just open the HTML file
Cross-platform

Everything runs locally via Web Crypto API, Canvas API, and typed arrays.

Usage

Encode: Drop any file + two images → get two PNGs.

Decode: Drop the two PNGs → get the original file back. Order doesn't matter.

Tech Stack

Vanilla JS (ES modules, no frameworks)
Web Crypto API (AES-256-GCM)
Canvas / OffscreenCanvas
pako (zlib compression)
PNG output only

No frameworks. No build tools. Single HTML + JS.

Try It Now

👉 https://goodrelax.github.io/gr-tools/grtm2cd/

Drop a file and two images — see what happens.

📂 https://github.com/GoodRelax/gr-tools

Please use responsibly.

The Symbol for All of Us is Null

GoodRelax — Sun, 15 Feb 2026 06:21:54 +0000

The Symbol for All of Us is Null

You might be thinking, "What is this guy even talking about?"

But if you've found your way to this post, I have a feeling this will click for you somewhere along the way.

Give me five minutes.

There's something humanity does unconsciously to make sense of the world.
AI does the exact same thing.
Mathematics describes it beautifully.

And at the end:

Why is Null the ultimate symbol for everything?

It all connects in a single thread.

And once you see that thread, the world starts to look a little clearer.

Let's walk through it.

To Understand Is to Divide

The world is full of things we don't understand.

But we have a trick for dealing with that: we give different things names and sort them into categories.

Round fruits? We split them into:

Apples
Oranges
Pears

…and that's how we make sense of them.

This is the logic of cognition that every one of us runs unconsciously.

AI Does the Same Thing

AI understands words as vectors in absurdly high-dimensional space.

What does that even mean? Let's--true to form--divide and understand:

Words: assign IDs to things and concepts
Absurdly high-dimensional: thousands or even tens of thousands of indices
Vectors: array-format data you can think of as arrows with direction and magnitude
Understands: tidies them up nicely

In pseudocode:

apple  = [2, 3, 5, ...]
orange = [3, 5, 7, ...]

dirOfApple = GetDirection(apple)
lenOfApple = GetLength(apple)

In real LLMs, these vectors live in thousands or even tens of thousands of dimensions. From a human perspective, the combinations are just… endless.

Visually, it looks something like this:

This is roughly how LLMs like ChatGPT and Gemini work under the hood--it's called embedding.

For a deeper dive, check out 3Blue1Brown's videos. Absolute masterpieces:

Transformers, the tech behind LLMs – Deep Learning Chapter 5

Analogy ↔︎ Contrast / Induction ↔︎ Deduction / Concrete ↔︎ Abstract

Most sports and martial arts have fundamental forms. So does the way we see and think about things.

These three pairs are the basic stances of reasoning. Most people use them without realizing it. But once you name and practice them consciously, you'll understand anything faster and deeper.

Analogy ↔︎ Contrast :  
      Apples and oranges are both sweet.
                        ↑↓
      Apples are red; oranges are yellow.

Induction ↔︎ Deduction:  
      An apple fell from the tree. There seems to be gravity.
                        ↑↓
      An orange detached from a branch will fall due to gravity.

Concrete ↔︎ Abstract :  
      There's a round, red, sweet apple  
      and a round, yellow, sweet orange.
                        ↑↓
      There are two round fruits.

"Obvious?" Okay, let me explain a bit more carefully.
It's going to get gradually more serious from here.
We'll use some light math, but nothing super rigorous,
so take it easy. Skipping the formulas is totally fine.

Analogy and Contrast Are Mappings

Analogy is finding what's the same.
Contrast is finding what's different.

An example:

An apple is round, red, and sweet.

An orange is round, yellow, and sweet.

Apply analogy and contrast:

Analogy: a linear transformation toward the same direction  
             → Apples and oranges are both sweet and round  
          
Contrast: a linear transformation toward opposite directions 
             → Apples are red, but oranges are yellow

As a vector diagram:

In notation, using linear maps $T_{analogy}$ and $T_{contrast}$ :

$Analogy:Tanalogy(apple⃗)↑Tanalogy(orange⃗)\text{Analogy} : T_{analogy}(\vec{apple}) \uparrow T_{analogy}(\vec{orange})$
$Contrast:Tcontrast(apple⃗)↓Tcontrast(orange⃗)\text{Contrast} : T_{contrast}(\vec{apple}) \downarrow T_{contrast}(\vec{orange})$

Induction and Deduction Are Vector Subtraction and Addition

Induction is searching for laws from specific past observations.
Deduction is inferring specific future events from laws.

Newton's universal gravitation is the classic example.

Induction:  Extracting a law vector  
  → An apple fell from the tree. There seems to be gravity.

Deduction:  Superposing a law vector  
  → An orange detached from a branch will fall  
     to the ground due to gravity.

As a vector diagram:

In notation:

\text{Induction}: \quad \text{Extraction}(\vec{fact_1}, \vec{fact_2}, \dots) \Rightarrow \vec{law}

\vec{law} = \vec{facts} - \frac{\sum \vec{noise}}{n}

\text{Deduction}: \quad \text{Superposition}(\vec{object}) \Rightarrow \vec{future}

\vec{future} = \vec{object} + \vec{law}

Induction is estimation. You stack multiple observations, cancel out the noise, and let the hidden law float to the surface.
Deduction is certainty. A law applies to the future, no ifs or buts.

Concrete and Abstract Are Information Gain/Loss for Shifting Levels

To concretize: is to add parameters (attributes),
gain information, and move down a level of cognition*.
No special rules.
To abstract: is to remove parameters (attributes),
lose information, and move up a level of cognition,
toward the nice essence.

An apple is round, red, and sweet — that's specific.
A fruit is just something round and edible — that's general.

Concretize: Add parameters, gain information, move down a level.
  → "fruit" + round + red + sweet = "apple"

Abstract: Remove parameters, lose information, move up a level.
  → "apple" - color - taste = "round thing"

As a diagram:

In notation:

$Concretize(object⃗)⇒object⃗⊕parameters⃗\text{Concretize}(\vec{object}) \Rightarrow \vec{object} \oplus \vec{parameters}$
$Abstract(object⃗)⇒object⃗⊖parameters⃗\text{Abstract}(\vec{object}) \Rightarrow \vec{object} \ominus \vec{parameters}$

Take the abstraction "human." Add the parameters "47 years old" and "male,"
and you get "middle-aged dude." 🍺

The Nice Essence

When you abstract by stripping away information, doing it haphazardly leads to nonsense.

Remove the stubble and wrinkles from a middle-aged man and you just get a boy.

That's not what we want -- we want to extract the information that actually matters.

That's where PCA (Principal Component Analysis) comes in.

PCA? Sounds fancy? You've probably already experienced it though.

You know those personality quizzes with ~50 questions

that plot you on a matrix like "Instinctive ↔ Logical" vs. "Extroverted ↔ Introverted"?

Those 50 questions are basically a 50-dimensional vector.

PCA squishes it down to 2 dimensions to make a "personality map."

In notation:

\text{Extract}(\vec{data}) \Rightarrow \vec{essence}

\vec{essence} = Z \, W_k, \quad W_k = [\vec{v}_1, \dots, \vec{v}_k] \quad \text{where} \quad \Sigma \vec{v} = \lambda \vec{v}

$Z$ : Zero-centering
$W$ : Weight matrix
$λ\lambda$ : Eigenvalues = the size of each MECE-organized component of information
MECE: Mutually Exclusive, Collectively Exhaustive

Set $k = 2$ and you get a 2D matrix.

This is pretty much the same thing we do unconsciously when we "get the gist" of something.

For more, this video is excellent:

Abstract vector spaces – Chapter 16, Essence of Linear Algebra

A Symbol Is a First Principal Component

When we organize information about something, some of it matters more than the rest.

Naturally, we want to pin a simple mark on the most important piece so it sticks.

That's what symbols are.

Flags, logos, kings, pop idols…

When people rally around a symbol, here's what they're actually doing:

from everyone’s messy, sprawling vectors, they converge on the single most important direction.

That most important vector = PCA's first principal component.

PCA extracts the dominant direction of variance.

The first principal component can be interpreted as a symbol capturing shared structure.

The arrow that best represents everyone.

What's at the End of Abstraction?

Abstraction strips away information toward the nice essence.

Strip a solid down and we get a plane.
Strip a plane down and we get a line.
Strip a line down and we get a point. → $R0\mathbb{R}^0$ still contains the information "a single point exists."
Strip even that away, and…?

\mathbb{R}^3 \to \mathbb{R}^2 \to \mathbb{R}^1 \to \mathbb{R}^0 = {*} \to \emptyset = \text{Null}

What remains is primordial space, prior to any structure.

That Is Null.

Here, Null means the ultimate absence after abstraction.

If we keep abstracting everything in the universe, we arrive at Null -- nothingness.

And so Null:

Belongs to no one.
Carries no attributes.
Is the ultimate symbol, with every vector stripped away.

Apples, oranges, you, me — all of us.

Strip away the infinite-dimensional noise, and everyone arrives at the same space. That space is Null.

Primordial space before creation. Form is emptiness. The Big Bang. They all point to the same thing.

Friends who share the same symbol — let’s get along. ♪

The Soul of Software Lives in Its Names - Kotodama

GoodRelax — Sat, 31 Jan 2026 15:41:48 +0000

In mathematics, you can call points “beer mugs” and nothing breaks.
In software, names don’t affect the compiler
— but they change everything for humans and AIs.
In Japan, we have a word for this: Kotodama (言霊).

The Soul of Software Lives in Its Names — Kotodama

Kotodama (言霊) is an ancient Japanese concept suggesting that words possess spiritual power.

In modern Japan, the term is rarely discussed in daily life. Most people are not deeply religious; we simply respect traditions and enjoy Christmas, Halloween, and New Year’s shrine visits as cultural rituals.

So why talk about Kotodama in software engineering?

Because this concept isn't about mysticism. It expresses a fundamental truth about how we build systems.

We have countless principles for great software: KISS, YAGNI, DRY, SOLID, SoC, SLAP, CQS. But beneath all of them lies a single practice that quietly determines the destiny of a codebase:

Naming.

Good naming creates readable code, reduces bugs, and allows software to evolve.

The Hilbert Perspective vs. The Human Perspective

The great mathematician David Hilbert once said:

"It does not matter if we call the things chairs, tables and beer mugs or points, lines and planes."

In mathematics, objects function correctly regardless of their labels, provided the logic and structure are consistent.

Software is technically the same. A program executes whether you name a class X, Foo, or PaymentProcessor. The compiler does not care.

But humans do.

Poor naming makes code impenetrable. Efficient development relies on a shared mental model. When we read a variable name, we aren't just reading text; we are invoking an idea.

In this sense: The soul of software lives in its names.

Kotodama in the Modern Stack

Interestingly, the concept of Kotodama mirrors this idea perfectly.

Intent: Parents name children with hopes for their future. In code, we name variables to define their purpose.
Encapsulation: In ancient Japan, people had "true names" (imina / mana) that were kept hidden to protect them. This is surprisingly similar to object-oriented programming, where we hide private state behind meaningful abstractions.

Words matter. Names carry intent, structure, and understanding.

That is Kotodama in software.

Even in the age of AI, names are more important than ever. High-quality prompts with precise naming produce significantly better code. AI doesn't just process logic; it processes the semantics we provide.

The GR Naming Cheat Sheet

To help developers harness this power, I created the GR Naming Cheat Sheet.

When you are struggling to find the right name, this table may help you.
I hope this sheet improves your code — and that your software makes everyone, including me, a little happier.

References:

GRSMD — A Privacy-First Markdown Renderer That Runs in Your Browser

GoodRelax — Sun, 25 Jan 2026 02:45:13 +0000

This post has been moved

Please check out the latest version here:

GRSMD: Instant Markdown Viewer — Local & Private

GoodRelax ・ Mar 1

#markdown #privacy #webdev #javascript

Forem: GoodRelax

The End of the Era Where Software Has Value

How I Prevented Quality Collapse in AI-Driven Dev with AI Agents and SDD

SDD lives or dies by its spec template and process — and the process can be automated by AI

A sample of AI Agent Team

Quality Gates = Inspection Criteria

① Have AI write the spec — incrementally, with inspections in between

The spec "template" is everything

Natural language makes AI guess wrong

EARS notation eliminates ambiguity

After writing the spec, have it inspected

② Have AI design — expressing Clean Architecture with colors

③ Derive test cases from the spec

Implementation inspection results

④ The full run — results

Sounds easy so far, but...

The full picture of gr-sw-maker

⑤ Have AI reflect — AI improving its own process

Challenges ahead

Summary

Try it now

SDD: AI Turned My 5-Line Memo into Specs and Software in 45 Minutes by gr-sw-maker

Why?

What?

How?

1. Install gr-sw-maker via npm

2. Write a 5-line memo (requirements doc) for gr-sw-maker

3. Answer the AI's interview questions and say "Do as you recommended!"

4. After that, I requested two spec changes (added an Update button, enabled file:// direct opening)

5. Also had it write a process improvement report

Time breakdown

Deliverables

Evidence

So... is it any good?

"But is it just a toy?"

Thoughts

Try it yourself

ANMS : A Spec Template Built for AI

EARS + Gherkin + Mermaid, reorganized for AI-driven development.

Why I Made This

ANMS — AI-Native Minimal Spec

Stable Top, Flexible Bottom

The Right Notation for Each Layer

Ch1: Foundation — Natural Language + Tables

Ch2: Requirements — EARS

Ch3: Architecture — Mermaid

Ch4: Specification — Gherkin

Example: "The Chauffeur Car"

What Humans Still Do

Resources

GRSMD: Markdown Viewer to Keep You in the Zone

Just press [R] to update AI result

Why?

What I built

How it works

Who is this for?

Workflow

Bonus — code files too

Shortcuts

What hasn't changed

Try it

GRSMD: Instant Markdown Viewer — Local & Private

Update

Just drop a .md file onto it or paste with Ctrl+V

— it renders immediately.

Press [New Tab] for multiple documents.

What it renders

Why it works better than VS Code preview for some workflows

Privacy model

Special tip

Try it

Hide Any File in Two Images — Browser-Only, No Server

GRTM2CD 🗺️🐈🐕

GoodRelax Treasure Map to Cat and Dog

The Story

👉 Try it now

What It Does

How It Works

Why Two Images?

Why Browser-Only?

Just drop a `.md` file onto it or paste with `Ctrl+V`

Press `[New Tab]` for multiple documents.