Autonomous Software Development: Who Decides to Start

You save a schedule in AuricIDE: weekdays at 09:00, action Conductor, Start by itself switched on. At 09:00 another agent is still running, so AuricIDE refuses the Conductor start and shows a toast that names the reason. Nothing crashed. The schedule was valid. The time was right. Starting it would have put two runs in charge at once.

Now leave Start by itself off. A schedule is a cron expression or an interval plus one action: Reminder only, Skill, Combo, Conductor or Custom agent. At 09:00 it becomes an inbox button, whatever the action. Nothing starts until someone clicks. The entry stores the action. The click makes the decision.

Is autonomy just an agent that can reach further?

No. The obvious reading says autonomy is reach: the agent takes a ticket, edits files and runs checks while you are away, so the job is to widen what it can do alone. The reach is real. Demirer, Musolff and Yang studied more than 500,000 GitHub developers in NBER working paper 35275 and found that autonomous coding agents raised commits by 240%, projects by 80% and releases by 30%. A commit records activity. A release records something shipped. The authors read the gap as human bottlenecks further down the chain.

Now put that agent behind a calendar entry, and the question changes. A second run can start while the first is still working. A project switch is a bad moment when you have unsaved tabs. The entry records a decision made earlier, under other conditions. It cannot know that you are mid-edit at 09:00 or that another agent already holds the ticket. A shared workshop calendar can reserve the bench for nine o'clock. Somebody still opens the door.

Autonomous software development is decided less by how capable the agent is than by the conditions under which the app refuses to start it, and by what you hear when the run ends. A stronger agent could shorten that list of conditions. It could not answer whether this start, right now, is a good idea.

When does AuricIDE start without a click?

Start by itself is the one switch that can, and the guards still get a vote. It is off by default. It sits on Skill, Custom agent and Conductor entries, so Reminder only and Combo always wait for a click. A Combo starts on that click and runs its steps in order, each with the provider and permission it is pinned to. Skill and Custom agent entries also have a Headless checkbox. Turning on Start by itself ticks it, and you can untick it. Conductor has no Headless box.

The guards depend on the action and on how late the occurrence is.

A Skill can start while you are typing because it does not switch the open project. The Conductor can switch projects, so for that one case it waits for saved tabs and a quiet machine. When there are no ready tickets, the toast says the cycle was skipped, which makes an empty night visible instead of leaving you to wonder.

A refusal is not a failure.

What do you hear after a run?

It depends on the run. A finished headless run leaves an inbox entry named <name> finished, with a summary. A failed agent gets a toast and an inbox entry named <name> failed. Both stay hidden while the Conductor will retry the ticket, because a failure the app is about to handle is a false alarm. Only the final, given-up failure raises the toast. With the judge on, a rejected ticket returns to Open with the reason. Two attempts is the limit. A crash, a missing verdict or a 10 minute review timeout counts as a rejection.

A Conductor run ends more quietly. The agents it spawns leave no finished entry of their own. One inbox entry says Conductor run finished and tells you that tickets are done or how many started. It does not describe what changed. If the window is in the background, a system banner announces the finish too.

Silence has two labels. An interactive agent shows Stalled? after 120 seconds without output. A headless agent shows Long run? 45 minutes after launch, counted from the launch and not from its last line of output. Neither label says the agent failed. Each tells you which kind of silence the app has noticed.

A restart ends the old process. The agent appears as Interrupted with a Resume button, and Resume starts a fresh session with a continuation prompt. The same signals are laid out in how AuricIDE monitors running agents.

What does this restraint cost?

Coverage. AuricIDE gives up unattended hours so that a self-start is something you switch on deliberately, and so that everything else waits for a person.

Closed app, stopped clock. Close the lid and the next slot does nothing. Switched off, a Mac runs nothing. You feel the missing overnight run. The app stops with the window instead of leaving a helper behind.

Late means button, not catch-up. An occurrence older than 15 minutes drops back to a button. You lose the catch-up. You also avoid a run that begins while you are in the middle of something else.

A short ending. A Conductor run closes with one line in the inbox. You hear that it is over, and you open the tickets to learn what happened.

No file watcher and no webhook. AuricIDE has nothing that starts an agent because a file changed or a request arrived. A schedule has to be written down first, and even then the switch and the guards decide whether it starts.

Every button hands the next move to a person. That attention is part of what an agent costs, and no invoice shows it.

What holds in another tool?

Unattended work is judged by the starts a tool will refuse and by who hears the ending. Test both. Leave an unsaved tab open, make two things due at once, close the app before the due minute, and see which start, which wait and which tell you why. Then check the end: a finished notice only tells you to look, and Resume may continue the old process or start a new one. The same test fits any software development automation that keeps going with nobody at the keyboard. A start that cannot be declined is exposure, not autonomy.