DEV Community: László Szabó

Vincent 0.10.0: Less Hype, More Reliability for Agentic Development

László Szabó — Thu, 24 Sep 2026 05:25:16 +0000

Not every release needs a giant new feature.

Sometimes the most useful release is the one that removes friction from everything you already do.

That is the idea behind vincent 0.10.0.

After several releases that expanded vincent quite aggressively, this one focuses more on:

robustness
fixing rough edges
improving everyday workflows
adding familiar developer conveniences

The result is a smaller release on paper, but one that makes vincent noticeably more comfortable to use.

First: what is vincent?

vincent is an open-source tool for running agentic software-development workflows with human control built in.

Instead of treating AI coding agents as isolated chat sessions, vincent gives them structure around:

workflows
tasks
branches
retries
human approval gates
transcripts
pull requests
containers
parallel work
cost controls
external triggers

The goal is not to remove engineers from the loop.

It is to make agentic development repeatable, observable, and controllable.

Version 0.10.0 mostly improves what working inside that environment feels like.

Skills are now much more natural in chat

Claude Code and Codex increasingly rely on skills to extend what agents can do.

Vincent can now discover those skills and expose them directly inside chat.

Press Tab or F2 and vincent shows the skills available to the current agent.

You can then select one and insert its invocation directly into your message.

Completion also appears automatically while typing things such as:

/review

for Claude Code, or:

$review

for Codex.

Vincent also understands where those skills actually come from.

For example, Codex can expose:

repository skills
user skills
system skills
plugin skills

And when a chat belongs to a containerized task, vincent looks at the environment inside the container, rather than incorrectly showing skills from the host machine.

That distinction matters once agents start running in more isolated environments.

Skill execution is visible too

A skill invocation should not disappear into an opaque agent transcript.

In 0.10.0, executed skills are represented explicitly.

Instead of seeing a large dump of skill content — or nothing at all — the transcript can show:

Skill: review
Arguments: ...
Status: completed

or indicate when the skill failed.

That applies both in the TUI and when reading task or chat transcripts later.

For me, this is part of an important principle:

If an agent performs an action, the surrounding system should make that action observable.

`@file` mentions arrive in chat

This is probably one of those features that feels obvious the moment you use it.

Typing:

inside the chat composer now opens a ranked list of files from the chat workspace.

Keep typing:

@auth

and vincent narrows down the candidates.

Select a result, and vincent inserts the reference in the format expected by the underlying agent.

No manually copying paths.

No jumping between terminal panes just to point the model at a file.

There is also a CLI equivalent:

vincent chat files

This is exactly the kind of small quality-of-life improvement that makes conversational coding workflows much less annoying over time.

Work on a branch that already exists

Previously, vincent generally created its own branch and worktree when starting work.

That isolation is useful, especially for autonomous tasks.

But sometimes you already have the branch you want.

Maybe you created it yourself.

Maybe you checked it out and started experimenting manually.

Maybe you want an agent to continue exactly where you left off.

0.10.0 adds support for that.

vincent task add --branch my-feature --existing-branch

and:

vincent chat start --branch my-feature --existing-branch

Vincent can now work directly on that branch.

It also tries to behave conservatively around Git state.

If the branch is safely behind its upstream, vincent can fast-forward it.

If it has diverged, vincent blocks rather than trying to modify it behind your back.

And if the branch is already checked out in your normal working copy, vincent can work there directly instead of creating another worktree.

That makes vincent much easier to introduce into an existing workflow rather than forcing every interaction to start from vincent itself.

Multiline chat input

Yes, this deserves its own section.

Chat drafts can finally contain newlines.

Use:

Ctrl+J
Shift+Enter
Alt+Enter

while plain Enter continues to send the message.

It is not a groundbreaking AI capability.

It is also one of those things you immediately miss when a terminal chat does not support it.

`/clear` is represented correctly

Agent conversations have context boundaries.

The UI should not pretend otherwise.

When /clear is used, vincent now marks that location in the transcript.

Previously, reading an old conversation could make earlier messages appear as though the agent still had them in context.

Now the transcript represents what actually happened more accurately.

That becomes increasingly important when transcripts are used for:

debugging
auditing
understanding agent decisions
reproducing failures

Send messages from files or stdin

Large prompts and shell-sensitive commands are another source of unnecessary friction.

Vincent now supports:

vincent chat send --message-file prompt.md

and the same capability when starting a chat.

This also helps with skill invocations such as:

/review

or:

$my-skill

which some shells may otherwise interpret or modify unexpectedly.

It is a small addition, but useful when chat becomes part of a scripted workflow instead of something driven exclusively from the keyboard.

Safer global workflow updates

Vincent already has workflows that can be created and updated with agent assistance.

0.10.0 extends that idea to global workflows.

An update can now produce a proposal rather than silently replacing your configuration.

The workflow waits at an approval gate before installation.

You can inspect the proposal and then explicitly apply it.

vincent workflow ls --global

vincent workflow apply

That distinction matters to the direction of the project.

I want agents to be able to help operate and evolve the system.

I do not want that to mean quietly giving them ownership of every configuration change.

Automation and control do not have to be opposites.

And a lot of fixes

The release also contains a collection of less glamorous but important fixes.

Among them:

containerized chats now see the correct agent credentials
skills typed as the first message of a task chat work correctly
@something no longer accidentally disables skill completion
cleaner Claude Code and Cursor output handling
task forms no longer retain stale branch names
blank workflow values behave consistently
installing vincent skills for multiple agents works correctly
example DAG workflows handle unpushed parent branches correctly
Windows installation documentation is clearer

None of these make for a dramatic release announcement.

Together, they matter quite a lot.

Why I like releases like this

Agentic development is moving extremely quickly.

It is easy to focus only on capability:

Can the agent do one more thing?

But once these tools become part of everyday engineering, a different set of questions becomes equally important.

Can I understand what happened?
Can I trust what branch it is touching?
Can I see which skill executed?
Can I recover the transcript later?
Can I move between manual work and agentic work naturally?
Does the tool stay out of my way?

That is where a lot of the work in vincent is moving now.

The goal is not simply to give an agent more power.

It is to build a dependable control plane around that power.

Try vincent

If you are experimenting with:

Claude Code
Codex
coding agents
multi-step agent workflows
human-in-the-loop automation
agent-driven pull request workflows

I would love for you to try vincent.

It is fully open source.

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

👉 vincent 0.10.0 changelog:
https://lezli01.is-a.dev/vincent/changelog.html#0100--skills-and-files-in-chat-and-work-on-an-existing-branch

Feedback, issues, ideas, and contributions are very welcome.

And if you are already building agentic development workflows, I am especially interested in hearing:

What are the small workflow annoyances that bother you most when working with coding agents every day?

AI Can Write Code Faster Than We Can Review It

László Szabó — Wed, 23 Sep 2026 07:21:40 +0000

Coding agents are getting very good at producing code.

Maybe too good.

One engineer working with agents can now generate multiple meaningful pull requests in the time it previously took to implement a single feature.

That sounds like a massive productivity win.

Until you look at the review queue.

More agent throughput
        ↓
More code
        ↓
More pull requests
        ↓
Same number of experienced reviewers
        ↓
Review becomes the bottleneck

We didn't eliminate the bottleneck.

We moved it.

Why not let another agent review it?

That's the obvious next step.

Agent A
   ↓
writes code
   ↓
Agent B
   ↓
reviews code
   ↓
CI passes
   ↓
merge

And I absolutely think agent review will become an important part of modern engineering pipelines.

But there is an uncomfortable question hiding behind this model:

Who takes responsibility for code that no human has ever reviewed?

This matters a lot more when you're building systems where failures have consequences.

I've worked on cybersecurity products deployed in environments where security and reliability are not abstract quality metrics.

They matter operationally.

In that kind of environment, telling engineers:

"The agents reviewed each other's work."

is not necessarily enough.

Agents can independently catch bugs.

But they can also independently misunderstand the same requirement.

Code generation isn't the same as delivery throughput

There's another problem.

Imagine your agents create ten PRs today.

Your team can realistically review three.

Tomorrow the agents create ten more.

You haven't increased delivery throughput.

You've created 17 pieces of unfinished inventory.

This is basically a queueing problem.

And once you start looking at agentic development through that lens, the optimization target changes.

The question stops being:

How do we make agents generate even more code?

and becomes:

How do we safely move agent-generated changes through the engineering system?

I think the review pipeline needs to change

The answer probably isn't "humans review everything exactly as before."

That doesn't scale.

But I also don't think the answer is "agents approve agents and humans disappear."

A more realistic agent-native pipeline might look something like:

Agent implementation
        ↓
Deterministic verification
        ↓
Independent agent review
        ↓
Risk classification
        ↓
┌───────────────────────────────┐
│ Low risk → automated pipeline │
│ Medium   → targeted review    │
│ High     → deep human review  │
└───────────────────────────────┘
        ↓
Merge queue

The important part is risk.

Changing a typo in documentation isn't the same as changing authentication logic.

Updating a test helper isn't the same as touching authorization, cryptography, persistence, financial calculations, or safety-critical behavior.

Yet most PR workflows still treat them remarkably similarly.

Human attention becomes the scarce resource

Agents make implementation cheaper.

That means something else becomes relatively more expensive:

experienced human judgment.

We should probably stop spending that judgment on things machines can verify reliably.

Humans shouldn't be hunting for:

formatting mistakes
lint violations
missing imports
obvious null errors
trivial test failures
mechanical style inconsistencies

Machines are better suited for those.

Human reviewers should spend their limited attention asking questions such as:

Does this architecture still make sense?
Is the requirement interpreted correctly?
What happens when a dependency fails?
Did we introduce a security boundary violation?
Does this change create an operational risk?
Are there domain assumptions hidden in this implementation?
Is this actually the right solution?

That's where engineering judgment matters.

And sometimes agents should simply stop coding

This may be one of the stranger consequences of agentic development.

If your review queue is already overloaded...

generating more code may have negative value.

That means agent orchestration systems may eventually need WIP limits just like mature manufacturing and Kanban systems.

if review_queue > threshold:
    stop_starting_new_work()

The most productive coding agent might occasionally be the one that decides:

Don't write another PR yet.

This is becoming a real engineering problem

I've been discussing this with people from other companies dealing with variations of the same problem.

The interesting part is that the conversation is already moving beyond:

"How can we use AI to write code?"

toward:

"How do we redesign the SDLC when producing code is no longer the expensive part?"

I've also been experimenting with some of these ideas while building Vincent, particularly around controlled agent workflows, deterministic steps, explicit states, human gates, and workflows that know when they should stop rather than blindly continuing.

I wrote a longer article exploring the problem, possible review architectures, and the parts I still don't think we have good answers for.

👉 When Agents Write Faster Than Humans Can Review

I'm curious how other teams are handling this

If you're already using coding agents heavily:

Has code generation started outpacing your team's review capacity?

And if it has, what did you change?

More automated verification?
Agent reviewers?
Smaller PRs?
Risk-based reviews?
Merge queues?
WIP limits?
Something completely different?

I'd especially love to hear from teams using agents in security-sensitive or high-reliability systems.

Because I suspect the next major problem in agentic software development isn't going to be writing code.

It's going to be deciding what code we can trust.

Vincent 0.9.0: Coding-agent automation that knows when to stop

László Szabó — Fri, 18 Sep 2026 19:39:31 +0000

Vincent 0.9.0 is out.

And while there are plenty of new features in this release, the part I care about most is something less flashy:

Vincent is getting better at knowing what it should not do.

Fourteen days after 0.8.0, the release contains:

428 commits
23 additions
6 changes
11 fixes
57 pull requests represented in the changelog

For anyone unfamiliar with the project, vincent is a local, vendor-independent control plane for coding agents.

It can run tools such as Claude Code, Codex and Cursor through explicit workflows, isolate tasks into branches and worktrees, coordinate parallel work, enforce gates, run verification, and keep the orchestration state on your machine.

0.9.0 takes another major step toward making that model useful for longer-running automation.

Work can now start itself

Until 0.9.0, something had to explicitly invoke vincent.

You could create a task from the TUI, CLI or API, but there was always a direct action that started the process.

0.9.0 introduces event triggers.

Vincent can now react to:

GitHub issues
GitHub pull requests
command output
signed HTTP events
cron schedules
recurring intervals

That means workflows such as these are now possible:

issue receives "agent-please" label
        ↓
Vincent creates task
        ↓
workflow starts
        ↓
agent implements change
        ↓
checks run
        ↓
human reviews result

Or:

02:00 every night
        ↓
dependency audit
        ↓
agent investigates outdated packages
        ↓
proposed changes wait for review

But adding event-driven execution introduces a much more important question:

Who is allowed to turn automation on?

Agents can propose automation. They cannot arm it.

Triggers are intentionally conservative.

A trigger does nothing until both the trigger itself and trigger support globally are enabled.

When a trigger is armed for the first time, vincent records the events that already exist instead of executing a backlog of old work.

Triggered tasks can also default to a paused state.

And there is another rule I consider particularly important:

An agent can create or modify a trigger proposal, but vincent will refuse to apply it if doing so would arm the trigger.

There is no override flag.

The agent can write the automation.

A human decides whether that automation gets authority to run.

That distinction is going to matter more as coding agents become increasingly capable.

From issue to pull request to merge

Vincent 0.8.0 could open a pull request for a task.

0.9.0 goes further.

From the task itself you can now:

inspect PR checks
comment
re-run checks
close a PR
reopen it
merge it

But again, the interesting part is the boundary.

The merge action is not exposed as an MCP tool.

Agents do not get the merge button.

And when a human requests a merge, vincent checks that the exact state being reviewed is still valid.

It refuses the operation if:

the branch is behind
a check is still running
the PR head has moved

The goal is not to eliminate human involvement.

The goal is to make human involvement happen at the places where it actually matters.

Agents now live inside the task container

Containerized tasks are also more complete in 0.9.

Previously, command steps and checks could execute inside the task container while the actual agent CLI still ran on the host.

That meant a supposedly containerized workflow was partially split across environments.

Now, when a task defines a container image, the agent itself runs inside that container as well.

That gives the workflow a much cleaner execution boundary:

task
 └── container
      ├── agent
      ├── commands
      ├── checks
      └── task environment

The transcripts, cost tracking and controls remain available just like they are for host execution.

Talk to a task after it stops

A workflow stopping does not necessarily mean the work is finished.

Sometimes a task is blocked.

Sometimes it is sitting at a gate.

Sometimes it failed in a way that needs investigation.

0.9 adds the ability to open a conversation with an agent directly on that task.

The agent starts with the task context, its branch and the reason execution stopped.

So instead of reconstructing the problem somewhere else, you can investigate it where the work actually happened.

Parallel workflows got harder to break

0.8 introduced fan-out workflows: one task could split an issue into multiple parallel lanes.

0.9 contains the first substantial reinforcement of that system.

Previously, blocked lanes could make the fan-out painful to recover.

Now retrying the parent task can re-admit all blocked lanes below it.

Vincent also tracks resource usage across the whole task tree more accurately, including a new tree-wide spending ceiling:

parent task
├── lane A
├── lane B
├── lane C
├── retries
└── follow-ups

        ↓

one shared cost limit

That matters once a single user action can produce a substantial amount of autonomous work.

Better observability into what the agent actually received

Agent orchestration becomes difficult to debug when configuration comes from several levels.

What model ran?

What effort level?

What exact prompt was rendered?

Was the value set globally, in the workflow or on the step?

0.9 adds a Step Details view that records the actual values when execution happens.

That includes:

rendered prompt or script
agent
model
effort level
source of each configuration value
execution outcome

Older task attempts are not retroactively guessed.

If vincent did not record something at the time, it says so.

That sounds small, but I think this kind of honesty in tooling matters.

A lot of 0.9 is about refusing invalid states

There is a pattern throughout this release.

Vincent now refuses more operations that previously could have been ambiguous or silently incorrect.

For example:

unsafe PR merges are refused
trigger proposals cannot secretly arm automation
invalid retry configuration on unsupported workflow steps is rejected
conflicting TUI keybindings are rejected before being written
branches with commits beyond their base are protected from permanent deletion

That leads to one of the principles behind this release:

Much of a stable release is a promise about what the tool will refuse to do.

Features make automation powerful.

Refusals make it trustworthy.

Better recovery and operational tooling

There are plenty of smaller changes around the edges too.

Scheduled backups can now be maintained by the daemon.

Individual deleted tasks can be restored from an archive.

Agent usage limits are tracked more carefully so multiple tasks do not repeatedly launch processes into a known quota wall.

vincent doctor performs more useful diagnostics.

vincent agents shows installed agent versions, authentication state and quota information.

And vincent can now detect when its installed agent skills are older than the running build.

None of these features make a particularly dramatic screenshot.

They do, however, make a system considerably nicer to operate.

Vincent is building vincent

One metric from this release probably says more about the project than anything else.

Between the 0.8.0 and 0.9.0 tags, 88 pull requests were merged.

76 originated from vincent/ task branches.

The 0.9 release preparation itself was also executed as a vincent workflow: 21 steps that eventually produced the PR used to prepare the release.

Using your own orchestration system to build itself is an extremely effective way to discover where the abstractions break.

And they do break.

0.9 contains plenty of fixes precisely because vincent is now exercising those workflows every day.

The road to 1.0

Vincent is still 0.x.

Some interfaces still change.

Some workflow configurations that previously failed silently are now errors.

Some TUI keys moved to make behavior consistent.

That instability is intentional while the foundations are still being hardened.

For me, the important change in 0.9 is that vincent is starting to feel less like a tool that happens to run coding agents and more like an actual control plane for agent-driven software work.

Something can observe an event.

Decide that work may need to happen.

Create a controlled task.

Run agents in isolated environments.

Fan the work out.

Verify the results.

Produce a pull request.

And then stop at the boundary where a human decision still matters.

That is the direction I want to keep pushing toward 1.0.

📖 Full 0.9.0 release write-up

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

💻 GitHub

https://github.com/lezli01/vincent

Feedback, issues and contributions are very welcome.

Failure Should Be a State, Not a Dead End

László Szabó — Thu, 17 Sep 2026 09:09:16 +0000

AI agents fail.

That part is inevitable.

What matters is what your workflow does next.

In many agentic systems, failure effectively means:

stop the execution
lose useful context
restart the task
rediscover what went wrong
repeat work that already happened

That feels less like recovery and more like starting over.

Failure should be part of the workflow

In vincent, I wanted failure to be something the workflow can represent explicitly.

A failed attempt still has valuable information:

the agent transcript
produced output
timing information
the failure reason
the branch and worktree
everything that happened before the failure

That state should not disappear just because one step failed.

Instead, the workflow can decide what happens next.

Recovery can take different forms

Depending on the situation, you might want to:

🔄 Retry the same task
✏️ Change something and retry
🛠️ Run a repair agent in the existing worktree
⏭️ Skip the failed task
🛑 Cancel the workflow
👤 Ask a human to decide what happens next

The important part is that none of these require pretending the previous attempt never happened.

Restarting an agent is not the same as recovering a workload.

Why this matters

As agent workflows become longer and more complex, failures become normal operational events.

A workflow with ten, twenty, or fifty dependent tasks cannot realistically treat every failure as:

Something failed.
Start again.

The orchestration layer needs to understand failure as a first-class state.

That makes workflows easier to debug, easier to recover, and much safer to run when agents are touching real codebases.

This is especially important for autonomous agents

The more autonomy we give agents, the more important recovery becomes.

Retries alone are not enough.

Sometimes the right response is another agent.

Sometimes it is a human.

Sometimes the task should simply remain blocked until somebody understands what happened.

The orchestration system should preserve enough context to make that decision intelligently.

I wrote more about how I approach this in vincent, my open-source AI SDLC workflow tool:

👉 https://lezli01.is-a.dev/vincent/docs/why/failure-should-be-a-state-not-a-dead-end.html

I’m curious how others are handling this in agent orchestration systems.

Do you treat agent failure mostly as a retry problem, or as workflow state?

The Terminal Should Show the Work, Not Own It

László Szabó — Tue, 15 Sep 2026 06:51:25 +0000

As AI coding agents become more capable, I think we need to rethink one assumption that still shapes a lot of developer tooling:

The terminal session that starts the work should not necessarily own the work.

For short interactions, the traditional model is perfectly fine:

open terminal
→ start agent
→ ask for something
→ get result
→ exit

But agentic development is moving beyond short conversations.

Tasks can now involve:

retries
approval gates
parallel branches
long-running implementation work
rate limits
scheduled execution
external validation
Git worktrees
multiple agents
human intervention halfway through a workflow

At that point, the task starts looking less like a chat session and more like a workload.

The terminal is ephemeral

Terminal sessions are temporary by nature.

You close the tab.
Your SSH connection drops.
Your laptop sleeps.
You restart the application.
You simply want your terminal back for something else.

None of those things should necessarily mean that the underlying work has to disappear with it.

That is the distinction I wanted to make in vincent.

The execution should live somewhere durable

In vincent, workflow execution is owned by a background daemon.

That layer is responsible for things such as:

workflow state
agent processes
scheduling
persistence
retries
approvals
Git worktrees
task lifecycle

The TUI, CLI and API are clients of that state.

They let you inspect and interact with the work, but they do not define its lifetime.

Conceptually:

        CLI
         │
         │
TUI ── Control Plane ── API
         │
         │
    Agent Workloads

Close the TUI and the workload can continue.

Reconnect later and you can inspect the same task again.

Use another client and you are still looking at the same underlying execution state.

Why I think this matters

As coding agents become more autonomous, the distinction between interface and execution lifecycle becomes more important.

We already accept this separation in many other areas of software engineering.

A Kubernetes workload does not disappear because you close kubectl.

A CI pipeline does not stop because you close the browser tab.

A background job does not belong to the shell command that originally enqueued it.

So why should a long-running AI engineering workflow belong to one terminal process?

Agentic coding is becoming infrastructure

The more responsibility we give coding agents, the more orchestration concerns start appearing:

state
retries
concurrency
approval
scheduling
recovery
observability
persistence

Those are not really terminal concerns.

They are control-plane concerns.

And I think developer tools built around agents will increasingly need to treat them that way.

The terminal still matters

None of this means the terminal is going away.

Quite the opposite.

The terminal is still one of the best interfaces for developers.

But there is an important difference between:

"The terminal controls the workload."

and:

"The terminal owns the workload."

I strongly prefer the first.

The terminal should be a window into the system.

Not the system itself.

I wrote more about the reasoning and the architecture behind this approach in the vincent documentation:

👉 https://lezli01.is-a.dev/vincent/docs/why/the-terminal-should-not-own-the-work.html

Vincent is an open-source project exploring workflow-driven, human-controlled AI software development.

I’m curious how other agent frameworks and developer tools approach this problem.

Should long-running coding agents belong to the terminal session that launched them, or to a durable orchestration layer behind it?

Did I Build a Worse LangGraph?

László Szabó — Thu, 10 Sep 2026 10:22:02 +0000

When you build an orchestration tool for AI agents, there is an uncomfortable question you eventually have to ask:

Why does this need to exist when LangGraph already exists?

I recently tried to answer that question for vincent.

And the answer was not that LangGraph and vincent are completely different.

They aren't.

There is substantial overlap.

Both can coordinate agentic workloads. Both can express structured execution. Both can deal with parallel work, retries, long-running processes, and human checkpoints.

The real difference is the level of abstraction.

LangGraph orchestrates what an AI agent does.
vincent orchestrates what AI coding agents do to a software project.

That distinction has turned out to be much more important than I originally expected.

The Repository Is Part of the Workflow

In a typical agent orchestration system, the central abstraction is application state.

Conceptually:

state
  ↓
node
  ↓
new state

For software-development automation, there is another extremely important piece of state:

repository

A coding agent does not merely return structured output.

It modifies files.

Those files live inside Git repositories.

Changes may need to happen in isolated worktrees.

Parallel agents may produce separate branches.

Results may need to pass deterministic verification.

A human may need to approve them.

Eventually, those branches may need to merge.

And that merge may fail.

In vincent, those are not just implementation details around the agent.

They are part of the orchestration model.

Parallelism Means Something Different

Consider a fan-out workflow.

In a general-purpose agent graph, several nodes may execute independently and later combine their resulting state.

For coding agents, parallelism can mean something much more concrete:

main
├── agent-a branch
├── agent-b branch
└── agent-c branch

Each agent works in an isolated repository state.

The join is no longer only about combining application data.

It can literally mean:

git merge

And therefore it can produce:

merge conflict

That changes what the runtime needs to understand.

This Is About Defaults, Not Possibility

An important point in this comparison:

This is not a capability argument.

You can absolutely build repository-aware coding workflows using LangGraph.

You can put repository paths, commit hashes, branch information, diff metadata, and verification results into graph state.

You can implement worktree management.

You can implement merge semantics.

You can build approval gates.

You can integrate coding agents.

The difference is not what is possible.

The difference is what the runtime treats as a first-class concept.

LangGraph deliberately provides flexible, low-level orchestration primitives.

vincent deliberately provides opinionated software-development primitives.

Being Opinionated Has a Cost

That specialization is not universally better.

Quite the opposite.

LangGraph can be used to build an enormous variety of agent systems.

vincent intentionally has a much narrower domain.

Its workflows revolve around concepts such as:

repositories
coding agents
commands
checks
worktrees
branches
approvals
retries
merging
software delivery

If your problem has nothing to do with software-development automation, vincent is probably the wrong abstraction.

That is the tradeoff.

Generality gives you flexibility.

Opinionated semantics give you stronger defaults.

They Can Also Work Together

The comparison becomes even more interesting when you stop thinking about the projects as mutually exclusive.

A sophisticated architecture could look like:

vincent
   ↓
coding workflow
   ↓
custom agent
   ↓
LangGraph
   ↓
reasoning / retrieval / tools / memory
   ↓
repository changes
   ↓
vincent verification / approval / merge

LangGraph could power the intelligence inside an agent.

vincent could govern how that agent is allowed to operate against a real software project.

Those are different responsibilities.

The Full Comparison

I wrote a more detailed breakdown covering the architectural overlap, repository semantics, fan-out/fan-in behavior, human control, durability, and the tradeoffs of an opinionated coding-agent runtime.

You can read it here:

LangGraph vs vincent: generic graph primitives against an opinionated coding-agent runtime

I'd be very interested to hear how others building coding agents, AI development platforms, or LangGraph-based systems think about this separation.

Is repository-aware orchestration something that should live inside the agent framework itself?

Or does it make sense as a separate layer?

Automation Without Giving Up Control — or Your Profession

László Szabó — Wed, 09 Sep 2026 17:53:39 +0000

There is a recurring fear around AI and agentic automation:

If agents can eventually do most of the work, what is left for us?

I think this question starts from the wrong assumption.

It treats professional work as if its value comes primarily from performing individual steps.

Write this code.
Run this command.
Check this test.
Create this pull request.
Deploy this service.

But those steps have never been the whole profession.

The real value comes from knowing why those steps should happen, what good looks like, which trade-offs are acceptable, and when the result is safe to ship.

Agentic automation doesn't necessarily remove that responsibility.

It can actually make it more visible.

Automation changes where your skills are applied

Imagine an experienced software engineer using an agentic workflow.

The agent may:

create an isolated worktree
inspect the codebase
implement a change
add or modify tests
run the test suite
format the code
analyze failures
iterate on the implementation
prepare the result for review

A significant amount of traditional implementation work can happen automatically.

At first glance, that sounds like the engineer is being removed from the process.

But look at what the workflow still depends on.

Someone needs to decide:

What problem are we solving?
Is this actually the right problem?
What architectural constraints apply?
What should the agent be allowed to change?
Which existing behavior must remain compatible?
What level of test coverage is sufficient?
Which trade-offs are acceptable?
What risks deserve additional review?
Is the resulting implementation maintainable?
Should this change actually reach production?

Those aren't incidental details.

They determine whether the automated work produces something valuable or merely produces something.

Execution is not ownership

This distinction becomes increasingly important as agents become more capable.

An agent can execute a task.

That does not mean the agent owns the outcome.

A compiler can compile bad architecture.

A CI pipeline can successfully validate the wrong feature.

An automated deployment system can deploy a perfectly functioning implementation of a bad product decision.

AI doesn't fundamentally change this.

It just increases the amount of execution we can delegate.

The professional still owns the context around that execution.

And that context often requires years of accumulated experience.

The engineer doesn't disappear. The engineer moves up a level.

For a long time, automation has pushed engineering work upward.

We stopped manually writing machine instructions.

We stopped managing memory addresses for most applications.

We stopped manually provisioning every server.

We stopped copying binaries onto production machines.

We automated builds.

We automated tests.

We automated infrastructure.

We automated deployment.

And software engineering did not disappear.

Instead, the abstraction level moved.

Agentic development is another step in that direction.

If an agent can handle more of the implementation loop, the engineer can spend more attention on:

Architecture

How should the system evolve?

Product understanding

What actually creates value for the user?

Constraints

What must never be violated?

Risk

What could go wrong, and how serious would it be?

Evaluation

How do we know the result is actually correct?

Direction

What should happen next?

Judgment

When is the machine technically successful but professionally wrong?

These are not secondary skills.

They increasingly become the job.

Full automation does not have to mean zero control

There is another false choice hidden in many conversations about AI automation.

Either:

a human supervises every individual step, or
the agent receives complete autonomy and we accept whatever happens.

Neither model is particularly attractive.

If I have to approve every command, I haven't automated much.

But if the system can freely publish packages, merge code, deploy services, or modify external systems without meaningful boundaries, I've probably automated too much.

There is a better model.

Automate aggressively inside well-defined boundaries.

Then require human judgment when crossing the boundaries that matter.

Execution permission is not delivery authorization

This is a principle I've been thinking about while building vincent.

An agent may need considerable freedom while working on a task.

For example, inside an isolated worktree it may be perfectly reasonable to allow it to:

edit files
run commands
execute tests
retry failed approaches
generate artifacts
inspect diffs

Requiring approval after every action would destroy much of the value of agentic automation.

But that doesn't mean the same agent automatically receives permission to:

merge the pull request
publish the package
deploy to production
close the issue
release the artifact

Those are different permissions.

I think of it as:

Execution permission != delivery authorization

The agent can be trusted to explore and execute within the task while the professional retains authority over whether the outcome crosses an important external boundary.

Human gates should be part of the workflow

This is why vincent has explicit manual steps.

A workflow can execute automatically until it reaches a meaningful decision point.

At that point it pauses.

The state of the task remains available for inspection: the branch, worktree, results, transcripts, and diff.

The professional can then decide whether to:

approve and continue
reject the result
skip the action where appropriate

The important part is that the approval isn't an informal convention.

It is part of the executable workflow.

For example, conceptually:

steps:
  - agent:
      task: implement-feature

  - command:
      run: dotnet test

  - manual:
      message: Review the implementation before creating the PR

  - command:
      run: create-pull-request

Everything before the gate can run efficiently.

But the action that changes the outside world requires a deliberate decision.

Where you put the human matters

Simply saying "a human reviews AI-generated code" isn't enough.

Review timing matters.

Consider this workflow:

agent writes code
↓
tests run
↓
PR created
↓
package published
↓
deployment starts
↓
human reviews eventually

Technically, there is a human in the loop.

Practically, there isn't much control.

Compare it with:

agent writes code
↓
tests run
↓
results collected
↓
HUMAN DECISION
↓
PR / publish / deploy

Now the approval has meaning.

It defines a clear boundary:

Everything before this point may happen automatically. Crossing this point requires authorization.

That is much stronger than relying on someone to notice afterwards that automation made a poor decision.

Expertise becomes the input to automation

There is another reason I don't believe agentic development automatically devalues experienced professionals.

Good automation is built from expertise.

Consider two engineers asking an agent to implement the same feature.

One says:

Implement feature X.

The other provides:

relevant architecture
domain constraints
compatibility requirements
testing expectations
security boundaries
expected failure modes
performance constraints
acceptance criteria

They may technically be using the same model.

They are not going to get the same result.

The quality of agentic work depends heavily on the quality of the environment, constraints, workflow, evaluation, and decisions surrounding the agent.

And creating those things requires understanding the profession.

The valuable skill is increasingly knowing what to automate

There is an interesting inversion happening.

Previously, professional expertise was mostly demonstrated by performing difficult work yourself.

Increasingly, another form of expertise is becoming important:

Knowing which parts you no longer need to perform manually.

That means recognizing repetitive processes.

Turning implicit knowledge into explicit constraints.

Building reliable verification.

Separating reversible actions from dangerous ones.

Designing useful approval boundaries.

Creating workflows that can fail safely.

Giving agents enough autonomy to be useful without giving them authority they don't need.

That is engineering too.

Automation should amplify expertise, not erase it

I don't want an AI agent that needs me to press Continue every 30 seconds.

That isn't meaningful automation.

I also don't want an AI agent making every consequential decision simply because it technically can.

The useful space lies between those extremes.

Let agents do what machines are increasingly good at:

repetition
exploration
execution
iteration
mechanical verification
information gathering

And let professionals concentrate on what expertise is particularly valuable for:

intention
architecture
judgment
trade-offs
risk
quality
accountability

The goal isn't to keep humans artificially busy.

It's to make sure human attention is spent where it has the highest value.

Our profession will change

I don't think software engineering ten years from now will look exactly like software engineering today.

It shouldn't.

Our profession has always changed as our tools improved.

Some tasks we currently consider fundamental may become almost entirely automated.

Other skills will become far more important.

We may spend less time writing individual implementations and more time designing systems in which implementations can be generated, evaluated, rejected, improved, and safely delivered.

But that is not the same thing as giving up the profession.

It is the profession evolving.

The engineer who understands the system, defines the boundaries, evaluates the result, and owns the outcome still matters enormously.

Perhaps more than ever.

The point is not to stay in the loop everywhere

It's to stay in the loop where your judgment matters.

That's the philosophy I'm trying to apply while building vincent: automate repeatable agentic workloads without forcing professionals to surrender control over their outcomes.

Agents can execute.

Automation can orchestrate.

But professionals still decide what success means.

And ultimately, that decision determines the outcome.

If you're interested in the implementation side of this idea, I wrote a shorter piece in the vincent documentation about explicit approval gates and separating execution permission from delivery authorization:

👉 Automation without giving up control

And if you're interested in vincent itself:

👉 vincent — durable local orchestration for agentic development

🔥 HotRulez just passed 1,000 downloads

László Szabó — Mon, 07 Sep 2026 06:34:39 +0000

HotRulez has officially passed 1,000 downloads on the JetBrains Marketplace. 🎉

I originally built it for a very simple reason:

I wanted proper tooling for Firebase Security Rules in my IDE, but every option I found was paid.

So I built my own — and released it free and open source under the MIT license.

HotRulez adds proper .rules file support to JetBrains IDEs, including Android Studio and IntelliJ IDEA.

Some of the features include:

🔥 Syntax highlighting
🧹 Formatting
🔎 Structural diagnostics
🧭 Symbol resolution and navigation
📚 Quick documentation
🧱 Structure view and code folding
💡 Quick fixes and member inspections

Roughly two months after its first Marketplace release, the download counter crossed 1,000.

That's obviously a small number compared with huge developer tools, but for a niche plugin I originally created because I personally wanted it to exist, it means a lot.

More importantly, downloads continued growing after the initial launch traffic disappeared.

That tells me something I find much more interesting than the number itself:

Other developers had the same problem.

I wrote more about the milestone, what HotRulez supports today, and what I've learned from seeing people actually use it:

👉 HotRulez crossed 1,000 downloads — and I'm pretty proud of that

HotRulez is open source, and feedback and contributions are always welcome.

Resolving one GitHub issue as a DAG of parallel AI agents

László Szabó — Sun, 06 Sep 2026 12:58:06 +0000

One AI coding agent is still fundamentally sequential.

It reads something, changes something, runs a test, reacts to the result, and moves to the next piece of work.

Giving it more tokens doesn't change that execution model.

With vincent 0.8.0, I wanted to explore a different approach: split an issue into a dependency graph of work units and let independent agents execute those units concurrently.

The model is simple:

nodes are implementation units
needs edges describe real dependencies
independent nodes can run in parallel
each unit gets its own branch and worktree
dependent units start from a branch that already contains their dependencies
an integration step validates the combined result

I’ve now been running this workflow against vincent itself.

A real run

Issue #324 was decomposed into three units across two waves.

Wave 1 produced a dependency required by the remaining work.

Wave 2 then ran two independent implementation lanes concurrently.

Their individual coding times were roughly:

4m18s
10m22s

Sequentially: ~14m40s.

As one parallel wave: ~10m22s.

So this particular run saved around four minutes.

That number isn't spectacular, and I don't want to pretend it is.

What's more interesting is the scaling property:

the floor becomes the longest dependency chain through the graph rather than the sum of all independent work.

There are costs, of course.

More parallel lanes mean more agent sessions, more worktrees, more merges, and more opportunities for integration problems. The article goes into those trade-offs as well as how vincent constrains lanes to avoid agents modifying overlapping files.

I also found something counterintuitive while testing the scheduler.

vincent supports both barrier and eager DAG scheduling.

eager sounds obviously better because dependent work can start as soon as its own dependencies finish.

But across the real workflows I've run so far, it saved zero additional time compared with barrier.

What it did sacrifice was reproducibility: an eagerly scheduled lane can start from a different branch state depending on timing.

For agent-generated code, that's a meaningful debugging cost.

My takeaway so far:

Get the graph right first. The scheduler is the last thing to optimize.

I wrote up the implementation, actual workflow, real timings, costs, failure modes, and the lessons from running it on vincent itself:

https://blog.lezli01.is-a.dev/blog/vincent-dag-workflows/#two-waves-on-a-real-issue

vincent v0.8.0: From Agent Conversations to Durable Workflows

László Szabó — Sun, 06 Sep 2026 11:59:23 +0000

I've released vincent v0.8.0, and this release pushes the project much further toward the workflow I've wanted from coding agents from the beginning:

explore conversationally, then turn that work into controlled and repeatable execution.

Chat first. Workflow when you're ready.

One of the biggest additions is free chat.

vincent can now maintain conversational coding sessions with Claude, Codex and Cursor, each running against its own Git worktree and branch.

But the important part isn't simply having another chat interface.

A chat can now be handed off directly to a task.

The task adopts the same worktree, branch, base revision and existing changes. Nothing needs to be copied or recreated.

That means you can:

Explore a problem interactively with an agent.
Inspect or modify the result.
Decide that the direction is worth pursuing.
Hand the existing workspace to a structured vincent workflow.
Let deterministic commands, agents, checks, gates and fan-out take over.

That transition between exploration and orchestration has been one of the missing pieces in agentic development for me.

Fan-out is becoming a real execution graph

v0.8.0 also significantly expands parallel agent workloads.

Fan-out lanes can now depend on sibling lanes using needs:.

They can also be derived dynamically at runtime, allowing a planning step to decide what work should exist rather than requiring the complete graph to be hard-coded in advance.

And with schedule: eager, dependent work can start as soon as its actual dependencies have completed instead of waiting for every unrelated lane in the current round.

This makes workflows such as:

planning → parallel implementation → dependent implementation → integration

much more natural to express.

Importantly, barrier scheduling remains the default because eager scheduling intentionally trades some reproducibility for throughput.

Better observability

Agent orchestration becomes difficult very quickly if you can't answer:

What did the agent actually receive?

v0.8.0 adds a new Step Details view that records the resolved execution context at the time the step runs.

That includes things such as:

the fully rendered prompt or command
agent, model and effort resolution
permission mode
timeouts
loop and fan-out context
rendered conditions
token usage
cost
duration
exit codes
failure reasons

This information is recorded when execution happens instead of being reconstructed later from configuration that may already have changed.

For debugging non-deterministic workflows, that distinction matters.

Containers, GitHub and workflow authoring

There is quite a bit more in this release.

Task command/check steps can now execute inside task-scoped containers.

vincent can create GitHub pull requests directly from completed work and display live CI checks inside the task workspace.

The TUI workflow editor has grown from editing a subset of workflow properties into a much more complete structured editor, including nested fan-out lanes, defaults, fields and control-flow settings.

Daemon configuration can also be inspected and edited through the API, CLI and TUI.

Better everyday interaction

A large amount of work also went into making vincent nicer to actually use every day.

Assistant output now has richer Markdown rendering, including tables, links and highlighted code blocks.

There is a raw/rendered toggle and better copy support.

Chat scrolling and navigation have improved.

And there's now a quiet output level for the times when you want to read the conversation rather than every tool invocation behind it.

vincent can also surface real usage quota windows from Codex and Claude Code where those CLIs make the information available.

Where vincent is heading

The individual features are useful, but v0.8.0 is really about the direction of the project.

I don't think agentic software development should be reduced to repeatedly opening a coding agent and writing increasingly elaborate prompts.

There should be a layer around those agents that understands:

execution
dependencies
concurrency
human gates
Git state
retries
failures
costs
provenance
observability
recovery

while still leaving room for the interactive conversation that makes coding agents so useful in the first place.

That's the problem I'm trying to solve with vincent.

The complete v0.8.0 release notes are here:

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

I'd especially love feedback from people already using coding agents for workflows that go beyond a single interactive session.

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

DEV Community: László Szabó

Vincent 0.10.0: Less Hype, More Reliability for Agentic Development

First: what is vincent?

Skills are now much more natural in chat

Skill execution is visible too

@file mentions arrive in chat

Work on a branch that already exists

Multiline chat input

/clear is represented correctly

Send messages from files or stdin

Safer global workflow updates

And a lot of fixes

Why I like releases like this

Try vincent

AI Can Write Code Faster Than We Can Review It

Why not let another agent review it?

Code generation isn't the same as delivery throughput

I think the review pipeline needs to change

Human attention becomes the scarce resource

And sometimes agents should simply stop coding

This is becoming a real engineering problem

I'm curious how other teams are handling this

Vincent 0.9.0: Coding-agent automation that knows when to stop

Work can now start itself

Agents can propose automation. They cannot arm it.

From issue to pull request to merge

Agents now live inside the task container

Talk to a task after it stops

Parallel workflows got harder to break

Better observability into what the agent actually received

A lot of 0.9 is about refusing invalid states

Better recovery and operational tooling

Vincent is building vincent

The road to 1.0

Failure Should Be a State, Not a Dead End

Failure should be part of the workflow

Recovery can take different forms

Why this matters

This is especially important for autonomous agents

The Terminal Should Show the Work, Not Own It

The terminal is ephemeral

The execution should live somewhere durable

Why I think this matters

Agentic coding is becoming infrastructure

The terminal still matters

Did I Build a Worse LangGraph?

The Repository Is Part of the Workflow

Parallelism Means Something Different

This Is About Defaults, Not Possibility

Being Opinionated Has a Cost

They Can Also Work Together

The Full Comparison

Automation Without Giving Up Control — or Your Profession

Automation changes where your skills are applied

Execution is not ownership

The engineer doesn't disappear. The engineer moves up a level.

Full automation does not have to mean zero control

Execution permission is not delivery authorization

Human gates should be part of the workflow

Where you put the human matters

Expertise becomes the input to automation

The valuable skill is increasingly knowing what to automate

Automation should amplify expertise, not erase it

Our profession will change

The point is not to stay in the loop everywhere

🔥 HotRulez just passed 1,000 downloads

Resolving one GitHub issue as a DAG of parallel AI agents

A real run

vincent v0.8.0: From Agent Conversations to Durable Workflows

Chat first. Workflow when you're ready.

Fan-out is becoming a real execution graph

Better observability

Containers, GitHub and workflow authoring

Better everyday interaction

Where vincent is heading

Vincent 0.7.0: The control plane now runs its own development

Workflows became real interfaces

Recovery became part of the workflow

The control plane became scriptable

Vincent builds Vincent

`@file` mentions arrive in chat

`/clear` is represented correctly