AI-Assisted Engineering AMA

The first question starts with a frustration: AI working guides appear to require weekly rewrites. Litvinov separates knowledge by lifetime. Model settings, versions, caching, and the quirks of a harness form the volatile layer. Specifications, repository rules, and AGENTS.md evolve with the product but change less often. Intent, scope, invariants, acceptance criteria, and feedback loops last longest. If a rule survives a model change and improves delegation to people, it probably belongs to the foundation.

Building a generic in-house harness is risky because new models and vendor products quickly absorb capabilities once covered by custom test generators or review tools. Institutional knowledge is safer in the process: how specifications are written, where sources of truth reside, which telemetry is captured, and how outcomes are measured. That layer survives a model replacement. Controls still need a budget; every possible check can make the engineering loop unusable.

A mandate that everyone must use AI does not change practice. Early adopters will respond, others will see another executive campaign, and some will resist because they fear automation. A neighboring team solving a familiar problem with a dependable loop is more persuasive than a polished demo. Adoption joins executive direction and platform capabilities with AI champions who run pilots, share practices, and turn paths into repeatable workflows.

Middle management is the connecting layer. These leaders are overloaded; they do not define strategy, yet they must explain it and deliver predictable quality. They need a tool that reduces their own noise, not another mandatory ritual. A useful pilot starts from a business goal and measures the flow. Faster frontend generation brings no benefit when requirements, backend rules, or approvals remain the constraint. Demanding five times more output without system analysis merely pressures people.

The excitement of rapid generation should not be suppressed; the definition of done should change. The result is an observable product behavior plus evidence that it works. Litvinov suggests starting with a baseline: human time to accept a change, rework rate, DORA metrics, and telemetry for agent runs. Each task then records intent, scope, exclusions, invariants, and acceptance criteria. Mechanical conditions move into hooks and CI, changes are classified by blast radius, and every pull request carries an evidence package with tests, contracts, visual proof, and rollback information.

Generation can scale to dozens of agents, but human understanding cannot, so the same agent should not both produce a change and certify it. As the system matures, nondeterministic guidance becomes deterministic checks, while delayed centralized reports become early feedback inside the working loop. Code authorship also separates from accountability. The business needs a working system, yet every area still needs a named owner. Engineers and technical leaders become accountable not only for a diff but also for the reliability of the pipeline that produces and validates changes.