Engineering for Agents That Never Sleep
Originally posted on X.
At Cognition, 70% of all Devin sessions are currently kicked off by a person (through the webapp, Slack, or Linear). The other 30% start automatically via API, scheduled sessions, scheduled Devins, and other automations.
That ratio will continue to invert. Within a few months it will likely be 30/70. Within a year, 10/90.
The interesting question is why.
Most of the signals that trigger engineering work are already machine-readable. An alert fires. A test fails. A spec gets approved on a project board. A deploy goes out and latency spikes. Right now, a human reads that signal, context-switches, opens a session, and types a prompt telling the agent what the signal already said.
That person is acting as a relay between two systems that could talk directly.
Once you see it that way, the prompt is the bottleneck. The alert, the failing test, the approved spec, any of these can kick off an agent directly.
The engineer’s job becomes designing the system of triggers, constraints, and quality gates that let agents run reliably on their own.
Cloud agents are the foundation. You can’t wire an agent into your incident response pipeline if it only exists when someone’s IDE is open.
The prerequisite is unglamorous but real: comprehensive unit tests so agents can verify their own output, good documentation so agents have context without asking, reproducible dev environments so agents can run code without custom setup, and rich system context so agents understand architecture, conventions, and how services interact beyond what any single repo tells them.
That scaffolding is the difference between an agent that opens a PR and an agent that closes an incident at 3am. Without it, you have agents that write code. With it, you have agents that ship software.
The prompt box will still exist, but on the best teams, most of the work will already be underway before anyone opens it.
With Devin, this is where we think the puck is headed. If you’d like to learn more, reach out.



Right now you could have an agent knock out a user story while you sleep and have a PR ready for you in the morning. The issue is writing a detailed enough user story so it can do TDD and not make business logic errors or misunderstandings.
Sounds like a good way to spam Jira