DEV Community: Ilya Golovenkov

Pro Sells Time, Not Safety — ELY Agent Input Preflight v0.8.0

Ilya Golovenkov — Mon, 05 Oct 2026 19:34:25 +0000

ELY Agent Input Preflight v0.8.0 is released.

This release introduces an optional paid Pro entitlement, but I made one rule non-negotiable:

Pro sells time, not safety.

The Community edition keeps the complete verification and safety core.

GitHub Release:
https://github.com/Golovenkov79/ely-agent-input-preflight/releases/tag/v0.8.0

Product page:
https://elyzorix.ru/tools/agent-input-preflight/

What is ELY Agent Input Preflight?

ELY Agent Input Preflight is a local-first verification layer for AI coding agents.

Its job is not to replace the coding agent.

Its job is to independently answer questions such as:

Is the project ready before the agent starts?
Did the agent change files it was not supposed to change?
Did generated Python code remain structurally valid?
Did the requested work actually happen?
Is there independent execution evidence?
Can the final result be trusted instead of trusting only exit code 0?

The project is built around an important distinction:

PROCESS → EXECUTION → ACCEPTANCE → FINAL

A successful process exit is not automatically proof of a successful result.

What changed in v0.8.0?

v0.8.0 adds the foundation for an optional Pro entitlement.

New functionality includes:

ely-preflight upgrade
ely-preflight license status
online Pro activation
local license deactivation
Ed25519-signed entitlement verification
pinned public verification key
local signed entitlement storage
safe fallback to Community mode
public license API via elyzorix.ru
dedicated HTTP User-Agent for Cloudflare compatibility
public Pro checkout and license claim flow

The important part is what did not change.

Community is still complete

I did not move the safety core behind the paywall.

Community still includes:

Preflight checks
project detection
skills
read-only agent mode by default
execution evidence
failure diagnosis
diagnostic probes
Generated-Code Admission
Independent Postflight
PROCESS / EXECUTION / ACCEPTANCE / FINAL semantics
local run history
core safety policy

You do not need Pro to know whether an AI coding agent did something unsafe or failed verification.

That would defeat the purpose of the tool.

So what is Pro for?

The design principle is simple:

Community protects correctness. Pro should reduce time and friction.

The paid layer is intended for convenience, automation and productivity rather than making the free version artificially unsafe or incomplete.

I think developer tools should earn money by making work faster — not by intentionally weakening the free safety layer.

Real-money end-to-end test

Before releasing v0.8.0, I tested the commercial route with an actual 499 RUB subscription purchase.

The verified path was:

payment
→ payment provider webhook
→ license issued
→ license claim
→ Windows activation
→ signed entitlement
→ PRO ACTIVE

What changed after I stopped trusting exit code 0: ELY Agent Input Preflight v0.7.0

Ilya Golovenkov — Sat, 03 Oct 2026 13:59:12 +0000

A few days ago I wrote about why I stopped treating exit code 0 from an AI coding agent as proof that the requested work was actually completed correctly.

That idea has now turned into the next release of ELY Agent Input Preflight: v0.7.0.

The biggest change is a new layer called Generated-Code Admission.

The goal is simple:

before generated source code is allowed to contribute to a successful final result, ELY should independently check whether that source can be admitted at all.

GitHub:
https://github.com/Golovenkov79/ely-agent-input-preflight

Release v0.7.0:
https://github.com/Golovenkov79/ely-agent-input-preflight/releases/tag/v0.7.0

Project page:
https://elyzorix.com/tools/agent-input-preflight/

The verification boundary is now more explicit

One of the most useful pieces of feedback on my previous post was that there are several different questions hidden behind a single word like "success".

Did the agent process complete?

Did the requested operations actually execute?

Does the resulting repository satisfy the acceptance criteria?

Can the generated source itself be independently admitted?

I now keep those questions separate:

PROCESS
  ↓
EXECUTION
  ↓
ACCEPTANCE
  ↓
FINAL

The important part is that these states are not silently collapsed into one green check.

An agent can complete successfully while the repository still needs review.

A test command can run while the generated source itself is invalid or out of scope.

And sometimes the honest answer is simply:

NOT_PROVEN

which then becomes:

NEEDS_REVIEW

instead of a false VERIFIED.

Generated-Code Admission

v0.7.0 adds an independent admission layer between AI-generated source changes and the final Postflight decision.

For Python source, the Community release currently performs bounded, deterministic checks including:

syntax validation;
structural parsing;
source-scope checks;
project-local policy checks;
baseline dangerous-construct detection.

The baseline currently detects or blocks supported forms of:

eval(...)
exec(...)
os.system(...)
subprocess.run(..., shell=True)

including supported import aliases.

This is intentionally not presented as a complete security scanner.

It is a bounded admission layer with deterministic rules.

If ELY cannot prove a result, it does not silently convert uncertainty into safety.

For example, a dynamic subprocess flag such as:

subprocess.run(cmd, shell=flag)

cannot automatically be treated as safe just because flag is not literally True.

The admission result stays NOT_PROVEN.

Project-local scope and policy

A project can also define local admission rules.

For example:

{
  "admission": {
    "allowed_paths": ["src/*.py"],
    "denied_paths": ["secrets/*"],
    "forbidden_calls": ["open"]
  }
}

This lets the project say not only "is this valid Python?", but also:

was this file supposed to be changed here?
is this path allowed?
is this call allowed by this project's policy?

An invalid, dangerous, out-of-scope, or policy-violating source does not get promoted to a successful final result.

Why I did not put the safety layer behind Pro

I also made a product decision while building this release.

The Community version keeps the full core verification and safety functionality.

I do not want a model where:

"we found a dangerous generated-code pattern, but you need the paid plan to verify it properly."

That would defeat the purpose of the project.

The future Pro layer is planned around time and automation, not better safety.

Examples include:

one-command end-to-end workflows;
reusable workflow profiles;
batch and multi-project orchestration;
CI / PR automation;
richer reports;
history analytics;
unattended or scheduled workflows;
team-oriented workflow management later.

The same verification core should remain available in Community.

A short version of the product rule is:

Pro sells time, not safety.

Local-first is still the default

The Community core remains local-first.

It does not require:

an ELY account;
a remote dashboard;
telemetry;
a cloud database.

Run history and verification evidence remain local.

The project is still released under Apache-2.0.

What v0.7.0 was tested against

Before publishing the release, I ran the full regression suite plus adversarial admission cases.

The final release candidate passed:

169 automated tests;
self-preflight;
release archive audit;
SHA-256 verification;
fresh Windows install smoke;
successful admission smoke;
adversarial NOT_PROVEN smoke.

The Windows source package SHA-256 is:

698996db4534579dc99b5c4625e3c56ed246b7e188117919e65ddc75bfd351cf

The current idea

The project started with a simple rule:

an AI agent saying "success" is evidence, not authority.

v0.7.0 pushes that idea one step further.

Now the generated source itself has to cross an independent admission boundary before it can help produce a verified final result.

There is still a lot to build.

But I would rather have a system that says:

NEEDS_REVIEW

when evidence is incomplete than one that produces a confident green check from assumptions.

If you work with coding agents and have run into similar verification problems, I would be interested in hearing where your current workflow still relies on trust rather than independent evidence.

GitHub:
https://github.com/Golovenkov79/ely-agent-input-preflight

Release:
https://github.com/Golovenkov79/ely-agent-input-preflight/releases/tag/v0.7.0

Website:
https://elyzorix.com/tools/agent-input-preflight/

Why I stopped trusting “exit code 0” from AI coding agents

Ilya Golovenkov — Mon, 28 Sep 2026 05:55:03 +0000

AI coding agents are getting much better.

They can inspect repositories, change multiple files, run commands, write tests, and sometimes complete work that would have taken a developer hours.

But I kept running into the same problem:

the agent would finish, return exit code 0, and say that everything was successful.

Sometimes it really was.

Sometimes it wasn't.

That made me realize that I did not only need a better coding agent.

I needed an independent way to verify what the agent had actually done.

The problem

When an AI coding agent works on a project, several things can go wrong:

required files may be missing before the run even starts;
the agent may misunderstand the project structure;
it may modify files it was not supposed to touch;
tests may not actually run correctly;
the agent may report success even when verification is incomplete;
a successful process exit does not necessarily mean the project is actually in a good state.

The stronger coding agents become, the more important this problem becomes.

If an agent changes 10 or 20 files, I do not want to manually inspect every line after every run.

And if agents become even more autonomous, manual verification becomes even less practical.

That is the problem I wanted to solve.

What I built

I built a small open-source CLI called ELY Agent Input Preflight.

👉 Try ELY Agent Input Preflight on GitHub:

https://github.com/Golovenkov79/ely-agent-input-preflight

The idea is simple:

Check whether the project is ready before the AI agent starts.
Detect the project type.
Prepare the right context and instructions.
Run the coding agent in read-only mode by default.
Monitor whether project files changed unexpectedly.
Run independent verification after the agent finishes.
Record the result locally.

The important part is this:

an agent exit code of 0 is not automatically treated as success.

ELY can return:

VERIFIED
FAILED
NEEDS_REVIEW

So the agent's own result is only one signal.

It is not the final authority.

Before the agent starts

The first layer is Preflight.

Before the coding agent runs, ELY checks whether the project has the inputs it is supposed to have.

That can include things such as:

required files;
required directories;
file patterns;
environment variables;
valid JSON files;
non-empty files;
optional files that should produce warnings instead of blocking the run.

If something critical is missing, ELY can stop the run before the coding agent starts.

That sounds simple, but it avoids wasting an expensive agent run just to discover later that the required context was incomplete.

Project detection and skills

ELY also detects the type of project it is looking at.

The current release includes project detection for:

Python;
Android;
.NET.

Based on that detection, ELY can select matching built-in guidance before preparing the handoff to the coding agent.

The goal is not to replace the agent.

The goal is to make sure the agent starts with better context and clearer rules.

Read-only by default

One design decision was especially important to me:

the coding agent should not get write access by default.

With the current Codex integration, ELY starts the agent in an explicit read-only sandbox unless write access is deliberately enabled.

If I only want an agent to inspect a project, I do not want it silently modifying files.

Write access has to be explicitly requested.

That gives me a much clearer separation between:

inspection;
modification.

File integrity monitoring

ELY also takes a snapshot of project files before an agent run.

After the agent exits, it compares the workspace again.

This allows ELY to detect:

created files;
modified files;
deleted files.

That matters especially for read-only runs.

If a supposedly read-only agent run changes protected project files, ELY can treat the result as a failure.

This is independent of what the agent claims it did.

A real example

During development I had a Codex run where the agent completed with exit code 0.

Inside its sandbox, however, many tests could not run correctly because temporary writable storage was unavailable.

The agent still completed its inspection and reported the limitation.

ELY did not simply trust the agent result.

After Codex exited, ELY ran its own Postflight verification outside the agent sandbox and independently checked the project.

The Postflight verifier was able to run the project's tests normally and verify the state independently.

That was the moment when the idea became useful to me.

The interesting part was not that the coding agent was "bad".

It was that the agent and the verifier were operating under different conditions.

A successful agent run and a successfully verified project are not always the same thing.

Independent Postflight verification

After the coding agent exits, ELY performs its own verification step.

For Python projects, the current built-in verifier can run the project's unittest suite when a tests directory is available.

The final result can then be classified as:

VERIFIED

The independent verification passed.

FAILED

The agent failed, the project changed when it should not have, the Preflight checks became blocked, or the independent verifier failed.

NEEDS_REVIEW

ELY does not currently have enough automated verification for that project type.

I prefer this to pretending that every run can be automatically proven correct.

Sometimes the right answer really is:

this needs a human review.

Current flow


text
Preflight
  -> Project detection
  -> Skill selection
  -> Agent handoff
  -> Codex
  -> File integrity check
  -> Independent Postflight verification
  -> Run history