DEV Community: MAURIZIO ARGONETO

CVE reachability with an LLM and a code graph

MAURIZIO ARGONETO — Fri, 30 Oct 2026 13:10:12 +0000

Asking a language model whether a CVE affects your code is easy. Deciding when not to believe the answer is the hard part.

On one real project we started with a hundred critical CVEs and went through them by hand. Seven or eight out of ten could not be reached from our code. That ratio comes from one codebase, so treat it as an anecdote. Anyone who runs a scanner knows the effect anyway: when everything is red, nobody opens the dashboard, and each CVE costs a developer an afternoon of reading advisories and grepping code.

vex-engine is the pipeline I built to give that afternoon back. It runs on GitLab CI, reads each CVE with an LLM on Amazon Bedrock, looks for it in the code with the graph that OWASP dep-scan builds, and commits a CycloneDX VEX verdict to the repository. Dependency-Track then shows only the CVEs that need a person.

There are two ways to get this wrong. A false positive costs a developer some time. A false negative hides a real vulnerability behind a confident not_affected, and preventing that is the reason for most of the design. So I follow one example through the pipeline, a Pillow CVE in an image decoder, and at every stage I ask the same question: could this stage hide a real vulnerability, and what stops it?

The code, the CI template and the lab app are on GitLab. Every snippet below comes from that repository.

The architecture in one paragraph

On every push, Trivy reads requirements.txt and writes a CycloneDX SBOM. Dependency-Track matches each component against NVD, GitHub and OSV and returns the CVEs. In parallel, OWASP dep-scan 6.3 reads the source and builds a code property graph with its atom engine. The analysis then takes one CVE at a time through three modules:

Strategist (LLM call): reads the advisory and writes a search plan.
Locator (no model): queries the graph.
Auditor (second LLM call): judges the evidence.

The verdict goes into vex.json. Exploitable CVEs open one GitLab issue per component, and people close issues with labels that flow back into the VEX.

Why a regex scanner was not enough

The first version also had three phases, but the middle one was a Scanner. The Strategist wrote search patterns, the Scanner ran them as regular expressions over the files that imported the library, and the Auditor received thirty lines above and below every match.

Noise went down. Then it met this:

config = yaml.safe_load(open("settings.yml"))   # safe
data   = yaml.load(request.body)                # vulnerable

A text search finds both lines. The Auditor gets two blocks of code with no idea where request.body comes from or who calls the surrounding function. It has to guess, and on a bad day it guesses not_affected.

I replaced the Scanner with a Locator that queries a code graph. The Scanner stayed in the codebase with two smaller jobs, covered below. The division of labour stayed the same, and the rest of the post builds on it: the LLM reads the CVE at the start and judges facts at the end. The graph does the looking.

Step 1: turn the CVE text into a search plan with Bedrock

A CVE is written for people. "Heap overflow in the TIFF decoder when processing crafted images" does not tell you which function in your code triggers it, and no database does either. NVD used to add structured data such as scores and affected configurations to every entry; in April NIST announced it would stop enriching every CVE. Reading an advisory and mapping it to code used to need someone with security experience, every time.

The Strategist does that reading. It receives the CVE description and the package name and returns a plan as strict JSON. For CVE-2017-18342 (PyYAML before 5.1, yaml.load() can execute arbitrary code on untrusted data) the plan looks like this, with illustrative values:

{
  "trigger_type": "api_call",
  "vulnerable_symbols": ["yaml.load", "yaml.load_all"],
  "conditions": "the argument comes from untrusted input and no SafeLoader is passed",
  "safe_alternatives": ["yaml.safe_load", "yaml.safe_load_all"],
  "import_aliases": ["yaml"],
  "attack_vector": "a YAML document with a python/object tag executes code when loaded"
}

Each field has a consumer downstream. The Locator uses vulnerable_symbols and import_aliases (Pillow is imported as PIL, PyYAML as yaml). The Auditor uses conditions, attack_vector and safe_alternatives.

This is the first place a real vulnerability can disappear. If the Strategist names the wrong function, the graph looks for the wrong thing. This part of the prompt guards against it:

- vulnerable_symbols: ALL the PUBLIC functions/classes an application may call that
  lead to the vulnerable code, fully qualified from the TOP-LEVEL import name.
  If the bug is inside an internal decoder or C module (e.g. TiffDecode.c), name
  the public entry points that reach it (e.g. "Image.open" for image decoders).
  If it is in a class used internally by convenience functions, list those too
  (e.g. a bug in requests.Session redirects: "requests.get", "requests.post", ...).
  Missing an entry point hides a real vulnerability, so when unsure list more, not fewer.

In the Pillow example the bug lives in a C decoder that no application calls directly. Applications call Image.open, which reaches the decoder when it opens a TIFF. The prompt asks the Strategist to make that jump, from where the bug is to where your code touches it.

The plan also says how the bug fires:

api_call: the application must call a specific function.
framework_implicit: the library acts on its own. A CVE in Django's multipart parser fires on every upload before your view runs, and your code never names the parser.
config: a setting turns the bug on.

The Strategist picks the type from the CVE text, and the type decides which question the Locator asks.

Nothing uses the answer before validation. The JSON must parse, the trigger type must be one of the three values, and symbol names are normalised. If Bedrock is unreachable, a keyword heuristic produces a fallback plan and the pipeline marks it as heuristic, because a guessed plan must never clear a CVE. Plans are cached per run, so each CVE/package pair goes to the model once.

A wrong symbol list is the cheapest way to hide a vulnerability. Ask for more entry points, never fewer, and record where each plan came from.

Step 2: match symbols against the dep-scan code graph

The Locator uses no model. It reads the graph that OWASP dep-scan builds with atom, which combines three views of the same code. The syntax tree knows that Image in your file is Pillow's module. The call graph knows who calls whom. The data flow knows where a value travels.

dep-scan exports the graph as two JSON slices. usages lists every call with its arguments and line. reachables lists flows that start from external input, such as an HTTP request. The CI job pins the image, because the slice format changes between atom versions, and writes a marker file only when the slices are complete:

vex_reachability:
  stage: analyze
  image:
    name: ghcr.io/owasp-dep-scan/dep-scan:v6.3.0
    entrypoint: [""]
  allow_failure: true
  script:
    - |
      if depscan -i "${VEX_APP_SRC}" -o "${CI_PROJECT_DIR}/depscan-out" -t python \
        --reachability-analyzer SemanticReachability \
        --explanation-mode EndpointsAndReachables \
        --vdb-scope app --no-banner \
        && [ -s depscan-out/python-usages.slices.json ]; then
        touch depscan-out/.complete
      fi

dep-scan exits 0 even when it produces no slices. Partial slices would report "library not used" for every file that failed to parse, and the analysis would close CVEs it never looked at. Without .complete, the Locator treats the graph as missing.

Matching is one small function. atom writes resolved calls such as PIL.py:<module>.Image.open. The Locator splits them into segments and compares from the end:

def symbol_matches(qualified: List[str], symbol: str) -> bool:
    sym = [s for s in _norm(symbol).replace("()", "").split(".") if s]
    if not sym or len(sym) > len(qualified):
        return False
    return qualified[-len(sym):] == sym

PIL.Image.open matches [pil, image, open]. yaml.load matches yaml.py:<module>.load and never safe_load, because the last segment differs. That fixes the case that sank the Scanner.

Pin the dep-scan image and check that the slices exist. A graph that failed silently looks exactly like a codebase that never uses the library.

Step 3: route each CVE by what the graph finds

The graph can give four answers, and each has a fixed next step.

1. The vulnerable function is called

For every call site the Locator collects the file and line, the origin of each argument, the external-input flows that cross the enclosing function, every path from an entry point to the call, and the source of each function on those paths. All of it goes to the Auditor. This is the Pillow case: Image.open is called at line 17 of upload_avatar.

2. The library is used, but not through the vulnerable function

This looks like good news, and it is the outcome most likely to hide a real problem, because the Strategist can still miss an entry point. Take a CVE in the redirect handling of requests.Session. The Strategist names requests.Session. The application only does this:

r = requests.get(user_supplied_url)

requests.get builds a Session internally, so the vulnerable code runs. Stopping at "not called" would be wrong. Before trusting it, the Locator runs three checks, one for each way "not called" could be false:

Check	Fails when	Why it matters
The symbols came from the LLM	Bedrock was down and the keyword heuristic produced them	a guessed list proves nothing
They are real, callable APIs	the plan names `TiffDecode.c`, a private `_imaging` module or a decoder plugin	no application calls a C file, so "not called" is trivially true
A text search agrees	grep finds `ImageMath.eval(` where the graph saw nothing	the graph has a hole: an unparsed file, an alias, a `getattr`

Any failure sends the CVE to in_triage. If all three pass, the Auditor receives every use of the library and one question: does any of these calls reach the vulnerable code internally?

3. The bug fires without a call

For framework_implicit and config there is no symbol to look for. If the library is imported, the Locator collects every place the application uses it and the Auditor decides whether the vulnerable feature is in use. On the lab app it sees upload_avatar reading request.FILES, so multipart uploads are in use.

If the library is not imported anywhere, the CVE goes straight to in_triage. A server, a plugin or a string in the settings can load a package without any import in your code.

4. The graph is missing

If dep-scan failed or the language is not Python, the old Scanner runs. If it finds uses, the Auditor judges. If it finds nothing, the CVE goes to in_triage, because without the graph "not found in the text" proves nothing.

The relationship between the graph and the regex comes down to one rule:

If the graph says "called", believe it. If it says "not called" or "not imported", the text has to agree. When they disagree, doubt wins.

Step 4: when the library is never imported, rebuild the tree from PyPI

For an api_call CVE, "never imported" sounds conclusive. It isn't, because the graph only sees your code. If Django uses sqlparse internally, a sqlparse CVE can be reached through Django, and the graph never looks inside Django.

An SBOM generated from requirements.txt has no dependency tree. The Locator rebuilds one from the requires_dist metadata on PyPI, breadth-first from the SBOM's components. On the lab app that is 34 packages in about two seconds.

PyPI cannot tell you whether Django calls the vulnerable function in sqlparse. It only tells you that Django declares a dependency on it. That is enough to know when a CVE must stay open:

Library	PyPI tree	Verdict
jinja2	direct, nothing else requires it	`not_affected` if no text search finds an import
sqlparse	required by Django	`in_triage`
private package	PyPI returns 404	`in_triage`

The jinja2 row is the only case the Locator closes on its own, without calling the LLM. Before it does, a regex looks for any import of the package, including dynamic ones through importlib or __import__.

Optional extras count as dependents, but the walk does not traverse them. Following every extra makes every library transitive (Pillow → docs extra → sphinx → jinja2) and nothing could ever be closed. The known trade-off: a package reached only through another package's extra, such as requests[security] → pyOpenSSL → cryptography, can look direct.

The graph sees your code. PyPI sees what your dependencies declare. Neither one is allowed to clear a CVE on a guess.

Step 5: let the Auditor judge evidence

The Auditor receives the Strategist's plan, the CVE description and a block of evidence built from the slices. The prompt tells it what kind of material it is reading:

EVIDENCE FROM THE CODE GRAPH (OWASP dep-scan). For every call site of the
vulnerable API you get: the arguments' origin, the external-input flows that
cross the enclosing function, every call path from an entrypoint, and the code
of every function on those paths. These are facts from data-flow analysis, not
guesses: the vulnerable API IS called at these lines.

For each call site decide:
1. Can attacker-controlled data (HTTP request, uploaded file, message, CLI arg)
   reach the call through one of the paths? Follow the arguments' origin.
2. Are the trigger conditions met (arguments, options, file format, settings)?
3. Is there validation or a safe alternative that blocks the attack?
The CVE is "affected" if at least one call site is exploitable.

A rule engine can't answer these questions. Is there validation before the call? Is the argument a constant or an upload? Does the file format match the CVE? Is yaml.load called with a SafeLoader? A person answers in seconds when looking at the right snippet. The graph's job is to put that snippet, and the path that leads to it, in front of the model.

The evidence is capped so prompts stay small: at most 8 call sites per CVE, 5 paths per call site, call depth 8, and 80 lines per function. That is enough to follow a request from a Django view to a library call in a typical web app.

The Auditor answers with strict JSON: a verdict that is exactly affected or not_affected, a confidence between 0 and 1, a reasoning that cites the path, and the call sites it considers exploitable.

The graph decides what the model sees. The model decides what it means.

What the Auditor cannot verify

In case 2 above (library used, vulnerable function not called) the Auditor is asked whether requests.get reaches Session internally. Nothing in the evidence answers that. The engine passes no library source, no documentation and no web search, so the model answers from training data.

For widely used libraries such as requests, Pillow, PyYAML and Django, that is usually right: the mapping between public functions and internal classes is stable and well documented. For a niche package, or a release newer than the model's training cutoff, it can be wrong. A smaller model knows less than a larger one.

Two things contain this. The confidence threshold sends an unsure answer to in_triage, which is what usually happens with a library the model barely knows. And every reasoning is written into the VEX and committed, where a reviewer can read and challenge it. A model that is confidently wrong passes the threshold; only the review catches it.

The next step is to replace memory with facts: have atom also build a graph of the installed library and show the Auditor the real path from requests.get to Session. vex-engine does not do this yet.

Step 6: fail closed

The final rule does not depend on the model:

# Fail-closed: None (doubt, error, low confidence) -> in_triage, stays visible
if is_reachable is None:
    state = "in_triage"
else:
    state = "exploitable" if is_reachable else "not_affected"

A verdict with confidence of 0.8 or more (VEX_MIN_CONFIDENCE) becomes exploitable or not_affected. Everything else becomes in_triage and stays on the dashboard for a person: a malformed answer, a lower confidence, a timeout, a missing package URL from Dependency-Track.

One failure mode only shows up over time. An LLM is not deterministic, and on an ambiguous CVE it can flip between not_affected and exploitable on every run, closing and reopening the same issue. The bot counts its own flips. After two (VEX_MAX_AUTO_FLIPS) it stops touching the issue, leaves it open and labels it vex::needs-human. A human decision resets the counter.

This rule is what makes a smaller model safe to use. I ran the whole pipeline with a 12B open model through Ollama on a laptop. It produced more in_triage verdicts than the Bedrock model and no hidden errors.

Worst case, vex-engine leaves you with the dashboard you already had.

One CVE, end to end

Back to the Pillow decoder CVE on the lab app (old Pillow, PyYAML and Django, with insecure code written on purpose).

The Strategist returns trigger_type: api_call with PIL.Image.open among the symbols, because that is the public function that reaches the decoder. The plan came from the model, and the symbol is a real API.

The Locator finds Image.open in the graph and builds the evidence. Simplified:

Call site 1: Image.open @ vuln_demo.py:17 (in upload_avatar)
Vulnerable symbol: PIL.Image.open
Arguments: img_file <- request.FILES['avatar']
Call paths (entrypoint -> call):
  <module> --(line 56)--> upload_avatar --(line 17)--> Image.open
Code of the functions involved:
  def upload_avatar(request):
      ...
      img_file = request.FILES['avatar']
      with Image.open(img_file) as img:

The Auditor does not have to find the call or trace the data. It only decides whether an attacker controls that file: it is a user upload, and nothing validates it before the decoder runs. Verdict affected, confidence above the threshold, call site vuln_demo.py:17.

The result is a VEX entry marked exploitable and a GitLab issue for the Pillow component with the file, the line, the origin of the argument and the path from the entry point. The developer who opens it can go straight to the fix.

A full run on the lab app looks like this. The app is vulnerable by design, so the exploitable share is far higher than in a real codebase:

Of 80 CVEs, 40 are closed with a written reason, 6 stay visible for a person, and 34 exploitable ones are grouped into two issues, one for Pillow and one for Django.

Write verdicts to vex.json and let people close the loop

Every verdict is written to vex.json in the application's repository, using standard CycloneDX fields, and committed with [skip ci] only when something changed:

{
  "id": "CVE-XXXX-YYYY",
  "analysis": {
    "state": "not_affected",
    "justification": "code_not_reachable",
    "response": ["will_not_fix"],
    "detail": "Vulnerability CVE-XXXX-YYYY analyzed by LLM Analyzer (python) on 2026-10-20. <Auditor reasoning>"
  }
}

A Dependency-Track trap

In the uploaded VEX, affects[].ref must stay the Dependency-Track project UUID (the BOM's metadata.component.bom-ref). If you rewrite it with the component's purl, Dependency-Track returns HTTP 200 and silently discards the verdict. The only trace is Unable to locate affected element in its logs. vex-engine keeps the purl in a separate property, vex:component-purl.

Closing labels

Issues open only for exploitable CVEs, one per component. People close them with a label that says why, and the pipeline turns the label into a VEX decision:

Label	VEX written	Expiry	What the bot does
`vex::fixed`	nothing forced, it's a claim	none	next analysis checks the graph; still reachable → issue reopens
`vex::false-positive`	`false_positive`	90 days	skipped until expiry, then back to `in_triage`
`vex::mitigated`	`not_affected` + `protected_by_mitigating_control`	90 days	same
`vex::risk-accepted`	`exploitable` + `will_not_fix`	90 days	stays visibly exploitable

If VEX_APPROVERS is set and someone else closes the issue, the bot reopens it. Two vex:: labels at once count as a conflict. A person reopening an issue revokes the decision. When a library is upgraded and its CVEs leave the SBOM, the issue closes by itself.

A decision that never expires becomes a blind spot. Ninety days is a setting. The expiry itself is the point.

Keep the analysis current with three triggers

A pipeline that runs only on push misses new CVEs on code nobody touches, and misses the decisions people make on issues. vex-engine runs on three triggers:

Push or manual run. The full chain, from SBOM to verdict. On push only CRITICAL and HIGH CVEs go to the model (VEX_MODE=critical).
Issue webhook. Closing or reopening a security issue, or adding a vex:: label to a closed one, runs vex_issue_sync --issues-only: no scan, no LLM, Dependency-Track updated in about a minute.
Schedules. A nightly run syncs issues and expires decisions with no LLM. A weekly full analysis (VEX_MODE=full) catches new CVEs on unchanged code.

Two jobs write vex.json, so they share a GitLab resource group and run one at a time. Set its process mode to oldest_first to keep them in order. A project enables everything by including one template:

include:
  - project: 'demo-security/vex-engine'
    file: 'ci-template.yml'
    ref: main

stages: [scan, upload-bom, analyze, sync-vex]

What it costs on Amazon Bedrock

The LLM is called in two places, the Strategist and the Auditor, and only during an analysis. The SBOM, Dependency-Track, the graph, the webhook and the nightly sync make no model calls. The Strategist runs once per CVE in scope; the Auditor runs only for CVEs the graph does not settle on its own.

The default model is Amazon Nova 2 Lite. The task is narrow and structured (read text, return JSON), so a small model is enough. Switching model is one variable, and the same prompts run locally through Ollama, in which case no code leaves the machine:

LLM_PROVIDER=bedrock                         # or: ollama
BEDROCK_MODEL_ID=eu.amazon.nova-2-lite-v1:0  # default
OLLAMA_MODEL=gemma4:12b                      # local option
VEX_MIN_CONFIDENCE=0.8

A run costs cents on Bedrock and nothing locally. The real infrastructure cost is the graph: atom runs on the JVM and the dep-scan image is about 3.8 GB, so cache it on your runners.

What the analysis can't see

Each of these ends in in_triage, never in not_affected:

Malware without a CVE. Out of scope.
Bugs deep inside a C extension. The graph only sees the Python that calls into it.
Argument-level data flow. Python data flow is tracked at function level: the graph knows that external input crosses a function, not which argument carries it. That's why the final judgement stays with the Auditor.
Private packages. PyPI doesn't know them, so they can't be placed in the dependency tree.

Checklist

Component	Configuration	What it guarantees
Strategist prompt	all public entry points, more when unsure	the graph looks for every way in
Fallback plans	marked as heuristic	a guessed plan never clears a CVE
dep-scan job	pinned image, `.complete` marker	a failed graph is treated as missing
Symbol matching	segment suffix match	`yaml.load` never matches `safe_load`
"Not called" checks	LLM origin, real API, regex agreement	a hole in the graph ends in triage
PyPI tree	direct leaf only, extras not traversed	transitive libraries stay visible
Auditor evidence	8 sites, 5 paths, depth 8, 80 lines	small prompts with the right snippet
Verdict rule	`VEX_MIN_CONFIDENCE=0.8`, fail closed	doubt never hides a CVE
Anti-oscillation	`VEX_MAX_AUTO_FLIPS=2`, `vex::needs-human`	an unstable verdict goes to a person
VEX upload	keep `affects[].ref` as the project UUID	Dependency-Track keeps the verdicts
Labels	approvers, 90-day expiry	decisions are attributed and revisited
Writers	shared resource group	concurrent jobs don't drop decisions

Try it

Everything here ran with OWASP dep-scan 6.3.0, Dependency-Track 4.13 and Amazon Nova 2 Lite on Bedrock, on Python projects. The slice format changes between atom versions, so expect the matching code to move.

To run it on your own project: clone vex-engine, point VEX_APP_SRC at your source, add the include: block above to your .gitlab-ci.yml, and start with LLM_PROVIDER=ollama if you'd rather keep code on your machine for the first run. The lab app in the repo is the fastest way to see all four routing cases.

The rule that killed "Just Start Coding" at our Hackathon

MAURIZIO ARGONETO — Fri, 18 Sep 2026 10:00:53 +0000

GDG Basilicata and the IEEE Student Branch at the University of Basilicata, together with the university's Department of Sciences, booked a room built for fifty to eighty students, split them into teams of three or four, and gave them eight hours to build something with Google's Gemini models. Nobody installed a GPU driver. Nobody touched a local model weight. Every team redeemed a free API key from Google AI Studio and worked entirely in the browser.

That's the first pillar of the format we built, and it's the boring one: cloud-first, zero local setup. It matters because the fastest way to kill momentum in a student hackathon is a broken CUDA install at hour two. Remove the infrastructure problem and you get eight real hours of thinking and building instead of six hours of pip errors.

The interesting part is what we did with the time that freed up.

Writing code fast isn't the hard part anymore

Any team in that room could ask an agentic coding tool for a working prototype in twenty minutes. That capability is common now, which is exactly why we didn't grade on it. Our scoring grid put 35 of 100 points on a file most hackathons never ask for: SPEC.md.

Before touching an IDE, each team spent an hour and a half writing down what they were building, for whom, and how they'd know it worked — functional requirements, architecture, expected output, non-functional constraints. A mentor had to sign off before the team could move to code. We called this phase Spec-Driven Development, and it changed the room's energy. Teams argued about scope before they argued about syntax. Some rewrote their spec twice before a mentor approved it.

Only after that did agentic coding tools come into play — Google Antigravity, Cursor, VS Code with Gemini Code Assist. The agent reads SPEC.md, scaffolds the app, and helps wire up the Gemini API calls. The team's job shifts from typing code to checking what the agent produced against the spec they wrote an hour earlier. That's a different skill than typing fast, and it's the one we wanted to measure.

The pitch is engineered too

In the last hour before submission lock, teams didn't write slides from a blank deck. They uploaded SPEC.md, their code, and their documentation into NotebookLM and used it to generate a three-minute pitch script, an FAQ for the Q&A round, and, for teams who wanted it, an audio overview they could play as part of the demo. Thirty of the hundred points went here: how clearly a team could explain what they built and defend it in two minutes of jury questions.

Four tracks were open on the day: study tools for university life, services for local government and territory, autonomous agents, and multimodal apps mixing text, image, audio or code. Output had to land as a web app, a dashboard, or an AI agent, nothing more exotic than that, on purpose — a constraint that stops a team from disappearing into scope an eight-hour sprint can't survive.

The schedule, hour by hour

Time	Phase
07:30–08:30	Room setup, projector and Wi-Fi checks
08:30–09:15	Check-in and team matchmaking
09:15–09:45	Keynote: stack, tracks, rubric
09:45–11:00	Spec Definition — SPEC.md, mentor sign-off
11:00–11:15	Coffee break
11:15–13:00	Agentic Coding Sprint
13:00–14:00	Lunch
14:00–16:00	Integration & polish, Gemini API wiring
16:00–17:00	Pitch prep with NotebookLM, submission upload
17:00	Submission lock
17:00–17:30	Jury's technical filter, pitch order set
17:30–18:45	Live pitch showcase: 3-minute pitch, 2-minute Q&A per team
18:45–19:15	Jury deliberation
19:15–19:45	Awards
19:45–20:30	Teardown

The deadline is not a suggestion. At minus sixty, minus thirty and minus ten minutes, someone walks the room and calls it out loud. Write access to the submission folder closes automatically at 17:00, no five-minute grace period — the first team you grant one to will tell the next twenty it's negotiable.

Five roles, none of them optional

Running this for a room that size, with a jury on top, needs more than a tech lead. We split it five ways.

Role	Owns
Event Lead	Overall coordination, university relations, MC on the day
Logistics & Venue Lead	Room booking, Wi-Fi, power strips, catering
Tech & Mentor Lead	API keys, Google AI Studio support, Spec-Driven Dev guidance
Marketing & Community Lead	Graphics, social channels, photo and video
Platform & Judging Lead	Submission platform, CSV exports, the judges' scoring sheet

Mentors and judges are different people doing different jobs. Mentors unblock teams on specs, API access, or NotebookLM extraction; they don't score anything. Judges score the spec, the working demo, and the pitch, and nothing else.

What actually broke

University Wi-Fi struggled under dozens of simultaneous connections, so we asked IT for a dedicated SSID ahead of time and kept a couple of 4G hotspots on hand as backup. A handful of students got stuck redeeming their AI Studio API key; mentors carried spare keys to unblock them on the spot instead of debugging Google's account flow live in front of a team on the clock. Teams with no prior exposure to writing specs stalled in the first phase, which is why the quickstart doc ships a pre-filled template instead of a blank file:

# SPEC.md

## Obiettivo
<One sentence: what problem does this solve, for whom>

## Requisiti Funzionali
- ...

## Requisiti Non Funzionali
- ...

## Output Atteso
<Web app / Dashboard / Agent — what does "done" look like>

Handing teams a template doesn't lower the bar — a mentor still has to approve it — it just gets them past the blank-page freeze in the first ten minutes.

Why another chapter could run this tomorrow

None of this needs a compute budget. The API key is free, the IDEs are free or already on student laptops, and NotebookLM runs in a browser tab. What it needs is a room, five people willing to own the roles above, three or four mentors, and a rubric that rewards a good spec and a good pitch as much as a working demo. The competition template we cloned on Kaggle — visibility set to Restricted, rubric swapped in, CSV export at lock time — is reusable as-is by any group running a Google-model hackathon.

The retrospective after this run flagged the usual fixes for next time: earlier mentor briefings, a longer matchmaking window, clearer wording on what counts as "multimodal." None of that touches the four pillars. Cloud-first, spec before code, an agent that reads the spec instead of guessing, and a pitch built from artifacts the team already produced — that combination is what let a computer science student and a humanities student sit at the same table and ship the same prototype.

Building a smart greenhouse in the woods: the architectural experiment of DevFest Basilicata - DevF{or}est

MAURIZIO ARGONETO — Wed, 12 Aug 2026 15:38:40 +0000

_By Maurizio Argoneto and Francesco di Donato @francesco_didonato_d1f65 _

How do you organize a tech conference that isn't just the usual sequence of slides in a dark hotel room? GDG Basilicata answered that question by bringing 66 developers to La Majonica, a forest in the municipality of Tito (PZ, Italy), for the third edition of DevFest — rebranded for the day as "DevForest".

But the real innovation wasn't just the location. The event broke the classic format by introducing a single, fascinating constraint: technical interdependence. Instead of isolated workshops, the entire day had one global goal — build a working smart greenhouse, live, piece by piece, across different teams.

Here's how we merged Botany, IoT, 3D Printing, Cloud computing, and Generative AI into a single, functioning pipeline.

🤝 Talks as "integration contracts"

The morning was dedicated to five 30-minute talks. These weren't just theoretical presentations — they were actual technical contracts: each speaker handed over the exact specifications (JSON formats, endpoints, physical tolerances) that their group had to respect during the afternoon Build Sprint, so the whole system could talk to itself.

The 5 pillars of our ecosystem:

Botany (Francesco Albanese) — Biology before code. He defined the plant's vital thresholds (soil moisture, air temperature), which became the conditional logic of our software, and made the case for why IoT actually matters for energy and water conservation.
Electronics / IoT (Soumaya Erradi) — The "nervous system". Using an ESP32 microcontroller, a DHT11 sensor, and a capacitive soil sensor, the team wrote the C++ firmware to read environmental data and drive a water pump relay.
3D Fabrication (Luigi Tuccillo) — The "armor". Bare hardware doesn't survive in a greenhouse. Using Tinkercad and AI-assisted modeling, the team designed and printed a PETG case (heat- and moisture-resistant) with tolerances tight enough to properly house the ESP32.
Cloud & Data (Gregorio Palamà) — The "brain". A serverless Cloud Function on Firebase evaluated incoming data and made irrigation decisions by querying Gemini.
App & Generative AI (Mike Trizio) — The "voice". A dashboard built in Angular to show real-time data and let users ask, by voice, "How is the plant doing?" — and get an empathetic answer read back via text-to-speech.

🏗️ The real architecture (spoiler: not everything went 100% smoothly)

For the Dev.to crowd, here's the juicy part. IoT always looks easy in online tutorials — things change when you're in a forest with limited connectivity.

We ruled out a push model from the Cloud to the ESP32: the device wasn't exposed to the internet, and there was no way to configure NAT/firewall rules out in the woods. So the architecture we actually shipped in the afternoon was built around polling.

The final stack:

ESP32 → Spring Boot API Gateway (Cloud Run) → External Firestore → Angular App

The system handled 4 parallel flows:

Telemetry — The ESP32 sent POST requests to the Java gateway, which performed an upsert of the telemetry data (humidity, temperature) into Firestore.
Manual command — The user clicked a button on the Angular app, sending a command to the Gateway.
Chat with Gemini — The Angular app built a dynamic prompt by injecting live sensor data and sent it to Gemini to generate a conversational response about the plant's health.
Scheduled automation — A Firebase Node.js (TypeScript) Function ran every hour. It applied a pre-filter (e.g. soil moisture < 40%), passed 48 hours of historical data to Gemini in a batch, and forced the output to match a structured Zod schema (shouldWater, durationSeconds, reason). If the answer was positive, it queued the command on the Gateway.

The polling trick and the in-memory queue

To get the irrigation command to the physical pump, the ESP32 sent a GET /adjustments request to the Spring Boot Gateway at regular intervals. The Gateway kept an in-memory command queue (a ConcurrentHashMap of ConcurrentLinkedQueue). Once read, the command was removed — exactly-once delivery — and executed by the pump.

🔍 Retrospective: what worked and what "exploded"

The best part of building things live is the evening retrospective — held, literally, around a campfire.

The big wins:

Separation of concerns. Because the JSON contracts were nailed down in the morning, teams could work in parallel. If the Cloud team got stuck, the IoT team just kept testing against mocked data.
The dual use of Gemini. Using AI for two completely different jobs — a creative, natural-language response on the frontend, and an algorithmic decision constrained by a Zod schema on the backend — turned out to be a winning combination.

Technical debt (don't repeat this in prod):

The in-memory queue. A RAM HashMap for the command queue is perfect for a hackathon and disastrous for scalability. If the Cloud Run instance restarted (or scaled out), commands were simply lost. For v2, the plan is to move the queue to a Firestore collection (pendingCommands) or to Cloud Tasks / Pub/Sub.
Polling latency. Being a pull system, there was a noticeable delay between the AI's decision and the actual pump activation, dictated by the ESP32's polling cycle.
Tricky IAM permissions. Firestore lived in a different Google Cloud project than Cloud Run. Without explicitly granting the roles/datastore.user role to the service account, the system failed silently with PERMISSION_DENIED errors.

📹 Event coverage & video references

The DevForest experiment caught the attention of both local media and the tech community. Worth a look if you want to see the greenhouse — and the woods — in action: Web site

🎯 Conclusion

As Maurizio Argoneto put it:

"The day was focused on nature and technology — we had the opportunity to experience, through talks and labs, what it means not just to design, but to practically build something real. We did this with 3D-printed elements, sensors capable of reading a plant's vital state, all the way to transforming this data in the cloud and designing an app for monitoring and interaction."

The success of DevFest Basilicata didn't hinge on which libraries were used — it hinged on forcing different teams to depend on each other in an environment with real physical and network constraints. It was the physical embodiment of what it actually means to build and maintain distributed software.

If you want to replicate the project, the entire Spring Boot gateway code is open source, and you can test it with the Firebase CLI and a simple ESP32.

See you at the next DevFest! (Hopefully with a persistent message queue 🚀)

From Code Smells to Strategy Spells - Directing AI with Human Judgment

MAURIZIO ARGONETO — Mon, 13 Apr 2026 14:49:30 +0000

In 2026, the question is no longer whether AI can code. It already does. Your new "Junior AI" coworker is tireless, never complains about long meetings, and can write 5,000 lines of code in a second. It has read every architecture book and knows every design pattern by heart, from Strategy to Repository.

But there is a trap. AI knows how to apply a pattern, but it doesn't know when — and more importantly, when not — to apply it. Without human judgment, AI suffers from "algorithmic over-zealousness." It will build a rocket just to go to the supermarket, leaving you with a 300-line "elegant" disaster for a problem that only needed 50 lines of simple code.

AI knows how to apply a pattern, but it doesn't know when — or when not — to apply it.

The $440 Million Warning: Knight Capital

Technical debt is often dismissed as an aesthetic problem, but history tells a different story. On August 1, 2012, Knight Capital lost $440 million in just 45 minutes.

The cause? A combination of "dead code" left festering in production for eight years and the reuse of a simple variable flag. A cosmetic-level mistake triggered an architectural monster. The lesson is clear: technical debt is a fatal business risk, and AI, in its rush to "clean up," can easily trigger these dormant disasters if it lacks context.

A Compass for Technical Debt: The 3-Level Framework

To direct AI effectively, we must first categorize the "smell." This is a practical 3-level diagnostic framework:

Fig. 1 — The 3-Level Code Smell Framework with Impact Scores

Level 1: Cosmetic

Magic numbers and unclear names (e.g., msg[:160]). These require simple renames or constants. Patterns are never needed here.

Level 2: Structural

Duplicated logic or 200-line methods. We fix these by extracting private methods. We only introduce patterns if the logic is guaranteed to grow.

Level 3: Architectural

The "God Class" that does everything. This is where "Strategy Spells" (design patterns) are justified — but only if the business context allows for the added complexity.

The Solution: "Ask First, Code Later"

The secret to clean code in 2026 isn't a better prompt; it's a better workflow. The methodology uses three composable workflows to inject human judgment into the machine:

Fig. 2 — Human-Guided Agentic Refactoring Workflow (Cursor · Windsurf · GitHub Copilot · Antigravity · any agentic IDE)

1. The Interview (`/refactor-interview`)

Before touching a single line of code, the AI must ask 6 strategic questions. How big is the team? Is the logic stable? If you are a team of three and the logic won't change, the AI is explicitly forbidden from using complex patterns like Strategy or ABC interfaces. We turn advice into hard constraints.

About the team: How many people work on this file? Is it in production?
About logic stability: Will the conditions or cases change? Is this logic duplicated elsewhere?
About technical requirements: Does this need unit testing in isolation? Any non-functional constraints?

2. The Strategic Scan (`/refactor-analyze`)

Once context is set, the AI scans the file. It doesn't just list duplications; it assigns Impact Scores (1–3) and maps smell dependencies. It identifies the "root cause" so we don't fix symptoms while leaving the real disaster behind.

Smell	Level	Impact	Notes
Magic number `160`	L1	1	Replace with `SMS_CHAR_LIMIT`
Unclear parameter `u`	L1	1	Rename to `user`
Structural duplication	L2	2	Branches repeat the same pattern
God Class	L3	3	Does 5 different things

3. Constrained Execution (`/refactor-execute`)

The final step is "Controlled Execution." The AI proposes a 3–5 step plan with risk estimates. It shows step-by-step diffs and waits for human approval and "green tests" before proceeding. This eliminates the "Black Box" and ensures the AI remains a partner, not a rogue agent.

Every pattern introduced requires a comment in the code:
# Pattern: [name] — justification: [specific reason from the interview]

Conclusion: You Are the Pilot

When we compared a "Naive AI" (no context) with an "Interviewed AI" (with context) on the same messy file, the result was undeniable:

Fig. 3 — Naive AI vs Interviewed AI: same file, same tests, very different outcomes

300 lines of over-engineered complexity vs. 180 lines of clean, maintainable code. Both passed the tests, but only one is sustainable for a human team.

In the age of AI, your value as a Senior Developer has shifted. It is no longer about the speed of your typing, but the quality of your judgment. AI is the engine, but you are the Pilot.

Remember: Ask first, code later.

Maurizio Argoneto is CTO at Publisys Spa and AWS Community Hero