Sec 10 / domain / 01 / 06

AI Programming.

AI-assisted software development is not only about making code faster to write. It is about keeping the meaning of a system visible while humans and LLM agents change it: requirements, design decisions, manifests, tests, traces, and validation records need to stay connected as the code evolves.

On this site, this domain asks how software intent can be represented in a form that is inspectable, traceable, and mechanically checkable where possible — without pretending that tools can replace human design judgment.

Yoav Fekete works on this domain / primary system: Clause / focus: design-intent preservation.

AI-assisted software development mark A small constraint diagram: an INTENT box connects to a PROGRAM box through a trace. INTENT visible PROGRAM checked TRACE
FIG / domain mark
KindDomain
Flagship systemClause
Primary concernDesign intent
Adjacent domainsSemantic AI Search / Geometric Reasoning

Sec 10.1 / definition

What the route means on this site, in one block.
AI-assisted software development
noun / domain / software practice

The practice of designing software systems, artifacts, and workflows so humans and LLM agents can work on code without losing design intent, traceability, reviewability, or validation discipline. Code matters, but code is not enough: requirements, design decisions, manifests, tests, traces, validation records, and review records are part of the system's meaning.

On this site
Route
/ai-programming/
Real domain
AI-assisted software development
Flagship system
Clause
Author
Yoav Fekete

Sec 10.2 / why it matters

Faster code editing needs stronger artifact discipline.

LLMs increase editing speed.

LLM tools can help write, modify, and explain code quickly. That speed is useful, but it does not automatically preserve architectural memory or review attention.

The risk is design drift.

The problem is not only bugs. A codebase can still run while requirements blur, design decisions disappear, tests stop matching intent, and future edits lose the thread.

Serious systems need connected artifacts.

Requirements, designs, manifests, tests, validation records, and implementation traces help humans and agents inspect whether a change still belongs to the system being built.

Sec 10.3 / approach

Give intent a durable form, then check what can be checked.

Yoav’s approach is to treat software intent as something that needs a durable form. A serious codebase is not only code; it is also requirements, design decisions, manifests, traces, tests, validation records, and the reasoning that connects them. When those links are left only in chat history, memory, or scattered comments, they are easy for both humans and agents to lose.

The goal is to make the important commitments explicit enough to inspect. Some things can be checked mechanically: unresolved references, missing traces, naming conflicts, manifest gaps, test coverage gaps, and broken validation records. Other things still require judgment: architecture, tradeoffs, scope, adequacy, and whether the represented intent is the right intent.

Clause is the main system growing from this domain. It is experimental: an artifact discipline for AI-assisted software development, not a production-ready platform and not a claim that agents already generate verified code from Clause artifacts.

Stance
  • Represent intent explicitly.
  • Connect decisions to implementation.
  • Check mechanically where possible.
  • Keep validation reviewable.

Sec 10.4 / related system

The system and concept frame behind this domain.

Clause / framework

Clause is an experimental, repo-native artifact discipline for AI-assisted software development. It keeps design intent intact under LLM-assisted editing by connecting requirements docs, design docs, manifests, code, tests, and validation records through mechanically checked references.

SYSTEMview

Artifact discipline

The surrounding discipline that makes LLM-assisted work reviewable: visible intent, connected artifacts, deterministic checks where possible, and explicit records of what has and has not been validated.

CONCEPTUAL FRAME

Sec 10.5 / Working vocabulary

Artifact discipline Design intent Mechanically checked references Manifest-driven implementation Design coverage Generate-check-repair loop

Sec 10.6 / Questions this domain opens

What does AI-assisted software need beyond faster code generation?

A practical account of why chat, diffs, and tests are not enough when LLM-assisted edits accelerate through a codebase.

How can design intent survive repeated LLM-assisted edits?

Why the hard part of AI-assisted software is keeping requirements, architecture, and validation connected after the first edit.

What should be mechanically checked, and what still requires judgment?

How repo-native artifacts can preserve traceability from a requirement to a design decision, implementation trace, test, and validation record.