DEV Community: MAURIZIO ARGONETO

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