AI-Assisted Engineering AMA

The first question came from LinkedIn: the author has to rewrite his own AI working guides almost weekly, with up to 70% of the text changing. Litvinov treats that share as a symptom of storing things with different lifetimes in one toolkit, and offers three durability tests: the tool-change test (if the knowledge ages when the model changes, the layer is volatile), the lifetime test (a prompt lives for one request, context for a feature or a repository, principles for years) and the portability test (does the rule work outside AI, when delegating to people). Intent, invariants and acceptance criteria last longest — such as the invariant that once all the money is debited, no operation goes through and every screen shows zero. The middle layer is specifications, project rules, AGENTS.md. The volatile part is model knobs, cache behaviour, a particular harness, codex.toml, how often you clear context. The feedback loop does not age either: a model needs feedback, not only feedforward.

Alexander looks at the same question from inside a large company, where teams build their own agents for separate SDLC stages — review, test generation, work with requirements — and end up competing with a generic harness. Colleagues of his built an agent that generated tests and fought for prompt quality; then newer models arrived and tests began to be generated out of the box. The same happened with review, which the likes of Cursor, Claude and Codex now do with no know-how at all. Hence his hypothesis of a six-month harness half-life: when he checked it, the share that changed significantly was not 50% but around 40%. At Alexander's request Litvinov unpacks the word itself: a harness is the wrapper that gives a model an agent loop, tools, planning, a sandbox, subagents and context compaction. It covers the model's weak spots, but the stronger the model, the more it gets in the way — like an Ilizarov apparatus left on after the bones have healed. Alexander, for his part, suggests investing in whatever survives a model change: specifications, verification and telemetry.

The second question is how to change people's mindset. Alexander splits them into those tuned for growth, who become early adopters and champions, and those who want things to run in the usual groove: a mandate from above spurs the first group on, while the second quietly denies it. What convinces people is the neighbour on the project who shows that a task is now done by an agent, because there are tests around it and a wrapper that makes delivery painless. The chat adds a third type — saboteurs convinced that AI was created to fire everyone; the participants advise understanding the reason and, failing that, parting ways. Viewers refine the point: saboteurs stay while the drivers burn out. Litvinov sees a leadership problem here, with leads missing the emergent communities, and gives an anti-pattern: a company invites him for a transformation and complains about people already building their own platform. His answer is to join forces, because adoption comes from both directions: enterprise SDLC, an AI platform and self-service from above, champions and their community from below.

Next comes the question about a business that demands five times the value now that an operation takes a fifth of the time. Litvinov answers yes and no: domains optimise differently. In R&D, he reckons, the speed-up runs into the hundreds — a hundred agents test a hundred hypotheses in parallel, and the constraint becomes the human time needed to review the results; an old Oracle container database with hundreds of tables, reachable only through a UI, will not accelerate that way. To directors asking for a tenfold gain he suggests first breaking the work into stages and seeing what can be collapsed. Alexander adds the systemic view: a generated frontend is useless if the blocker sits in the backend, the business process or the business specifications. Litvinov's example is the rules of lawyers, brand and content policy: until that expertise is turned into policies and gates checked without people, the chain of edits will not shrink. Middle management, he says, is the busiest and least protected group in this wave.

The third question is how to take the euphoria about their own speed away from engineers without demotivating them. Litvinov does not propose removing the euphoria: what should change is the definition of the result — not "I applied Opus 5" and not the number of lines, but changed product behaviour. Alexander describes how, in his side projects with agents, he accumulated more deterministic checks than he ever wrote in ordinary ones, and admits that a new constraint holding the design intact pleases him more than shipping a feature. The fourth question is how an ordinary backend or frontend engineer should transform. Alexander sees a drift towards the forward-deployed engineer, a term Palantir introduced: working with an agent resembles management work — a clear brief, done criteria, acceptance in the spirit of BDD and Cucumber. Growth lies in domain understanding and design, so that you sense trouble when an agent proposes taking every building block at once. Litvinov calls the next step in role evolution the AI-assisted engineer, and Alexander adds the value of a trained eye: without one, any agent answer sounds fine.

The fifth question is a roadmap for verifying the work of coding agents. Litvinov starts from the point that verification is not tests written after the agent: generation can be handed to twenty agents, but understanding does not divide by twenty, so what you build is a cheaper way to accept one decision. Step zero is a measurable baseline: human time to accept a change, the rework share, DORA metrics and logging of which model, which provider and which prompt stack were involved. Then come intent and acceptance, specifications and invariants in AGENTS.md, mechanical rules moved into hooks, classification by blast radius, and an evidence-based pull request carrying a package of proof — and the change must not be checked by the same agent that made it. The last question is whether a business can be built on code nobody personally authored. Alexander answers through the bus factor and the pipeline: sausage quality comes not from mixing by hand but from a process certified to ISO 9000. Litvinov insists a named owner always remains, exactly as for a third-party library you merely added.