Why I Built AICRE: Making Linux Development Environments More Visible for AI Coding Workflows

The problem

AI coding agents are becoming part of everyday software development. Developers use tools such as Codex, Claude Code, Aider, and local development tools as part of their workflows.

But before using these tools, it is useful to understand the environment they are running in.

What operating system is available? Which development tools are detectable? What information can actually be established about the machine? And, just as importantly, what remains unknown?

I wanted to build a small tool that could help make some of these facts more visible without pretending to know more than it actually can.

Introducing AICRE

AICRE (AI Computer Readiness Engine) is an open-source, local-first Linux command-line tool.

It collects a bounded set of local system and development-environment metadata and presents separate findings across five dimensions:

• Resource: selected host-facing CPU, memory, and storage observations.
• Software: detection of selected development tools through permitted PATH entries.
• Compatibility: explicit checks such as Linux platform and minimum Python version.
• Privacy: information about AICRE’s own collection and exclusion behavior.
• Security: deliberately limited observations, not a complete assessment of host security.

Each readiness dimension reports a status:

pass, warning, fail, or unknown.

The important part is that these dimensions remain separate. AICRE does not combine them into a single score.

Why local-first matters

AICRE is designed to perform its inspection locally.

During its inspection workflow, it makes no network requests and does not execute the programs it discovers.

It does not read credentials, API keys, private keys, .env contents, chat histories, or user documents.

This is a deliberate design boundary: collect only selected information needed for the tool’s defined inventory and reporting scope.

Reports are generated locally in formats including JSON, Markdown, and offline HTML. PDF output is also available as an optional feature.

Evidence matters more than impressive-looking scores

One design decision was especially important to me: an unknown result should remain unknown.

For example, observing the host’s available memory or CPU does not establish the effective resource limits available to a process running inside a container.

Similarly, detecting python3 or git on PATH does not prove that the detected tool is correctly configured, secure, or fully functional.

AICRE therefore distinguishes observed facts from conclusions it cannot establish.

The unknown status is not necessarily a failure. It can mean that the available evidence is insufficient to make a reliable assessment.

Reports and snapshot comparison

AICRE can generate structured reports and compare saved snapshots.

This makes it possible to inspect changes between two observations rather than relying only on a single report.

The project supports JSON, Markdown, offline HTML, and optional PDF output.

The goal is to make findings easier to inspect, preserve, and compare.

What AICRE does not claim to do

It is important to be precise about the boundaries of this project.

AICRE is not:

• A security scanner.
• A malware scanner.
• A sandbox for AI agents.
• A complete secret scanner.
• A guarantee that a machine is safe for autonomous agents.
• A tool that configures or repairs the host system.

It does not run AI agents, install software, or change system settings.

It currently targets Linux and requires Python 3.11 or newer. Windows and macOS support are not claimed.

Project and source code

AICRE is open source under the MIT License.

The v0.4.0 release represents the project’s completed, deliberately limited scope. The focus is now on maintaining correctness, reliability, and documentation rather than expanding the feature set.

Repository:

https://github.com/zghaibehi-create/aicre

Latest release:

https://github.com/zghaibehi-create/aicre/releases/tag/v0.4.0

I’d appreciate your feedback

I’m interested in hearing from Linux developers and people who work with AI coding tools.

A few questions:

1. Is a separate, evidence-backed view of these environment dimensions useful?
2. Which observations would you expect from a local development-environment inventory tool?
3. Is the distinction between detected, assessed, and unknown information clear enough?
4. What would make the reports easier to understand and use?

I’m the creator of AICRE, and this article is an invitation to discuss the engineering decisions behind it.

Thanks for reading.