Current-state workflow
A technical map of task intake, context assembly, dependency state, agent execution, tools, permissions, verification, human review, deployment, and downstream feedback.
AI platform engineering for software factories
Find what is limiting your coding agents in production.
Aleutian analyzes one autonomous software-development workflow end to end, establishes a measurable baseline, identifies the system constraint that is most limiting results, implements one targeted change, and measures what changed.
Two-week Software Factory Systems Review. One workflow. Your existing agent stack. No platform migration required.
Duration2 weeks
Scope1 workflow
StackUse what you have
EngagementFixed scope
Best fit: teams where AI-assisted engineering has moved beyond individual experimentation—typically 10+ engineers using coding agents, multiple autonomous workflows, or an explicit mandate to stand up a software factory.
The short version
Exactly what the engagement is.
The scope is intentionally explicit. You should be able to decide from this page whether the engagement is relevant before scheduling a call.
- What is it?
- One production coding-agent workflow gets diagnosed and improved. Aleutian measures the current system, localizes the dominant constraints, changes one bounded part of it, and re-runs the evaluation.
- How long?
- Two weeks. The scope is deliberately limited to one workflow so the work ends in an engineering result rather than an open-ended transformation program.
- What do we have afterwards?
- A system map, baseline, failure evidence, one implemented change, before/after results, and prioritized next engineering decisions.
- How much?
- $18,000 fixed fee. Work that cannot fit inside the defined two-week workflow is scoped separately before it begins.
- Do we replace our current tools?
- No. Keep Factory, Warp, Claude Code, Cursor, Codex, internal agents, CI/CD, or other existing tooling. The engagement evaluates the system you actually operate.
- Are we buying an Aleutian platform?
- No. This is a vendor-neutral engineering engagement. Aleutian components may be used when they solve a measured problem; there is no required platform migration.
What you get
A concrete engineering result after two weeks.
This is not a strategy deck and it is not a replacement coding platform. The review starts with one real software workflow and ends with measured artifacts your team can keep using.
Evaluation set + metrics
A representative task set and explicit success criteria for measuring acceptance, review burden, rework, failure classes, cycle time, and cost where data is available.
Failure analysis
Evidence showing whether failures originate primarily in intent, context, dependencies, model reasoning, tooling, verification, permissions, or missing production feedback.
One targeted change
An implemented improvement to the highest-leverage constraint that is technically feasible within the review scope—for example context selection, dependency analysis, eval coverage, verification, routing, or workflow controls.
Before / after results
The modified workflow is run against the same evaluation criteria where possible so the effect of the change is measured rather than inferred.
Prioritized engineering plan
A short list of the next system changes worth testing, the evidence needed to justify them, and the changes that do not currently have enough evidence.
Software Factory Systems Review — $18,000
Two weeks · one production workflow · fixed scope · existing agent stack
Discuss whether a workflow fits
Two weeks · one production workflow · fixed scope · existing agent stack
Who it is for
Teams where AI-assisted development is becoming an operating system, not an individual tool.
The review is useful once agent use is large enough that local developer experimentation no longer explains the result. A useful rule of thumb is 10+ engineers regularly using coding agents, multiple autonomous or semi-autonomous workflows, or an explicit requirement to establish a software-factory capability. That is a heuristic, not a hard eligibility threshold.
Good fit
You have enough real usage, organizational pressure, or planned autonomy to justify system-level measurement.
- 10+ engineers regularly use coding agents on production repositories
- you operate multiple agent workflows, agent swarms, or automated software tasks
- you are using or evaluating systems such as Factory, Warp, Claude Code, Cursor, Codex, or internal agents
- you have an executive or engineering mandate to implement a software factory
- review burden, rework, or failure rates are limiting further autonomy
- you cannot confidently attribute failures to context, dependencies, model behavior, tooling, verification, permissions, or workflow design
Not the right engagement
The review is not intended to manufacture a software-factory strategy before there is a real workflow to inspect.
- one developer is casually experimenting with an AI coding tool
- you have not identified a workflow or task class to automate
- you primarily want vendor selection or an executive AI strategy deck
- you need a replacement IDE, a general-purpose coding agent, or a full platform migration
- there is no access to representative tasks, repositories, operators, or acceptance criteria
- the required intervention is obviously a multi-month platform build rather than a bounded test
Typical entry points: “We have 20 engineers using coding agents and review is becoming the bottleneck.” “We bought or are piloting a software-factory platform and need to know whether it is actually improving delivery.” “Leadership wants a software factory, but we need an engineering plan grounded in our repositories and workflows rather than a vendor demo.”
Vendor names are examples only. Aleutian is designed to work across the stack rather than require a specific agent provider.
Two-week engagement
Baseline first. Change one thing. Re-evaluate.
The scope is deliberately small enough to finish. The objective is not to redesign the entire SDLC in two weeks; it is to replace one ambiguous agent problem with a measured system diagnosis and a tested next step.
Map, baseline, localize
Instrument and inspect one representative workflow before proposing a solution.
- Define the task class, repository scope, and intended outcome.
- Map context, dependencies, tools, permissions, verification, review, and deployment.
- Lock the initial evaluation tasks and success criteria.
- Run representative cases and classify failures by system cause.
- Select the highest-leverage constraint that can be tested within scope.
Change, re-run, decide
Implement one bounded intervention and measure its effect against the baseline.
- Implement the targeted system change.
- Run the same evaluation protocol where technically possible.
- Compare acceptance, review load, failure classes, rework, cycle time, and cost.
- Document what changed, what did not, and what remains uncertain.
- Deliver the prioritized next engineering decisions.
The problem
Model capability is only one variable in factory performance.
A coding agent can fail even when the underlying model is capable: the task can be underspecified, context can be stale, a dependency can be omitted, a tool can return incomplete state, permissions can be too broad or too narrow, tests can cover the wrong behavior, or production feedback can be disconnected from the run that caused it.
If those inputs are not recorded and measured, teams cannot reliably determine why a workflow succeeded or failed. They can change the model, prompt, harness, or review policy, but they cannot attribute the result to the change.
The agent produced the wrong change.
That statement is not a diagnosis. Multiple system failures can produce the same visible result.
Localize the failure before changing the system.
- IntentTask requirement or acceptance condition was incomplete.
- ContextRelevant code, design state, or operating constraint was absent.
- DependenciesThe affected surface extended beyond the files considered.
- ModelThe supplied evidence was adequate and the model still reasoned incorrectly.
- ToolsA command, retrieval step, sandbox, or external service returned incomplete or wrong state.
- VerificationThe checks that ran did not test the behavior that mattered.
- AuthorityThe agent could not perform a required action, or was permitted to do too much.
- FeedbackThe post-deployment result was never connected back to the originating run.
Engineering objective
Measure useful autonomous work, not code generation in isolation.
A factory should be evaluated against the outcome it is intended to improve. More generated code, commits, or pull requests may be useful intermediate signals, but they do not by themselves establish that more software was delivered correctly or with less human effort.
The measurement set should make the cost of autonomy visible as well as the benefit.
Task success
What proportion of attempted work satisfies explicit acceptance criteria under the intended production workflow?
Review burden
How much human time is required to inspect, correct, re-prompt, or complete the work?
Correction rate
How often do accepted changes require follow-up fixes, reversions, or additional implementation?
Production failures
Which failures pass evaluation and review, and what was missing from the pre-deployment evidence?
Cycle time
Does the full path from task intake to acceptable production result become faster?
System cost
Inference, compute, retries, review, remediation, and operational overhead should be measured together.
System boundary
The software factory is the operating loop around agent execution.
The agent is one component in a larger production system. The system has to translate intent into an executable task, assemble relevant state, constrain execution, verify the result, move accepted work into production, and connect downstream outcomes back to the decisions that produced them.
A software dark factory is the limiting case: human intervention becomes the exception rather than the default. Reaching that state is therefore a system property, not a model feature.
01Intent
02Specify
03Context
04Execute
05Verify
06Review
07Deploy
08Observe
context + retrieval state
dependency + impact model
evaluation + verification
permissions + isolation
evidence + provenance
production outcomes
Whole-system question: does this production system give autonomous agents enough information, constraint, verification, and feedback to make acceptable changes repeatedly?
Evaluation method
Treat factory changes as controlled system changes.
The method is the same whether the proposed change is a new model, retrieval strategy, dependency representation, tool, agent topology, permission boundary, verification step, or review policy: define the intended use, establish a baseline, state the expected gain, evaluate the full workflow, and monitor the result after deployment.
Define the workflow
Task class, users, repositories, operating context, non-goals, and production endpoint.
Establish baseline
Current acceptance, human review, cycle time, failures, rework, and cost.
State the change
What component is changing, why it should help, and what failure modes it could introduce.
Lock evaluation
Tasks, success thresholds, required evidence, exclusions, and reproducibility record.
Run system eval
Measure end-to-end behavior in the actual architecture, not only component benchmarks.
Deploy with controls
Fallback, escalation, approval, permission, verification, and rollback conditions.
Monitor + re-evaluate
Connect production behavior back to the changed system and revise from measured outcomes.
The decision is not “is the new agent better?” It is “does the evidence justify changing this production system for this intended class of work?”
Scope
Aleutian is not building another general-purpose coding agent.
Agent vendors are already competing on coding capability, interfaces, orchestration, remote execution, model routing, and workflow automation. Aleutian is focused on the platform information and evaluation systems around those agents.
The commercial entry point is the two-week systems review above. Repeated constraints observed across engagements can become reusable tooling or product components; the review does not assume in advance that the answer is a new agent, a new model, or an Aleutian component.
Agent execution layer
Common platform responsibilities already include interactive coding, cloud runtimes, sandboxes, model selection, tools, pull-request generation, and workflow orchestration.
- coding and task execution
- remote environments and sandboxes
- model selection and routing
- tool and workflow orchestration
- developer and SDLC integrations
Factory systems layer
Aleutian is testing the cross-cutting information, control, and measurement problems needed to operate autonomous software workflows as production systems.
- context and retrieval reliability
- dependency and affected-surface analysis
- evaluation and acceptance design
- run evidence and decision provenance
- permissions, isolation, and escalation
- linking runs to production outcomes
Current work
Each project tests one part of the system.
These are research artifacts and engineering components, not a claim that Aleutian already has a complete software-factory platform. Each exists to make one system question concrete enough to implement, measure, and falsify.
depctl
Tests whether software changes can be evaluated against an explicit dependency and affected-surface model instead of only the files named in the task.
change → dependency graph → affected surface → verification scopeGitHub →
Proof
Tests whether machine-produced work can retain an independently verifiable evidence record that survives outside the agent process that generated it.
record → content hash → signature → independent verificationGitHub →
Retrieval-Augmented Instruction
Tests whether deterministic evidence selection, scoped support boundaries, and explicit unsupported-answer behavior can materially improve the reliability of a constrained local model.
evidence selection → answer / decline → trace → evaluationRead the field studies →
Model + system evaluation
Tests how model, context, and architecture changes should be compared against a production baseline before they are allowed to change the operating system.
baseline → controlled change → system eval → controls → production measurementResearch index →
Research basis / Oct 2026
Current evidence supports measuring the system, not assuming more agent activity means more delivered software.
Vendor sources below establish how current software-factory products define their system boundaries. Independent research is included separately and with its limitations.
CHEN & STRATTON / HARVARDA 718-firm working paper reports coding-agent adoption associated with more lines of code, commits, and pull requests, while resolved issues/epics did not increase significantly and pull-request review time increased. The paper does not establish a universal causal effect.SOURCE ↗
METR / RESEARCHMETR's 2025 randomized study measured a slowdown for experienced open-source developers using then-current tools. Its 2026 follow-up says speedups now appear likely but that selection effects prevent a reliable estimate of the newer effect size.SOURCE ↗
WARP / VENDORWarp defines a software factory across triage, specification, implementation, review, and verification, with context, compute, inference, measurement, orchestration, and access as supporting layers.SOURCE ↗
FACTORY / VENDORFactory's public product description spans model routing, full-SDLC execution, quality gates, operations, analytics, deployment, and governance rather than code generation alone.SOURCE ↗
TESSL / VENDORTessl's published factory guidance emphasizes versioned context, scoped tools, verification, feedback loops, and task-level evaluations.SOURCE ↗
Start with one workflow
In two weeks, know what is limiting it and what to change next.
Bring a real coding-agent workflow, representative tasks, and access to the engineers who operate it. Aleutian will baseline the system, localize the dominant failure modes, implement one bounded intervention, and measure the result. Standard engagement: $18,000 fixed fee.