AI-Assisted Development

Livt is designed to be used side by side with AI coding agents. The Livt extension provides a project-aware agent with explicit file access, while other coding agents can use the same validation, build, test, package, and vendor workflows as a developer.

This page describes the practical workflows: using Agent Context, reusing official packages, migrating existing code, and reviewing AI-assisted results before they become dependencies.

Working Side by Side With Agents

A good Livt agent workflow is collaborative. The developer describes intent, chooses boundaries, reviews the plan, and decides when the result is ready. The agent handles the mechanical work of creating files, running commands, reading diagnostics, and applying corrections.

A typical loop is:

Describe intent -> load context -> review plan -> implement -> validate/build/test -> review -> publish

For repository-based work, ask the agent to use the same commands a developer would use:

livt validate
livt build
livt test

This keeps the feedback loop concrete. The result is not accepted because the agent produced code; it is accepted because the package has the right structure, the source is reviewable, and the tests pass.

Using Existing Coding Agents

Livt can be used with common coding agents and editor assistants, including GitHub Copilot, Claude Code, Codex, and other tools that can inspect a repository and edit files. These tools are most useful when they receive clear project context and a specific task.

A practical request should name the package or component goal, expected public API, packages to reuse, and test cases. For example:

Use the Livt agent context.
Add a component that receives bytes from Uart, parses a simple command,
and exposes the command as a public field.
Reuse Livt.IO where possible.
Create tests for reset, one valid command, and an incomplete command.
Run livt validate and livt test after implementation.

Keep the task small enough to review. When the agent proposes a plan, check the component boundaries, package dependencies, and tests before letting it generate or modify many files.

Livt Agent Context

Livt Agent can inspect and change only project paths authorized through Agent Context. Add the complete project, Sources, Tests, Project Files, a directory, or an individual file from the Livt Project view.

An authorized directory covers existing descendants and lets an approved edit create files within that scope. If a task needs a manifest, constraint, README, or another project file, authorize it as deliberately as Livt source.

For a broad task, ask for a plan first. The agent should create or change the smallest coherent file set, validate syntax, write valid progress into the project, run focused checks, repair project files with focused edits, and finish with the relevant test suite.

Fine-Tuned Livt Models

Eccelerators also provides Livt-specialized models for teams that want a more controlled and focused agent setup. These models can be integrated into usual agent tools and VS Code workflows.

Fine-tuned Livt models are useful when a team wants:

• Livt-specific behavior without repeatedly sending a very large context
• lower token usage and lower operating cost
• deployment in European data centers
• on-premise deployment for customer environments with stricter data policies
• a model setup that is aligned with the team's Livt package and review workflow

Large general-purpose models still work well with Livt. Fine-tuned models are an additional option when cost, data residency, latency, or specialization matters.

Reuse Before Rewriting

A good agent should prefer existing Livt packages before writing new infrastructure. This matters because reusable packages carry documented APIs, tests, and known behavior.

When a task touches I/O, networking, math, crypto, or application-level building blocks, ask the agent to inspect and reuse official packages first:

• Livt.IO for UART, RAM, I2C, and peripheral-style components
• Livt.Net for Ethernet, ARP, IPv4, ICMP, TCP, HTTP, and endpoint helpers
• Livt.Math for fixed-point, complex arithmetic, lookup tables, MAC helpers, and pseudo-random generators
• Livt.Crypto for AES, SHA, HMAC, HKDF, CMAC, ChaCha20, Poly1305, AEAD, and deterministic random primitives

For example, an application like a web-connected FPGA component should compose from packages such as Livt.Net and Livt.IO instead of asking the agent to create a network stack or UART implementation from scratch.

Migration Workflows

AI-assisted migration works best when the source is treated as reference behavior, not as a file to translate line by line. For C, HLS, HDL, or older prototype code, use a staged workflow:

1. Identify the public boundary of the desired Livt component.
2. Capture the behavior that must be preserved.
3. Ask the agent for a plan and test strategy.
4. Generate a small Livt package with source, tests, and livt.toml.
5. Run livt validate, livt build, and livt test.
6. Review the code and tests before publishing or integrating the package.

Human Review

AI-assisted development does not remove engineering judgment. The developer should still own:

• public component and interface boundaries
• timing assumptions and context choices
• package dependencies and version choices
• test scenarios and acceptance criteria
• security, safety, and deployment decisions
• final code review and release approval

The agent is strongest when it handles structured implementation work. The engineer remains responsible for deciding what the hardware should do and when a package is ready to reuse.

Practical Prompt Patterns

Use prompts that tell the agent what to build, what to reuse, and how to prove it works.

For package creation:

Create a Livt package named PacketCounter.
Reuse Livt.IO if serial input is needed.
Expose a small public API to reset, accept a byte, and read the count.
Add tests for reset, one packet, and two back-to-back packets.
Run livt validate and livt test.

For package reuse:

Before implementing new components, inspect the available Livt packages.
Prefer Livt.Net and Livt.IO for networking and peripheral behavior.
Only write new code for the application-specific part.

For migration:

Treat the C/HLS source as reference behavior.
Propose a Livt component boundary first.
Then create a small package with source, tests, README, and livt.toml.
Keep the first version conservative and easy to review.

Summary

Livt supports AI-assisted hardware development as a practical workflow today. Developers can use common coding agents with Livt-aware context or choose specialized models when their environment requires them. The common thread is the same: describe intent, reuse existing packages, run the Livt CLI, review the result, and publish only when the package is ready.