vibecodiq

Posted on Dec 5 • Originally published at vibecodiq.com

Stop Letting AI Delete Your Code: Deterministic Regeneration with ASA v1.0

#ai #programming #architecture #vibecoding

AI coding tools are great at one thing: rewriting lots of code very fast.

That’s also exactly how they break your system.

If you’ve ever:

Asked an AI to “update this schema” and lost a hand‑written edge case
Let a tool “clean up this service” and watched a subtle validation vanish
Tried to regenerate a scaffolded module and ended up diffing walls of code

…then this post is for you.

In this guide, we’ll look at how ASA v1.0 lets you regenerate Python slices safely – preserving your business logic byte‑for‑byte while still letting AI help with the boring parts.

The Pain: Regeneration Fear

A typical AI‑assisted workflow today:

Use your favourite tool (Cursor, Copilot, etc.) to scaffold a FastAPI endpoint.
Add some custom behaviour on top – edge cases, extra validation, domain rules.
A week later, requirements change. You need a new field or different error semantics.
You ask AI to “regenerate the handler and service to match the new schema”.

What comes back is a brand‑new version of the file.

It may be cleaner. It may even pass tests. But it almost certainly:

Rewrote parts of your manually added logic
Changed error types or messages
Modified behaviour in ways the AI can’t explain

After this happens once or twice, you learn a new instinct:

“Never regenerate a file you’ve touched.”

Congratulations – your “AI‑generated” scaffolding just became zombie code.

ASA’s View: Separate Intent from Implementation

Agentic‑Sliced Architecture (ASA) starts from a different assumption:

Specs should be regenerated. Business logic should not.

So it separates your flow into three layers:

Spec (slice.spec.md) – a human‑readable Markdown description of a feature: purpose, inputs, outputs, behaviour, errors, side‑effects, dependencies.
Contract (slice.contract.json) – a strict, machine‑readable JSON version of that spec.
Generated code skeleton – FastAPI router + service + repository + schemas + tests.

The important bit: all of this lives inside a Slice – a vertical feature unit like domains/auth/login/ instead of being scattered across folders.

You create it with:

asa create-slice auth/login

Then you fill in domains/auth/login/slice.spec.md with your feature description.

From Spec to Code: The Deterministic Pipeline

Once your spec is ready, ASA v1.0 runs a deterministic pipeline:

asa generate-contract auth/login
asa generate-skeleton auth/login

Behind the scenes, this does:

Parse the Markdown spec
Emit a JSON contract with inputs/outputs/behaviour/errors/side‑effects
Generate Python modules that match that contract

The generated folder looks like this:

domains/auth/login/
├── slice.spec.md
├── slice.contract.json
├── handler.py
├── service.py
├── repository.py
├── schemas.py
└── tests/
    └── test_slice.py

Given the same spec, you’ll always get the same contract and skeleton files. No randomness, no “almost the same but slightly different” diffs.

So where does your custom logic live?

Markers: Where Your Logic Lives (and Survives)

ASA reserves explicit regions in generated files for your implementation.

For example, in service.py you’ll see:

from .repository import LoginRepository
from .schemas import LoginRequest, LoginResponse

class LoginService:
    def __init__(self) -> None:
        self.repo = LoginRepository()

    # === BEGIN USER CODE ===
    def execute(self, request: LoginRequest) -> LoginResponse:
        # Your implementation here
        user = self.repo.get_user_by_email(request.email)
        if not user:
            raise ValueError("USER_NOT_FOUND")

        if not self.repo.verify_password(user, request.password):
            raise ValueError("INVALID_CREDENTIALS")

        token = generate_jwt(user.id)
        return LoginResponse(jwt_token=token, expires_in=3600)
    # === END USER CODE ===

Everything between BEGIN USER CODE and END USER CODE is your territory.

You can:

Hand‑write it
Ask an AI assistant to generate it
Refine it over time

ASA will never overwrite this region during regeneration.

The Magic Trick: Regenerate Without Losing Logic

Now imagine you extend the feature:

Add ip_address: string to the inputs
Log login attempts for security
Maybe enrich the response with an extra field

You update slice.spec.md to reflect the new behaviour, then run:

asa generate-contract auth/login
asa regenerate-slice auth/login

Here’s what happens:

ASA re‑parses slice.spec.md and updates slice.contract.json.
It regenerates the skeleton files (schemas, handler signatures, test stubs, etc.).
For files that contain user markers, it extracts your code, regenerates the structure, and injects your code back into the new version.

Your execute() implementation is preserved exactly, but now:

The LoginRequest model includes ip_address
The handler signature matches the new contract
Tests and scaffolding are up to date

You’ve just updated your feature end‑to‑end without manually touching any glue code – and without losing a single line of business logic.

Keeping Architecture Clean: Linting Boundaries

Overwriting logic is one problem. Eroding architecture is another.

When AI tries to “help”, it often reaches for the nearest import that makes the code compile, even if it breaks your domain boundaries.

ASA ships with a linter that understands Slices and performs AST‑based checks:

asa lint auth/login

It verifies that:

All required files exist and contracts are valid
Slice structure is consistent
Imports don’t cross domains in illegal ways

If a repository in auth/login tries to import something like domains.billing.invoice, the linter fails and tells you exactly where the violation happened.

This makes it much harder for “just make it work” AI changes to quietly turn your codebase into spaghetti.

Using ASA with AI in Practice

ASA v1.0 is a Python CLI, not a black‑box SaaS.

You can plug it into whatever workflow you already have:

Use an LLM to generate specs (slice.spec.md) from product requirements.
Let ASA turn those specs into contracts and skeletons.
Use AI again to help implement the logic inside marker regions.
Regenerate safely whenever the spec changes.
Run asa lint in CI to enforce boundaries before merge.

The more agents and tools you add, the more you’ll appreciate that spec → contract → code is deterministic and repeatable.

When to Reach for ASA

You probably don’t need ASA for throwaway prototypes.

You almost certainly need it if:

You are building a long‑lived product with an AI‑heavy dev loop
Multiple agents or tools will touch the same backend
You’re already afraid to regenerate code you generated a month ago
You care about domain boundaries and want them enforced, not just drawn on a diagram

In that world, “just trust the AI” is not a strategy.

You want an architecture that:

Treats specs as the source of truth
Makes regeneration safe by design
Protects business logic with explicit markers
Guards your boundaries with a linter

That’s what ASA v1.0 is designed to do.

If you want to see it in action, check out the regeneration demo https://vibecodiq.com/demo/ and docs on the ASA starter kit repo https://github.com/vibecodiq/asa-starter-kit.

DEV Community