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 reason is simple: most signals that create engineering work are already readable by software.
Most engineering work starts from signals that systems already produce. Today, a person reads those signals, switches context, opens Devin, and writes a prompt that repeats information the system already had.
That person is acting as a relay between two systems that could talk directly.
That manual handoff can go away.
The alert can start Devin. The failing test can start Devin. The approved spec can start Devin. The latency spike can start Devin.
The engineer’s job shifts to setting up the triggers, constraints, and quality gates that let those sessions run safely and produce usable work.
That requires agents that run in the cloud. An incident pipeline needs to be able to start an agent whether or not someone has an IDE open.
It also requires the basics: comprehensive unit tests, clear documentation, reproducible dev environments, and enough system context for the agent to understand architecture, conventions, dependencies, and service interactions across repos.
That setup determines how useful the agent is. With the right tests, docs, environments, and context, Devin can open PRs, validate changes, and handle real operational work.
The prompt box will still be there. On strong engineering teams, more of the work will already be started 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