AI Usage

For information on Analog Devices Inc. stance on AI usage, please see Responsible AI @ ADI.

AI tools are most useful when they are connected to the same sources of truth and validation paths that engineers already use: documentation, command-line tools, tests, builds, hardware interfaces, and code review. This page describes how ADI exposes that context to coding assistants and what a coding harness adds on top of a language model.

Tooling for AI-assisted work

A large language model can explain, draft, and connect ideas quickly, but it is not a substitute for project knowledge or validation. The value comes from placing the model in a workflow where it can inspect a code base, call the right tools, read the documentation, and report verified results.

We utilize two complementary mechanisms to achieve this:

  • MCP Servers exposes tools and data through the Model Context Protocol. By coupling context with assertion, they allow the system to dynamically steer theagent toward optimal tool usage on the fly.

  • Skills package task-specific instructions and tool inventories as text files. They teach the agent how to utilize tools and execute tasks without forcing tight coupling or rigid hooks.

A foundational design choice is our CLI-first stance: every tool available to the MCP is also accessible via the CLI. This ensures that frequent tasks can be automated programmatically and sustainably.

MCP servers and skills

Our set of MCPs and Skills include:

  • doctools MCP: Searches ADI public documentation under https://analogdevicesinc.github.io and https://wiki.analog.com.

  • pyadi-iio MCP: Interacts with hardware at runtime. It exposes tools for device discovery, connection management, property configuration, data capture, and signal generation across supported device classes.

  • pyadi-dt MCP: Exposes device tree generation, linting, and inspection tools.

  • pyadi-jif MCP: Provides a programmatic interface to pyadi-jif, including JESD mode queries and system-level solving.

  • Scopy skills: Catalogs Scopy development tools such as the package generator, test tools, CI scripts, format and license checks, and development plugin commands.

We believe documentation is part of the code base and that assistants should have access to it just like users have.

Besides using the doctools MCP, public documentation sources can be fetched directly, for example, the source for this page is docs/contributing/ai.rst. Each rendered page also provides a Copy content button that copies the page as Markdown, which uses adi_doctools/theme/harmonic/scripts/html2md.js; the MCP uses adi_doctools/cli/aux_html2md.py to convert with Python.

The coding harness

A coding harness is the software layer that wraps a LLM. It interfaces the model, manages context usage and compaction, summarizes tools in the context, and employs observability and recovery strategies.

To ensure quality, we build the coding harness to be:

  • Honest: the agent describes the validation steps it took.

  • Accurate: tools to verify implementations and claims.

  • Useful: fixes are delivered as patches that a developer can inspect and apply.

../_images/agentic-loop.svg

During a session, the harness can inject context, steer tool use, and employ multiple models with different roles. Since we collect the collateral generated by the run, including tool output and the agent session, the result can be reviewed. If something goes wrong, the interaction can be traced back to the step that introduced the issue.

Examples of coding harnesses are pi.dev, OpenCode, Claude Code, and OpenAI codex.

Jagged frontier and context

LLMs are prediction models with attention: Attention constructs weighted graphs between tokens for every single forward pass. At scale, enables cognitive-like behaviour emerges. However, models are incredible at creating perfectly coherent narratives, which may be factually incorrect.

LLMs perform well on tasks within the jagged technology frontier, the uneven boundary where the model excels at. A study shows that subjects using AI completed 12.2% more tasks and finished 25.1% faster on tasks inside the model capabilities frontier, but were 19% less likely to produce correct solutions on complex tasks (Dell’Acqua et al., 2023).

Another study shows that performance also degrades over long sessions: frontier models corrupt roughly 25% of document content by the end of ~20-iteration workflows, with an extra 3–6% loss per tool call at 2–5× the token cost. Non-compliance accounts for only ~3% of failures; the dominant causes are tool misuse and mistake propagation between rounds (Laban, 2026 pre-print).

To mitigate this nature of the model, we ensure the quality of the context and tools available for the model, with careful analysis of sessions.

Pull request reviewer

The pull request reviewer is an AI-assisted reviewer integrated into CI/CD. It uses the tooling present in each workflow to provide contextual feedback on pull requests: builds, static analysis, style validation, checks, and any other project-specific tool that is meaningful for the code base.

It supports models from multiple vendors, cloud-hosted or self-hosted. The tool does not approve or merge code; final decisions remain with our reviewers, and there is always a human-in-the-loop. It enables resolving repetitive review work early and leave humans with a smaller, better-described problems.

How it works

On dispatch, the agent runs in a read-only environment, compiles the code base, and validates issues and fixes against the actual build output. It then posts annotated feedback as a GitHub Summary with downloadable git patches and the agent session.

../_images/llm-run.svg

Figure 1 LLM run example.

Usage

Access is available to any user with write access to the analogdevicesinc GitHub organization. For third-party pull requests, an ADI developer can request a review on your behalf.

The workflow is included in each repository.

Tip

Adding the llm review label on the pull request also triggers the llm review.

Go to github.com/analogdevicesinc/<repository>/actions/workflows/llm.yml (for example, actions/workflows/llm.yml for this repository), click Run workflow, and enter the pull request number, branch, or Git SHA to review.

LLM Agent llm.yml 44 workflow runs Apr 7, 4:11 PM GMT+2 18m 54s Apr 7, 10:39 AM GMT+2 13m 1s Apr 2, 12:38 AM GMT+2 1m 13s Apr 2, 12:37 AM GMT+2 26s Apr 2, 12:13 AM GMT+2 3m 49s Apr 2, 12:02 AM GMT+2 51s Apr 1, 11:58 PM GMT+2 8s Apr 1, 11:09 PM GMT+2 57s Apr 1, 6:41 PM GMT+2 Actions Management New workflow All workflows LLM Agent Top Level Checks Runners Usage metrics Performance metrics Filter workflow runs Event Status Branch Actor This workflow has a workflow_dispatch event trigger. Run workflow LLM run 212 LLM Agent #64: Manually run by user main LLM run 411 LLM Agent #61: Manually run by user main LLM run 83 LLM Agent #58: Manually run by user pi LLM run 83 LLM Agent #57: Manually run by user pi LLM run 83 LLM Agent #54: Manually run by user pi LLM run 404 LLM Agent #53: Manually run by user pi LLM run 404 LLM Agent #52: Manually run by user pi LLM Agent LLM Agent #51: Manually run by user pi LLM Agent Use workflow from The branch, tag, PR number, or SHA tocheckout 1234 Prompt to use, overwrites the default Extra prompt to concatenate Model size. medium Branch: main Run workflow Run it 3 2 1 Go to ... analogdevicesinc/linux/actions/workflows analogdevicesinc/documentation/actions/workflows Set the referenceto review

How to dispatch a LLM run.

Optional inputs include additional prompt instructions and model size selection. The default prompt is defined in .github/workflows/llm.yml of each repository, for example .github/workflows/llm.yml. The LLM front-end used is pi.dev.

Once finished, the GitHub Summary contains the review, and the run artifacts include git patches with suggested changes and a session file to continue locally. An example run is available here.

You can download and apply all patches in one go with apply-patches.sh:

~$

apply-patches --repo=documentation 123456789

One liner to install:

~$

curl -fSsL \
 "https://raw.githubusercontent.com/analogdevicesinc/doctools/refs/heads/main/ci/scripts/apply-patches.sh" \
   -o ~/.local/bin/apply-patches.sh && \
 grep -q "/apply-patches.sh" ~/.bashrc || echo "source ~/.local/bin/apply-patches.sh" >> $_ ; . $_