Katakana

Katakana, the sister script, is identical in sound to hiragana and uses the same five vowels.
Only the shapes are different.

It is the script Japanese uses for words borrowed from other languages and for the sounds of things.

When you travel, katakana is the script that most often rewards you, because once you can sound it out, you discover that many of the words are borrowed English hiding under Japanese pronunciation.

The word "hotel" is written in katakana,
"taxi" is written in katakana,
"ramen" (which is really Chinese noodles) on a shop sign is often written in katakana,
"Terebi" is television,
"Kōhī" is coffee,
"Toire" is toilet.

Because the sounds are identical to hiragana, the five vowels carry over without change.

Where hiragana is round and flowing, katakana is angular and sharp, built from short straight strokes.

Here is the full set of katakana, laid out exactly as the hiragana chart, so you can see that only the shapes have changed.

	a	i	u	e	o
—	ア a	イ i	ウ u	エ e	オ o
k	カ ka	キ ki	ク ku	ケ ke	コ ko
s	サ sa	シ shi	ス su	セ se	ソ so
t	タ ta	チ chi	ツ tsu	テ te	ト to
n	ナ na	ニ ni	ヌ nu	ネ ne	ノ no
h	ハ ha	ヒ hi	フ fu	ヘ he	ホ ho
m	マ ma	ミ mi	ム mu	メ me	モ mo
y	ヤ ya		ユ yu		ヨ yo
r	ラ ra	リ ri	ル ru	レ re	ロ ro
w	ワ wa				ヲ wo
n	ン n

The same two marks appear here as well.
The dakuten strokes soften a consonant, so カ ka becomes ガ ga.
The handaku circle turns the h row into a p, so ハ ha becomes パ pa.

A long vowel is not written by repeating the vowel but by a single horizontal bar, called chōonpu.
So the long oo in a borrowed word is a bar, and rāmen appears as ラーメン, with the bar holding the a long.
When you see that bar, simply hold the vowel before it.

Between the two kana charts you now have every basic sound in the language, and every one of them rests on the same five pure vowels.

Hiragana

Here is the full set of hiragana, the script used for native Japanese words.

Read across each row as the consonant joined to the five pure vowels.

	a	i	u	e	o
—	あ a	い i	う u	え e	お o
k	か ka	き ki	く ku	け ke	こ ko
s	さ sa	し shi	す su	せ se	そ so
t	た ta	ち chi	つ tsu	て te	と to
n	な na	に ni	ぬ nu	ね ne	の no
h	は ha	ひ hi	ふ fu	へ he	ほ ho
m	ま ma	み mi	む mu	め me	も mo
y	や ya		ゆ yu		よ yo
r	ら ra	り ri	る ru	れ re	ろ ro
w	わ wa				を wo
n	ん n

A few of these are not spelled the way an English eye expects.

The し in the s row is "shi", not "si".
The ち in the t row is "chi", not "ti".
The つ in the t row is "tsu", a single sound, the "ts" of "cats" followed by "oo".
The ふ in the h row is "fu", a soft "f" made with both lips rather than teeth.
The ら row is closer to a light "d" or a flap than to an English "r", but "r" is the accepted spelling.

Two more marks change the consonant, not the vowel.

A small pair of strokes, called dakuten 濁点だくてん, softens a sound:
か "ka" becomes が "ga",
さ "sa" becomes ざ "za",
た "ta" becomes だ "da",
は "ha" becomes ば "ba".

A small circle, called handakuten 半濁点はんだくてん, turns the h row into a p: は "ha" becomes ぱ "pa".
The vowels underneath stay exactly the same.

Finally, two things about rhythm.
A small つ before a consonant marks a short silent pause, a doubling of that consonant, as in the "tt" of "Nippon".

And ん is the one lone consonant, an "n" or "m" sound that stands by itself.

When you reach a Japanese word later, sound it out by these five vowels and it will be close to right.

Katakana, the sister script used for words borrowed from other languages, sounds identical to hiragana and follows the same five vowels.

Japanese "kana" pronunciation

The following brief introduction to Japanese sounds is not intended to teach you to read, but rather to give you an idea of what sounds are available in Japanese.

English, and especially American, readers make pronunciation guesses based on their ABC, and those guesses are almost always wrong because Japanese writing in the so-called "romaji" alphabet is based on Latin, not English.

The good news about learning it is that, unlike English, Japanese is very consistent. Once you learn it, you will be able to read correctly for the rest of your life.

I am not saying Japanese does not have its own problems, but to keep things simple, let's focus on the vowels.

There are only five vowels, and each one makes exactly one sound every time, with no exceptions.

The five vowels:

The "a" sounds like the a in "father". It is never the "a" in "day" or the "a" in "cat".
The "i" sounds like the "i" in "machine". It is never the "i" in "ice".
The "u" sounds like the "u" in "boot". It is never the "u" in "cube".
The "e" sounds like the "e" in "bed". It is never the "e" in "me" and never the "a" in "day".
The "o" sounds like the "o" in "boat", but shorter and without letting it glide into "oo" at the end. It is never the o in "hot".

That is all you need to remember.

The long vowels

Each of the five vowels can also be long, meaning the same sound is simply held for twice as long.
The sound does not change, only its duration.
I mark a long vowel with a bar over the letter, called a macron: ā, ī, ū, ē, and ō.

The "ā" is a long "aa".
The "ī" is a long "ii".
The "ū" is a long "uu", as in the shū of Shūdōkan 修道館しゅうどうかん.
The "ē" is a long "eh".
The "ō" is a long "oh", as in "dō", the way 道どう is pronounced.

Length is not decoration. It can change the meaning of a word.
The training hall is a dōjō, 道場どうじょう, with both o sounds long.
The school is 修道館しゅうどうかん, with a long u and a long o.

Common pronunciation mistakes

Here are a few examples:

Karate is pronounced 空手からて, with the last syllable not "tee" but ending in "e", as in "energy".
It is true that the original name for Okinawan hand fighting was "tī", and it uses the same Chinese character for "hand" 手て as in karate 空手からて. However, the word "karate" is purely Japanese and should be pronounced according to Japanese standards, again, ending in "e", as in "energy".

The rice wine, or "sake", is 酒さけ, ending in "e", as in "energy", not "sa-kee".

However, "saki", meaning "point", is 先さき , ending in "i", as in "machine" and not "sa-kay".

My name, Uki, is 宇気うき, ending in "i", as in "machine", not "yoo-kay".

Japanese syllables

Every other sound in the language is a consonant placed before one of these five vowels, and the consonant does not alter the vowel.

The "ka" is "k" plus "a", pronounced like the start of the word "comma".
The "ki" is "k" plus "i", as in "key".
The "ku" is "k" plus "u", as in "cooper".
The "ke" is "k" plus "e", as in the name "Ken".
The "ko" is "k" plus "o", as in "comb".

The same pattern repeats for every other consonant.

Visiting Japanese schools

Probably the most important reason to practice the Japanese language nihongoにほんご ・ 日本語にほんご is to visit actual schools in Japan.

I know this sounds far-fetched for a white-belt teenager in an American or European town, but it is a real possibility.

Many schools welcome black-belt kuro obiくろおび ・ 黒帯くろおび practitioners to visit their school dōjōどうじょう ・ 道場どうじょう for two weeks to improve their art. Remember, it would be polite to wear the white belt shiro obiしろおび ・ 白帯しろおび as you arrive, out of respect for the school and the "beginner's mind", shoshinしょしん ・ 初心しょしん attitude.

I think everyone should dream of such a visit and strive to make it happen.

Why We Use Japanese in the Dojo?

I have been practicing martial arts in Poland, Okinawa, Japan, Chicago, and Washington State.

Three continents, three national languages, a single set of commands in Japanese. 

Similarly, when using the first computer I purchased (Atari 800XL), I never changed the system settings to the local Polish language. Somehow, even back then, I knew that if I wanted to take computers seriously, I needed to learn in the language of origin. To this day, when I see family or friends struggling with Polish menus, I helplessly shrug my shoulders despite being an architect and a director-level software developer.

It is called lingua franca in trade business, or lingua latina in intellectual circles. 

Europe has had Latin and especially Greek for the past three thousand years. Scientists, clergy, and lawyers use Latin names to be precise in biology and medicine, and even in everyday writing (e.g., for "et cetera", "et al.", and thousands of other words). Everybody knows enough Greek to understand what "geo-logy" or "anthropo-morphic" means.

The worldwide community of Japanese martial arts practitioners uses Japanese. 

This is not because Japanese is particularly easy, nor does anyone expect practitioners to become fluent.

We learn Japanese so we can distinguish the nuanced difference between, for example, the two "hook-punch swings", kagi-tsuki and furi-tsuki. OK, I am showing off.

The alternative, which is translating everything into the local language, would shatter the single most important thing that connects us to each other and to the source: the integrity of the common art.

Until this point, I have avoided using Japanese names in my writing, except for commonly known terms like "karate" or "dojo". 

However, as I am writing this publication, I want to learn and practice just enough Japanese to build a common language for the art.

Please expect to see notation such as this, and I will explain the rest as we progress.

- <ruby>kagi-tsuki<rt>かぎつき</rt></ruby> ・ <ruby>鉤突き<rt>かぎつき</rt></ruby> 

- <ruby>furi-tsuki<rt>ふりつき</rt></ruby> ・ <ruby>振り突き<rt>ふりつき</rt></ruby>

Real values, not GDP

Every civilization reveals its values in what it measures. 

Rome counted legions and grain. 

Medieval Europe counted souls and acres. 

The modern world counts money in motion, the sum of every transaction within its borders, and calls it the health of a nation. The number is Gross Domestic Product. Simon Kuznets, the economist who built the modern version of that metric for the US Congress in 1934, warned in his own report that "the welfare of a nation can scarcely be inferred from a measurement of national income". 

I find that warning remarkable, since it came from the man who invented the tool, before anyone had even started to misuse it. We built our politics, our foreign policy, our schools, and our private definitions of success on the number anyway. A country that grows is succeeding. A country that contracts is failing. A person who earns more this year than last is moving in the right direction. The logic runs so deep that most people never notice it is a choice, not a healthy fact.

The Gross Domestic Product (GDP) counts the antidepressants sold and the therapy sessions booked. 

It counts the security systems installed in neighborhoods where neighbors no longer know each other.

It counts the fast food that makes us sick, the traffic, the divorces, the medical bills for diseases produced by the way we live. 

What it cannot count is the meal cooked from a garden and shared without a receipt. The friendship that made the therapy unnecessary. The morning walk or run that kept the doctor away. An hour of practice in a dōjō that produced nothing sellable and changed everything.

Research on the exact income threshold has moved over the years. A flat dollar figure that ignores what a dollar actually buys where you live is its own kind of category error, the same mistake GDP makes at a national scale, repeated at a personal one.

None of this is an argument against prosperity, and I want to be direct about that before it reads as one. I grew up under a communist socialism which failed in every country that tried it, including my native Poland, and failed darkly and miserably. 

I have no interest in experiencing poverty again, real or romanticized, as a virtue. I have worked my whole career in software to become an architect and director at a comfortable salary. The point is not that money is bad or that more of it is worthless. The point is that past basic financial security, GDP counts none of the five things that actually determine whether a day felt worth living (purpose, physical vitality, genuine community, time that belongs to you, and a relationship with the natural world that gives back as much as it takes), and a government can count every growth target while folk quietly lose all that matters.

The Japanese have a word for the convergence of those things: ikigai 生き甲斐いきがい, the reason you get up in the morning, the specific overlap of what you love, what you are good at, what the world actually needs, and what can sustain you economically. 

Okinawa, where I lived for three years and where this book's own training lineage runs, has produced more centenarians (or people who actively live over 100) per capita than almost anywhere on earth. I write about what that place actually taught me in a later chapter. The short version here: the researchers who study Okinawan longevity did not find a miracle diet or a rare gene. They found people who had never separated living from meaning in the first place, something ikigai names directly and GDP cannot name at all.

Other attempts to measure what is worth exist. 

Bhutan's Gross National Happiness index tracks psychological wellbeing, time use, cultural resilience, and governance alongside income. 

The OECD Better Life Index adds housing, social connection, and work-life balance to its picture of a country. 

The Happy Planet Index weights life expectancy and reported well-being against the ecological footprint, which exposes an uncomfortable fact: some of the world's richest societies by GDP are buying their comfort at an ecological cost that their own children will pay. 

None of these indices is perfect. Together they sketch something GDP was never built to see: a picture of people actually flourishing, not merely transacting.

This book is my own account of chasing that convergence, approached from an unusual direction. Not through economics or policy, but through the healthy mind and body, through the discipline, through the slow discovery that via practice, fine art, and a still mind can be three depths of the same practice rather than three separate hobbies. 

I call the three stages warrior, artist, and sage, and the rest of this book is the specific, sometimes narrow, path.

Book as a bronze mirror

I own a library of thousands of books in paper, audio, and various digital formats.
There are many books like this, but this one is mine.

I have no audacity to say I bring anything new to this field.
I realize scholars might get frustrated with this book if they ever bother to read it.

However, this book does serve a couple of useful purposes.

First and foremost, it is a self-study guide.

It was written as a set of my separate notes while studying Shudōkan Karate, Kobudō, Aikidō, and the culture of Okinawa and Japan.

When I write these words, it is as if I am polishing a bronze mirror.

A round bronze mirror holds great symbolic significance in Japan and much of South and East Asia.

The mirror is a piece of metal that requires frequent polishing, a time-consuming and effort-intensive task. I know, as I own one.

As I started preparing this book for publishing, I became acutely aware of my own impermanence. I had no idea how long I would live. A stroke, coronary heart disease, cancer, or even a simple road accident could happen to anyone, any time.

I realize that at this moment, virtually no one I personally know is interested in the subject. However, since I have built a lifetime of daily notes, study, books I have read, travel, and experiences that I do not want to disappear.

I hope that people who are not interested today may pick it up in 20 years.

I certainly always wished I had any writings from my own ancestors.

My introduction to Japanese culture

 My introduction to Japanese culture

My relationship with Japanese culture dates back to early childhood. In retrospect, it is neither random nor surprising.

I grew up on Japanese cartoons, which were a dramatic improvement over depressing socialist television Poland had to offer in the 1970s.

As I write this in 2026, my three daughters also love watching Japanese cartoons.
The kawaii 可愛いかわいい culture is even stronger now than it was in 1990s Japan. The boy heroes are still swinging katana swords.

When I was a teenager, I practiced a very traditional Shotokan karate; Japanese culture was as important to us as the physical training.

I remember that when I was young, I watched the TV series Shogun, which exposed me to the nuances of Japanese culture.

Consequently, I left Poland, joined my already established family in America, enlisted in the U.S. Marines, and, at my own request, was sent to Okinawa, Japan, where I lived (mostly off-base) for three very formative years.

I studied "Cultural Anthropology of East Asia" in the Asian division of the University of Maryland with professors who were absolutely dedicated to their subject.

The word "culture" would later become a life's passion in the context of Japanese, East Asian, Slavic, and Proto-Indo-European (PIE) studies.

The word "Anthropology", in other words, means a "Behavioral Science" of humans.

Made in China - new respect

 

For last 30 years, since my return from Japan, I have been fascinated in how much pride and attention Japanese put in everything they do. 

This is especially visible how they wrap items sold and gifts.

Today, before opening these linen, I had to take a photo and give my appreciation to this Atlinia “Made in China” item. 

These days, we buy almost everything made in China which is a totally separate topic on how American industry committed suicide.

However, this is the first Chinese item that was presented in a way I love and how I will remember it.

temple

Tonight, I was writing a chapter for my new book, and I thought I would share it.

On Saturday mornings, I often found myself at a nearby Buddhist temple, Fukusen-ji 福泉寺, at dawn. The temple sat on a bluff overlooking the bay on the East side of Okinawa Island. The building sat slightly away from the coastal road, with a steep stairway leading up the bluff. 

Introducing AIKO assistant native macOs app

For years, have been trying to build AIKO (AI-child in Japanese) because I have always dreamed of a personalized AI that represents my favorite historical figures, scientists, and philosophers in a room with me.

I also needed to manage a collection of over 5,984 notes and blog posts.

Over the years, I tried iterations of various solutions, from command-line rule-based systems to Skype, then Telegram-based chats. They say, "Writing is re-writing".

These days, with Large Language Models, customized chats, note aggregation, and summarization, nightly automation has become doable.

I did not want to use someone else's solution, as I need to know that I designed my personal assistant with safety and privacy in mind.

I started by creating "skill agent" scripts in the chat window, then decided to organize all of that in a pleasant macOS application.

In this post, I proudly present a new AIKOassistant.ai native macOS app.

For now, I will continue using many scripts I already have, but I also believe personal AI deserves a better front end than the command line alone. 

AIKOassistant.ai is my answer to that.

OpenClaw

VirusTotal reports hundreds of actively malicious OpenClaw skills, describing the marketplace as a malware delivery channel and warning that without active sandboxing the blast radius is “basically your entire system”.

I am not trying to say, be aware, but I also appreciate progress OpenClaw brought to the community.

Kakato geri

 

Pinan Shodan bunkai

 

A Practical Framework for Safe Deployment of Autonomous AI Agents

Summary

Autonomous coding agents can increase delivery speed, but they also introduce operational, financial, and security risks at scale. This paper presents a governance-first architecture for safer autonomy: explicit Functional Requirements, deterministic stop conditions, operating system–enforced containment, staged promotion controls, and auditable execution artifacts. It is written to help engineering leaders, security teams, and executives move from experimentation to controlled deployment without treating model obedience as a security mechanism. This is the author's practical approach rather than a universal policy template, shared because these concerns are timely and real. The objective is practical adoption through bounded authority, measurable progress, and reversible outcomes.

Overview

Autonomous software agents that can read repositories, generate code, execute commands, and interact with external systems represent a qualitative shift in operational risk. These systems are not productivity tools in the traditional sense. They are actors capable of modifying state, consuming financial resources, and introducing security vulnerabilities at machine speed.

The central challenge is not whether agents increase developer velocity. They do. The challenge is whether their authority is bounded, observable, and reversible.

This paper presents a practical framework for deploying autonomous or semi-autonomous coding agents in a controlled environment. It is written for engineers designing systems, security teams responsible for governance, and corporate decision-makers accountable for operational risk.

The core thesis is simple: autonomous agents are best treated as high-privilege distributed systems. They benefit from containment, separation of duties, economic guardrails, and auditability by design.

This requirement becomes more critical as organizations push agent runs from minutes to hours, days, or weeks. Without strict control loops, long-running autonomy can consume tens of thousands of dollars while delivering mediocre outcomes. The framework below treats long-running agent execution as an operations discipline with explicit ownership, measurable progress, and clear stop conditions.

Scope and Non-Goals

This framework targets coding agents with execution authority, including agents that can modify files, run commands, execute tests, and initiate delivery workflows.

It does not focus on read-only advisory models that cannot change the system state.

It assumes baseline engineering infrastructure already exists, including version control, CI pipelines, and protected branch controls.

Organizations can adapt these controls to fit their own regulatory, technical, and operational context.

Reframing the Risk Model

Traditional developer tooling assumes a human-in-the-loop at all times. An IDE may suggest code, but a human compiles, runs, and deploys it. Autonomous agents collapse these boundaries.

An agent that can:

• modify source files
• execute shell commands
• access network resources
• run tests
• open pull requests
• deploy artifacts

is functionally equivalent to a junior engineer with root access and infinite stamina.

Risk, therefore, shifts from "incorrect suggestion" to:

• silent corruption of data or code
• lateral movement across filesystem boundaries
• accidental exposure of credentials
• runaway cloud API costs
• infinite execution loops
• dependency injection attacks
• supply chain manipulation

Security posture needs to evolve accordingly. It is useful to treat agents less as assistants and more as privileged processes.

Functional Requirements as Execution Contracts

Long-running agent runs should not start from a vague prompt. Each run should bind to explicit Functional Requirements (FRs) that are testable and auditable.

Each FR should define:

• FR identifier and owner.
• Objective and non-goals.
• Allowed input and output boundaries.
• Acceptance criteria tied to executable tests.
• Security constraints and prohibited actions.
• Cost ceiling and runtime ceiling.
• Done criteria and rollback criteria.

If an objective cannot be expressed as an FR with executable acceptance criteria, it is likely not ready for autonomous execution.

Directory-Scoped Agent Threads

One practical pattern for safe scaling is to treat each repository directory as an independent agent thread with its own contract, tests, and policy boundary.

In this model, autonomy is partitioned by directory rather than by a single repository-wide agent context.

Each directory-scoped thread should maintain:

• Its own Functional Requirements document.
• Its own unit test scope and acceptance thresholds.
• Its own `WORK_PLAN.json` for declared intent and stop conditions.
• Its own `config.yaml` for runtime limits, tool allowlists, and policy references.
• Its own security review artifact is linked to execution history.

Operational boundary rules should be explicit:

• A thread may read and write only within its directory scope and declared shared interfaces.
• Cross-directory modification requires a formal handoff or integration gate.
• A thread should not mutate another thread's policy artifacts without explicit promotion approval.
• Shared dependency or infrastructure changes should be routed through a dedicated integration thread.

This pattern introduces practical benefits by converting autonomy from a single broad permission domain into many small, auditable execution domains.

The governance benefits are substantial:

• Smaller blast radius for faulty behavior.
• Cleaner ownership and accountability by subsystem.
• More deterministic rollback and incident containment.
• Per-thread budget tracking and performance measurement.
• Safer parallel execution across independent workstreams.

This pattern also introduces complexity and should be adopted with discipline:

• Fragmented policies can drift across directories.
• Integration risk can move from the code level to the contract level.
• Operational overhead increases if standards are inconsistent.

These risks can be controlled through shared policy templates, schema validation for `config.yaml` and `WORK_PLAN.json`, and periodic integration verification across thread boundaries.

Principles for Safe Agent Deployment

The following principles form a practical baseline.

Least Privilege by Construction

Do not rely only on prompt instructions to restrict behavior. Enforce boundaries at the operating system and runtime levels.

Concrete measures:

• Run agents under dedicated OS users.
• Use read-only mounts for repository sources.
• Allow writes only to explicitly declared staging directories.
• Remove network access by default.
• Provide whitelisted command wrappers instead of raw shell access.

If an agent needs to run tests, expose a single controlled binary, such as `run_tests.sh`. Avoid unrestricted shell access.

Separation of Duties

Avoid designing a single all-powerful agent. Instead, fragment authority across specialized agents:

• Planning agent: read-only access, writes append-only plan files.
• Code generation agent: writes only to staging.
• Security review agent: read-only, produces risk reports.
• Test execution agent: allowed to execute only approved test runners.
• Cost control service: enforces budget policy and can terminate runs.
• Progress evaluator: calculates no-progress streaks from test outcomes.
• Promotion gate: a deterministic program that validates policy compliance before merge.

Each agent should have a single narrow capability. No single agent should be able to read, write, execute, and deploy unilaterally.

This mirrors established enterprise controls such as code review workflows and financial approval chains.

Deterministic Guardrails

Autonomous systems benefit from hard limits:

• Maximum wall-clock runtime per job.
• Maximum tool calls per job.
• Maximum file modifications per run.
• Maximum token or API budget per request and per month.
• Explicit iteration caps in reasoning loops.
• Explicit no-progress iteration caps based on test outcomes.

Each run should declare these limits in a machine-readable policy before execution begins.

When limits are exceeded, the system should fail closed and avoid reasoning its way around constraints.

Fail-closed behavior should be deterministic:

• Stop all new tool calls.
• Record an append-only stop event with a reason code.
• Persist the execution manifest, logs, and diff snapshot.
• Revert to the last safe checkpoint or quarantine the workspace.
• Require explicit human re-authorization before any resume action.

Operating System–Enforced Sandbox Isolation on macOS

Prompt restrictions are advisory controls. Autonomous execution requires enforceable containment at the operating system boundary, where permissions, process identity, and mount policy determine what an agent can and cannot do.

The author uses macOS as the reference platform in this section because it provides a strong security baseline, mature process-isolation primitives, and practical support for mount-based containment, which is needed for autonomous-agent workloads.

Why macOS Is Suitable for This Model

macOS provides practical primitives for this containment architecture:

• A strong Unix permission model for deterministic access control.
• First-class disk image support for mount-based writable isolation.
• User-level isolation for dedicated execution identities.
• Full-disk encryption support for protected data at rest.
• Large unified memory and Metal acceleration for local LLM workloads.
• Mature BSD-derived process and sandboxing architecture.

Dedicated Execution Identity

Agent workloads should run under a separate, non-administrative macOS user account dedicated to automation.

This account should have no sudo privileges and no access to sensitive user directories, credential stores, or administrative control paths.

All agent subprocesses inherit this identity. As a result, every child process inherits the same permission limits, producing deterministic containment across the execution tree.

Isolated Filesystem Boundary

A dedicated APFS disk image mounted as a sandbox volume provides a clean writable boundary for autonomous runs.

A mounted volume is preferable to a normal directory because mount lifecycle, ownership, and access controls are explicit and independently managed from the host filesystem hierarchy.

The sandbox volume should be the only writable location available to the agent runtime. Read access outside this boundary should be narrowly scoped and policy-defined.

Detaching the volume serves as an immediate kill switch for agent writes and constrains further state mutation.

Group-Based Access Control

A dedicated operating system group should define which users and services are allowed to access the sandbox volume.

Access is enforced by Unix permissions and ACL policies, not by model instructions.

Without explicit operating system reconfiguration, agent processes cannot expand their filesystem scope beyond the mounted boundary.

Execution Surface Minimization

Autonomous runtimes should expose whitelisted command wrappers rather than unrestricted shell execution.

Execution rights should be narrowly scoped to predefined scripts and approved operational interfaces.

Privilege is granted through filesystem and process policy, not by prompt language. This reduces ambiguity and prevents instruction-level bypass attempts.

Optional Network and Resource Controls

Outbound network access should be explicitly allowed where required and denied by default elsewhere.

Additional containment layers should define CPU, memory, and runtime ceilings for agent workloads to limit runaway execution and protect host stability.

These controls complement filesystem isolation and provide bounded behavior under failure conditions.

Architectural Conclusion

Operating system enforcement transforms agent control from instruction-based guidance to policy-enforced boundaries.

Autonomous execution should be constrained first by operating system primitives, then by higher-level controls such as Functional Requirements, unit tests, work planning, and security review.

Economic Controls

Agentic systems introduce a new class of financial risk: algorithmic spending.

A poorly bound reasoning loop can consume thousands of dollars in API usage without producing meaningful output. In practice:

• All external API calls should flow through a single gateway.
• Per-request cost estimation should occur before execution.
• Monthly budget caps should be enforced programmatically.
• Context size should be minimized by design.
• Static content should be cached to avoid repeated transmission.
• Real-time spend should be tracked during execution, not only at job end.

Economic policy is most reliable when implemented in code, not only documented in guidelines.

Practical budget policy for multi-day runs:

• Warning threshold: 70% of the allocated budget.
• Escalation threshold at 90%, requiring explicit approval to continue.
• Hard stop at 100% with automatic job termination.
• Optional degrade-to-local mode only if FR acceptance criteria still remain achievable.

Observability and Auditability

Autonomous behavior should be fully inspectable.

Every run should produce a structured execution manifest including:

• Agent identity
• FR identifiers
• WORK_PLAN hash
• Start and end timestamps
• Files read
• Files written
• Diff summary
• External calls made
• Token usage
• Cumulative cost versus budget
• Per-iteration progress score
• Exit condition
• Stop reason code, if terminated

Logs should be append-only. Overwriting history should be avoided.

Security teams should be able to reconstruct any run without relying on agent self-description.

In addition, anomaly detection rules should be implemented:

• Unexpected file type modifications.
• Large diffs beyond defined thresholds.
• New dependencies introduced.
• Changes to security-critical directories.
• Repeated iteration without state improvement.

Reversibility and Recovery

Agent actions should be reversible where feasible.

Modifications should occur in:

• Version-controlled repositories, or
• Disposable sandbox volumes.

Rollback should be achievable with a single command or mount discard. If recovery requires manual reconstruction, the system is usually not production-ready.

Periodic snapshotting of working directories provides an additional safety net.

WORK_PLAN.json as the Execution Contract

Before modifying code, agents should declare intent in a structured format using `WORK_PLAN.json`.

A `WORK_PLAN.json` document should include:

• Unique plan identifier.
• Referenced FR identifiers.
• Declared target files.
• Expected changes.
• Risk classification.
• Test coverage requirements.
• Iteration and no-progress limits.
• Budget limits and stop thresholds.
• Git branch and promotion policy.
• Security gate policy.
• Mandatory stop conditions.

Subsequent diffs can be compared against declared intent. If actual modifications exceed the declared scope, execution is halted.

This creates a contract between intention and effect.

Development and Staging Git Policy

Long-running autonomous work is safer when isolated from production branches.

Recommended policy:

• Agents can write only to ephemeral `agent` branches.
• Direct commits to protected branches should be avoided.
• Merge from `agent` to `develop` requires green tests and green security gates.
• Merging from `develop` to `staging` requires policy validation and budget-compliance artifacts.
• Promotion from `staging` to `main` requires explicit human approval or a pre-approved policy gate.
• Every commit message should include `plan_id` and the iteration number for auditability.
• Force-push is disallowed on protected branches.

Human-in-the-Loop at the Right Boundary

Full manual review of every command does not scale. However, a single approval gate at the transition from staging to production is defensible.

Recommended pattern:

• Agents operate in staging.
• Security and test gates run automatically.
• Promotion requires explicit human approval, or policy-based automated approval only for pre-scoped low-risk changes with zero critical findings and a full test pass.

This balances velocity and accountability.

Testing Beyond Functionality

Unit tests validate correctness. They do not validate containment.

Minimum unit-test requirements for autonomous execution:

• The existing unit test suite should pass before any run starts.
• Changed production files should have corresponding unit tests in the same run.
• Coverage on changed files should meet the threshold declared in `WORK_PLAN.json`.
• Global test coverage regression beyond declared tolerance triggers an automatic stop.
• New FR acceptance criteria should map to executable test cases.

No-progress detection should be test-driven:

• An iteration counts as progress only when it reduces failing tests, satisfies new acceptance tests, or improves declared quality metrics.
• If no measurable progress is made for `X` consecutive iterations, the run should terminate automatically.
• `X` should be declared before the run starts in `WORK_PLAN.json`; it should not be changed mid-run without explicit approval.

Additional test categories are required:

Security tests

• Path traversal attempts.
• Unauthorized write attempts.
• Network access attempts.
• Secret exfiltration simulation.

Economic tests

• Simulated high-cost prompt loops.
• Budget overflow scenarios.

Behavioral tests

• Iteration cap enforcement.
• Proper abort on missing success criteria.

Testing should intentionally attempt to break the system.

Security Review and Mandatory Stop Conditions

The security review should be independent of the code-generation role.

Required controls:

• Static analysis and dependency vulnerability scanning on every run.
• Secret scanning before any push or pull request creation.
• Policy checks for unauthorized paths, network calls, and command usage.
• Security review output stored as an append-only artifact linked to `plan_id`.

Recommended stop conditions for strict deployments:

• Any critical or high-severity security violation.
• Any confirmed secret exposure.
• Any unauthorized access to a filesystem or network.
• Any budget limit breach.
• Any no-progress limit breach.

On stop, the system should terminate execution, record the reason, and require human approval before restarting.

Standardized stop reason codes improve auditability:

• `STOP_SECURITY_VIOLATION`
• `STOP_SECRET_EXPOSURE`
• `STOP_UNAUTHORIZED_ACCESS`
• `STOP_BUDGET_EXCEEDED`
• `STOP_NO_PROGRESS`
• `STOP_RUNTIME_EXCEEDED`

The Role of the Software Engineer in an Agentic Development Landscape

In an agentic development landscape, software engineers remain the accountable technical authority for system intent, control design, and production impact.

Software engineers in this landscape are:

• Idea generators
• Architects
• Technical requirements creators
• Novel algorithm designers
• Unit test designers (not coders)
• Code functionality assessors

Idea Generator

Engineers define the problem space, scope, constraints, and non-goals.

Agents execute within defined intent; engineers are responsible for the clarity and correctness of that intent.

Poorly framed problems produce well-executed but misaligned outcomes.

Architect

Engineers design system boundaries, trust zones, and promotion gates.

They define how autonomy is partitioned, isolated, and governed.

Architecture is the primary mechanism for safe autonomy.

Technical Requirements Creator

Engineers translate objectives into explicit Functional Requirements with measurable acceptance criteria.

They define runtime ceilings, budget ceilings, security constraints, and mandatory stop conditions.

Agents should not operate on vague goals; engineers are accountable for formalizing execution contracts.

Novel Algorithm Designer

Engineers remain responsible for designing new algorithms, strategies, and system-level innovations.

Agents may implement known patterns efficiently, but conceptual and strategic breakthroughs remain a human engineering responsibility.

Architectural trade-offs and long-term system evolution remain under engineering ownership.

Unit Test Designer (Not Coder)

Engineers design the tests that encode correctness and safety.

They define coverage expectations, regression safeguards, and no-progress detection metrics.

Tests serve as control instruments for autonomous execution, not merely validation tools.

Engineers are responsible for the integrity and completeness of test design.

Code Functionality Assessor

Engineers evaluate whether the generated code satisfies intent beyond superficial test success.

They assess edge cases, performance characteristics, maintainability, architectural consistency, and security implications.

Final promotion decisions should remain grounded in human judgment and technical expertise.

Autonomous agents execute within constraints. Software engineers design the constraints. Responsibility for system behavior, safety, and production impact remains with human engineers.

Governance and Organizational Implications

Corporate leadership should recognize that deploying autonomous coding agents is a governance decision, not only a tooling decision.

Key considerations:

• Who owns agent configuration?
• Who defines privilege scopes?
• Who monitors cost and behavior?
• What is the incident response plan for agent-induced failures?
• Are there audit requirements for regulated environments?

Agent infrastructure should be reviewed with the same rigor as CI/CD pipelines and production deployment systems.

Conclusion

Autonomous agents can materially improve developer productivity and system maintenance. However, their deployment is most effective when engineered with explicit constraints.

The appropriate mental model is not "advanced autocomplete." It is "a distributed automated contributor with privileged access."

Safe deployment requires:

• Least privilege enforcement.
• Separation of duties.
• Deterministic guardrails.
• Functional requirements as executable contracts.
• Economic caps.
• Full observability.
• Reversible changes.
• Structured `WORK_PLAN.json` declarations.
• Test-driven progress gates.
• Independent security review.
• Enforced the git promotion policy.
• A defined human approval boundary.

Autonomy is not inherently unsafe. Unbounded autonomy is.

Organizations that treat agent systems as first-class operational actors, subject to the same architectural discipline as production services, will capture their benefits while containing their risks.

Maturity Levels

A practical adoption path avoids false binary choices between "no agents" and "full autonomy."

• Level 0: Prompt-only experimentation.
• Level 1: Staging-only agent writes.
• Level 2: Gated verification and budget controls.
• Level 3: Long-running autonomous programs with enforced FR contracts.

Measuring movement with computer vision

Today, I was measuring my movement using computer vision. 

Because of my interests, the numbers show Karate kata, which I need to improve.

Technique	Speed (ms)	Performance Score (%)
Morote-uke Gedan-barai (migi)	410	68
Chudan-tsuki (migi)	330	76
Yoko-tsuki (migi)	290	82
Morote-uke Gedan-barai (hidari)	395	70
Chudan-tsuki (hidari)	320	78
Yoko-tsuki (hidari)	285	84

At a basic level, video is a time-stamped measurement tool. Every frame is a discrete snapshot of body position at a known interval. At 60 frames per second, each frame represents about 16.7 milliseconds. That is already within the range where clinically meaningful differences in reaction time, initiation latency, acceleration, and braking can be observed.

What this allows, even from a simple smartphone recording, is segmentation of movement into phases. We can identify true stillness, first detectable motion, peak velocity, end position, and recovery. By counting frames between these events, we can estimate timing for each phase with reasonable accuracy, typically within ±15–20 ms at 60 fps. This is sufficient to distinguish preparation from initiation, early acceleration from late acceleration, and controlled stopping from overshoot.

From a biomechanical perspective, the most valuable measurements are not raw speed, but timing relationships. For example, which segment initiates first, the pelvis, trunk, shoulder, or distal limb? Even without full 3D motion capture, relative timing can be inferred by observing when each segment begins to move from frame to frame. Small delays of 30–50 ms are visible and repeatable when the video is consistent.

Acceleration profiles can also be approximated. By tracking the displacement of a joint or endpoint frame by frame, we can derive velocity curves and infer acceleration patterns. While this is not laboratory-grade kinetics, it is enough to distinguish relaxed, late-accelerating motion from tense, early-loaded motion. This is a key in my Karate kata training. In practice, this distinction often correlates strongly with efficiency, injury risk, and motor control quality.

Another important capability is repeatability analysis. By comparing multiple executions of the same movement, video analysis can reveal whether a motor pattern is stable or variable. As motor control improves, trajectories become more consistent even as speed increases. This is something clinicians often feel intuitively when watching patients, but video allows it to be tracked objectively over time.

It is also possible to infer aspects of neuromuscular tension indirectly. Excessive co-contraction often manifests as hesitation before movement, uneven velocity curves, micro-stutters, or prolonged deceleration. Relaxed, efficient movement tends to look sudden, clean, and symmetrical. While video cannot directly measure muscle activation, these kinematic signatures are surprisingly reliable when compared across sessions.

There are, of course, limits. Video cannot directly measure force, joint moments, or muscle activation. Depth perception is limited without stereo or depth cameras. Absolute joint angles are less reliable than relative timing unless the camera setup is carefully controlled. But for timing, sequencing, coordination, and motor learning, standard video is far more powerful than most people assume.

In short, video analysis sits in a useful middle ground. It is not a replacement for EMG, force plates, or optical motion capture, but it is far more than subjective observation. When used consistently, it becomes a practical tool for studying motor control, rehabilitation progress, and skill refinement, especially when the goal is improving timing, coordination, and efficiency rather than raw strength.

If your interest comes from physiotherapy, this approach aligns well with modern motor learning principles. It supports external observation, objective feedback, and gradual refinement without overloading the patient or practitioner with complex instrumentation.

I hope this gives you a clear picture of what can be done, and why it is both technically sound and clinically relevant.

My next step is to convert it to true 3D perception.

Multi-agents software development

A multi-agent foundation LLM is built for parallel, role-separated work on complex problems. It assumes that meaningful software development is not linear. Architecture, implementation, testing, refactoring, validation, and documentation are distinct cognitive tasks that benefit from concurrent execution. In this model, multiple specialized agents operate at the same time within a shared project state. Each agent has a defined role, constraints, and success criteria. One agent may reason purely about system architecture and invariants; another may implement code within a restricted scope; a third may generate or run tests; while a fourth evaluates performance, safety, or maintainability.

The defining feature is not chat conversation, but coordination. Agents exchange concrete artifacts such as diffs, test results, failure reports, and design notes. Progress is driven by state changes in the codebase rather than by turn-by-turn chat dialogue. Work can continue asynchronously until stopping conditions are met, for example, passing tests or satisfying performance thresholds. The human orchestrator acts more like an architect and technical lead, resolving ambiguities, arbitrating disagreements, and deciding when outputs are ready to merge.

A chat-agent foundation LLM, by contrast, is optimized for interactive reasoning with a single dominant thread of control. This is the familiar chat conversational model embedded in IDEs and chat interfaces. It excels at local transformations, explanation, debugging, and short-horizon planning. Context is ephemeral and largely conversational. The agent responds to prompts, proposes changes, and waits for feedback. There is no native concept of parallel roles, persistent task ownership, or long-running autonomous execution. Architectural coherence, testing strategy, and long-term state management remain primarily the responsibility of the human.

When you know what you want to change and need help expressing or validating it quickly, the chat-agent foundation LLM is the fastest tool. Its limitation is scale. As projects grow, the cognitive load of maintaining architecture, tests, and constraints in a single conversational stream increases, and progress becomes serial.

A local-agent medium LLM, in the 7B~32B class, occupies a different position entirely. It is constrained by model capacity but empowered by locality and control. These agents are best used as embedded workers inside well-defined pipelines. They are particularly effective when given narrow responsibilities such as refactoring a module, enforcing style rules, extracting structure from text, or performing deterministic transformations. Because they run locally, they can be integrated deeply into tooling, scheduled jobs, and automated workflows without latency or privacy concerns.

However, local agents rely heavily on external structure. They do not substitute for system-level reasoning across a large codebase. Instead, they amplify it when paired with strong orchestration, clear prompts, and explicit constraints. In practice, they function best as components within a broader multi-agent system rather than as standalone decision-makers.

Seen together, these three modes form a hierarchy. The chat-agent foundation LLM accelerates individual thought. The local-agent medium LLM reliably and repeatedly executes bounded work. The multi-agent foundation LLM coordinates execution across time, roles, and abstractions. 

If you want me to explain how I implement each one, leave a comment.

Goat

 https://youtube.com/shorts/Ax_u6imutGs?si=puxxyEk6pzpvngna

NVFP4

Keep the original full-precision model frozen as a teacher, then train the quantized NVFP4 model as a student to match the teacher’s output distributions using KL-divergence, rather than retraining the entire model with task losses.

Distillation from the teacher model is the key point.

Tamashii

Tamashii 魂 is usually translated as “soul,” but in Japanese practice it is less about an inner, metaphysical essence and more about a way of being present in action. When people speak of doing something “with tamashii,” they are not talking about emotion or passion alone. They are pointing to a form of moral and technical alignment, where intention, effort, and execution are inseparable.

In the context of doing things right, tamashii refers to the seriousness with which a task is taken, regardless of scale or audience. It is the refusal to treat any action as trivial. Whether polishing a floor, writing a line of code, forging a blade, or serving tea, the act is approached as complete in itself. Nothing is deferred to later. There is no shortcut justified by invisibility. The work carries the worker’s name, even if no one ever sees it.

This is why tamashii is often discussed alongside craft rather than belief. A sword with tamashii is not one imbued with mysticism, but one made without compromise. The smith did not rush cooling, did not accept a minor flaw, did not say “good enough.” Over time, this attitude becomes visible in the object. The result feels right, balanced, trustworthy. That feeling is not magic. It is accumulated care.

Tamashii also implies accountability beyond rules. Rules can be followed mechanically. Tamashii requires judgment. It asks, “Is this correct?” not “Is this permitted?” In Japanese workplaces and dojos, this distinction matters. Someone may technically meet requirements yet still be told their work lacks tamashii. What is missing is sincerity of effort, awareness of impact, or respect for the lineage of the task itself.

There is a quiet ethical dimension here. To act with tamashii is to acknowledge that actions shape the self. You are not only producing an outcome, you are becoming the kind of person who does things a certain way. Cutting corners is not just a practical decision, it is a formative one. Over time, habits harden. Tamashii resists that erosion by insisting on care even when tired, unseen, or under pressure.

In martial arts, this shows up as consistency rather than intensity. A strike done with tamashii is not the hardest strike, but the most correct one, aligned body, breath, timing, and intent. Power emerges as a byproduct of correctness. The same principle applies outside the dojo. When the process is right, results follow naturally. When the process is compromised, results become fragile.

Importantly, tamashii is not perfectionism. Perfectionism is anxious and self-referential. Tamashii is calm. It accepts human limitation but refuses indifference. Mistakes can happen, but care must be evident. The difference is felt immediately by others, especially those trained in the same discipline.

In modern contexts, tamashii often survives quietly. It appears in engineers who document systems for the next person, writers who revise for clarity rather than praise, parents who keep small promises, even when inconvenient. These acts are rarely celebrated, but they build trust. Over time, people learn who can be relied on. That reputation is not built on claims, but on repeated, unglamorous correctness.

So when tamashii is invoked in relation to doing things right, it is not a poetic flourish. It is a practical standard. Do the thing fully. Respect the work. Leave no residue of laziness or excuse. Let the quality of attention be visible in the result. That is tamashii in action, not as an abstract soul, but as a lived discipline.