AI-Assisted Development

Livt is designed to be used side by side with AI coding agents. A developer can work in a normal repository with tools such as GitHub Copilot, Claude Code, Codex, or Eccelerators fine-tuned Livt models, while the Livt CLI provides the same validation, build, test, package, and vendor workflows that a team would use manually.

This chapter describes the practical workflows: using agent context, creating packages with Eccelerators Labs, reusing official packages, migrating existing code, and reviewing AI-assisted results before they become dependencies.

The named services, package versions, and agent integrations on this page are version-sensitive. Verify current product documentation before making them part of an automated release process. The language examples in this documentation were checked with Livt CLI 0.0.10 and compiler 0.0.11-d5677568.

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

For general AI coding tools, start with the official Livt agent context:

https://github.com/eccelerators/livt-agent

The context gives an agent the Livt language rules, project layout, package workflow, test expectations, and implementation conventions. Add it to the workspace instructions, agent memory, RAG index, or prompt context depending on the tool.

The context is especially useful when a task involves syntax details, package layout, public API design, tests, or livt.toml configuration. It helps the agent produce Livt source instead of generic HDL-like or software-only code.

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.

Prompt-to-Package With Eccelerators Labs

Eccelerators Labs provides a hosted prompt-to-package workflow:

https://labs.eccelerators.com

In Labs, a user describes the desired component or subsystem. The agent turns that request into a reusable Livt package, then moves through the normal package lifecycle:

Prompt -> Plan -> Develop -> Review -> Publish

A completed lab can provide source files, tests, package metadata, command results, and downloadable artifacts. When VHDL output is available, Labs can also make that output available as part of the package artifact for downstream review or integration.

Labs is useful for first drafts, reusable IP blocks, teaching examples, package experiments, and migration work. The generated package should still be reviewed, versioned, tested, and integrated like any other hardware dependency.

Publishing From Labs

Labs can publish a reviewed package with livt publish. Once published, the package becomes available through the normal package registry workflow.

A downstream project can then consume it like any other package:

livt search MyGeneratedIp
livt add MyGeneratedIp@0.1.0
livt sync

This keeps the AI-assisted workflow aligned with ordinary Livt reuse. A package created by Labs is still a package: it has a name, version, source files, tests, metadata, and a review history.

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.

Labs Examples

Labs includes example prompts that demonstrate the intended workflow.

8-Point FFT

The fixed FFT example asks the agent to create a small teaching package for an 8-point fixed-point FFT. It reuses Livt.Math helpers such as Q15, ComplexQ15, and TrigQ15 instead of implementing all arithmetic locally.

This is the preferred style for algorithmic examples: describe the component, name the package dependencies, and tell the agent which public APIs should be used.

FIR HLS Migration

The FIR migration example starts from an HLS/C FIR filter and asks the agent to create a small tested Livt package. The Livt component exposes a compact API such as ProcessSample, SetCoefficient, and Reset, and includes tests for impulse response, DC gain, and reset behavior.

This pattern is useful when existing C or HLS code contains the algorithm, but the final package should have explicit Livt components, tests, and package metadata. The developer still decides the hardware boundary, numeric model, and which behavior must be preserved.

SecureDataBlock

The secure data block example asks the agent to create an encryption/decryption package using Livt.Crypto.Aes.Ctr128. The important instruction is not to implement AES locally. The package should reuse the official crypto component, wrap it in a small application-level API, and test deterministic round trips.

This is a good template for domain packages: reuse the official building block, add the application behavior, and keep tests focused on the public API.

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.

The FIR HLS migration example follows this approach. It keeps the package small, uses integer arithmetic for a deterministic demo, and verifies behavior with focused tests.

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 the Livt agent context, use Eccelerators fine-tuned models in controlled environments, or create packages through Eccelerators Labs. 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.