DEV Community: László Szabó

Professional Antipatterns: The CTO Who Chose Agentic Development Over Agentic Development

László Szabó — Mon, 05 Oct 2026 16:30:23 +0000

A colleague recently gave an internal presentation about GitHub's Spec Kit and spec-driven development.

It was a good presentation.

The demo was practical. Claude Code and Cursor were used as the coding agents. The workflow showed how you can take an idea, turn it into a specification, create a technical plan, break that plan into tasks, and then let the agent work through the implementation.

At the end, the presenter asked our CTO what he thought.

The answer was approximately:

"It's cool, but I think we're going to go with agentic development instead."

There was a short silence.

Because we had just spent the presentation looking at...

agentic development.

Wait, isn't Spec Kit agentic?

Yes.

That's what made the answer so strange.

Spec Kit isn't competing with Claude Code, Cursor, Copilot, or other coding agents.

It gives those agents a process.

Instead of:

Build this feature.

and hoping the agent correctly reconstructs all the missing context, the workflow becomes something closer to:

idea
  ↓
specification
  ↓
technical plan
  ↓
tasks
  ↓
agent implementation
  ↓
validation / convergence

The agent is still doing the work.

In fact, that's the whole point.

You're giving an autonomous or semi-autonomous coding agent better inputs, clearer boundaries, persistent artifacts, and checkpoints where a human can review what is happening.

You can absolutely disagree with that approach.

Maybe specifications create too much overhead.

Maybe your team works on changes small enough that a formal planning phase isn't useful.

Maybe you want agents to operate with significantly more autonomy.

Maybe you have a completely different orchestration model.

Those would all be interesting discussions.

But:

"We won't use this because we're going agentic."

isn't really one of them.

It's like watching someone demonstrate Kubernetes and responding:

"Looks interesting, but we're going with containers."

The actual antipattern

The funny part isn't that someone didn't understand Spec Kit.

Nobody understands everything.

Especially now.

The AI development ecosystem is moving ridiculously fast. New agent frameworks, protocols, models, IDE integrations, orchestration patterns, and methodologies appear constantly.

A CTO not knowing the details of one of them is completely normal.

The antipattern is something else:

Feeling that being the most senior technical person in the room means you must always have an answer.

When you don't understand something, there are two options.

You can ask:

"Help me understand how this differs from the agentic approach we're considering."

Or:

"Where does the human stay in the loop here?"

Or simply:

"I don't know Spec Kit well enough yet. Walk me through how it fits into an agent-based workflow."

All three are good questions.

And none of them make a technical leader look weak.

Quite the opposite.

Engineers can tell

Trying to bluff through a technical discussion has an unfortunate property:

The people you're bluffing are usually technical too.

They know.

The moment a confident answer reveals that the underlying concept wasn't understood, something changes in the room.

And it's not just about that one topic.

People start wondering:

If this decision wasn't based on understanding the thing we just demonstrated...

what are the bigger technical decisions based on?

That is where the real damage happens.

A CTO doesn't need to personally know every framework.

A CTO does need engineers to trust the reasoning behind technical direction.

And trust is surprisingly easy to lose.

"I don't know" is an underrated leadership skill

One of the strongest things a technical leader can say is:

"I don't know."

Followed by:

"Explain it to me."

That creates a completely different engineering culture.

It tells people that learning is more important than appearing knowledgeable.

It tells senior engineers that their expertise is actually wanted.

It makes technical discussions about finding the right answer rather than defending hierarchy.

And perhaps most importantly, it makes it safe for everyone else to admit when they don't know something either.

If the CTO has to pretend to understand everything, eventually everyone below the CTO learns to do the same.

That's not a great environment for engineering.

Agentic development needs more structure, not less

There's another interesting part of this story.

As coding agents become more capable, the need for good specifications doesn't disappear.

Arguably, it becomes more important.

When a developer writes every line manually, misunderstandings are discovered gradually during implementation.

When an agent can produce thousands of lines of code in minutes, it can also implement the wrong interpretation incredibly efficiently.

The bottleneck starts moving.

Less:

How quickly can we write this?

Did we clearly define what should be built?
Did the agent understand the constraints?
Can we review the decisions it made?
Can we verify the result?

That's exactly why specifications, plans, acceptance criteria, checkpoints, and review workflows are becoming interesting again.

Agentic engineering doesn't make engineering discipline obsolete.

It changes where that discipline needs to live.

The lesson

This isn't really a story about Spec Kit.

And it's not about whether Spec Kit is the best way to build software with agents.

It's about technical leadership.

You don't lose credibility because you haven't heard of something.

You don't lose credibility because an engineer knows more about a particular technology than you do.

You don't even lose credibility by saying:

"I don't understand this yet."

You lose credibility when everyone in the room realizes you don't understand something...

while you're pretending that you do.

A question might cost you five seconds of looking less than omniscient.

A confident non-answer can cost you the trust of every engineer who heard it.

This is part of my Professional Antipatterns series: stories about the strange ways software organizations sometimes manage to make engineering harder than it needs to be.

Originally published at:

https://blog.lezli01.is-a.dev/blog/professional-antipatterns-cto-spec-kit/

I Built an Agent Skill to Make Management Happy

László Szabó — Tue, 29 Sep 2026 12:43:47 +0000

It didn't make me write better code.

It didn't make me deliver features faster.

It didn't make the product more reliable.

It made me commit more often.

And according to the KPI dashboard, that meant I had improved.

A while ago, I worked at a company where individual Git commit counts were tracked as an engineering performance metric.

One day, I was told that my number of commits was lower than some of my coworkers'.

I needed to improve it.

There was one small problem.

At the time, I wasn't working purely as an individual contributor.

I was simultaneously doing things like:

software architecture
technical decision-making
mentoring
code reviews
team leadership
debugging difficult problems
coordinating work across products
and, occasionally, actually writing code

Most of those things produce exactly zero Git commits.

But the dashboard didn't know that.

The dashboard knew one thing:

commits = productivity

So I decided to improve my productivity.

At least according to the dashboard.

I built an agent skill

My normal development style was fairly simple.

I would work on a coherent piece of functionality, finish it, review the changes, and commit it.

Sometimes that meant one commit.

Sometimes a few.

I never thought:

"How many commits should this work generate so my KPI looks good?"

Apparently, I should have.

So I created an agent skill called:

crazy-commiting

Its job was simple.

Take my current changes and split them into the maximum number of reasonable, coherent commits.

Not fake commits.

Not whitespace changes.

Not:

fix
fix2
final fix
final fix 2
really final

Every commit still had to make sense independently.

The agent would inspect my changes, determine which parts could logically stand on their own, stage them separately, and create proper commit messages.

Instead of doing this:

Implement user synchronization

I might now get something closer to:

Add synchronization configuration model
Add repository method for loading remote users
Implement user mapping logic
Add synchronization service
Add synchronization validation
Add synchronization error handling
Add synchronization tests

Same feature.

Same code.

Same amount of engineering work.

Much better KPI.

My workflow effectively became:

finish work
↓
review changes
↓
"do the crazy commiting"
↓
agent generates many clean commits
↓
push

And something interesting happened.

Management was happy

A few weeks later, my numbers had improved.

Management noticed.

The KPI dashboard was happy.

Therefore, apparently, my performance had improved.

Except nothing meaningful had changed.

I hadn't become a better engineer.

I hadn't started delivering dramatically more value.

I hadn't suddenly become more productive.

I had simply optimized my behavior for the measurement system.

Same engineer.

Same work.

Same code.

More commits.

Better performance according to the dashboard.

That was probably the clearest demonstration of Goodhart's Law I've personally experienced:

When a measure becomes a target, it stops being a good measure.

The funny part is that I didn't even need to game the system dishonestly.

I automated the completely legitimate act of making smaller commits.

The metric did the rest.

A commit has no unit of value

The fundamental problem with commit count is that a commit doesn't represent a standardized amount of work.

These are both one commit:

Fix typo in error message

and:

Migrate authentication subsystem to new identity provider

One might represent thirty seconds of work.

The other might represent three weeks of investigation, architecture discussions, implementation, testing, deployment planning, and coordination.

Git doesn't care.

The counter goes:

1
1

You can also take exactly the same change and represent it as:

1 commit

or:

4 commits

or:

17 commits

without changing the final state of the repository at all.

That's not a great property for something you're using to evaluate human performance.

It gets worse for senior engineers

Commit count becomes even less meaningful as engineers become more senior.

Imagine a staff engineer spends an afternoon helping three teams avoid a bad architectural decision.

The outcome could be:

commits: 0

Another engineer spends that afternoon implementing the agreed solution.

Their outcome might be:

commits: 6

Who contributed more?

That's not even the right question.

They contributed in different ways.

A technical lead might spend time:

reviewing pull requests
mentoring engineers
designing systems
investigating production incidents
coordinating migrations
reducing technical risk
challenging unnecessary complexity
helping someone else solve a problem
preventing bad code from being written in the first place

The best architectural decision of the week might result in:

0 lines added
0 commits
0 pull requests

because someone realized that a new service didn't need to exist.

That's still engineering.

Sometimes the most valuable code is the code you successfully convince the team not to write.

The metric changes the behavior

This is the part that worries me more than the accuracy of the dashboard.

People adapt to incentives.

If engineers know commits are measured, eventually they start optimizing commits.

If lines of code are measured, they'll produce more lines.

If story points are measured, suddenly every task becomes an eight.

If pull requests are measured, features get fragmented into unnecessary PRs.

If tickets closed are measured, tickets get smaller.

You haven't necessarily improved productivity.

You've improved people's ability to produce the thing being counted.

My agent skill just made the feedback loop extremely obvious.

I effectively automated KPI optimization.

And the dashboard couldn't tell the difference between:

engineer became more productive

and:

engineer learned how the measurement works

That is a serious problem if the number is being used for performance management.

Activity metrics aren't necessarily useless

This doesn't mean commit data has zero value.

A sudden change in activity can be useful context.

If someone normally contributes regularly and disappears from the repository for three weeks, it might be worth asking:

"What are you working on?"

Maybe they're stuck.

Maybe they're doing architecture work.

Maybe they're mentoring a new engineer.

Maybe they're investigating production issues.

Maybe their work is happening in another repository.

Maybe they're disengaged.

The commit graph can help start the conversation.

The problem begins when we skip the conversation and let the graph become the conclusion.

signal → question → context → understanding

is useful.

signal → performance score

is dangerous.

What should we measure instead?

There isn't one magical replacement metric.

That's kind of the point.

Software engineering is a complex system.

Frameworks such as DORA focus much more on how effectively software moves through an organization: delivery speed, reliability, recovery, and the performance of the delivery system.

The SPACE framework explicitly treats developer productivity as multidimensional, covering things like satisfaction, performance, activity, communication, collaboration, efficiency, and flow.

Notice the important difference.

They aren't trying to find:

developer_productivity = some_counter

because that number probably doesn't exist.

For individuals, I'd much rather have conversations around things like:

What did you help deliver?
What difficult problems did you solve?
What risks did you reduce?
What did you improve?
Who did you unblock?
What knowledge did you spread?
Did your decisions make the team faster?
Did the system become easier or harder to maintain?
Did the product become better?

Those questions are messier than a dashboard.

They're also much closer to the work we're actually trying to evaluate.

AI makes this problem even more interesting

There's another reason I've been thinking about this lately.

AI coding agents make activity metrics even easier to inflate.

Generating:

commits
pull requests
lines of code
tests
documentation
tickets

is becoming increasingly cheap.

If an organization measures engineering productivity primarily through visible repository activity, agents can generate enormous amounts of apparently productive activity.

That doesn't necessarily mean more value is being delivered.

In my case, the agent wasn't even writing more code.

It was simply reorganizing the same code into a shape that made the KPI dashboard happier.

We're entering an era where optimizing superficial engineering metrics can literally be delegated to an agent.

That should probably make us reconsider the metrics.

The weirdest part

I originally created crazy-commiting partly because I thought the situation was absurd.

But it worked.

The number went up.

The dashboard showed improvement.

Management was happy.

And that might be the best test of a bad KPI I've found so far:

If I can improve the metric significantly with an agent without improving the product, the team, or the engineering outcome, what exactly is the metric measuring?

Probably not productivity.

This is part of my Professional Antipatterns series, where I write about strange, counterproductive, and occasionally absurd things I've encountered in software engineering — without naming the companies or people involved.

The original post is also available on my blog:

https://blog.lezli01.is-a.dev/blog/professional-antipatterns-commit-count/

If you've encountered similarly questionable engineering KPIs, I'd genuinely like to hear the story.

Because somewhere out there, a dashboard is probably congratulating someone for generating their 47th commit today.

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.

DEV Community: László Szabó

Professional Antipatterns: The CTO Who Chose Agentic Development Over Agentic Development

Wait, isn't Spec Kit agentic?

The actual antipattern

Engineers can tell

"I don't know" is an underrated leadership skill

Agentic development needs more structure, not less

The lesson

I Built an Agent Skill to Make Management Happy

I built an agent skill

Management was happy

A commit has no unit of value

It gets worse for senior engineers

The metric changes the behavior

Activity metrics aren't necessarily useless

What should we measure instead?

AI makes this problem even more interesting

The weirdest part

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

`@file` mentions arrive in chat

`/clear` is represented correctly