DEV Community: László Szabó

Vincent 0.7.0: The control plane now runs its own development

László Szabó — Sun, 30 Aug 2026 09:24:37 +0000

I just released Vincent 0.7.0, and this release marks an important milestone for the project:

Vincent now builds Vincent.

All development on the project now goes through Vincent workflows — from creating an approved GitHub issue through planning, implementation, verification, human gates, merge, and release preparation.

The journey from 0.4.0 to 0.7.0 added quite a bit.

Workflows became real interfaces

Workflows can declare their expected inputs, including:

labels
types
required fields
RE2 validation

Vincent also gained a workflow-authoring skill designed around a principle I care about quite a lot: don't use an AI agent when deterministic automation can do the job better.

Commands and native control flow come first. Agents are used where reasoning is actually required.

Recovery became part of the workflow

Real automation fails.

So Vincent now has mechanisms for continuing rather than throwing work away:

follow-ups on completed tasks
recorded repair agents for blocked tasks
retry backoff
safer daemon backup/restore
improved diagnostics through vincent doctor

The control plane became scriptable

0.7.0 significantly expands the CLI.

Tasks can now be started idempotently, created from GitHub issues, populated through JSON/stdin, queried through vincent status, limited with max_cost_usd, and integrated with notifications.

Logs, transcripts, approvals, retries, repairs and task answers can all be handled without entering the TUI.

The TUI hasn't been neglected either — tasks now open into a dedicated workspace containing steps, attempts, metadata, output and file-grouped diffs.

Vincent builds Vincent

This is the part I'm most excited about.

My own development workflow now uses Vincent itself:

GitHub issue
    ↓
planning
    ↓
implementation
    ↓
documentation
    ↓
cross-platform verification
    ↓
human gates
    ↓
merge
    ↓
release audit

Claude Code, Codex or Cursor can provide the inference.

Vincent owns the durable workflow, state and verification around them.

That's the architecture I've been working toward: a local, inspectable and vendor-independent control plane for coding agents.

Vincent is also MIT licensed again.

I wrote a deeper overview of everything that changed between 0.4.0 and 0.7.0 here:

https://blog.lezli01.is-a.dev/blog/vincent-0-7-release/

Feedback and contributions are very welcome.

Vincent v0.7.0: Better visibility, stronger automation, less babysitting

László Szabó — Sat, 29 Aug 2026 08:52:52 +0000

Vincent v0.7.0 is out.

This release is mainly about one thing:

Making agentic development workflows easier to operate when you are not staring at them.

As Vincent has grown, simply starting an agent has become the easy part.

The harder questions are:

What is it doing right now?
Does it need input from me?
Can I control it from a script or over SSH?
Can it notify me when something important happens?
Can I inspect what happened without opening the TUI?
Can I put limits around how much an autonomous task can consume?

v0.7.0 tackles a lot of that.

A proper workspace for running tasks

The TUI received one of its biggest UX improvements so far.

Opening a task now takes you into a dedicated full-screen workspace with separate views for:

Steps & Attempts
Task Details
Output
Diff

Attempt selection follows you between views, outputs can be switched between retries, and failed attempts expose their result summary directly in the timeline.

The main task board can now stay what it should be: a board.

The details live where they belong.

Agents can finally tell you what they are doing

A running step can now publish its own status:

vincent status "Running integration tests"

That status becomes visible in the TUI and is also available through the API.

This sounds like a small feature, but it changes the experience of running longer workflows quite a bit.

Instead of:

running...

you can see something closer to:

» Investigating the failing authentication test

or:

» Waiting for the GitHub checks to complete

Agent steps also receive the VINCENT_* environment variables that command and check steps already had, so agents can report their own progress through their shell tools.

Vincent can notify you when it actually needs you

Previously, Vincent could ring the terminal bell when a task reached an interactive state.

That is useful — assuming the TUI is open.

v0.7.0 adds configurable external notifications.

You can run a command whenever a task enters states such as:

notify:
  command:
    - notify-send
    - "Vincent needs attention"
  on:
    - blocked
    - awaiting_input
    - awaiting_gate
    - done

Vincent passes a JSON payload to the command, including information about the task and the transition.

Because this is command-based rather than tied to a specific notification provider, you can integrate it with whatever makes sense for your setup:

desktop notifications
Slack
scripts
webhooks
file drops
custom internal tooling

The important part is that a task can now run in the background and actively tell you when human involvement is useful.

The CLI can now control almost everything

A major goal of this release was reducing the dependency on the TUI for operational tasks.

vincent task now includes commands for actions such as:

vincent task pause
vincent task resume
vincent task skip
vincent task approve
vincent task reject
vincent task retry
vincent task repair
vincent task archive
vincent task answer

This makes Vincent much easier to use from:

shell scripts
CI environments
cron jobs
remote SSH sessions
automation around existing developer tooling

For example, blocked tasks can now be discovered and retried programmatically:

vincent task ls --state blocked --json \
  | jq -r '.[].id' \
  | xargs -n1 vincent task retry

The TUI remains useful for interactive work, but it is no longer the only practical control surface.

Logs and transcripts are first-class CLI citizens

Two new commands make debugging and remote operation significantly easier:

vincent daemon logs

and:

vincent task transcript <task-id>

Daemon logs are read directly from disk, so they still work even if the daemon itself is unavailable.

Task transcripts can be viewed as human-readable output, NDJSON, or raw agent JSONL.

That makes it much easier to inspect what happened inside an attempt without digging through Vincent's data directory manually.

Create tasks directly from GitHub issues

Vincent can now create a task from a GitHub issue.

For projects connected to GitHub, Vincent can pull in:

the issue title
description
issue URL
labels
assignee
milestone
issue number

Workflow fields can also be populated from issue metadata when their definitions match.

This is a particularly useful bridge between traditional development workflows and agentic execution.

An issue can increasingly become the starting point for a reproducible workflow rather than merely a description of work waiting for someone to pick it up.

Put a budget around autonomous work

v0.7.0 also introduces per-task spending limits.

That means autonomous workflows can have explicit boundaries around how much agent execution they are allowed to consume.

For long-running or heavily automated workflows, this is an important safety mechanism.

Autonomy is much more useful when it comes with limits.

Better tooling for writing workflows

Workflow authors also get some useful additions.

Create a starting workflow:

vincent workflow init

And render a workflow template without running it:

vincent workflow render

The latter is especially useful when building workflows with fields and templates because you can validate the generated result before actually executing anything.

Smaller changes that matter

There is a lot more in this release, including:

idempotency keys for task creation
stronger checks around restricted agent execution
agent adapter version and capability reporting
safer process recovery
workflow source tracking
new built-in workflows
improved retry and polling behavior
better wrapping of long content in the TUI
macOS release signing/notarization work

You can find the full list in the changelog.

Where Vincent is heading

The goal with Vincent is not to build another chat UI around an LLM.

I want the unit of work to be a workflow.

Agents are one tool inside that workflow, alongside commands, checks, control flow, human gates, retries, parallel execution, and deterministic automation.

And increasingly, I want those workflows to be able to run without requiring constant supervision.

v0.7.0 is a fairly big step in that direction.

If you're experimenting with agentic software development, I'd love to hear what kinds of workflows you're building.

Full changelog:
https://lezli01.is-a.dev/vincent/changelog.html

GitHub:
https://github.com/lezli01/vincent

I didn’t start building vincent because I wanted to create another AI coding tool.

László Szabó — Fri, 28 Aug 2026 06:42:06 +0000

I built it because I got tired of being the workflow engine myself.

For many coding tasks, especially QA issues, I kept giving agents essentially the same process:

Understand the ticket.
Check whether the issue could be valid.
Reproduce it.
Fix the root cause.
Add regression tests.
Update the documentation.
Bring everything back for review.
After approval, open the PR and update the ticket.

The problem wasn’t that agents couldn’t perform these steps.

The problem was that I had to keep orchestrating them.

I was carrying context between stages, checking whether conditions had been met, deciding when the workflow should stop, and repeatedly explaining what should happen next.

At some point the obvious question became:

Why am I describing this process again?

Why can’t I describe it once and simply provide the ticket ID next time?

That question became Vincent.

The goal is not to hide everything inside one huge prompt. It’s to make agentic development workflows explicit, reusable and inspectable with control flow, checks, persisted outputs and human gates when human judgment is actually valuable.

I wrote the story behind it here:

https://lezli01.is-a.dev/vincent/docs/why/the-workflow-i-kept-repeating-and-how-vincent-was-born.html

I’d be interested to hear how others are handling this: are you still orchestrating coding agents manually, or have you started turning your recurring processes into reusable workflows?

vincent: a local-first control plane for AI coding agents

László Szabó — Thu, 27 Aug 2026 08:25:02 +0000

AI coding agents have become surprisingly capable.

But once I started using them seriously, I ran into a different problem:

Starting an agent is easy. Managing many of them isn't.

A few tasks quickly turned into multiple terminals, repositories, branches, prompts, transcripts and agent sessions. I wanted to be able to start work, leave it running, see what every agent was doing, enforce deterministic checks, intervene when necessary, and switch between different agent providers without redesigning the whole workflow.

So I built Vincent.

👉 https://github.com/lezli01/vincent

Vincent stands for:

Vendor-independent co*ntrol plane for executing native agent* tooling.

It is an open-source, MIT-licensed, local-first orchestrator for AI coding-agent workloads.

The idea

Vincent isn't another coding agent.

Instead, it sits above the agents you already use.

Currently it can execute:

Claude Code
OpenAI Codex
Cursor Agent

Vincent uses their native CLIs and the authentication already configured on your machine. It doesn't try to replace them and it doesn't need to store their credentials.

The architecture is centered around a local daemon:

                 ┌─────────────┐
                 │     TUI     │
                 └──────┬──────┘
                        │
                 ┌──────▼──────┐
CLI / scripts ──►│ Vincent     │◄── REST / SSE
                 │ daemon      │
                 └──────┬──────┘
                        │
         ┌──────────────┼──────────────┐
         ▼              ▼              ▼
     Claude Code      Codex        Cursor Agent

The daemon owns the state, scheduling and execution.

That means I can close the TUI or terminal and the tasks continue running.

Workflows instead of giant prompts

One of the biggest things I wanted was to avoid solving everything with one enormous AI prompt.

Vincent workflows are YAML and can mix agentic steps with deterministic operations.

A workflow can contain things like:

agent prompts
shell commands
verification checks
conditions
loops
parallel execution
isolated fan-out
reusable workflow includes
human approval gates

Conceptually, you might have something like:

steps:
  - name: implement
    agent: codex
    prompt: |
      Implement the requested change.

  - name: test
    run: go test ./...

  - name: fix
    if: previous.failed
    agent: codex
    prompt: |
      The tests failed.

      Fix the implementation based on the failure.

The important part isn't the exact syntax here.

It's the separation of responsibilities.

If a compiler, test runner, linter or script can determine something reliably, I don't want to spend AI tokens asking an LLM to do it.

Use agents where reasoning is useful. Use normal software everywhere else.

Checks, not claims

This led to another important design decision.

An agent saying:

"I've completed the task and all tests pass."

doesn't mean the task succeeded.

Vincent can use deterministic checks to decide that.

If a check fails, the actual failure can be fed back into the next attempt.

So instead of:

Agent: looks good!
Task: success

the model becomes closer to:

Agent makes change
       ↓
Run real verification
       ↓
   success?
    /     \
  yes      no
  ↓         ↓
next     retry with
step     real failure

This makes agent execution much more useful for unattended workloads.

Every task gets its own worktree

Parallel agents modifying the same checkout is a great way to create chaos.

Vincent isolates development tasks using Git worktrees.

Each task gets its own:

worktree
branch
execution state
transcripts
step history

So multiple tasks can operate against the same repository without competing over the developer's working tree.

You can also configure global and project-level concurrency limits.

Humans are still part of the workflow

I don't think autonomous should mean uncontrollable.

There are situations where I explicitly want an agent to stop.

Vincent supports human gates, blocked tasks and intervention.

For example, a workflow can require approval before something sensitive happens.

If an execution fails, I can inspect the result and decide whether to:

retry it
edit and retry
repair it with another agent
skip the step
abort the task

There are also follow-up runs, so after an agent finishes a task I can ask it to make another change on the same branch and worktree without reconstructing the context manually.

A TUI for watching the factory

Vincent includes a terminal UI because once several workloads are running, visibility becomes important.

The TUI gives me a central view of:

running and queued tasks
workflow steps
live agent output
duration
token usage and cost
blocked tasks
projects
workflows
agent availability

It's essentially the dashboard I wanted when I started running multiple coding agents simultaneously.

Crash recovery matters

This is one of the less glamorous parts of agent tooling, but probably one of the more important ones.

What happens when the orchestrator crashes halfway through a 30-minute agent task?

Vincent is designed around durable state.

Transitions are persisted, interrupted executions can be reconciled after restart, transcripts are retained, and tasks don't simply disappear because the UI closed.

I've tried to treat agent workloads more like real jobs running on an execution platform than temporary terminal sessions.

Vendor independence

I also deliberately don't want workflows tightly coupled to a single AI vendor.

An individual workflow step can choose an agent, model, reasoning effort and permissions.

That means one workflow could theoretically use different models for different parts of the job.

It also means switching your preferred agent doesn't require throwing away the orchestration layer around it.

It works from more than the TUI

The TUI is useful for humans, but Vincent isn't TUI-only.

Operations are also available through the CLI and a localhost REST + SSE API.

For example:

vincent project add /path/to/repo

vincent task add \
  --project 1 \
  --title "Add a health endpoint"

vincent task ls --state running

vincent workflow validate \
  .vincent/workflows/feature-pr.yaml

Commands support JSON output as well, so Vincent itself can become part of larger automation.

Installing it

On macOS:

brew install lezli01/tap/vincent

On Windows:

winget install --id lezli01.Vincent --exact

or:

scoop bucket add vincent https://github.com/lezli01/scoop-bucket
scoop install vincent/vincent

With mise:

mise use -g github:lezli01/vincent

There are also deb/rpm packages and standalone binaries for Windows, macOS and Linux.

Why I open sourced it

Agentic development is moving extremely quickly.

I don't think the interesting problem anymore is simply:

"Can an LLM write this function?"

The problem I'm increasingly interested in is:

"How do we turn AI agents into reliable, observable and controllable software-engineering workloads?"

That involves scheduling, isolation, verification, retries, state management, human gates, observability and cost management.

In other words, a lot of familiar software engineering problems — just applied to a new kind of worker.

Vincent is my attempt at building that layer.

It's still pre-1.0 and evolving quickly, but I already use it for my own development workflows.

The project is now MIT licensed, so you're free to use it, modify it, build on it or contribute.

If this problem sounds familiar, I'd love to hear how you're currently managing multiple coding agents.

And if you want to try Vincent:

⭐ GitHub: https://github.com/lezli01/vincent

📖 Documentation: https://lezli01.is-a.dev/vincent/

Feedback, issues and contributions are very welcome.

Firebase Security Rules deserve better IDE support

László Szabó — Tue, 30 Jun 2026 11:18:40 +0000

I have been writing Cloud Firestore Security Rules for years, and I usually edit them in the same place where I do the rest of my work: Android Studio or another JetBrains IDE.

And every time, the same thing bothered me.

A .rules file controls access to production data, but in many IDE setups it is treated almost like plain text.

No proper structure awareness.
No useful formatting.
No diagnostics while editing.
No symbol support for helper functions.

For something that decides who can read and write your data, that feels wrong.

So I built hotrulez, a free and open-source JetBrains plugin for Firebase Security Rules.

What hotrulez does

hotrulez adds IDE support for .rules files inside IntelliJ-based IDEs, including Android Studio.

It currently supports:

syntax highlighting
formatting
parse error diagnostics
structure-aware rule parsing
helper/function symbol support

The goal is simple: make Firebase Security Rules easier to read, write, and maintain in the IDE where many Firebase developers already work.

What it does not do

hotrulez does not evaluate authentication logic.

It does not replace the Firebase Emulator Suite.

It does not tell you whether your rules are secure.

That part still belongs to proper tests, reviews, and Firebase’s own tooling.

The plugin focuses on the editor experience: helping .rules files feel like real code instead of a plain text blob.

Why I built it

Security rules tend to grow slowly.

At first, they are small enough that you can keep everything in your head. Then helper functions appear. Then nested match blocks grow. Then multiple collections get different access patterns. Eventually, the file becomes important enough that editing it without language support feels uncomfortable.

I wanted a free, open-source option that made this experience better in JetBrains IDEs.

So I built one.

Who it is for

hotrulez is probably useful if you:

use Firebase or Cloud Firestore
edit .rules files in Android Studio or IntelliJ
maintain larger Firestore rulesets
want basic IDE support without using a paid plugin
prefer open-source developer tooling

Links

GitHub: hotrulez
JetBrains Marketplace: Firebase Rules

Feedback, bug reports, and feature ideas are very welcome, especially from people maintaining larger Firebase Security Rules files.