AI Dev Podcast #8 / Claude Dualism: How Not to Overdelegate Permissions to Claude/Codex

Andrey frames the episode: on one side you want the agent to do everything — read the mail, write code, test a feature, draft the requirements; on the other, this is a very eager but not quite competent colleague who has to be fenced in. Alexander adds the staging: the era of IDE hints, where an engineer visibly accepted or rejected every suggestion, is behind us, and in Russia at least, by 2026 agents are working at full tilt; but without rebuilding the engineering system around them, an agent quickly produces a lot of code that maps poorly onto functional and non-functional requirements and onto the system's further life. Vladimir started like everyone else: developers quietly installed free Qwen without asking, then Codex, which by his recollection handed out generous free limits in February and March, then Claude. The delight lasted until you came back two weeks later to add a function and saw how much the model had touched on the side.

The same thing repeated on real projects: as soon as the models were handed meaningful functionality rather than code completion, they began editing what nobody had asked about and "fixing" whatever looked wrong to them. The sharpest case was authorization in an internal service: mid-iteration the agent proposed dropping the table with all the users — no authorization, no problem. In the studio someone notes it is not as grand as "let us recreate Terraform", but it unsettles for a different reason: if you caught this one by accident, what went unnoticed? No global losses followed: agents get no production access at all, only reads for metrics. The team then went looking for a methodology that would limit that freedom, and of those existing at the time they liked Amazon's AIDLC best: a detailed preprint and a lab that keeps developing it. They took it as a base, stripped out Amazon's toolset and the tie to its cloud, and added their own constraints and code-style checks.

The second change was documentation. Sending the model into Confluence on every request is expensive in tokens and unreliable, and giving it write access to the wiki invites later investigations into where things went. So user stories, architecture decisions and the reasoning behind them moved into Git next to the code, while Confluence keeps the external interfaces: deployment diagrams and API descriptions shared with neighbouring teams. The process is assembled not as a tool but as a set of skills, which keeps the context from overloading. Base skills load everywhere: the code style (Python for this team), a setup skill that creates the folder structure and drops a file for the current model into the root, and a common AIDLC skill holding the rules, the security templates and the note on when a separate architecture decision is needed.

In inception an intent becomes a user story in a mandatory format — who, how, when and what result they expect, with positive and negative examples — and is split into units. There are no sprints but bolts, one or two coding sessions long yet with a finished result; units, Vladimir says, are essentially epics in Jira. He wants the product owner to run both phases, since the human load is nearly zero (state the intent, then confirm the generated wording, the risks and the non-functional requirements), but product people dodge it, so analysts step in. Construction covers the domain model, architecture decisions, code generation, infrastructure as code and external clients; they tried a protobuf client and it fits almost natively, except that the skills keep nudging you back towards REST. In operation an SRE agent watches Grafana dashboards, collects Prometheus metrics and spams warnings — letting it fix things directly would be lovely, but they are still afraid to.

Four governance skills run at transitions between phases, always at release, and whenever someone explicitly asks for a check. The ADR review verifies that a new unit has an architecture decision at all, that it does not break the internal rules kept in a references folder, and that it does not conflict with earlier decisions; a separate step re-reads past ADRs and inflates the context badly — on Qwen that check simply died, so it was moved into subagents and runs in a clean session. On a hard conflict the choice goes back to a human, and a comment is appended to the superseded decision. Traceability produces a Markdown file and a CSV: the story number, the path through bolts and ADRs, and where to look at the result; the matrix is rarely read by eye, and convenient analytics over it do not exist yet. The health check watches the integrity of the process rather than the liveness of the application: a form with a calendar was asked to switch by months and quarters, and the check flags the conflicting behaviour. Security review builds on a Microsoft rule set whose name Vladimir could not recall, and works like a SAST tool with a security bias.

A separate debate is ADRs versus specs. Alexander, who is reading a book on AI-assisted engineering and owes its author feedback, treats an ADR as frozen in time while a spec stays alive with the feature, so in his own pet projects he went to read the specs. Vladimir began the same way, with five or six large ADRs of the "we picked Kafka rather than RabbitMQ" kind, but ended up making any noticeable project-level decision an ADR, and his specs merged into them. The numbers: two projects fully in production, one close behind, about six more expected by the end of the quarter, and roughly fifteen people who came back with feedback. The showcase is an admin panel that had taken two years to write: one engineer spent two weeks porting it from Java to Python alone, showed a first result, then two colleagues joined him, and the three finished in under two months. Their feedback shortened the ADRs and brought traceability into the process. A brownfield system with twenty developers is still ahead; Alexander notes that such processes rest on the enthusiasm of their initiator. Much was added to the skills after newcomers asked how to use them at all, so they walk the user through the steps.