DEV Community: Olivier Miossec

Decision model in action, Jev in Cloud operation with PowerShell

Olivier Miossec — Thu, 01 Oct 2026 15:21:34 +0000

In Thinking, Fast and Slow, Daniel Kahneman describes two modes of thinking. System 1 is fast and intuitive: you know that 2 + 2 = 4 without any effort. System 2 is slow and deliberate: the result of 17 × 24 takes time and real cognitive effort.

That distinction was on the Typesafe.ai team's mind when they built Jev.

Jev isn't a model for writing text, generating code, or creating images. It's a decision model. You give it a context (plain text, JSON, email…) and predefined questions, then, it returns a predefined answer with a probability. Jev supports three question types:

Choice picks an option from a list.
Yes/No says whether a statement is true, with a probability between 0 and 1 (returned as noul)
Score rates the state against a rubric.

In other words, Jev gives you an answer you can act on directly: "yes, 87%" or "category B". An LLM, by contrast, writes a full response. The first is built for chaining automated actions; the second shines at explanations and documentation.

Jev is also fast and cheap. Answers are tiny, and only input tokens are billed; output is free.

The best use case are:

The possible answers are known in advance. Is this email a scam? How urgent is this request? Which team should handle it? If you can't enumerate the answers, or the task needs deep reasoning, a decision model probably isn't the right tool.
It happens a lot. Logs, metrics, tickets, emails: at that volume, speed and cost make all the difference.
It needs judgment, not deep thinking. Think of Jev as a human making a quick call on something too fuzzy for a regex or a script.
Something happens next. The answer feeds a workflow: route, alert, block, approve.

In one sentence: a decision model is worth it when you have a large pile of things that each need a quick human-like judgment, and that judgment should trigger an automatic next step.

There are a lot of example on Youtube and elsewhere, but they are very basic. To better understand Jev, I will use it in every day tasks of a cloud engineer.

To see what Jev can really do, I'll apply it to the everyday work of a cloud engineer, automated with PowerShell and the JEV PowerShell module from Doug Finke.
I will create another post later to explain who to work with Jev in detail with PowerShell.

Before starting, the TYPESAFE_API_KEY environment variable should be setup with the API key from TypeSafe.ai and store it in the TYPESAFE_API_KEY environment variable. Outside a quick test, don't hardcode it: pull it from a vault instead.

$env:TYPESAFE_API_KEY = "apikey_XXXXX"

First example, how to work with Jev in PowerShell

Now the first test to understand how Jev work.

# import module 
Import-Module ../Jev/Jev.psd1 -Force

# create the state, the context for the question
$feedback = [pscustomobject] @{
    message = 'The customer is blocked by a connection issue to the database.'
}

# define the criteria for the question
$criteria = @{
    support = 'The issue needs technical support.'
    sales   = 'The issue concerns sales.'
}

# create the question based on the criteria
$question = New-JevQuestion -Name TeamRouting -Type Choice -Instructions 'Which team should handle this?' -Criteria $criteria

# invoke the question with the current state
$result = Invoke-Jev -State $feedback -Question $question

# check the result of the question
$result.answers.TeamRouting

The result look like

type choice confidence probabilities

choice support 1.00 @{support=1; sales=0}

The decision model pickup “support” with confidence, but it was just a test, and this example says nothing on how Jev can help in day to day task off a Cloud Engineer.

How to handle resource change and catch risky operation with Bicep -whatif

One of the first use case I have in mind is Infrastructure as Code change. In Terraform or Bicep it you have a complex infrastructure, the Terraform Plan or the Bicep -WhatIf will be dense. An you will have often several questions:

Do the change after a part of critical resource?
Do it weaken security on resources?
What will happen if something go wrong

If for example you use Bicep to manage a complex Azure Network Infrastructure, with Express Route Gateway, Circuit, VPN connection, you probably review the -whatif output before executing the change in a pipeline.

Here, Jev can help, the WhatIf output will be our state, or context.
Bicep WhatIf output is verbose and need to be cleaned and shorted for Jev. The output I used here is a 55Kb file.

   {
      "ResourceId": null,
      "ChangeType": "Create",
      "Before": null,
      "After": {
XXXX
    }

Some parts of the file are useless. When the “changeType” property is “noChange” or “ignore” should be striped before sending to Jev.

$whatIf = Get-Content -Path $WhatIfFile -Raw | ConvertFrom-Json

$changes = $whatIf.Changes | Where-Object -Property ChangeType -NotIn -Value @('NoChange', 'Ignore')

But the data still have the full Before and After payload of the resource, so the few properties that change are buried in ids. We only need to have the change type, the resource and the changed property paths.

$summary = foreach ($c in $changes) {
    $resource = if ($c.After) { $c.After } else { $c.Before }
    "$($c.ChangeType): $($resource.type) $($resource.name)"
    if ($c.ChangeType -eq 'Create') {
        '  properties: ' + ($resource.properties | ConvertTo-Json -Compress -Depth 10)
    }
    foreach ($d in $c.Delta) {
        "  $($d.PropertyChangeType) $($d.Path)"
    }
}

Now we can create an array of question.

$questions = @(
    New-JevYesNoQuestion -Name security `
        -Question 'Do the changes in `whatif` weaken the security of the environment?' `
        -TrueCriteria 'Password login enabled on a VM, no NSG on a NIC or subnet, a security setting removed or relaxed' `
        -FalseCriteria 'Security settings are unchanged or stronger'

    New-JevYesNoQuestion -Name public_ip `
        -Question 'Do the changes in `whatif` expose a resource to the internet with a public IP?' `
        -TrueCriteria 'A public IP address is created or attached to a NIC, a VM or a load balancer' `
        -FalseCriteria 'No public IP is created or attached'

    New-JevQuestion -Name risk -Type Score `
        -Instructions 'How risky is it to deploy the changes in `whatif`?' `
        -Criteria @(
            'No risk: cosmetic or read-only property changes'
            'Low: new isolated resources'
            'Medium: changes to shared network resources (VNets, peerings, route tables)'
            'High: an outage or a security incident is likely'
        )
)

And get the answer. Here you can see that the decision stays in the code and can be used later

$state = @{ whatif = $summary -join "`n" }
$answers = (Invoke-Jev -State $state -Question $questions -Mock:$Mock -Raw).answers

$reasons = @(
    if ($answers.security.noul -gt 0.7) { 'Weakens security' }
    if ($answers.public_ip.noul -gt 0.7) { 'Exposes a public IP' }
    if ($answers.risk.score -ge 2) { "Risk level $($answers.risk.score)" }
)

[pscustomobject]@{
    Decision = if ($reasons) { 'Review' } else { 'Pass' }
    Reasons  = $reasons -join '; '
    Changes  = @($changes).Count
    Security = [math]::Round($answers.security.noul, 2)
    PublicIp = [math]::Round($answers.public_ip.noul, 2)
    Risk     = $answers.risk.score
}

The result

Decision : Review
Reasons : Weakens security; Exposes a public IP; Risk level 2.72
Changes : 16
Security : 0.9
PublicIp : 0.97
Risk : 2.72

Mixing PowerShell result and Jev insights.

Another use case for a decision model is reviewing NSG configurations, especially when a simple PowerShell query is insufficient. A decision model can provide insights beyond PowerShell’s capabilities.

In this example, PowerShell is used for deterministic checks (like a management port open to the Internet) and Jev to check the rule to NSG best practices.

First part PowerShell need to test rules.

$managementPorts = 22, 3389, 5985, 5986
$internetSources = '*', 'Internet', '0.0.0.0/0', 'Any'
# merge singular and plural rules 
function  Get-RuleValue {
    param([object]$Single, [object]$Plural)
    @(@($Single) + @($Plural) | Where-Object -FilterScript { $_ })
}
# Then a function to test the port
function Test-PortMatch {
    param([string[]]$Range, [int[]]$Port)

    foreach ($r in $Range) {
        if ($r -eq '*') { return $true }
        if ($r -match '^(\d+)-(\d+)$') {
            $low, $high = [int]$Matches[1], [int]$Matches[2]
            if ($Port | Where-Object -FilterScript { $_ -ge $low -and $_ -le $high }) { return $true }
        }
        elseif ([int]$r -in $Port) { return $true }
    }
    $false
}
function Get-DeterministicFinding {
    param([Parameter(Mandatory)][pscustomobject]$Rule)

    if ($Rule.Direction -ne 'Inbound' -or $Rule.Access -ne 'Allow') { return @() }
    if (-not ($Rule.Source | Where-Object -FilterScript { $_ -in $internetSources })) { return @() }

    if ('*' -in $Rule.DestinationPort) { 'All ports open inbound from the internet' }
    elseif (Test-PortMatch -Range $Rule.DestinationPort -Port $managementPorts) { 'Management port open inbound from the internet' }
}
$config = Get-Content -Path $Path -Raw | ConvertFrom-Json -AsHashtable

$rules = foreach ($nsg in $config.networkSecurityGroups) {
    $subnets = @($nsg.properties.subnets | ForEach-Object -Process { ($_.id -split '/')[-1] })
    $nics = @($nsg.properties.networkInterfaces | ForEach-Object -Process { ($_.id -split '/')[-1] })

    foreach ($r in $nsg.properties.securityRules) {
        $p = $r.properties
        $rule = [pscustomobject]@{
            Nsg             = $nsg.name
            Rule            = $r.name
            Priority        = $p.priority
            Direction       = $p.direction
            Access          = $p.access
            Protocol        = $p.protocol
            Source          = @(Get-RuleValue -Single $p.sourceAddressPrefix -Plural $p.sourceAddressPrefixes)
            Destination     = @(Get-RuleValue -Single $p.destinationAddressPrefix -Plural $p.destinationAddressPrefixes)
            DestinationPort = @(Get-RuleValue -Single $p.destinationPortRange -Plural $p.destinationPortRanges)
            Description     = $p.description
        }
        $rule | Add-Member -NotePropertyName HardFindings -NotePropertyValue @(Get-DeterministicFinding -Rule $rule)
        $rule | Add-Member -NotePropertyName State -NotePropertyValue ([ordered]@{
                nsg          = [ordered]@{
                    name               = $nsg.name
                    associated_subnets = @($subnets | ForEach-Object -Process {
                            [ordered]@{ name = $_; purpose = $config.subnetPurpose[$_] ?? 'unknown' } })
                    associated_nics    = $nics
                }
                rule         = [ordered]@{
                    name              = $rule.Rule
                    priority          = $rule.Priority
                    direction         = $rule.Direction
                    access            = $rule.Access
                    protocol          = $rule.Protocol
                    source            = $rule.Source
                    destination       = $rule.Destination
                    destination_ports = $rule.DestinationPort
                    description       = $rule.Description ?? '(none)'
                }
                nsg_standard = $standard
            })
        $rule
    }
}

Now the Jev part. We need to setup the standard for NSG rules.

$standard = @'
NSG STANDARD (sample)
- Management ports (22, 3389, 5985, 5986) are only allowed from the Azure Bastion subnet or the snet-mgmt subnet.
- No inbound allow rule may use source * or Internet, except on subnets explicitly marked as public-facing, and only for 80/443.
- Data subnets accept traffic only from the application subnets of the same landing zone, on the data ports they need.
- Use specific ports; port ranges wider than 10 ports need a documented reason in the rule description.
- Prefer Application Security Groups or specific subnet prefixes over the VirtualNetwork service tag.
- Every custom rule must have a description stating its purpose and owner.
- Temporary rules must include an expiry date in the description.
'@

$questions = @(
    New-JevQuestion -Name intent -Type Choice `
        -Instructions 'What is `rule` most likely for, given the purpose of the subnets in `nsg`?' `
        -Criteria ([ordered]@{
            app_traffic         = 'Application traffic between tiers or from clients'
            management_access   = 'Administrative access (SSH, RDP, WinRM, Bastion)'
            platform_dependency = 'Platform needs: DNS, identity, monitoring, backup, load balancer probes'
            vendor_or_partner   = 'Access for a third party, vendor or partner network'
            temporary_or_test   = 'Troubleshooting, test, migration or other temporary access'
            unclear             = 'Purpose cannot be determined from the rule and its context'
        })

    New-JevYesNoQuestion -Name compliant `
        -Question 'Does `rule` comply with every applicable point of `nsg_standard`?' `
        -TrueCriteria 'No point of the standard is violated by the rule as configured' `
        -FalseCriteria 'At least one point of the standard is violated'

    New-JevYesNoQuestion -Name broader_than_needed `
        -Question 'Is the source, destination or port scope of `rule` broader than its apparent purpose requires?' `
        -TrueCriteria 'All ports for a web tier, VirtualNetwork tag where one subnet would do, large CIDR, * source' `
        -FalseCriteria 'Specific ports, specific subnets or ASGs matching the purpose'

    New-JevYesNoQuestion -Name looks_temporary `
        -Question 'Does the name or description of `rule` suggest a temporary, test or troubleshooting rule?' `
        -TrueCriteria 'Words like temp, test, debug, troubleshoot, migration, POC, a ticket number, or a past date' `
        -FalseCriteria 'Name and description describe a permanent, owned purpose'

    New-JevYesNoQuestion -Name description_mismatch `
        -Question 'Is the description of `rule` missing, or does it contradict what the rule actually allows?' `
        -TrueCriteria 'No description, or the description names other ports, sources or purposes than configured' `
        -FalseCriteria 'The description accurately states what the rule allows and why'

    New-JevQuestion -Name severity -Type Score `
        -Instructions 'What is the security severity of `rule` as currently configured?' `
        -Criteria @(
            'None: correct and tightly scoped'
            'Low: hygiene or documentation issue'
            'Moderate: broader than needed, no internet exposure'
            'High: exposes a sensitive subnet or breaks segmentation'
            'Critical: direct internet exposure of sensitive services'
        )
)

Then we can invoke Jev for each rules

foreach ($rule in $rules) {
    $a = (Invoke-Jev -State $rule.State -Question $questions -Mock:$Mock -Raw).answers

    $action = if ($rule.HardFindings.Count) { 'security-ticket-p1' }     # deterministic, never overridden
    elseif ($a.severity.score -ge 3) { 'security-review' }
    elseif ($a.intent.confidence -lt 0.5) { 'human-review' }
    elseif ($a.looks_temporary.noul -gt 0.7) { 'owner-confirm-or-remove' }
    elseif ($a.broader_than_needed.noul -gt 0.7) { 'tighten-rule' }
    elseif ($a.compliant.noul -lt 0.3) { 'non-compliant-owner-ticket' }
    elseif ($a.description_mismatch.noul -gt 0.7) { 'fix-description' }
    else { 'ok' }

    $findings = @(
        $rule.HardFindings
        if ($a.compliant.noul -lt 0.3) { 'Not compliant with NSG standard' }
        if ($a.broader_than_needed.noul -gt 0.7) { 'Scope broader than needed' }
        if ($a.looks_temporary.noul -gt 0.7) { 'Looks temporary' }
        if ($a.description_mismatch.noul -gt 0.7) { 'Description missing or misleading' }
    )

    [pscustomobject]@{
        Nsg       = $rule.Nsg
        Rule      = $rule.Rule
        Action    = $action
        Severity  = if ($rule.HardFindings.Count) { 4 } else { [math]::Round($a.severity.score, 2) }
        Findings  = $findings -join '; '
        Intent    = $a.intent.choice
        Compliant = [math]::Round($a.compliant.noul, 2)
        Ports     = $rule.DestinationPort -join ','
        Source    = $rule.Source -join ','
    }
}

Result

Nsg : nsg-vm-legacy-01
Rule : allow-winrm
Action : security-review
Severity : 3.08
Findings : Not compliant with NSG standard
Intent : vendor_or_partner
Compliant : 0.06
Ports : 5985
Source : 203.0.113.0/24
Nsg : nsg-vnet-spoke
Rule : allow-ssh-any
Action : security-ticket-p1
Severity : 4
Findings : Management port open inbound from the internet; Not compliant with NSG standard; Scope broader than needed
Intent : management_access
Compliant : 0.02
Ports : 22
Source : *
Nsg : nsg-vnet-spoke
Rule : allow-port-range
Action : tighten-rule
Severity : 2.1
Findings : Not compliant with NSG standard; Scope broader than needed
Intent : app_traffic
Compliant : 0.06
Ports : 1024-65535
Source : 10.2.1.0/24

Using Azure Policy Linter to control policy definition

Last example, working with Azure Policy definition. For testing definition, we first need a linter.

The result.json file contains the finding of the linter on specific definition part with a severity (error/warning/informational).

The rule for a decision model is to turn these finding into actionable items.
First step, get the content for each policy and run the linter.


$resultFile = Join-Path -Path $Path -ChildPath 'PolicyResult.json'
$files = Get-ChildItem -Path $Path -Filter '*.json' -File | Where-Object -Property Name -NE -Value 'PolicyResult.json'

$null = policylinter $files.FullName -o $resultFile
if ($LASTEXITCODE -ne 0) { throw "policylinter failed with exit code $LASTEXITCODE" }

$lint = @{}
(Get-Content -Path $resultFile -Raw | ConvertFrom-Json -AsHashtable).GetEnumerator() | ForEach-Object {
    $lint[(Split-Path -Path $_.Key -Leaf)] = @($_.Value)
}

Then the Jev part.

$questions = @(
    New-JevYesNoQuestion -Name findings_matter `
        -Question 'Does at least one item in `linter_findings` mean `policy` may not evaluate or enforce as intended?' `
        -TrueCriteria 'A finding changes which resources match: wrong array logic, missing alias, broken condition' `
        -FalseCriteria 'Findings are style, old API versions, optional properties or best-practice hints, or there are no findings'

    New-JevYesNoQuestion -Name description_matches `
        -Question 'Do displayName and description of `policy` match what policyRule really evaluates and its default effect?' `
        -TrueCriteria 'Same resource types, same condition, same effect as the rule' `
        -FalseCriteria 'The text promises other resource types, another condition or a stronger effect than the rule'

    New-JevYesNoQuestion -Name weakens_security `
        -Question 'Could assigning `policy` weaken security?' `
        -TrueCriteria 'The remediation opens network access, uses hard-coded public IP ranges, or grants a broader role than needed (Owner, Contributor)' `
        -FalseCriteria 'The policy only audits or denies, or remediates with a least-privilege role'
)

For each policy, Jev is called 
foreach ($file in $files) {
    $definition = (Get-Content -Path $file.FullName -Raw | ConvertFrom-Json).properties
    $findings = $lint[$file.Name]

    $state = [ordered]@{
        policy          = [ordered]@{
            displayName = $definition.displayName
            description = $definition.description
            parameters  = $definition.parameters
            policyRule  = $definition.policyRule
        }
        linter_findings = @($findings | ForEach-Object { "$($_.severity) $($_.ruleIdentifier) at $($_.path)" })
    }
    $a = (Invoke-Jev -State $state -Question $questions -Mock:$Mock -Raw).answers

    $action = if ($a.weakens_security.noul -gt 0.7) { 'Security review' }
    elseif ($a.findings_matter.noul -gt 0.7) { 'Fix the rule' }
    elseif ($a.description_matches.noul -lt 0.3) { 'Fix the description' }
    elseif ($findings.Count -gt 0) { 'Backlog' }
    else { 'OK' }

    [pscustomobject]@{
        Policy             = $file.Name
        Warnings           = @($findings | Where-Object -Property severity -EQ -Value 'Warning').Count
        Informational      = @($findings | Where-Object -Property severity -EQ -Value 'Informational').Count
        FindingsMatter     = [math]::Round($a.findings_matter.noul, 2)
        DescriptionMatches = [math]::Round($a.description_matches.noul, 2)
        WeakensSecurity    = [math]::Round($a.weakens_security.noul, 2)
        Action             = $action
    }
}

The result:

Policy : policy4.json
Warnings : 1
Informational : 0
FindingsMatter : 0.28
DescriptionMatches : 0.68
WeakensSecurity : 0.87
Action : Security review

These are a few examples of what a decision model can do in cloud engineering. Decision model can do more. Our daily work generates a constant stream of data: metrics, logs, IaC plans, traces, network routes. Most of it contains noise, and we already rely on scripts and observability tools to turn it into tasks. Jev fits right into that chain. It applies judgment to your data, against your rules, and leaves the final decision in your code.

Volume is also why a general-purpose LLM is often too expensive for this kind job. Jev isn't: everything in this article used 103,525 tokens, for a total of $0.0039.

You can find the code of this post here

Azure Virtual Network Routing Appliance: peering performance, hub-and-spoke control

Olivier Miossec — Mon, 21 Sep 2026 20:06:37 +0000

Yet another routing appliance? The name of this new Azure service is confusing. Is it a sort of NVA? A new kind of routing engine? No, the name tells too little, you need to look at the problem it solves.

When two applications in different VNETs need to talk (the East-West pattern), you have two options.

The first is VNET peering. Throughput and latency are excellent: traffic stays on the Azure backbone, and VMs behave as if they were on the same network. But peering isn't transitive. With more VNETs that need to talk to each other means peerings. Difficult to control and manage at scale.

The second is to route through a central device in a hub: Azure Firewall, a third-party NVA, or even your on-premises network. You get central control and visibility, but every flow now depends on the capacity of that device. It becomes the bottleneck. A NVA will be blocked by the VMs capacity, Azure Firewall can manage up to 100 Gbps but you will have to pay the price.

Most companies chose the second option and accepted the performance hit in exchange for more governance. But this trade-off become harder to defend when workloads move large volumes of data between VNETs: data pipelines, centralized databases, AI workloads reading from storage in another landing zone, agents calling APIs across the Azure tenant.

The Azure Virtual Network Routing Appliance is between the two options. It's an Azure-managed forwarding layer that you deploy in your hub (or any central VNETs, you don't need a gateway to make it work). It runs on dedicated networking hardware, directly inside the Azure Backbone, and comes in 10, 50, 100 or 200 Gbps tiers. VNETs route through it the way they would through an NVA, without the NVA bottleneck.

It is not a firewall. It doesn't inspect traffic. Control comes from the Azure-native tools around it: UDRs, NSGsand Azure Monitor metrics. If controlling flows is needed, keep your firewall in the path for those flows.

Deploying it takes three steps. First, register the feature on your subscription:

Register-AzProviderFeature -FeatureName AllowVirtualNetworkAppliance –ProviderNamespace Microsoft.Network

The second step is to create a virtual network (or use an existing one) with a dedicated subnet, named VirtualNetworkApplianceSubnet.

resource hubVnet 'Microsoft.Network/virtualNetworks@2024-05-01' = {
  name: 'hub-vnet'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        10.0.0.0/21
      ]
    }
    subnets: [
      {
        name:VirtualNetworkApplianceSubnet
        properties: {
          addressPrefix: 10.0.0.0/24
        }
      }
    ]
  }
}

Then we can deploy the Virtual Network Routing Appliance.

resource routingAppliance 'Microsoft.Network/virtualNetworkAppliances@2025-07-01' = {
  name: 'vnra-test'
  location: location
  properties: {
    bandwidthInGbps: 10
    privateIPAddressVersion: 'IPv4'
    subnet: {
      id: '${hubVnet.id}/subnets/VirtualNetworkApplianceSubnet'
    }
  }
}

Once it's deployed, the portal view is nearly empty. There's nothing to configure beyond the properties.

The interesting part is the Metrics blade. Bytes, packets and flows, inbound and outbound, are available out of the box, with no diagnostic settings to configure. That's your visibility on east-west traffic.

With PowerShell, Get-AzVirtualNetworkAppliance gives you a bit more detail. In the IP configuration you'll see several ipconfig_4_xxxx entries, a hint that more than one instance sits behind the single private IP you route to

So how do spokes VNETs can use it? First, each spoke need a peering with the hub VNET. And, make sure that spoke VNETs are not peered with each other.

Peering alone isn't enough. Every spoke subnet that should use the appliance needs a UDR pointing to the appliance's private IP as next hop:

resource spokeRouteTables 'Microsoft.Network/routeTables@2024-05-01' = 
  name: 'vnra-to-other-spoke-rt'
  location: location
  properties: {
    disableBgpRoutePropagation: false
    routes: {
      name: 'to-appliance-10-2-0-0_16'
      properties: {
        addressPrefix: 10.2.0.0/16
        nextHopType: 'VirtualAppliance'
        nextHopIpAddress: 10.0.0.4
      }
    }
  }
}

Apply the route tables on both sides. With that in place, workloads in two spokes that aren't peered together can talk through the hub, at close to peering performance.

After these operations you should have this architecture.

You can also send 0.0.0.0/0 to the appliance so every spoke gets the same route table. The appliance doesn't NAT, so internet traffic still needs a next hop that does, configured on the appliance subnet. And check the return path, especially for Private Endpoint traffic. The simplest design is still RFC1918 to the appliance and the default route to your firewall.

The service went GA in August 2026, so several preview restriction are gone: IPv6 and dual-stack are supported, and the region list has grown. A few limits remain:

Two appliances per region per subscription.
Bandwidth is fixed at creation. To change it, you need to delete and redeploy the appliance.
VNET flow logs is not supported yet.
Terraform needs the AzAPI provider; AzureRM doesn't support it.
Traffic through the appliance isn't covered by VNET encryption.

The Virtual Network Routing Appliance doesn't replace your firewall. It removes the reason your firewall was doing routing in the first place. If your hub firewall today spends most of its time forwarding east-west traffic, this is worth a look: send private traffic through VNRA, and keep the firewall for the flows that actually need inspection.

Prompting Anthropic v5 for Cloud Engineers: Practical Rules for Sonnet 5, Open 5, and Fable 5.1

Olivier Miossec — Mon, 14 Sep 2026 21:22:18 +0000

With each new model generation, Anthropic updates its prompting best practices, and the 5th generation is no exception.
This post distils the practical guidance from Anthropic’s documentation into actionable rules for Sonnet 5, Open 5, and Fable 5.1, focused on cloud engineering workflows.

Rules for every current model

Give the reason, not just the rule
The model will use the why or the reason to generalise and find an answer on what wasn’t present in the prompt.

Don’t do: Don't use Write-Host in the script.

Do: Don't use Write-Host: this script runs as an Azure DevOps pipeline task where only the streams are captured, and Write-Host output is invisible in the job log.

Write the output contract explicitly
The model has no idea of your convention and format.

Don’t do: Write me a PowerShell function to get ExpressRoute circuit status.

Do: Write a PowerShell 7 function Get-ErCircuitHealth. Contract:

[CmdletBinding()], approved Verb-Noun, singular noun, comment-based help with at least one .EXAMPLE
Accepts -SubscriptionId (mandatory, ValidateNotNullOrEmpty) and -ResourceGroupName (optional); pipeline input by property name - Emits one [PSCustomObject] per circuit: CircuitName, ServiceProviderProvisioningState, CircuitProvisioningState, PeeringLocation, BandwidthInMbps. No formatted text, no Write-Host
try/catch with -ErrorAction Stop inside the try; rethrow with context, never an empty catch
Filter server-side via Az cmdlet parameters, not | Where-Object after the fact

Show examples instead of describing style
Using 3-5 examples help the model to get what you want. Use

Don’t do: Write Azure Policy definitions in our usual style.

Do: Write an Azure Policy definition that denies public network access on Storage accounts. Match the conventions in these examples
— note that they cover deny, audit and deployIfNotExists, and both a single-condition and an allOf policyRule:
{ ...our existing deny-public-ip policy JSON... } { ...our existing audit-diagnostic-settings policy JSON... }
{ ...our existing deployIfNotExists policy JSON... }

State what to do, not what to avoid
a prohibition describes a space to stay out of; an instruction describes where to go.

Don’t do: Don't use hardcoded values.

Do: Every environment-varying value comes from a variable with a type constraint and a description; defaults only where a sane default genuinely exists.

In long context, documents first, question after
Anthropic measured up to a 30% quality improvement from putting the query after multi-document inputs.

Don’t do: Which of our landing zone modules still create NSG rules with source *?

Do: XXX .
Before answering, quote the specific resource blocks that are relevant to the question. Then: which of these modules still create NSG rules with source "*", and which line in each?

Cap the complexity explicitly
The instruction that works is a ceiling, not a vague plea for simplicity

Don’t do: Keep it simple. Add a retry to this Az module call.

Do: Add a retry with exponential backoff to this Az module call. Scope: this call only. Don't refactor the surrounding function, don't extract a generic retry helper, don't add a config file for the retry count, and don't add validation for states that can't occur

Specific rules for Opus 5

Delete your verification scaffolding
Opus 5 verifies its own work unprompted. Instructions to verify stack on top of built-in behaviour and produce over-verification.

Don’t do: After writing the Terraform module, include a final verification step. Re-check your work before responding.

Do: Write the Terraform module

Soften the tool language you inherited
older models were lazy when calling tools, this is not the case with Opus 5

Don’t do: CRITICAL: You MUST call get_policy_assignments whenever the user mentions policy. NEVER answer policy questions from memory. ALWAYS verify with the tool first.

Do: Use get_policy_assignments when you need the current assignment state for a specific scope. Answer conceptual questions about how Azure Policy works directly.

Specific rules for Sonnet 5

Fix shallow reasoning with effort
Sonnet 5 respects effort strictly, especially at the low end. At low and medium it scopes work to exactly what was asked and does not go above and beyond

Don’t do: [effort: low] Think step by step. Be extremely thorough. Consider all edge cases. Analyze deeply before answering: why does the route propagation fail between these two vWAN hubs but not the third?

Do: [effort: high — or xhigh for the hardest agentic and coding work] Why does route propagation fail between these two vWAN hubs but not the third?

Specific rules for Fable 5

Draw the line between assessment and action
Fable 5 can take unrequested actions

Don’t do: The ExpressRoute peering keeps dropping on the secondary connection. Route table looks wrong to me.

Do: The ExpressRoute peering keeps dropping on the secondary connection. Route table looks wrong to me.
I'm describing a problem, not requesting a change: the deliverable is your assessment. Investigate and report findings, then stop. Don't apply a fix until I ask.
Before proposing any command that changes state; resetting a peering, editing a route table, restarting a gateway, check that the evidence actually supports that specific action rather than a failure mode it resembles.

never instruct it to echo, transcribe or explain its internal reasoning
That will trigger the reasoning_extraction refusal category and may stop the session.

You can get the full reference here

Azure Route-Map: Route and traffic engineering in Azure

Olivier Miossec — Fri, 07 Aug 2026 19:23:22 +0000

Everything in Azure networking is easy until you connect something to it. It's the joke I open with every time I run a training session on how Azure networking actually behaves behind the scenes, and routing is no exception.

I've already written about routing in Azure with UDRs and the risk of building asymmetric paths (Asymmetrical routing in Azure network). This post goes one level deeper: modifying the BGP advertisements themselves.

That's traffic engineering. It's routine practice in on-premises networking and a new one in Azure. Two features carry most of the weight today: advertised gateway prefixes on a hub VNET, and Route-maps in Virtual WAN and Azure Route Server (in public preview).

Advertised gateway prefixes

Azure virtual networks expose a property called summarizedGatewayPrefixes (GA since 2026-08-20). It lets you hand the gateway a list of CIDR blocks to advertise instead of its default advertisement.

The default behaviour is straightforward: an ExpressRoute Gateway or VPN Gateway advertises every address space of its own VNet, plus every address space of each peered VNet using gateway transit. In a hub-and-spoke topology, that means every spoke prefixes are advertised to the gateway.

So instead of advertising 10.0.0.0/24, 10.0.1.0/24 and 10.0.2.0/24 separately, you configure 10.0.0.0/22 on the hub VNet and the gateway advertises that single prefix. For each peered spoke, Azure checks whether the spoke's address space is covered by a summary — if it is, the spoke prefix is suppressed. If it isn't, it keeps being advertised individually.

ExpressRoute private peering caps the number of prefixes that can be advertised on a single connection to 1,000 IPv4 and 100 IPv6. Cross the ceiling and the session drops. That is not a graceful degradation; it's an outage. In a Hub VNet with a few hundred spokes and multiple address spaces per spoke, you get there faster than you'd like.

The property only takes effect on a VNet that has a GatewaySubnet and a deployed gateway. You can set it earlier; it just does nothing.
It applies to both VPN Gateway and ExpressRoute Gateway.

Route Maps

This used to be the only BGP manipulation available outside Virtual WAN. That changed: Route Maps for Azure Route Server entered public preview recently.

Route-maps is a policy engine on the virtual hub. It inspects, modifies and filters the routing information exchanged between the hub and a connection, in the inbound direction, the outbound direction, or both.

It applies to ExpressRoute connections, site-to-site VPN connections, point-to-site connections, and VNet connections. One route-map per direction, per connection.

Worth knowing up front: you cannot apply a route-map to the connection between on-premises and an SD-WAN or firewall NVA deployed in the hub, other connections in that hub still work normally.

A route-map is an ordered list of rules. Each rule has match conditions and actions, plus a Next step setting that decides whether a matched route continues to the following rules or terminates there.

Match conditions — Route-prefix, AS-Path, Community, each with an equals or contains criterion:

Property	Criterion	Meaning
Route-prefix	equals	Matches those exact routes only
Route-prefix	contains	Matches those routes and everything more specific underneath
AS-Path	equals	AS-PATH must contain the listed ASNs in that order
AS-Path	contains	AS-PATH contains one or more of the listed ASNs, order irrelevant
Community	equals	Route must carry all the listed communities
Community	contains	Route carries one or more of them

Multiple match conditions in a rule are evaluated as a logical AND, all of them have to be satisfied. A rule with no match condition matches every route on the connection. If no rule matches, the default is allow, not deny.

Actions — drop, or modify:

Property	Action	Effect
Route-prefix	Drop	Matched routes are filtered out of the advertisement
Route-prefix	Replace	Matched routes replaced by the prefix(es) in the rule (this is summarization)
AS-Path	Add	Prepend the listed ASNs
AS-Path	Replace	Set AS-PATH to the listed ASNs — with no value, clear it
Community	Add / Replace / Remove	Add, overwrite, or remove specific communities

A single rule can carry several modifications; the order in which they're written doesn't matter.

Use cases

Summarization

Same problem as Part 1, this time on a Virtual WAN hub. You're heading toward the ExpressRoute advertised-prefix ceiling and you need to cut the count.

Match: Route-prefix, contains, 10.2.0.0/16
Action: Route-prefix, Replace, 10.2.0.0/16
Applied: Outbound, on the ExpressRoute connection

Instead of a pile of /24s, the circuit sees one /16.

Two caveats. Summarization strips the BGP community and AS-PATH from the resulting route.

Filtering

Match: Route-prefix, contains, 10.2.0.0/24
Action: Drop

The prefix is no longer advertised to that peer. This is not a firewall. You've removed a route, not blocked traffic. If the peer has another path to that destination, a default route, a summary from elsewhere, a User Defined Route, the packets still flow. Filtering is a routing tool. Use Azure Firewall or NSGs for security.

BGP communities

A community is a tag attached to a route so that the receiving side can make policy decisions on it. Virtual WAN preserves communities generated by BGP peers, within a hub and across inter-hub connections.

The natural use is classification. Say you tag by workload tier:

Prefix	Community
`10.0.0.0/21`	`65001:100` database services
`10.0.8.0/21`	`65001:200` production applications
`10.0.16.0/21`	`65001:300` test
`10.0.24.0/21`	`65001:400` dev

Match: Route-prefix, contains, 10.0.0.0/21
Action: Community, Add, 65001:100

The connected network can then apply local preference, filtering or QoS policy on the tag rather than maintaining a prefix list that goes stale every time someone deploys a spoke.

Do not remove the Azure-reserved communities in the 65515:*, 65517:* and 65518:* ranges. They are used internally and stripping them breaks routing in a way that is unpleasant to debug.

AS-PATH manipulation

This is the part where most designs go wrong, so it's worth being precise.

The scenario

A Virtual WAN with two hubs: Hub-Paris (France Central) and Hub-London (UK South). A branch office runs a site-to-site VPN with BGP to both hubs, so it learns Azure routes from both. An application VNet attached to Hub-Paris advertises 10.2.100.0/24.

Every Virtual WAN hub and gateway uses ASN 65515, and that is not configurable. Inter-hub propagation doesn't add an ASN either. So the branch receives 10.2.100.0/24 from two neighbours with an identical AS-PATH. Equal length, equal everything, you have no say in which hub it picks.

Goal: the branch should prefer Paris and keep London as a warm backup.

The fix

Apply the route-map outbound, on the branch's VPN connection in Hub-London:

Match: Route-prefix, equals, 10.2.100.0/24
Action: AS-Path, Add, your ASN (repeat it two or three times for margin)
Direction: Outbound
Connection: the site-to-site VPN connection to the branch, in Hub-London only

The branch now receives the prefix with a one-ASN path from Paris and a longer path from London. Paris wins on AS-PATH length; London stays in the RIB as a backup and takes over if Paris drops.

Why not inbound at Hub-Paris

Because inbound route-maps are applied before the route enters the hub's defaultRouteTable — and that table feeds every propagating connection, including the inter-hub link to London. Prepend inbound at Paris and both hubs advertise the prepended route to the branch. You've made the prefix uniformly less attractive and changed nothing about which hub gets chosen.

Inbound is the wrong direction for this problem. It's the right direction for a different one.

Choosing an ASN

2-byte ASNs only. If your network runs 4-byte ASNs, you can't use them in a route-map action.
Don't use reserved numbers: public 8074, 8075, 12076; private 65515, 65517, 65518, 65519, 65520.
For Express Route only Don't use private ASNs for prepending. the Microsoft Enterprise Edge router that connect to your network locally removes private ASNs from the AS-PATH, so your prepend never reaches the your routers and you spend an afternoon wondering why nothing changed. This stripping doesn't apply to a VPN-connected branch.
Never prepend the receiving router's own ASN. It will reject the route as a loop. Same reason you can't prepend 12076 over ExpressRoute.
64496–64511 are RFC 5398 documentation ASNs and are explicitly not permitted in the path over ExpressRoute.

The distinction that matters:

Inbound route-maps can influence Azure's own best-path selection. The modified AS-PATH is what lands in defaultRouteTable, and with hub routing preference set to AS Path, the hub compares those lengths. This is how you make Azure prefer ExpressRoute over VPN, or one hub over another, for return traffic.
Outbound route-maps cannot. Best-path selection happens before outbound route-maps run. Outbound only changes what the peer sees.

things to remind

One line to remember: inbound influences Azure's choice; outbound influences your peer's choice. Pick the direction that matches whose decision you're trying to change.

Route-maps aren't applied to the virtual hub address space.
A prefix can be modified by Route-maps or by NAT, not both.
Your spoke VNet connections must propagate to the Default route table for their prefixes to reach on-premises at all.
Set Terminate on the last rule, or you'll spend time debugging a rule you thought had stopped processing.
Use the Route Map dashboard to verify. It shows the route before and after the map, with AS-PATH and communities — which turns "I think this worked" into "this worked."

Azure has quietly grown a real traffic-engineering toolbox. summarizedGatewayPrefixes handles route scale on classic hub-and-spoke; Route-maps gives Virtual WAN the prefix, AS-PATH and community control that on-premises networks have had for twenty years; Route Server is catching up.

But the tools don't change the fundamentals. A summary is a promise about reachability, and a promise your address plan can't keep becomes a blackhole. A dropped route is not a blocked flow. And an AS-PATH prepend only does something if it's applied in the direction of the decision you're trying to influence, which is why the single most useful thing to internalise is inbound changes Azure routes, outbound changes your peer routes.

Route Map can be difficult to master, it is a good advise to confirm your design on a test environment before going in production.

I would like to thank Jose Moreno; his blog helped me understand Route Maps. I recommend reading it.

Local AI with Foundry Local and PowerShell: chat, memory, tools; building a harness.

Olivier Miossec — Fri, 17 Jul 2026 17:53:05 +0000

Since June 2026, the frontier labs have not stopped shipping: Fable, Sonnet 5, GPT-5.6 (Sol, Terra and Luna), Grok 4.5 trained on Cursor metrics, without talking about Chinese models DeepSeek R4, Kimi K3 and GLM 5.2. The race for the next frontier model is wide open.

A quieter signal runs alongside it: the move to open-weight models. Microsoft is testing DeepSeek, Uber Eats and Airbnb are running Qwen, Cursor uses Kimi. These models run on hardware you control, and they do real work for a fraction of the cost of a frontier API call.

Three reasons push in the same direction: API cost, privacy and data residency (GDPR and the Cloud Act discussion in the EU), and the fact that the gap between open-weight and frontier models has narrowed sharply in the last few months.

This is where Foundry Local fits. It ships SDKs (Python, C#, Rust, JS, C++) and a CLI exposing a REST API, in under 100 MB. It handles model acquisition and hardware acceleration for you: pick a model from the curated catalogue — Mistral, Phi, Qwen and others — and Foundry Local selects the right backend for your machine (CPU, GPU, NPU).

What Foundry Local doesn’t give you is the harness: the small program between the model and the real world that holds the state, executes the tools, and decides what comes back. This post is about writing it in PowerShell.

To install Foundry Local CLI, use the latest release on the GitHub page of the project.

Everything below is in preview. This post uses the Foundry Local CLI 0.1.1 and has been tested on CLI 0.1.2.

Scripts used in this post can be find on my GitHub repos

You can find a YouTube Video with all the demo here

The CLI runs a local service. Everything else in this post talks about it, so start here.

>Foundry server status

You should have something like:

StateReady
PID60900
Started2026-07-13 18:58:02Z
Uptime1d 2h 13m 39s
Web URLs http://127.0.0.1:56172

If not, you can start the server.

>foundry server start

You can get a list of models available for your platform via this command.
>foundry model list

To get more information about a particular model, use this command:
>foundry model info mistral-7b-v0.2

Models are identified by an alias, and each alias can resolve to several variants. A variant is a build of the model for one acceleration backend, TensorRT or CUDA (NVIDIA), QNN (Qualcomm), or generic, and one device type (CPU, GPU, NPU).

Foundry Local picks a variant for you, but the pick is only as good as your hardware; a machine with no suitable GPU falls back to NPU.

The alias usually encodes the parameter count; for mistral-7b-v0.2, it is 7 billion. One exception is the Phi models, which use size tiers (mini, small…). More parameters mean a bigger memory footprint and generally more capability, though architecture and training quality matter at least as much.

The “model info” command also reports the context window, in tokens. This matters more than it looks: as you approach the limit, older turns get dropped, and the model starts answering confidently from a history it no longer has.

One last property: whether the model supports tool calling. The model never executes anything itself; it emits a structured request that your code executes and feeds back. In practice, below roughly 3B parameters, tool call reliability drops off fast.

To be able to use a model, it must be available in the local cache and loaded.

You can download a model:
>foundry model download qwen3.5-4b
And then load the model.
>foundry model load qwen3.5-4b
The latest command will download the model if it is not in the cache and load the model.
You can run the model by typing.
>foundry run qwen3.5-4b

You get a chat with the model; you can type /help to see available commands.

But this is just a chat. It is limited; there is no context, no memory, no tools, no harness.
To add more control, we can start building a solution in PowerShell using the included REST API.

The port is assigned at startup and changes when the service restarts. Don't hardcode it; read it back from the foundry server status command, or the SDK, before each session.
>foundry server status
If the service is not started, you need to use this command:
>foundry server start
To use the foundry CLI in PowerShell, we need to save the URI given by the command in a variable:

$restApiUri = "http://127.0.0.1:56172"

For the first script, we will do a simple chat, a simple question to the model.

$body = @{
        model    = "qwen3.5-4b"
        messages = @( @{ role = "user";   content = "Give the name of the capital of Belgium"   } )
    }

 $params = @{
        Method  = "POST"
        Uri     = "$($restApiUri)/v1/chat/completions"
        Body    = ($body | ConvertTo-Json -Depth 10)
        ContentType = "application/json"
    }

$result = Invoke-RestMethod @params

Foundry Local's REST API is OpenAI-compatible, which is the whole point: the body you build here is the same body you'd send to api.openai.com. Swapping a local model for a hosted one becomes a URL change.

The result contain an object with different property, among them the model, choices which is an array of HashMap containing the conversation with the model and total_tokens, a map listing used tokens, prompt_tokens, completion_tokens and total_tokens:
usage : @{prompt_tokens=11; completion_tokens=7; total_tokens=18}

It also contains the property Choices, an array that contains the interaction with the model. Normally the Model’s response is in the first (index 0). It contains the message, a map with a role (assistant), a content, the model response and the tool_call.

To get the message:

$result.choices[0].message.content

The script so far does nothing the CLI chat didn't. The first real gain is the system prompt: instructions that shape behaviour before the user ever speaks. It's the cheapest control surface you have.

To do so we need to modify the $message variable and add a hash table with the system role:

$messages = @(
    @{ role = "system"; content = "You are a PowerShell coding assistant. Only give code if requested." }
    @{ role = "user"; content = "Give me a PowerShell script to list all files in a given directory." }
)

This works, but the model has no memory. Every call is a cold start; nothing carries over. Memory here isn't a feature of the model; it's you resending the transcript on each interaction.

Which means the transcript needs to preserve insertion order and grow cheaply. A PowerShell array += reallocates on every append, so use a generic list:

[System.Collections.Generic.List[hashtable]] $Messages = @(
    @{ role = "system"; content = "You are a science popularizer specializing in physics." }
    @{ role = "user"; content = "Explain quantum computing in plain English in less than 200 words" }
)

The first interaction is similar to the two first examples. But for the next interaction with the model, the result is added to the message.

$assistantResponse = $result.choices[0].message.content
$messages.Add(@{ role = 'assistant'; content = $assistantResponse })

Then you can create a new message

$messages.Add(@{ role = 'user'; content = "Now explain it to a 5 year old" })

And start the conversation with the history.

Everything above sets up the last piece. Tool calling only works because of the transcript, the model's request, your result, and its final answer are three turns in the same history.

A model doesn’t execute tool, instead the model send back a request for the tool to be executed externally and return the result.

The function is a stub, it returns a canned answer so we can focus on the protocol, not on Azure stuff.

function Get-VnetPeeringStatus {
    param (
        [string]$VnetName,
        [string]$ResourceGroup
    )

    # Simulate a response from Azure
    return @{
        VnetName      = $VnetName
        ResourceGroup = $ResourceGroup
        PeeringStatus = 'Connected'
    }
}

To use a tool calling this function, the model needs to know its definition, which is a JSON array. You can define one or several tool.

$tools = @(
    @{
        type     = 'function'
        function = @{
            name        = 'Get-VnetPeeringStatus'
            description = 'Returns the peering status of an Azure VNet'
            parameters  = @{
                type       = 'object'
                properties = @{
                    VnetName      = @{
                        type        = 'string'
                        description = 'Name of the virtual network'
                    }
                    ResourceGroup = @{
                        type        = 'string'
                        description = 'Resource group containing the VNet'
                    }
                }
                required = @('VnetName', 'ResourceGroup')
            }
        }
    }
)

Then the message is needed:

[System.Collections.Generic.List[hashtable]] $Messages = @(
    @{ role = "system"; content = "You are an Azure infrastructure assistant. You have access to tools that query live Azure state. When a user asks about the status of a resource, call the appropriate tool instead of guessing. Only answer from tool results, never fabricate resource state." }
    @{ role = "user"; content = "Is the hub-vnet in rg-network-prod peered correctly?" }
)

Note how much heavier the system prompt is here. It tells the model to call the tool rather than guess, and to answer only from tool results. With small models this isn't optional, a 4B model asked about live infrastructure will happily invent a plausible peering status. The prompt is your first line of defence against this kind of hallucination.

Then we need to create the body:

$body = @{
    model       = $modelID
    messages    = $messages
    tools       = $tools
    tool_choice = @{ type = 'function'; function = @{ name = 'Get-VnetPeeringStatus' } }
} | ConvertTo-Json -Depth 10

“tool_choice” pins which tool the model may call. Here I force Get-VnetPeeringStatus, useful for a demo, since it removes one source of nondeterminism. In real use you'd set auto and let the model decide, which is also where small models start to disappoint.

After send the request to the model, we need to scan the response to see if a “tool_calls” is returned.

$choice = $result.choices[0]

if ($choice.finish_reason -eq 'tool_calls') {
    # Append the assistant turn (with its tool_calls) to history
    $messages.Add(@{ role = 'assistant'; content = $choice.message.content })


    foreach ($call in $choice.message.tool_calls) {
        $args = $call.function.arguments | ConvertFrom-Json

        # Dispatch — never Invoke-Expression on model output
        $result = switch ($call.function.name) {
            'Get-VnetPeeringStatus' {
                Get-VnetPeeringStatus -VnetName $args.VnetName -ResourceGroup $args.ResourceGroup
            }
            default { @{ error = "Unknown tool: $($call.function.name)" } }
        }

        $messages.Add(@{ role = 'tool'; tool_call_id = $call.id ; content = ($result | ConvertTo-Json -Depth 5 -Compress) })

    }
    # Re-send with updated $messages to get the final answer
    $body = @{
        model       = $modelID
        messages    = $messages
    } | ConvertTo-Json -Depth 10        

     $params = @{
        Method  = "POST"
        Uri     = "$($restApiUri)/v1/chat/completions"
        Body    = $body
        ContentType = "application/json"
    }

    $result = Invoke-RestMethod @params
    $result.choices[0].message.content
}

The assistant content is added to the $message variable to keep the history.

Then for each call in the model message, the tool (the powershell function) is executed, and we add a new hashmap with the role tool, the tool_call_id and the result of the function.

Finaly, we resend the updated message to the model and this time it will reply to the question sent in the first interaction.

These are the basic interactions: chat, system prompt, memory, tools. Nothing here is PowerShell-specific, the same steps work the same way in Python or C#.

But look back at what got built. The model didn't remember anything; we resent the transcript. The model didn't call a function; it emitted a name and we decided whether to honour it. The model didn't check its own output; the switch did. Everything that made this useful happened outside the model, in a hundred lines of PowerShell sitting between it and the rest of the world.

That's the foundation of a harness. It's the small program that holds the state, owns the allowlist, executes the calls, and decides what goes back in. When you use a hosted product, the harness ships with it and you never see it. Foundry Local gives you a model and a port. The harness is yours to write, which is the cost, and the entire point: nothing reaches your infrastructure unless your code let it through.

One practical note before you build on this. Everything above talks to the REST API, which means you own the plumbing, discovering the port, resolving aliases to variants, catching a service that isn't up. I will post something about what you can do with the SDK.

Experiment with it; try it on some workflows but remember Foundry Local CLI is in preview, and you may encounter bugs and malfunctions.

I'm wrapping all of this into a PowerShell module; alias resolution, streaming, the tool dispatch loop. More on that in a follow-up.

Scripts used in this post can be find on my GitHub repos

The price of AI: The end of free AI or how model rationing creates hidden technical debt

Olivier Miossec — Mon, 20 Apr 2026 14:39:17 +0000

Anthropic kept its new model, Mythos, out of public release, only a douzaine of enterprises get limited access. The stated reason: security.
Yes, Mythos might be powerful enough to worry security teams, but part of the secrecy reads like a smart marketing move and not as a pure risk mitigation.

GitHub is certainly starting doing the same, there are rumours about tighten rate limits, just check this. They Stopped signup for new Copilot Pro subscription here.

Until then, the use of AI was largely subsidized; subscription low prices do not actually compensate for the compute cost.

The bigger point is simple: models are getting stronger and adoption is exploding. Pew finds 62% of US adults use AI weekly, and McKinsey’s 2025 survey shows 88% of organizations use AI in at least one function.

Stronger models + surging usage = far more compute demand. Demand can spike exponentially; datacentre capacity grows far more slowly. You can’t plug power, add cooling, set up generator, connect network and racks servers overnight, datacentre projects take 6–24 months.

More, estimates put GPU demand in the millions of H100 equivalents, well beyond what the industry can produce today.

When demand outstrips supply, vendors ration access. The best models and largest number of tokens will go to the highest bidders; everyone else gets older models, throttled contexts, higher latency, or no access during peak times. Free tiers will, also, erode.

That creates a new business risk: workflows tuned to a specific model may only run reliably behind a paywall in the next months, sometimes an expensive one. The sponsored run we enjoy today will be over soon. Either you pay a premium that kills margins, or accept degraded service when vendors throttle subscriptions.

Don’t lock yourself to a single vendor. Choosing models by public benchmarks is risky; what matters is how a model performs on your data and in your workflows, not leader board scores.

If you are only using Claude Code, you should start working also with GitHub Copilot CLI, or/and OpenAI Codex or OpenClaude.

You need to run your workflows on several model, not as an experiment, but as a routing. There are to possible outcome.

The output is similar, with or without a few adjustments, great you have a low lock-in risk
The output is degraded; you have a decency you must mitigate.

Adopt a model agnostic mindset. Prompts and context that rely on vendor quirks (Claude’s long context, GPT’s tool syntax, Gemini’s multimodal shortcuts) create hidden technical debt, and fragile, costly systems.

Plan for scarcity: design for multiple models, measure outputs on your real data, and treat model access as a strategic dependency.

You're Already in AI control Debt. You Just Haven't Seen the Bill Yet

Olivier Miossec — Thu, 09 Apr 2026 21:21:27 +0000

Poor deadlines, unrealistic timelines, pressure to finish a project on time, or lack of knowledge, often result as of what we call technical debt. The concept of future cost, a debt that must be repay by refactoring or redeploying a system, and where interests are pay by extra maintenance actions and reduced reliability.

This concept was coined in 1992 by Ward Cunningham and has since become a widely used framework to argue for software quality, system sustainability, and long-term organizational efficiency.

Looking at AI adoption today in cloud and software engineering, the parallel is hard to miss. The developer shipping features without review, the office worker using OpenClaw to speed up their tasks, the cloud engineer letting an agent generate deployment documentation, the architect wiring up an unknown MCP server to get a job done. Worse still, many employees use AI with personal accounts and no validation from their IT department; enter the new world of shadow AI.

These situations are commonplace today, and sometimes the results go well beyond what was intended. We're not just delegating tasks only, we're delegating decisions.

Think of a critical system failing because agent-generated code wasn't production-grade, a presentation riddled with hallucinated references, secrets or API tokens pushed to a public repository, personal data sent to an LLM, or a rogue MCP plugin taking control of a machine. The thread connecting all these examples is a lack of control, diligence, and discernment.

This raises a real question: is agentic AI as safe as we assume? There are three systemic risks to be aware of: security risk, compliance risk, and quality risk.

In the early days of the cloud, people started using file transfer services without authorization. Strategic files, client data, and confidential information were sent outside company networks with no visibility. It wasn't because people were reckless, they knew it wasn't allowed, but the value proposition was compelling enough: instant file sharing.

The value proposition of AI is well known to anyone in a corporate role. People are already sending files and data to AI systems for proofreading, analysis, and document drafting. That alone is a breach. Agentic AI is simply the next step.

When the OpenClaw project launched under the name Clawbot, it quickly became one of the most popular repositories on GitHub. It's an open-source AI agent that connects to LLMs. It can run workflows, connect to your calendar, CRM, and other applications, a genuine game-changer for anyone who had been waiting for a real personal assistant.

But OpenClaw has a dark side. Between the project's rename on GitHub and the explosion of third-party plugins, malicious elements have polluted the ecosystem. You think you've deployed a plugin to manage your CRM — and you have, but it's also leaking your data to a third party. That email-reading plugin? It may be handing access to your mailbox to a threat actor. Check what the CVE database says about OpenClaw.

OpenClaw isn't the only risk vector here — think about MCP servers. Almost nobody had heard of MCP a few months ago; today there are more than 15,000 available. How many are misconfigured or outright malicious? Far from just helping you to complete tasks, they drastically expand your attack surface. You can check this website.

The same applies to plugins and skills: they can contain malicious scripts or prompt injection payloads. Not vetting what you add to your AI agent can turn it into a liability.

AI agents are also vulnerable to prompt injection when processing external documents, and the broader the permissions granted, the larger the blast radius.

This is the essence of shadow AI, analogous to shadow IT, where employees used unauthorized Dropbox accounts to share data. Here they're using AI agents with the same mindset, but with a far greater potential impact on the company's infrastructure

But shadow AI isn't limited to agents running on local machines. Anyone in a company can open an AI chatbot, it's just a webpage. People paste in Excel tables, internal documents, or email threads without a second thought. It's nearly invisible from a monitoring perspective, but company data is out the door.

Company data is now flowing to servers outside your control and may be used to train models. Code, medical, insurance, and legal data are already inside these systems. Data ingested by an LLM cannot be truly erased, it should be treated as a permanent data leak. Shadow AI makes this worse: by definition, none of it will ever be audited.

Data leaked to an LLM can include sensitive coding assets: tokens, API keys, and sometimes passwords. But there's a bigger problem. LLMs are incredibly effective at generating content that looks correct. We've recently seen multiple examples of consulting firms and law practices submitting documents filled with entirely fabricated citations.

Code generation isn't exempt from hallucinations either; non-existent APIs, invented function parameters, bogus CLI commands, non-functional logic. At least in this case, the verdict is fast and unambiguous: the code doesn't run.

More insidious is the sub-optimal code that does run. Security gaps, misconfigurations, systems that can't scale under load, all pushed to production without a second look. The result: incidents at scale.

The root cause is a loss of control over pace. With traditional software engineering, writing and reviewing code operated on a human timeline. With AI, the same output is generated in minutes instead of hours. A single coding agent can produce more in a day than a team can meaningfully review, forcing engineers to ship code they don't fully understand.

Even worse, AI agents will take the most optimal path to complete a task, which is a problem when the intent or context is malformed. The result can be quietly catastrophic. Cases of agents dropping databases or silently erasing data are more common than most teams realize.

AI is relatively new, and agentic AI even more so. The evolution is rapid, and adoption is outpacing it. Too fast for enterprises to put a governance skeleton in place. If even the largest tech players have suffered AI failures, it tells us this governance still needs to be invented — and that the AI control debt is already accumulating.

Using Claude Code in a PowerShell Project: An Introduction

Olivier Miossec — Sat, 14 Mar 2026 18:47:01 +0000

Generative and agentic AI have reshaped software development in a few short months. This is more than asking a chatbot for help; it’s a mindset shift and a cultural transformation in how we design, generate and maintain code.

Claude Code is one of the most advanced agentic tools for code generation, but like any generative system it can produce incorrect or low quality output. See the sloop content on Instagram, AI used carelessly, it can create the same "surface level" results you see on social platforms, attractive but unreliable.

In this post I’ll show how to use Claude Code in a PowerShell project: we’ll build a module to automate GitHub issue management.
First, a quick intro: Claude Code is part of Anthropic’s ecosystem (alongside Claude.ai, the Claude API and Claude CoWork). Claude Code is designed as an agentic coding assistant rather than a simple chatbot.
You can download it here

Claude Code is not a Chatbot, it is an AI Agent; it follow a workflow, gets the context, analyzes, plan the work and creates the code. In Claude Code, you don’t ask a question, you specify the result you want and the agent executes.

There is one important notion in Claude Code (and other AI tools), the Context. Context is the agent’s working memory, measured in tokens. It’s critical to manage. Claude Code sessions typically support large contexts (hundreds of thousands of tokens, depending on your plan). Monitor usage with the /context command; if you approach ~60% capacity, run /compact to reduce context size and avoid degraded behaviours.

The first best practice with Claude Code, is to keep a CLAUDE.md at the project root: treat it like a brief for the agent. Describe the project goals, constraints, runtime targets and coding conventions. That file becomes the agent’s persistent context, so you manage an agentic collaborator rather than a stateless LLM chat.

You can generate CLAUDE.md with the /init command: when run against an existing codebase, the agent analyses the repository and drafts the brief based on discovered files and patterns.

In this tutorial we start from an empty folder; you can author CLAUDE.md manually or ask Claude Code to create it for you.

"Create a new CLAUDE.md file in this folder with these instructions, PowerShell module for GitHub Issue Automation, named psGTIssue, the module will use classes, private function and public function, it run with PwSh 7 on Linux, MacOS and Windows. The project structure include, src, tests and build folder, the code should respect the camel case notation for variable and authorized verb for function (get-something), Pester will be used for unit testing"

You should have something like this:

# CLAUDE.md — psGTIssue Project Instructions

## Project Overview

**Module name:** `psGTIssue`
**Purpose:** PowerShell module for GitHub Issue Automation
**Runtime:** PowerShell 7 (pwsh) — cross-platform: Linux, macOS, Windows

---

## Project Structure

psGTIssue/
├── src/
│ ├── Classes/ # PowerShell classes
│ ├── Private/ # Private (internal) functions
│ ├── Public/ # Public (exported) functions
│ └── psGTIssue.psm1 # Module root — dot-sources all classes, private, public
├── tests/
│ ├── Unit/ # Pester unit tests mirroring src/ structure
│ └── Integration/ # Integration tests (optional)
├── build/ # Build output and scripts
│ └── psGTIssue.psd1 # Module manifest (generated or maintained here)
└── CLAUDE.md


---

## Coding Conventions

### Naming

- **Variables:** camelCase — `$issueTitle`, `$repoOwner`, `$pageNumber`
- **Parameters:** camelCase — `param([string]$issueTitle)`
- **Classes:** PascalCase — `class GitHubIssue`, `class IssueFilter`
- **Functions:** Approved PowerShell verb + PascalCase noun — `Get-GtIssue`, `New-GtIssue`, `Set-GtIssue`, `Remove-GtIssue`, `Invoke-GtIssueAction`
- **Private functions:** same verb-noun convention, not exported — `Get-GtApiHeader`, `ConvertTo-GtIssueObject`
- **Constants / enum values:** camelCase

### Approved Verbs

Always use verbs from `Get-Verb`. Common ones for this module:
---

Now, we can create the project structure. First, create the project skeleton. Use a prompt such as Create the project structure and Claude will scaffold folders, a .psd1 manifest, a .psm1 module file, a build.ps1 script and Pester test stubs.

"Create a public function that list all issue for a given repository, param are repository, organization name and a switch all, open, close"

Now we can create a function that list all issue for a repository

The agent will create several files, a function to call the GitHub API, a function to retrieve all issues in the repository and test files.

You see that the prompt used are optimised to create a function, the prompt should be optimised to get the result. If you want a modification, you should be precise on the result you want.

For example, using a switch for the parameter $State is not a great idead
We can ask Claude to replace the switch parameter in the Get-GtIssueList to a simple validateSet parameter with All, Open, Closed.

"replace the switch parameter in the Get-GtIssueList to a simple validateSet parameter with All, Open, Closed in the
@psGTIssue\src\Public\Get-GtIssueList.ps1"

You can work directly on a file work by using @ here @psGTIssue\src\Public\Get-GtIssueList.ps1 it will cost less in token as Claude will not have to search for the file.

Now it is time to check the status of the session with /context. The command will show the percentage used by the session. If the number is higher than 60% you should run the command /compact
It is a good practice to name the session (and its context) so you can retrieve it later.

/rename buildGitHubIssuePwSh

To restart the session

claude --resume "buildGitHubIssuePwSh"

Review generated code carefully. Common issues: the agent may prefer Write-Verbose over Write-Debug, and it might scaffold a .psm1 that dynamically dot sources files at runtime. For best practice a static .psm1 that explicitly imports and exports functions and classes is better; this improves readability, testability and module loading behaviours.

You can encode these conventions in CLAUDE.md, but they’re generic PowerShell best practices you’ll want in every project.

Claude Code supports skills; reusable instruction sets that tell the agent how to behave in specific contexts. Create a PowerShell module skill to enforce coding conventions, file layout and test patterns across projects.
All you need to do is to create a folder in .claude/skills/ and create the file SKILL.md.

You can ask Claude for that

"Create the folder ./claude/skills/powershell-module at the root and add the file SKILL.md"

Claude will create the file for you with some elements

  - Trigger conditions for when the skill applies
  - Naming conventions summary
  - Function templates (public & private)
  - Class template
  - Module dot-source order
  - API call rules
  - Pester test patterns
  - File placement checklist

You can add an header

--- 
name: powershell-module 
description: conventions and guidelines for building PowerShell modules
argument-hint: "[check|fix]" 
---

And information about write-verbose and write-debug and psm1 generation.

### write-verbose?/write-debug?
- Use `Write-Verbose` for informational messages that may be helpful for debugging but are not critical to the user, only visible when the `-Verbose` switch is used. 
- Use `Write-Debug` for detailed debugging information that is typically only relevant when troubleshooting specific issues. This can be enabled with the `-Debug` switch when running the function.
- Avoid using `Write-Host` for regular output; reserve it for special cases where you want to display colored or formatted output directly to the console. For standard output, return objects or use `Write-Output`.

### psm1 file 
- The `.psm1` file should contain all individual functions and class files, and the `Export-ModuleMember` call to specify which public functions are exported. The build script will handle the creation of the `.psm1` manifest file, so you do not need to create that manually.
- All actual code (functions, classes) should live in separate `.ps1` files under the `src/` directory, organized into `Public`, `Private`, and `Classes` subdirectories.

Once conventions live in a skill, you can simplify CLAUDE.md and rely on the skill for enforcement. Skills are shareable, store them in a repo so your teams can reuse the same conventions and templates.

Another way to extend Claude Code is to use sub-agent. Sub-agent is a separate agent that use its own context (it doesn’t impact your session) specialised in one task. The task must be specific and should not be related to any other task in your current session.

Agents are located inside ./claude/agents folder.

We can ask Claude code to create the agent

Create the folder ./claude/agents/ at the root and add the file security-check.md

Claude will create the markdown file with some security check; you can review them and add your own check.

You can run the check

Start security check with the sub agent security-check

Claude will produce a report in the terminal you can review and then act on it.

Claude Code is a powerful agentic coding tool; it lets you manage a team of coding agents as if you had human collaborators. That power demands discipline: be precise in your briefs, test outputs, and maintain human oversight. Agents can produce useful code quickly, but they also make mistakes; you must validate, adapt, and own the result.

In short

Core commands and session hygiene

/init — generate CLAUDE.md from an existing repo.
/context — show token usage (monitor session memory).
/compact — reduce context when usage is high.
/rename — name the session for later resume.
claude --resume "" — resume a named session.
1st rule of Claude: compact when usage approaches 60–80% of context capacity.

Project files

CLAUDE.md — project brief (goals, constraints, runtime, conventions).
.claude/skills/powershell-module/SKILL.md — reusable PowerShell conventions and templates.
.claude/agents/ — sub‑agents for isolated tasks (security, linting).

Will AI Replace Your Job? A Practical Guide for Devs and Cloud Engineers

Olivier Miossec — Fri, 06 Mar 2026 18:28:55 +0000

The hot question today is: Will AI take my job? Headlines about mass layoffs and viral posts claiming an entire team can be replaced with a single prompt make the fear feel immediate. Scrolling LinkedIn or Twitter, you see dramatic claims and quick takes.

Many of those claims are exaggerated, for now. Companies cut headcount for many reasons: cost, restructuring, strategic shifts, and sometimes, "AI" is just a convenient narrative. Dismissing AI as a simple chatbot hype is also a mistake. The reality is that AI, mostly agentic AI, will change our relationship with work and how enterprises create value.

Agentic AI is real, and some roles will be replaced, just as roles shifted during the Internet, SaaS, and cloud revolutions. In this post, I’ll try to identify which roles are most at risk, suggest ways to protect and reskill yourself, and show how AI can create new opportunities. Like past technological revolutions, Agentic AI will destroy some roles, like steam trains removed the need for diligence, but it will create others.

Generative AI is a powerful tool that can process texts based on general knowledge. It excels at producing and transforming text-based artifacts: contracts, job descriptions, support tickets, documentation, and code. Agentic AI goes further by orchestrating workflows and subtasks autonomously. If your role is primarily about following a strict, repeatable process to produce standardized outputs, an agent can often do it faster and cheaper.

Examples include analysts, consultants, HR processes, and other roles where a defined input yields a standardized output. Developers face partial automation too: AI can generate boilerplate code, tests, and scaffolding quickly. Accounting and routine financial reporting are vulnerable. Many managerial tasks, such as synthesizing and distributing information from up and down, can be automated or augmented.

We already see concrete examples of agentic systems accelerating decision cycles. In high-stakes contexts, automated analysis of multiple data sources can reduce days of work to minutes. Similar acceleration is appearing in HR workflows and financial analysis, where agents aggregate, filter, and summarize large datasets. In the current war in the Middle East, the Pentagon is using agentic AI to analyze multiple data sources to make decisions.

If your role is primarily execution, producing outputs from well-defined and static processes without having to make any design or judgment, it’s at high risk of automation. Execution can be delegated to agents cheaply. It scales much more than humans can do. Does that mean you’ll lose your job? Not necessarily.

Generative AI is powerful but limited: it doesn’t make value judgments, exercise domain judgment, or possess taste. Those human skills, judgment, critical thinking, navigating ambiguity, domain expertise, and taste, become stronger differentiators in an AI-augmented workplace.

Be proactive: learn how AI works beyond the surface of simple prompts. You don’t need to be an expert or LLM engineer, but you should understand core concepts, how models generate text or images, what tokens and context windows are, and how parameters like temperature affect output. It will help you to have a better vision of what generative AI can do, cannot do, and why hallucinations happen.

Get hands-on with agentic AI platforms and tooling. Explore multiple ecosystems (Anthropic, OpenAI, GitHub Copilot, and others) and experiment with APIs, MCP, agent orchestration, and observability. Use vendor resources and community tutorials to build practical experience.

To learn more about the Anthropic ecosystem, you can use these courses published here

You can also learn GitHub Copilot CLI, it is for developers, but you can try to learn it with this beginner course (if you want to learn more, this page will be useful).

You may also try on local AI tool, where you can use a model on your local device. A good start is to set up Foundry local (https://learn.microsoft.com/en-us/azure/foundry-local/get-started?view=foundry-classic).

You can also try any other alternative AI tools, for example, Mistral AI (https://mistral.ai/products/studio).

Don’t wait for corporate training. Start learning on your own and build demonstrable projects. Early adopters will have an advantage over peers who delay.

Don’t be desperate, AI will also create new roles. Here are practical examples of emerging job categories where human expertise will remain essential:

Agent governance and compliance, to add policies, audit data access, and permissions for agents.
AI debt management, to identify, track, and remediate risks from unsupervised agent usage.
Agent developer/integrator, for designing, building, and maintaining task-specific agents and orchestrations.
Data discoverability and indexing, to ensure agents can reliably find and use the right data (the “AI SEO” problem).
AI-assisted code reviewer/verifier, for validating code produced by agents and ensuring security, correctness, and maintainability.
Token and cost optimization engineer for minimizing inference costs and optimizing model usage patterns.
AI infrastructure engineer, to deploy and operate compute resources, networking, and observability stacks for agentic workloads.

These are predictions,s and I may be wrong. But like past revolutions, agentic AI will eliminate some roles and create new ones, often in places we don’t yet fully anticipate. Things about the Steam train, it revolutionized the world of transportation and the economy.

AI will reshape work, but it won’t simply “replace” people overnight. Tasks that are repeatable and execution focused are most at risk; judgment, design, domain expertise, and governance remain human strengths. The practical strategy for engineers is clear: learn how agents work, build hands-on experience, and pivot toward roles that require oversight, orchestration, and measurable impact. Those who combine technical fluency with judgment and governance skills will be best positioned in this new tech revolution.

When AI Agents Meet Wall Street: Why Markets Overreact and what Engineers Should Prepare For

Olivier Miossec — Sat, 28 Feb 2026 12:28:00 +0000

An economic bubble occurs when asset prices detach from long term fundamentals and are driven instead by irrational exuberance and social contagion.

Since 2025 we’ve seen that pattern again: mass layoffs, elevated valuations, and extreme market volatility, all of this are tied to the AI narrative.

Let’s try to analyse what happens and see if we can define a strategy for us, engineer.

Last year major tech firms, Meta, Amazon, Microsoft and others, announced mass layoffs totalling roughly 200,000 roles. Publicly, the rationale was the rise of AI: many positions will be automated or restructured around AI capabilities.

There is some truth in this reason, but this is not the main reason. To get the main reason, take a lot on what these companies are doing with their investments.

There’s truth in that claim, but it misses the main driver. Look at where these companies are investing infrastructure, chips, datacentres and energy capacity. It is not just about chatbots.

They’re not just chasing chatbots; they’re preparing for an agentic AI world. Training large models consumes massive energy, while inference, asking something, is far cheaper. The real shift is the infrastructure needed to run persistent, autonomous AI agents at scale.

Agentic AI is not like Chatbot: agents such as Claude CoWork operate autonomously, executing tasks without continuous human input; managing email, CRM workflows, scheduling, and more. Once created, an agent can remain active and consume resources while completing its tasks.

The capacity required is colossal: servers, accelerators, datacentre space, networking and power provisioning at scale.

To build that capacity companies must invest heavily; buying accelerators (e.g., NVIDIA GPUs), networking devices and datacenter capacity, and securing power contracts. That capital commitment helps explain why some firms reallocate headcount toward these investments.

It is capital reallocation, laying off people to build AI capacity, I can’t say it is fair or normal. But this is very rational.

What’s less rational is the market’s reaction to agentic AI in 2026. Agents differ from chatbots: the value proposition is task execution, not prompt finesse. An agent combines an LLM, tool access and autonomy, but that doesn’t mean it instantly replaces entire software categories.

In January Anthropic launched Claude CoWork, an agent that handles non technical tasks locally (initially macOS only): files, email, calendar, and deliver artifacts like spreadsheets and text summaries.

Claude CoWork wasn’t the first agentic solution, but it was the first to capture broad public attention. Anthropic developed it after customers used Claude Code for non coding tasks; managing email, expense reports and file organization, demonstrating real demand for delegated AI automation.

Soon after CoWork’s general availability, several SaaS and enterprise software stocks, like Salesforce, SAP or Adobe, saw a large market declines, contributing to a broader sell off in software. The MSCI Software & Services index fell significantly in early 2026.

The market appears to be pricing a future where AI agents displace some SaaS functionality. That view is optimistic and only partially rational, because agents may complement rather than fully replace many enterprise apps in the near future.

What’s coming next is surprising. Markets moved into irrational territory. On 20 February Anthropic published a blog post suggesting Claude Code could assist with static code analysis. It is just a concept, not a shipped product or roadmap. Yet cybersecurity stocks, from niche vendors to large firms like Palo Alto and CrowdStrike, tumbled in response.

On 23 February another Anthropic post suggested agents could assist with modernizing COBOL code, again a concept. Consulting firms and legacy technology vendors saw market pressure as investors extrapolated far beyond the announcement.

This is the irrational zone: a static analysis capability cannot replace entire cybersecurity teams, runtime scanners, or the complex processes that govern legacy banking systems. The market is reacting to buzzwords without understanding the engineering and operational realities behind the headlines.

Sound familiar? It echoes the dot com bubble, when a single buzzword in a press release could inflate a stock. The mechanism is the same: narrative driven speculation divorced from technical substance.

It’s easy to laugh, but boards will react. A sudden market signal can pressure executives to “do AI”, sometimes by reallocating resources toward visible AI projects at the expense of core capabilities like cybersecurity.

We may be in a feedback loop where irrational market moves trigger irrational corporate responses. As engineers, remember that AI is a tool, a powerful tool, but only a probabilistic predictor that generates text, code or images. It does not make value judgments or replace human decision making.

Strategy for engineers: learn agentic AI, not just prompt engineering, but how agents are built, orchestrated and monitored. Master relevant tools and workflows (e.g., agent orchestration, observability and safety patterns). AI will also create new roles; those who understand agentic systems will be better positioned.

And of course, there will be soon some AI tools that could complete the cybersecurity landscape, but it will be a real product, with verifiable, measurable and concrete results.

What is wrong with LinkedIn in the age of AI

Olivier Miossec — Wed, 11 Feb 2026 11:02:06 +0000

Like everyone in tech, I utilize LinkedIn to manage my professional network, showcase my work, and maintain visibility to recruiters. LinkedIn is central to professional life and has no real competitor.

Not long ago, I had a strange experience: a stream of posts about an Azure networking change. Nothing unusual, this kind of post floods my LinkedIn every week, but here, there was a tiny but consequential error. The update stated that the change would occur on 30 September 2025, yet the posts were dated December 2025. Everyone was warning readers to act on a change that, in reality, was scheduled for 31 March

This is where we are now: a lot of noise on a professional network. That noise is amplified by conformity. People avoid friction and rarely post dissenting views. The result is a chorus of similar takes that can feel caricatural; sometimes the most viral LinkedIn posts end up as jokes on Twitter or Reddit, and some have become famous memes.

This Mediocrity is only part of the problem on the platform. Much of LinkedIn is declarative and unverified: anyone can claim to be a Rust or Go expert simply by writing it. You can be a brain surgeon if you want; you only need to edit your profile. The platform is full of inflated titles and grandiose claims that often bear little relation to reality.

That’s bad news for job seekers. Recruiters must wade through noise and exaggerated titles before they even reach your profile. By the time they find you, they still don’t know whether your résumé is accurate or just inflated.

There is a lot of friction before reaching your profile. A potential recruiter will need to navigate through all the noise, do some research, and maybe find you. But at this point, the recruiter will have no idea if your profile is valid or if it is just an inflated one.

The recruiter needs to navigate to LinkedIn, like you do when trying to find a job. It’s often frustrating. The probability that a recruit will find you is limited.

LinkedIn’s interface, like any computer interface, is designed for humans to navigate into the complexity of data, to control their behaviours, and authorize access.

The interface is going to be disrupted by Artificial Intelligence. Agentic AI are systems that can autonomously plan, make decisions, and take actions to achieve goals without human direction, and can now replace some work tasks, including finding profile.

AI Agents do not have time to lose scrolling a feed on the interface; they work on raw data. When a recruiter instructs an agent to find an Azure architect skilled in Bicep and Terraform, the agent won’t scroll through posts and buzzwords. It will search raw, verifiable artifacts; GitHub and GitLab repositories, blog posts, published articles, … These are concrete and verifiable artifacts to spot the perfect profile.

In this agentic recruitment world, LinkedIn becomes secondary. It will be useful for correlation, but the primary sources will be your public artifacts: documented side projects, repositories, PRs and issues, and technical blog posts. Those are the things agents can verify and score.

To facilitate the AI, you should group them on a single page visible from GitHub, Twitter and LinkedIn. A personal brand API that automatically lists your original blog posts, your public repos, your PR, and your contributions. This will be your new AI era visit card.

LinkedIn still matters for human networking and visibility, but the rise of agentic hiring shifts the signal to verifiable, AI-readable artifacts. Start publishing concrete work and make it easy for agents to find and verify.

Azure Machine Configuration, Linux, and DSC Configuration

Olivier Miossec — Tue, 13 Jan 2026 22:03:23 +0000

I recently made a post about Azure Machine Configuration and PowerShell DSC, and how to deploy VM configurations as infrastructure as Code, just like the rest of your infrastructure.

But in this post, I focused mainly on Windows configuration and wrote almost nothing about Linux.

However, Azure Machine Configuration is also available for Linux VMs, where you can use DSC or Chef InSpec.

To run DSC configurations, VMs need to have the AzurePolicyForLinux extension and a managed identity.

But unlike Windows, most Linux VMs don’t come with PowerShell installed. To solve this problem, the AzurePolicyForLinux extension installs PowerShell in a Folder but doesn’t modify the Path of the VM. PowerShell can only be used by the policy.

The next step is to write a DSC configuration. There are many DSC resources for managing Windows, but to manage a Linux server, you will need a compatible DSC resource. The most advanced is the NxTools module. It is the recommended version to use with the Azure Machine configuration.

The NxTools module is a POSIX wrapper for several Linux commands and includes several DSC resources.

nxFiles, to manage files and folders
nxGroup, to manage groups and group membership
nxUser, to manage users
nxPackages, to manage packages (support only apt)
nxService, to manage service (only system)
nxScript, to execute scripts in DSC configurations

To demonstrate DSC on Linux with Azure Machine Configuration, let's ensure the user devTo is created and added to the group publisher, and a file with specified content is created using a script resource.

configuration demoDSCLinux
{

    Import-DscResource -ModuleName 'nxtools'


        nxUser ensureDevToUser {

            Ensure =  'Present'
            UserName =  'DevTo'
            FullName = 'Dev To Demo user'
            HomeDirectory = '/home/DevTo'
            Description = 'Ensure that DevTo user is present on the system'
        }

        nxGroup ensurePublishersGroup {
            # the group must be present and have root as only member
            Ensure =  'Present'
            GroupName =  'publishers'
            Members = @('DevTo')
        }

        nxScript ensurePublisherfilePresent {
        GetScript = {
            $Reason = [Reason]::new()
            $Reason.Code = "Script:Script:FileMissing"
            $Reason.Phrase = "File does not exist"

            if (Test-Path -Path "/home/DevTo/publisher.txt")
            {
                    $Reason.Code = "Script:Script:Success"
                    $Reason.Phrase = "File exists"
            }

            return @{
                Reasons = @($Reason)
            }
        }
        TestScript = {
            if (Test-Path -Path "/home/DevTo/publisher.txt")
            {
                return $true
            }
            else
            {
                return $false
            }
        }
        SetScript = {
            $null = New-Item -Path "/home/DevTo/publisher.txt" -ItemType "File" -Force
        }
        }

}

The first two resources create the DevTo user and create the Publishers group, and add the DevTo user.

The last one ensures that the file "/home/DevTo/publisher.txt" is present on the system using a nxScript resource. The GetScript block of the resource needs to return a Hashtable with a Reason object to work. The reason.phrase will be shown in the Azure Portal in case of noncompliance.

If you try to compile this configuration on your Windows or macOS machine, you will get an error; you need a Linux VM with PowerShell.

You can set up a dev VM for that, but you can also use a CI/CD pipeline to compile and package the configuration for Linux. You can also compile and package the DSC configuration in GitHub Actions.

First, you will need a script for compiling the configuration and creating the Azure Machine Configuration package.

# Check if the host is a Linux system

if ($IsLinux -eq $false) {
    Write-Error "This script must be run on a Linux system."
    exit 1
}

# install modules 
Install-Module -Name nxtools -Force
install-module -name PSDesiredStateConfiguration -RequiredVersion 3.0.0-beta1 -Force -AllowPrerelease
install-module -name GuestConfiguration -Force -RequiredVersion 4.1.0 

# compile the demo configuration

. ./DSC-Linux/demolinux.dsc.ps1

demoDSCLinux

# rename the MOF file 

Rename-Item -Path .\demoDSCLinux\localhost.mof -NewName demoDSCLinux.mof -Force 

# create the package for Azure Machine Configuration

New-GuestConfigurationPackage -name "demoDSCLinux" -Type AuditAndSet -Configuration .\demoDSCLinux\demoDSCLinux.mof -Force $true

The first line of the script tests if the host is a Linux machine. The configuration can only be created on Linux.

Then the script imports all the necessary modules, nxtools for the DSC resources, PSDesiredStateConfiguration for DSC, and GuestConfiguration to package the configuration.

It then compiles the configuration and packages it. The package can then be deployed to a Linux VM with Azure Machine configuration.