--- title: "Rails behind Dagny’s Rails | Dagny" description: "Inside the software factory that helps our team build, ship, and improve with AI." canonical: "https://dagnylabs.ai/blog/rails-behind-dagnys-rails" last-updated: "2026-10-25T13:46:10Z" --- # Rails behind Dagny’s Rails | Dagny [HTML page](/blog/rails-behind-dagnys-rails) [All field notes](/blog) How we work October 13, 2026 7 min read # Rails behind Dagny’s Rails Inside the software factory that helps our team build, ship, and improve with AI. Ali Omrani Managing Partner Share [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fdagnylabs.ai%2Fblog%2Frails-behind-dagnys-rails) [](https://x.com/intent/tweet?text=Rails%20behind%20Dagny%E2%80%99s%20Rails&url=https%3A%2F%2Fdagnylabs.ai%2Fblog%2Frails-behind-dagnys-rails) On this page - [Start with the person using the Mill](#start-with-the-person-using-the-mill) - [Give agents context that lasts](#give-agents-context-that-lasts) - [Make the work reviewable](#make-the-work-reviewable) - [Check the running software](#check-the-running-software) - [Build coordination around the work](#build-coordination-around-the-work) - [Carry the lesson into the next change](#carry-the-lesson-into-the-next-change) At Dagny, 98% of commits are made by cloud agents, across millions of lines of code. Over the last 2 months, over 3,000 cloud agents raised over 2,500 pull requests. 87% of the cloud agents were launched by an automation, AI forward-deployed engineer agent, or another cloud agent. Of commits made by cloud agents98% Cloud agents run in the last two months3,000+ Pull requests raised by those agents2,500+ Of agents launched by automations or other agents87% At that volume, coordinating the work becomes a substantial engineering problem by itself. Every change needs context, review, testing and a path to release. Who launched the cloud agents - 87% Automations and agents - 13% Human Cloud agents launched over the last two months. Every application we build creates work beyond the application’s first release. A request needs context. A change needs review. A database migration needs a safe path to production. Once the software is running, we have to understand what people are doing with the software and what should improve next. Whether we’re building for a partner or ourselves, we want to build software people love using. The Mill brings structure to how we do that: turning a problem into clear work, giving agents the context to build, and reviewing and testing what they produce before the solution reaches users. We think of the system around that work as our software factory, AKA The Mill. The Mill includes cloud agents, sandbox environments, shared engineering skills and tools. The Mill also includes how we manage work, critique each other’s work and decide that a change is ready. These are the rails behind the solutions we build. How a change moves through The Mill - 1 Ticket A problem turned into clear work - 2 Context Skills and repository guidance - 3 Pull request A bounded change to inspect - 4 Verify Review and the running software - 5 Release Merge order and approval Then, back to step 1: Lessons return to tickets, docs, skills and tests ## Start with the person using the Mill We approach an internal tool with the same product questions we bring to a partner’s application. Who is using the solution? What is the problem they want to solve? Where does the current process make that difficult? Even a tool with one user needs to fit that person’s work well enough that they want to use the tool. AI shortens the time needed to research a problem, try different variations of the solution, test them, and build something people can react to. That makes direction and feedback especially important. A misunderstanding can become working software very quickly. The first job is to turn what we learn in conversations, Slack and briefs into a piece of work with enough context to execute. Our format is simple: Problem, Outcome, Constraints and Done when. For example, a request to “improve search” leaves a lot open. An illustrative ticket might say that someone cannot find a record using the reference they already have, specify which references search should accept, preserve existing permission rules, and describe the checks that demonstrate success. Those details give both the implementer and reviewer something concrete to work against. ENG-214 Find a record by the reference people already have ProblemPeople can’t find a record with the reference they already have, such as an invoice or order number. OutcomeSearch returns the record for any accepted reference. Constraints - Accept invoice numbers, order numbers and customer IDs - Keep the existing permission rules: people only find records they can already open Done when - Each accepted reference returns the matching record in an end-to-end test - A person without access finds no restricted record - Existing searches return the same results as before An illustrative ticket. ## Give agents context that lasts A ticket explains the change. The repository explains the system the change belongs to. An agent also needs to understand how to work in that system: where the relevant code lives, how to run the system, which conventions matter and how to test the system end to end as a real user would. Some instructions are specific to a project. Others apply across our work, such as how to prepare a change for review. We maintain common engineering guidance in Dagny Skills alongside repository-specific context. Keeping shared practices in one place gives us a way to improve them deliberately. When an instruction is unclear, we can fix the instruction and work through how that change should reach the projects that use the instruction. There is a practical balance here. Too little context leaves the agent guessing. Too much duplicated or outdated context creates contradictions. We want the simplest useful instructions, close to the work, with a clear reason for each rule. ## Make the work reviewable Cloud agents can take scoped work into branches and pull requests. That lets implementation happen in parallel when the changes are independent. When one change depends on another, the order still matters. A pull request gives us a bounded change to inspect. We can compare the pull request with the ticket, read the code, examine test results and ask whether the pull request introduces a side effect elsewhere. The useful handoff includes what changed, how the pull request was checked and anything still unresolved. Automated review helps with this. In one review exchange, a bot refused to proceed while code review agent findings remained unresolved and asked for human involvement. That is a useful example of the boundary we want: findings must lead to a decision or a fix before work moves forward. Find a record by the reference ENG-214 · opened by a cloud agent - Tests Unit and end-to-end suites Passed - Code review agent 2 findings unresolved. Asking for a person to decide. Blocked - Agent testing Drove the user journey. Evidence attached: 3 screenshots Passed - Human review After the findings are fixed or decided Waiting Illustrative. The change moves forward only when each finding leads to a fix or a decision. People still supply judgment about the product and the implementation. We share candid feedback and critique the work because a plausible solution can still be awkward, unnecessarily complicated or aimed at the wrong problem. ## Check the running software Reading a diff and passing tests answer important questions. Seeing the application run answers others. One UI verification workflow we have worked through uses a disposable local stack. The sequence is explicit: launch the application and the application’s dependencies, diagnose whether the environment is healthy, drive the relevant user journey, collect evidence, then clean up. We describe those steps as Launch, Validate, Drive, Evidence and Cleanup. - 1 Launch Start the app and the dependencies - 2 Validate Check the environment is healthy - 3 Drive Run the user journey - 4 Evidence Capture what was exercised - 5 Cleanup Tear the stack down Separating those steps helps distinguish an environment that failed to start from a feature that failed during use. Separation also makes the check easier to repeat. A screenshot or a recorded result should show what was actually exercised and give the reviewer something they can inspect. Database changes add another dependency. If application code expects a new table or function, that database change has to be in place when the code needs the database change. Release planning needs to include migration checks, ordering and verification after deployment. The change is only useful once the running system can support the change. ## Build coordination around the work As more work happens in parallel, coordination becomes a product problem too. Someone needs to know which ticket a pull request addresses, what the pull request depends on, what evidence is available and where a decision is waiting, and how to coordinate a release. The Mill is our software factory for bringing that work together. We are building The Mill toward a clearer view of batches of work, agent activity, review evidence and the steps needed to release a change. The Mill brings related pull requests into merge order and makes human approval part of coordinating their release. The Mill also broadens agent visibility by reading status and progress of the cloud agent in real time. The same product discipline applies here: build around the decisions engineers need to make, keep the workflow understandable and leave room for the workflow to grow. ## Carry the lesson into the next change The factory improves through the team’s attention. A review can expose a missing constraint. A confusing check can reveal a gap in setup instructions. Using a feature can show that we solved the wrong part of the problem. When a lesson is worth keeping, the lesson has somewhere to go: the ticket template, repository documentation, a shared skill or a test. The important step is deciding what should change and making that change specific enough to help next time. When agents can produce thousands of pull requests, the quality of the system around them matters more. We still need to understand the problem, give useful feedback, and know whether the software works for the person using the software. The Mill brings those responsibilities into a repeatable process, and we keep improving that process alongside the products we build. Our goal is to make every iteration more useful, more reliable, and easier to build on. That’s the work behind Dagny’s Rails. On this page - [Start with the person using the Mill](#start-with-the-person-using-the-mill) - [Give agents context that lasts](#give-agents-context-that-lasts) - [Make the work reviewable](#make-the-work-reviewable) - [Check the running software](#check-the-running-software) - [Build coordination around the work](#build-coordination-around-the-work) - [Carry the lesson into the next change](#carry-the-lesson-into-the-next-change) ## Field notes by email Receive new notes from Dagny. Newsletter signup is currently unavailable. ## More from the notebook - [Field notes Oct 6, 2026 How a duplicate payment email led to Billing OS](/blog/how-a-duplicate-payment-email-led-to-billing-os) - [Field notes Oct 6, 2026 How disagreement shapes our work at Dagny](/blog/how-disagreement-shapes-our-work-at-dagny) ## What’s the first workflow you’d fix? Tell us where your team gets stuck. We’ll discuss what a first build could look like. [Book a call](/book-a-call)