AI4SDLC: what to buy, adapt, and keep under your control

The starting point is three decisions: what to rent, what to adapt, and what to own. Frontier models can usually be obtained from providers, with room to try different options for different tasks. The agent harness, which organizes the loop between a model and its tools, can often come from an existing product or open-source project. Writing that loop is enjoyable engineering work, but major suppliers improve it faster and gain access to upcoming models before their customers do. Standard compute belongs in the same category: an ordinary company is unlikely to reproduce a large AI laboratory’s infrastructure. Using existing capabilities frees the team to address problems specific to its organization. It still requires evaluating suitability, cost, and the ability to switch later.

The work that needs adaptation includes task routing, context preparation, and interfaces to internal tools. An agent may understand familiar open-source technology better than a company’s custom platform, so internal conventions must become legible. Wrapping an old API in MCP does not automatically make it usable by a model. Permissions, access policies, evaluation sets, and evidence from agent runs should remain under the company’s control. The talk gives a simple example: an excellent model cannot help if network access is prohibited or its allowlist is empty. Another failure mode allows actions but relies on manual checks for every version. A useful system combines the model, harness, permitted actions, and verification. Replacing the model or harness also needs deliberate support; otherwise dependence on one supplier becomes embedded in the system.

Polomodov distinguishes fast and slow improvement loops. In the fast loop, a company changes request routing, context packaging, tool interfaces, access policies, or release criteria. In the slow loop, major providers align models with compute infrastructure, including memory, numerical precision, and connections between accelerators. When an agent struggles with an internal workflow, the first useful intervention may be in the fast loop, without waiting for a new model. Different businesses assemble the wider system from different starting points: a vertically integrated company begins with products and compute; a laboratory with research and models; a product company with user tasks and feedback. Open weights shift part of the integration work to organizations that deploy and adapt the model. These examples identify possible points of investment, rather than requiring an internal platform team to reproduce the entire stack.

API compatibility does not guarantee behavioral compatibility. A harness needs adjustments for the abilities and weaknesses of a particular model, so maintaining a proprietary general-purpose agent loop can become a permanent race to catch up. Clear tool contracts offer a more durable investment: who acts, whose authority they use, what they can change, and how success is checked. Telemetry, execution traces, and evaluation sets serve different purposes alongside those contracts. A trace explains the steps taken; a successful demonstration establishes one case. Neither alone proves that the final task was completed or that existing capabilities still work. Building an evaluation baseline is demanding because every subsequent change must preserve it. The benefit is a way to compare versions on the same tasks, instead of selecting a fresh success for each demonstration.

The next step is to divide development into bounded episodes, such as fixing a bug. Each needs defined inputs, action boundaries, an expected outcome, telemetry, and checks. Polomodov illustrates the idea with a sequence from product intent through specification and planning to implementation and release. The purpose is to organize work around tasks that can be repeated and verified. An improvement cycle saves the task, execution history, and final state, reproduces the episode in a fixed environment, changes one layer, and reruns independent checks. A company can accumulate this material regardless of its model provider. The resulting episode catalog supports both agent improvement and supplier replacement because competing versions can be assessed on the organization’s own work. Without that foundation, switching returns to manual trials and subjective impressions.

Once an episode is sufficiently bounded and repeatable, a smaller or cheaper model may handle it; in some cases, task-specific fine-tuning may help. This is a hypothesis to validate with the same checks, not a promise that small models can replace large ones everywhere. Difficult, uncertain tasks remain candidates for a stronger model, while repeatable work moves into a system with measured quality. The talk highlights the relevance where expensive models are difficult to obtain or prohibited by internal rules. Audience Q&A adds a human dimension: should agents show more emotion? For engineering, Polomodov primarily wants a technically competent collaborator, while empathy may help exploration or consumer products. The discussion favors adjustable conversational tone according to user preference, with the agent’s technical value grounded in the quality of its work.