Silicon Chalet #68 met at Adnovum Bern on 3 September 2026, co-organized with the Microsoft Azure Bern User Group. Two talks, both in English, both grounded in shipped code rather than slides about code. Together they sketched a picture of what an agentic software development lifecycle (SDLC) looks like when the tools are real and the constraints are concrete.
Talk 1: From Architecture Diagram to Production on Azure
Adil Touati, Cloud Solution Architect at Microsoft, opened with a live demonstration. The premise was simple: start with an architecture diagram, end with a deployable application on Azure, and let GitHub Copilot and custom agents handle the scaffolding in between. The demonstration covered the full SDLC: application code, infrastructure as code (IaC), and deployment.
The starting point was a drawing. A Cosmos DB (database) instance, a Python Fast API backend, a React frontend, container apps for hosting. Nothing unusual for a modern web application. What made it unusual was what happened next: Copilot read the diagram, consulted a set of instruction files in the repository, and generated the application structure, Dockerfiles, and infrastructure as code.
The instruction files are where the real work lives. A global copilot-instructions.md in the .github folder defines organization-wide standards: naming conventions for Azure resources, accepted regions, mandatory tags, container app environments. Scoped instruction files in subfolders add domain-specific constraints: the app folder specifies Python and Fast API, the infra folder specifies Bicep and Azure Verified Modules. A scaffold prompt in a prompts folder tells Copilot what to build and in what order.
Adil then showed a custom agent, an infrastructure generator, defined as a markdown file with frontmatter specifying permissions (edit, search, terminal), scope (infra folder only), and rules (create Bicep, prefer Azure Verified Modules, enforce managed identity, no secrets). The agent also created its own instruction file for Bicep conventions, bootstrapping the standards it would follow.
The application compiled and tested. The infrastructure deployed to Azure via the Azure Developer CLI (azd up), which bootstraps the resources, builds the containers, and publishes the app. A few errors along the way, a missing tag, a location issue, a Docker configuration mismatch, were fed back to Copilot and resolved in-session.
Two points stood out. First, the instruction files are not optional decoration. Without them, Copilot guesses at the stack, the conventions, and the deployment target. With them, it follows organizational standards the way a new developer would after reading the onboarding documentation. Second, the agents are composable. An infrastructure generator agent and a platform reviewer agent can work as sub-agents, each with scoped permissions and domain-specific instructions.
Adil pointed to the Awesome Copilots repository on GitHub as a reference: over 200 agent templates, skills, and instruction examples that Microsoft maintains as a public resource.
Talk 2: From Policy to Proof, an AI Compliance Rules and Validation Engine
Daniel Hogg from Adnovum presented the second talk. He works in the CEO office, doing digital innovation and AI. His team had 20 days to build a proof of concept for a financial services customer: an AI-powered compliance rules engine that could read regulatory policy documents, extract rules, generate executable code, and evaluate loan applications against those rules.
The business problem is familiar. Credit processes in financial services are still largely manual. Regulations change, and each change requires expensive workflow modifications in deterministic systems. The question was whether AI could make this process more flexible without sacrificing the determinism and auditability that compliance requires.
The solution has two phases. In the first, a policy document is uploaded and parsed by an LLM. The LLM extracts rules, entities, and process definitions. Entities are the objects the rules operate on: companies, persons, balance sheets, applications. Rules are the conditions that must hold: equity ratios, risk-weighted capital, identity checks. When the extraction is complete, the system generates Python code for each rule and stores it in a database. A human reviewer approves the rules before they go live.
In the second phase, a loan application is uploaded. The LLM extracts the relevant data from the supporting documents, enriches it with external API calls (Know Your Customer, credit registers, company registries), and then evaluates the extracted data against the generated Python code. The evaluation is deterministic: the same inputs always produce the same results. The AI handles the messy work of reading documents and extracting values. The generated code handles the rule logic. A chatbot assistant can answer questions about the results, show evidence, and compare years.
Daniel demonstrated this with a concrete case: Kantonalbank-style mortgage application, 20 million Swiss Francs, enterprise customer. Three years of balance sheets uploaded. The system extracted the financial data, checked it against nine rules, and reported eight passes and one failure. The failing rule was a risk-weighted equity ratio that fell below the threshold in one of the three years.
The architecture runs on Azure native services. Container Apps for long-running API (application programming interface) calls, Azure AI Foundry for the models (cheap, fast GPT-class large language models for extraction), Supabase as a lightweight backend with real-time updates, Exa search for semantic web lookups (company information, adverse press), and Azure Dynamic Sessions for sandboxed execution of the AI-generated Python code.
Azure Dynamic Sessions are the key design choice. The generated Python code runs in isolated sandboxes, separate from the backend. This is necessary because the code is AI-generated and cannot be trusted to run in the main application environment. The sessions are reused (kept warm) to avoid cold-start latency. The same rule set always produces the same evaluation results.
The development process itself was agentic. Claude Code built the application from 28 requirement specification documents. The developer used a spec-review-build-validate approach: write the spec, let the agent generate code, review the output, validate against the spec. The developer used a spec-review-build-validate approach: write the spec, let the agent generate code, review the output, validate against the spec. The result was roughly 20,000 lines of code and 21 database tables across 7 domains, generated with approximately one billion input prompt tokens.
The cost was real. The developer reported high mental load and permission fatigue: the agent constantly asks for approval to proceed, and the temptation to keep it running into the evening is real. The developer was exhausted after the 20-day sprint. When asked how much faster this was compared to building the same system by hand, Daniel estimated roughly two times, not five times. The time saved on implementation was partly spent on specifying, checking, and validating.
What the two talks share
Both talks described the same shift. The developer’s job is moving from writing code to writing instructions. The instructions take the form of markdown files: global standards, scoped rules, agent definitions, scaffold prompts. The agent reads them and generates the code. The developer reviews, validates, and adjusts.
The instructions are the new specification. They encode organizational standards, platform constraints, security requirements, and domain logic in a format the agent can follow. Without them, the agent freestyles. With them, it follows the same standards a human developer would.
Both speakers were explicit about where humans stay in control. Adil: the agent generates and validates, the human makes design decisions, reviews compliance, and approves security. Daniel: the human approves every rule before it goes live, and the final loan decision includes a human gateway. The determinism of the rule execution is preserved by separating AI extraction from deterministic code evaluation.
Adil hit deployment errors during the live demo and fixed them by feeding the errors back to Copilot. Daniel reported developer exhaustion and permission fatigue. Both talks came from people who shipped code with AI agents and reported what happened.