My Personal AI-Driven Development

I use Emacs not only as an editor but also as a kind of IDE, similar to a programmer’s workbench. In addition to editing files, it handles multiple consoles, file operations, and Git workflows.

For features that Emacs does not provide, or provides in an inconvenient way, I rely on external tools.

I use IntelliJ IDEA as a debugger, and VS Code for AI integration.

OpenAI was integrated into VS Code’s Codex feature around late October 2025, and this dramatically improved the efficiency of AI-driven development.

Before that, I used Chappie-kun only as a supporting tool, but the combination of Chappie-kun and Ko-chan made a truly AI-first development style viable.

Another welcome aspect is that the Plus subscription keeps costs relatively low.

The programming language used is Scala 3, with functional programming introduced via Cats.

ScalaTest is used as the testing framework.

In the SIE project, the amount of code I write by hand has decreased significantly.

However, both Chappie-kun and Ko-chan often struggle with the true core of the system and the architectural keystones.

The most stable division of roles is for humans to design the architectural baseline and structural backbone, while delegating the implementation built on top of it to AI.

The following documents are created.

Because documentation is shared knowledge between humans and AI, it is written primarily in English.

Chappie-kun appears to think internally in English, so writing only in Japanese tends to introduce translation costs and semantic drift.

In addition to notation variants such as “control flow,” “control-flow,” and their Japanese equivalents, translation drift—where “quality attribute” becomes “quality characteristic,” “quality attribute,” or “quality requirement,” and both “safety” and “security” are rendered as the same Japanese term—introduces ambiguity; writing in English avoids this and yields higher precision.

This is not merely a matter of translation preference, but an inevitability rooted in the internal structure of LLMs.

Large language models learn relationships among terms as a high-dimensional vector space based on vast, primarily English corpora.

Within this space, terms such as “quality attribute,” “safety,” “security,” and “reliability” occupy distinct positions with specific semantic distances.

When translated into Japanese, multiple English terms may be collapsed into a single word, or a single English term may be split into different Japanese expressions depending on context, flattening meaning vectors that were originally distinct.

As a result, the LLM must rely more heavily on contextual inference to determine which concept is intended, reducing the stability of reasoning and code generation.

Writing in English is the lowest-cost and most effective way to stabilize the semantic space for LLMs, preserving correct distances between concepts while enabling reliable reasoning and generation.

In SimpleModeling, we emphasize that an Executable Specification is a verifiable specification.

It is a test program written in a BDD style,

thus combining these characteristics in a single artifact.

By executing the Executable Specification, you can mechanically confirm that the system behaves according to the specification. It is also critically important as a regression test.

Specification exploration is carried out together with Chappie-kun. However, due to limitations in handling multiple files simultaneously, fact-finding and cross-cutting checks are delegated to Ko-chan.

Chappie-kun consolidates the specification proposal, a human performs a light review, and if nothing feels off, the work proceeds to implementation.

Coding is basically delegated to AI. When it works well, it can produce code that is usable as-is.

However, failures do occur, so it is important to build in small increments and evaluate frequently.

As coding progresses and feedback cycles repeat, the specifications gradually solidify. These specifications are then documented.

Because Chappie-kun often forgets specifications when sessions change, or relies on vague and uncertain memories, it is important to document specifications frequently.

By leaving well-structured documentation at this stage, the amount of information AI can leverage for design and coding increases, enabling more accurate work.

Although creating documentation is a demanding task, it is one of AI’s strengths, and delegating it to AI often requires surprisingly little effort.

The specifications consolidated here are not documented verbatim; instead, they are selectively reflected into multiple existing documents where appropriate. New documents are created only when the specifications are better documented as standalone artifacts.

Executable Specifications can be created either in parallel with coding and documentation, or after the specifications have stabilized. In other words, you create test programs that verify the specifications.

By writing test programs, you can detect gaps or excesses in the specifications. They also allow you to confirm that the program behaves exactly as specified.

Because there is always a risk that AI may inadvertently break the program, it is extremely important to continuously verify via regression tests that the program maintains its intended behavior. At the same time, it is also important to use Git to ensure that the system can be restored even if something is broken.

Specifications that are nurtured through conversations with Chappie-kun and refined through coding and Executable Specifications are accumulated not only in programs but also formalized as documentation.

By accumulating documentation and Executable Specifications, a knowledge base that AI can reference gradually grows.

When you ask Chappie-kun to program, it chooses what it considers the most efficient approach within the given constraints. If no constraints are provided, it often freely modifies or even breaks stable code without distinguishing it from code still under development.

Conversely, if you precisely specify which parts must not be changed and what considerations must be taken into account during modification, it tends to follow those instructions closely and produce more satisfactory results.

For this reason, I believe that a key point of AI-driven development lies in how well documentation is prepared to impose effective constraints on coding.

However, since it is impossible to pack all information into a single prompt, it is important to create purpose-specific documents and organize them so that AI can easily make use of them.

These are articles about developing tools that leverage knowledge graph–based knowledge representation for modeling. After realizing the importance of connecting knowledge graphs to generative AI around mid-November, I consolidated the results of subsequent research and development.

If you are interested in my personal AI-driven development approach, the document structures of the following GitHub projects may serve as useful references.