Un material de opinie de Mihai Chihaia, Chief Revenue Officer al dvloper.io

Inteligența artificială schimbă rapid modul în care este construit software-ul. Acum, modelele generative pot scrie cod, pot genera teste, pot documenta aplicații și pot automatiza o parte tot mai mare din activitățile care, până nu demult, necesitau intervenția directă a unui dezvoltator. Dar dacă AI poate genera cod tot mai bine și tot mai repede, care mai este rolul celui care scrie cod?

Ei bine, în aceste împrejurări cu totul excepționale prin natura și importanța lor, expertiza tehnică nu numai că nu își pierde din importanță, ci chiar dimpotrivă. Pe măsură ce volumul de cod pe care îl putem genera crește, devine mai important să existe oameni capabili să înțeleagă ce trebuie construit, de ce trebuie construit într-un anumit fel și dacă ceea ce a produs AI-ul este, într-adevăr, corect.

„Problema nu este că AI-ul poate scrie cod. Problema este că acum putem genera foarte mult cod, foarte repede. Dacă acest proces nu este controlat de oameni care înțeleg arhitectura, securitatea, performanța și implicațiile pe termen lung ale deciziilor tehnice, putem acumula technical debt într-un ritm mult mai mare decât înainte.”

Aceasta este una dintre marile schimbări aduse de AI în dezvoltarea software. Instrumentele devin mai rapide, dar viteza nu este neapărat și nu întotdeauna sinonimă cu valoarea. Un sistem poate fi construit mai repede și, în același timp, poate fi mai greu de întreținut, mai vulnerabil sau mai costisitor pe termen lung. De aceea, competențele care vor conta tot mai mult sunt cele care permit dezvoltatorului să vadă problema de la un capăt la altul. Înțelegerea cerințelor de business, capacitatea de a pune sub semnul întrebării o cerință atunci când este necesar, alegerea arhitecturii, evaluarea riscurilor de securitate și performanță și validarea rezultatelor generate de AI devin cel puțin la fel de importante ca scrierea efectivă a codului.

Astfel, pe măsură ce codul devine mai ușor de generat, valoarea developerului se mută de la capacitatea de a scrie cod la capacitatea de a decide ce cod merită scris, cum trebuie construit și dacă rezultatul este cel corect. Această transformare nu se limitează însă la departamentele tehnice. 

În organizații, tentația de a privi AI-ul drept un substitut direct pentru oameni este tot mai mare. 

Unele companii au încercat să reducă rapid numărul de angajați, presupunând că agenții AI vor putea prelua activitățile acestora. În practică, însă, limitele acestei abordări devin evidente. AI-ul este un instrument foarte puternic, dar valoarea lui depinde de modul în care este integrat în organizație. AI-ul are nevoie de context. Pentru a putea funcționa eficient într-o companie, trebuie să înțeleagă procesele, datele, relațiile dintre acestea, regulile de business și limitele în care poate lua sau recomanda decizii. 

„De aceea, cred că adevărata transformare nu este «om versus AI», ci redesenarea modului în care se desfășoară munca. Unele activități vor fi automatizate, altele vor fi augmentate de AI, iar rolurile oamenilor vor evolua către zone în care judecata, contextul, responsabilitatea și creativitatea rămân esențiale. Nu cred că principala întrebare ar trebui să fie câți oameni poate înlocui AI-ul, ci ce putem construi diferit dacă oamenii și sistemele AI lucrează împreună.”

În acest nou context, se schimbă și piața serviciilor de dezvoltare software. Modelul tradițional, bazat în mare parte pe numărul de oameni și de zile necesare pentru realizarea unui proiect, este pus sub presiune de productivitatea oferită de AI. Vedem deja și vom vedea tot mai des tot mai multe echipe hibride, în care oamenii lucrează împreună cu agenți AI pe întregul ciclu de dezvoltare, de la programare și testare până la documentație și code review. Un Technical Lead cu competențe solide în AI poate coordona nu doar o echipă de dezvoltatori, ci și mai mulți agenți specializați.

În aceste condiții, numărul de man-days nu mai reflectă în mod necesar capacitatea reală de producție. Dacă o activitate care necesita anterior mai multe zile sau mai mulți oameni poate fi realizată într-un timp mult mai scurt cu ajutorul AI, valoarea serviciului nu mai poate fi definită exclusiv prin timpul consumat.

Este de așteptat, astfel, o tranziție de la modele bazate pe capacitate către servicii evaluate în funcție de rezultat și valoare. Clienții vor fi mai puțin interesați de dimensiunea echipei și mai interesați de ceea ce poate livra furnizorul, în cât timp, la ce nivel de calitate și cu ce responsabilitate asupra rezultatului.

Același principiu este valabil și la nivel de management. În piață apar deja soluții prezentate drept „AI CTO”, „AI CFO” sau chiar „AI CEO”. AI poate analiza cantități foarte mari de informații, poate identifica rapid corelații, poate construi scenarii și poate sintetiza date într-un timp foarte scurt. Pentru un executiv, aceste capacități pot schimba radical modul în care este luată o decizie.

Dar leadershipul nu înseamnă doar procesarea informației. Înseamnă asumarea responsabilității, înțelegerea contextului, gestionarea oamenilor, negocierea unor interese contradictorii și luarea unor decizii atunci când datele sunt incomplete. AI poate susține aceste procese, însă responsabilitatea pentru decizie nu dispare. 

Această nevoie de transformare stă și la baza AI Factory, framework dezvoltat de dvloper.io prin care urmărește să standardizeze componentele și procesele care se repetă în proiectele de implementare AI, de la accesul la date și modele și integrarea cu sistemele existente până la orchestrarea agenților, identity & access management, securitate, observabilitate și evaluarea rezultatelor. Obiectivul este ca organizațiile să poată trece de la experimente și proof-of-concept-uri la soluții AI care pot funcționa efectiv în producție, fără ca fiecare proiect să fie construit de la zero.

SharePoint is often seen as a place to store documents, publish announcements, and share information.

For this project, we wanted to take it further. The goal was to create a central platform for internal ISO compliance information and the processes that sit around it. Employees needed a clear place to find published policies, acknowledge the ones assigned to them, access training material, and follow their own deadlines. Administrators and process owners needed dedicated areas for managing policies, controls, evidence, risks, training, and reporting. Rather than treating those activities as separate tools, we brought them together within Microsoft 365. The result was a SharePoint website designed to make structured compliance work feel more connected, easier to follow, and easier to maintain over time.

SharePoint as the Foundation

Modern SharePoint pages provided the foundation, but the core of the experience came from custom SharePoint Framework web parts built with React. This allowed us to create focused interfaces around the work people actually needed to do, instead of sending them directly into raw Lists.

The portal includes dedicated experiences for policy management, controls, evidence, risks, training, dashboards, tools, and the homepage. A policy owner can create or update a policy, submit it for review, and follow it through approval and publishing. A reviewer can open a control or evidence item, add review notes, and update its status. A user can see assigned policies and training, confirm acknowledgment, and update training progress.

Behind these pages, SharePoint Lists provide the structured data layer. They store the records and relationships that make the portal work: policies, controls, risks, evidence metadata, training courses, assignments, events, categories, frameworks, and other reusable reference data. This keeps information consistent across the different web parts. A risk can be connected to relevant controls, evidence can be connected to a control and related policies, and training can be assigned to people or groups.

Document libraries complete the picture. Evidence files and training materials are stored in SharePoint, while the portal provides the task-focused interface around them. Native SharePoint version history also supports the policy lifecycle, allowing new versions to be created while retaining the history of the previous record.

This combination gave us the flexibility of SharePoint as a Microsoft 365 platform, while still allowing the website to feel tailored to the process rather than to the underlying data structure.

Creating Clear Handoffs for Power Automate

Not every part of a process needs to happen in a flow. We kept immediate actions inside the web parts wherever possible: creating records, changing statuses, acknowledging policies, uploading evidence, assigning training, and updating progress.        

For work that can take longer or needs to continue in the background, the portal creates a dedicated SharePoint request record or updates a flag that an automation can process. This creates a clear handoff between the website and Power Automate.

One example is the audit evidence package request. A user can create the request from the evidence area, choose the relevant audit period and framework, and then see the request status in the portal. Power Automate can process that request in the background, assemble the required information, update the same request record, and add a package location when the result is ready. The website can then expose the completed package from the request history.

The same pattern is used for policy upload requests. The web part extracts the information from an uploaded policy document and creates a structured request record for the next stage of processing. This keeps the browser experience responsive while preserving a visible history of what was requested and when.

The repository also contains workflow specifications for policy approvals, reminders, reviews, training notifications, risk follow-up, and audit activities. These flows are tenant-side components and are managed separately from the SPFx package. Keeping the boundary explicit made the solution easier to reason about: the web parts manage the user interaction and the List records, while Power Automate can manage the asynchronous work around them.

Bringing Reporting Into the Portal

The portal needed to show more than individual records. It also needed to make the overall state of the compliance programme easier to understand.

The homepage brings operational information together from SharePoint Lists. Depending on the user's role, this can include policy status, framework coverage, evidence activity, training completion, open risks, recent activity, and upcoming events or deadlines. Employees can focus on their own assigned policies and training, while administrative users can access broader indicators and navigation into the relevant areas.

For more advanced reporting, we embedded Power BI reports inside SharePoint. The dashboard web part supports configurable report URLs for the executive overview, audit status, policies, training, risks, evidence, and controls. That keeps reporting close to the processes and information it represents, without forcing users to move between a separate reporting portal and the operational website.

Power BI has a specific role in this solution: reporting and monitoring. It provides visibility into trends, status, and coverage. The website does not use it as a decision engine. Decisions such as approving a policy, reviewing evidence, or changing a risk status remain part of the defined process and the responsible user's work.

Authentication and Role-Based Access Control (RBAC)

Security was a core design principle of the solution. Instead of implementing a custom authentication system, the website leverages Microsoft Entra ID for identity management and SharePoint's native permission model for authorization.

Authentication

Users authenticate using their organizational Microsoft Entra ID accounts through Microsoft 365's Single Sign-On (SSO). This provides:

• Secure enterprise authentication
• Seamless access without additional logins
• Centralized identity management
• Multi-Factor Authentication (MFA) support (if enabled by the organization)

Because authentication is handled by Microsoft 365, the React-based SPFx components automatically execute within the authenticated SharePoint context.

Authorization (RBAC)

Role-Based Access Control (RBAC) is implemented using a combination of Microsoft Entra ID groups, Microsoft 365 groups, and SharePoint site permissions.

The access model consists of:

• Microsoft Entra ID Security Groups for managing organizational user memberships.
• SharePoint Modern Site Permissions (Owners, Members, and Visitors) to define site-level access.
• SharePoint Groups to simplify permission management for pages, lists, and document libraries.
• Modern Page Audience Targeting and page permissions to ensure users only see content relevant to their roles.

Rather than assigning permissions to individual users, access is granted to groups, making administration scalable and reducing maintenance overhead.

Development and Deployment

The portal was developed using the SharePoint Framework (SPFx) with ReactJS, enabling reusable, component-based development while integrating seamlessly with SharePoint Online.

Development

The application was built as a collection of independent React components and SPFx web parts, where each major page or feature was developed as a separate component. This modular approach improved maintainability, simplified testing, and allowed features to evolve independently.

Although the functionality was split across multiple web parts, they were packaged together as a single SPFx solution, making deployment and version management much simpler.

The development workflow included:

• ReactJS for building responsive UI components
• SharePoint Framework (SPFx) for SharePoint integration
• TypeScript for type-safe development
• SharePoint REST APIs and Microsoft Graph for data access
• Reusable components shared across multiple pages
• Local Development and Testing

During development, SharePoint's standard SPFx development workflow was used for local testing.

The application was tested using the local SharePoint Workbench and hosted Workbench, allowing individual web parts to be validated before deployment to SharePoint Online.

Deployment

After development was complete, the project was bundled and packaged into a single SPFx solution package (.sppkg).

Deployment was performed through the SharePoint App Catalog using the Manage Apps interface.

The deployment process consisted of:

• Bundle the solution using the SPFx build tools.
• Generate the .sppkg deployment package.
• Upload the package to the SharePoint App Catalog.
• Deploy the solution across the tenant.
• Add the required web parts to modern SharePoint pages.

Packaging all web parts into a single solution simplified application updates, versioning, and deployment across environments.

Power BI Development

Reporting and analytics were developed directly within the Power BI Service using its web interface.

Interactive dashboards were connected to SharePoint data sources and published for secure access within the SharePoint portal. Reports were then embedded into modern pages, allowing users to view analytics without leaving the application.

Power Automate Development

Business workflows were implemented using the Power Automate web portal.

Flows were designed to automate processes such as:

• Approval workflows
• Notifications
• List item updates
• Document processing
• Integration between Microsoft 365 services

These cloud flows were connected to SharePoint lists and document libraries, enabling business processes to run automatically without requiring custom backend services.

Conclusion

This project demonstrates that SharePoint can be much more than a document repository. By combining SharePoint Online, React-based SPFx web parts, Microsoft Entra ID, Power Automate, and Power BI, we built a unified platform that supports the day-to-day activities of an ISO compliance program while remaining entirely within the Microsoft 365 ecosystem.

Rather than relying on multiple disconnected applications, the solution brings together content management, business processes, reporting, authentication, and automation into a single experience. SharePoint Lists provide the structured data layer, document libraries manage files, SPFx delivers task-focused user interfaces, Power Automate handles long-running workflows, and Power BI provides operational visibility through interactive dashboards.

An important design decision was to keep responsibilities clearly separated. The web application focuses on user interaction and data management, Power Automate executes asynchronous business processes, Power BI delivers reporting and analytics, and Microsoft Entra ID, together with SharePoint permissions, enforces security and role-based access control. This separation makes the solution easier to maintain, extend, and evolve over time.

The result is a scalable, modular, and maintainable architecture that demonstrates how the Microsoft 365 platform can be used to build modern line-of-business applications—not by replacing SharePoint, but by extending it with the capabilities of the wider Microsoft ecosystem.

At the end of August, our team, together with our strategic joint venture partner AxelCore, will be in Las Vegas for VMware Explore 2026, where we'll be meeting with customers, partners, and members of the VMware community to discuss the future of enterprise private cloud.

Every year, VMware Explore brings together customers, partners, architects, consultants, platform engineers, and technology leaders from across the VMware ecosystem. But beyond the product announcements and technical sessions, its greatest value has always been the conversations.

This year, we expect many of those conversations to revolve around a common theme: the renewed strategic importance of private cloud. 

The Conversation Has Changed

For years, enterprise infrastructure discussions revolved around one destination: the public cloud.

Today, the conversation is different.

Organizations are increasingly prioritizing control, resilience, predictable costs, AI readiness, and operational consistency. Rather than asking whether to move to the cloud, they’re asking what kind of cloud architecture will best support the business they want to build over the next decade.

For many enterprises, Vmware Cloud Foundation has become a key part of that conversation.

Why VMware Cloud Foundation Matters

Modern infrastructure is no longer just about virtual machines.

It must provide a consistent platform for enterprise applications, Kubernetes workloads, AI initiatives, networking, storage, automation, and security, all operating as a single, integrated environment.

VMware Cloud Foundation helps organizations move beyond managing individual infrastructure components toward operating a unified private cloud platform. The result is greater operational consistency, simplified lifecycle management, and an architecture designed to evolve alongside changing business needs. 

What Enterprise Leaders Are Prioritizing

Across the organizations we work with, several strategic priorities continue to shape infrastructure decisions:

• Accelerating VMware Cloud Foundation adoption.

• Simplifying infrastructure operations through unified management.

• Modernizing data centers without increasing operational complexity.

• Expanding Kubernetes and platform engineering capabilities.

• Building secure, resilient, AI-ready infrastructure.

• Delivering consistent operations across on-premises, edge, and cloud environments.

These aren't isolated technology initiatives.

They're strategic business decisions that determine how quickly organizations can innovate, adapt, and scale in the years ahead.

Technology Alone Isn't Enough

Choosing the right platform is only the beginning.

Successful VMware Cloud Foundation adoption depends on sound architecture, careful planning, implementation expertise, and practical operational experience. The organizations seeing the greatest success are those that combine the right technology with experienced engineering teams capable of delivering complex enterprise transformations.

That's why Professional Services continue to play a critical role in helping organizations turn strategy into successful implementation.

A Community That Continues to Move the Industry Forward

One of VMware's greatest strengths has always been its community.

From VMUG events to VMware Explore, architects, consultants, platform engineers, customers, and partners openly share ideas, lessons learned, implementation experiences, and best practices. That collaborative culture has helped shape the VMware ecosystem for years and continues to accelerate innovation across the enterprise infrastructure landscape.

It's one of the reasons we look forward to VMware Explore every year.

Meet the dvloper and AxelCore Teams in Las Vegas

Together with AxelCore, dvloper delivers VMware Professional Services to Broadcom customers across North America. As a Broadcom Expert Advantage Partner, we help enterprise organizations accelerate VMware Cloud Foundation adoption through consulting, implementation, and modernization services.

If you'll be attending VMware Explore 2026, we'd love to connect.

Whether you're planning your next VMware Cloud Foundation initiative, evaluating your private cloud strategy, or simply interested in exchanging perspectives on where enterprise infrastructure is heading next, we'd welcome the opportunity to continue the conversation.

See you in Las Vegas.

In today's fast-paced tech landscape, traditional education often falls short of preparing developers for the realities they'll face in production environments. Our Core Competencies Academy bridges this gap—not by lecturing from a textbook, but by immersing learners in authentic, end-to-end application development with experienced mentors guiding every step.

From Linux Basics to Kubernetes: A Practical Progression

The academy's curriculum isn't designed around theoretical milestones. Instead, it mirrors the actual journey developers take in their careers. Students begin with the fundamentals—setting up Linux environments, configuring networks, and learning to work with the command line—skills that form the bedrock of professional development. This hands-on approach immediately builds confidence and removes the intimidation factor that often accompanies technical education.

But the magic happens through collaboration and mentorship. Rather than working in isolation, students have access to experienced mentors who understand the "why" behind each technology choice. When architecting a Document Manager application, mentors help students make informed decisions about databases, APIs, and security frameworks. This real-world guidance prevents the common pitfall of learning technologies in a vacuum without understanding how they work together in production systems.

Building Teams, Not Just Individuals

As students progress through backend development, frontend integration, and containerization, they're not just accumulating technical skills—they're learning to think like production teams. The curriculum deliberately intertwines frontend and backend tasks, forcing students to consider API design from both consumer and provider perspectives. When configuring Docker containers and Docker Compose, they experience firsthand the challenges of service orchestration and inter-service communication.

This integrated approach teaches the collaborative mindset essential in real workplaces. Students learn that a great API means nothing if the frontend can't consume it efficiently. They discover that containerization isn't just an operations concern—it directly impacts development workflow and deployment reliability. These insights come through doing, with mentors available to help when assumptions prove incorrect.

Authenticity in Learning: From Local to Production-Ready

The academy emphasizes real-world constraints. Students don't deploy to magical cloud environments; they build on personal VMs and local Kubernetes clusters, managing volumes, configuring ingress controllers, and setting up CI/CD pipelines. When they encounter the friction of managing secrets, configuring CORS, or troubleshooting container networking, they're experiencing the genuine problems that senior developers solve daily.

Setting up a self-hosted GitLab Runner, configuring kubectl, and deploying with Kubernetes manifests—these aren't academic exercises. They're the exact workflow that modern DevOps teams use. By traversing this path with mentorship, students don't just learn how to do these things; they develop intuition about why each step matters and how to adapt these patterns to new challenges.

A Culture of Continuous Improvement

Perhaps most importantly, the academy fosters a culture where questions aren't obstacles—they're opportunities. Mentors encourage students to design their own application architecture, choose their own technology stack (with guidance), and make decisions about trade-offs. When a student chooses Go over Java, or Vue over React, mentors help them understand the implications and learn from those decisions.

This approach transforms technical education from passive consumption into active collaboration. Students leave not just with a portfolio project, but with the problem-solving mindset, the confidence to make architectural decisions, and the experience of working with mentors who've walked the same path before them.

The Core Competencies Academy recognizes that great developers aren't created by completing tasks—they're forged through authentic challenges, thoughtful mentorship, and the collaborative spirit that defines modern software teams. It's education that prepares you not just for your first job, but for a career of continuous growth and meaningful contributions to real-world systems.

The journey from Linux basics to Kubernetes deployment is more than a technical curriculum—it's an apprenticeship in the craft of software development.

When a system is down, a token has expired, or the process just died mid-investigation - is the part you actually have to build.

Anyone can build the support-bot demo. Wire a capable model to a ticket, give it read access to a couple of APIs, and watch it diagnose a clean failure on stage. It looks like magic. It is also the easy 20%.

Then you put it in front of a real queue. Unattended. Overnight. Reaching into half a dozen live systems, any of which can be slow, broken, or mid-deploy at the exact moment the agent knocks. The demo agent doesn’t survive that. It stalls on the first timeout, loses its place on the first restart, and the next morning you find a row of half-finished investigations and no record of what they tried.

The hard part of an autonomous support agent isn’t the diagnosis. It’s persistence, the unglamorous discipline of not losing your place when the world around you misbehaves.

We borrowed the idea from the agentic coding tools we already live in, like Claude Code: a loop that keeps its footing. It remembers what it’s done, retries what failed, adapts when a step is refused, and picks up where it left off. None of that is the model. It’s the scaffolding around the model. So when we built our support agent, we treated that scaffolding as the product, not an afterthought. Here is what it actually takes.

1. The work has to outlive the process

Every ticket becomes a durable job, not a request held in memory. It lands in a queue that lives outside the agent, so if the worker is killed mid-investigation (deploy, crash, OOM, a careless kill -9), the job is still there when the lights come back on.

And it comes back honestly. On restart, anything that was “running” when the process died gets caught and marked, not left hanging as a zombie that the dashboard quietly lies about. The state of every job is always queryable, always truthful. That’s the floor: the agent can die, the work cannot.

2. The agent has to remember what it did

Every step the agent takes (each model turn, each tool call, the command it ran, the result it got back, the action that was blocked, the assumption it had to make) is written to an append-only log as it happens, one line at a time. Think black-box recorder, not a summary written at the end (the end is exactly when you don’t get to write anything).

So any investigation can be replayed after the fact, in order, by anyone. This is the difference between “the agent failed, please investigate” and a complete transcript of what it tried, in what sequence, and where it hit the wall. One of those is a ticket nobody wants. The other is a colleague’s handoff notes.

3. Degrade, don’t die

The agent depends on systems it doesn’t own: a secrets store, an orchestration API, the ticketing system, the platform’s own APIs, the log store. In production, “all of them healthy at once” is the exception, not the rule.

So a dependency being down is a condition the agent handles, not an exception that kills it. If it can’t resolve a particular tenant’s credentials, it doesn’t abort; it proceeds with whatever it can reach, and it says so plainly in the record. If an access token expires mid-run, it refreshes and keeps going. The agent is built to do useful work with partial information, because partial information is the normal case.

4. A blocked action is a message

The agent is read-only by construction. Anything that could change state is blocked at the gate before it ever runs: no writes, no deletes, no destructive commands, no exceptions. You don’t trust an unattended agent not to do damage; you make damage impossible.

But here’s the part that matters for persistence: when the sandbox refuses a command, it doesn’t throw an error that unwinds the whole run. It hands the agent a readable reason (“that path is read-only; use the query endpoint instead”), and the loop continues, with the agent adjusting its approach. Same trick the good coding agents use. A denied tool is feedback, not a fatal error.

5. Exhaust the layers before you escalate

The agent investigates in layers, from the cheap broad signals down to the specific deep ones, trying alternatives and dropping to the next source when one comes up empty. It only escalates to a human after it has actually run out of things to check.

And when it does escalate, it doesn’t dump a shrug into the queue. It hands over the full context, what it confirmed, what it couldn’t reach, what it had to assume, and what it recommends next:

Investigation: Inconclusive, escalated to on-call.

Confirmed:
• Instance exists, in ERROR state, on a region reporting healthy capacity.
• Tenant quota not exhausted.

Could not reach:
• Per-tenant secrets (store timed out) → continued with reduced access.

Assumptions logged:
• Fault attributed to scheduler, inferred from the most recent platform signal.

Recommended next actions:
• Route to on-call with the trace below; confirm scheduler health for that region.

That is not a bot giving up. That is a co-worker who did the legwork, knew the limits of what it could see, and tapped the right person on the shoulder with everything they need.

The business case, said plainly

The reason this is worth the upfront work shows up in four places:

• Continuity. It survives the 3 a.m. restart. The queue doesn’t lose tickets and the agent doesn’t lose its place, so unattended actually means unattended.
• Trust. It tells you what it knew, what it didn’t, and why. People stop second-guessing it, which is the only way they ever start relying on it.
• Auditability. Every run is replayable, step by step. When someone asks “why did it say that” three weeks later, the answer is a file, not a guess.
• Throughput. Humans only see the tickets that genuinely need a human, each one arriving with the investigation already done.

The closing thought

The model is what makes the agent smart for a single step. Persistence is what makes it dependable across ten thousand of them. One of those you can buy off a leaderboard. The other you have to build, and it is mostly queues, logs, fallbacks, and the discipline to assume every dependency is having a bad day.

If your agent looks brilliant in the demo and brittle in production, the gap usually isn’t the model. It’s everything underneath that lets it keep going when something breaks, because in production, something always does.

That’s the part we build.

Want to talk about where your agent gets brittle between the demo and production? Get in touch at dvloper.io.

Razvan Georgescu, VP of Data & AI, dvloper.io

Your AI assistant works. That’s not the problem. The problem is that nobody is actually using it.

It passes the demo, the answers are solid, and stakeholders sign off. It looks like a success. Then it goes live, and usage quietly drops. People tried it, found it helpful enough, and then returned to their usual way of working. No complaints. No escalation. Just silence.

This is usually where most companies get it wrong. The issue is labeled as adoption. More training is proposed. Internal nudges are introduced, but none of it changes much. Because the issue isn’t adoption.

Using the assistant creates more work than it removes.

A user asks a question and gets an answer. Then they have to stop, read it, decide if they trust it, and manually apply it somewhere else: another system, another tool, another conversation. The AI helps, but only partially. The rest of the process is still on them.

Over time, that trade-off becomes obvious. Saving time on information retrieval doesn’t justify adding friction to everything that follows. So people adapt. They route around it. That decision exposes the real problem. 

The assistant isn’t failing. It’s simply not part of the workflow.

When your agent sits next to the process, it’s optional. It depends on someone choosing to use it and doing the extra step of translating its output into action. That extra step is exactly where things get stuck. It’s also where our system-building work begins. 

If your team isn’t using AI, it’s worth asking a simpler question: What happens after AI gives an answer? 

If the answer is “a person takes it from there,” you don’t have a system.

Most teams don’t know exactly where that break happens. That’s usually the first thing worth mapping. → Schedule a System Review

Key European Cybersecurity Events — January to March 2026

The first quarter of 2026 marked an intense period of engagement for our teams across Europe. Our people participated as speakers, presenters, and technical contributors in four major cybersecurity events — spanning Greece, Italy, and Romania — all tied to EU-funded projects in which we are active consortium partners. Here is a summary of what took place and how we contributed.

1. CYBERGUARD — 1st General Assembly Meeting

29 January 2026  |  Thessaloniki, Greece  |  International Hellenic University (IHU)

The CYBERGUARD Consortium launched its First General Assembly Meeting at Thessaloniki City Hall, hosted by the International Hellenic University (IHU). The event brought together over 40 participants and marked the first major project milestone since implementation began on 1 December 2024.

CYBERGUARD aims to strengthen Security Operations Centres (SOCs) through AI-driven technologies and an efficient Cyber Threat Intelligence (CTI) sharing framework, improving the resilience of SOCs against complex and evolving attack vectors. The meeting covered project objectives and guidelines, management progress, AI-driven cybersecurity system design, CTI and offensive strategies, threat detection achievements, and technical partner demonstrations. Partners also reviewed Pilot Use Cases in terms of usability, performance, and operational relevance.

Dr. Mihai PĂUN (I-ENERGYLINK), consortium coordinator, opened the meeting. Mrs. Malgorzata Agata KOWALSKA (ECCC Project Officer) joined remotely to address the consortium. The project is funded under the Digital Europe Programme and brings together 13 partners from Cyprus, Greece, Spain, and Romania.

Our contribution

DVLOPER was represented by Tudor Chihaia, Mihai Chihaia, and Răzvan Georgescu. The team delivered a live demonstration of the CYBERGUARD Dashboard to consortium partners, showcasing its current state and capabilities. They also conducted a technical demonstration of Suricata intrusion detection rules, explaining their structure and operational logic within the CYBERGUARD architecture.

2. INTERSOC — 2nd General Assembly Meeting

10 February 2026  |  Terni, Italy  |  Hosted by ASM TERNI

The INTERSOC (INTERconnected Security Operation Centres) project held its 2nd General Assembly in Terni, Italy. The project focuses on disruption preparedness and resilience of digital infrastructures through advanced threat forecasting, cyber-incident detection and response, and the development of a user-centric intelligent threat defence platform.

The agenda included work package progress updates, Final Review Planning, a visit to the ASM TERNI pilot site, and a dedicated workshop — "Overall INTERSOC Architecture, Main Solutions and Demos" — covering the technology stack, integration interfaces, dashboard, and SOC-targeted system architecture. A workshop on Pilot Testing and Evaluation also took place.

INTERSOC is coordinated by EXIMPROD ENGINEERING (RO), funded by the ECCC under the Cybersecurity and Trust Programme (Grant No. 101145853), and gathers 13 partners from Spain, Italy, Greece, Cyprus, and Romania.

Our contribution

DVLOPER was represented by Louis Sardarescu and Adrian Batanu. Louis presented the latest Dashboard updates to the consortium, walking partners through the current development status and upcoming features. Adrian participated in the technical working discussions around the SOC Connector, contributing alongside the other technical partners in the consortium to define integration approaches and next steps.

3. SECUR-EU — 2nd General Assembly Meeting

12 February 2026  |  Terni, Italy  |  Hosted by ASM TERNI

Two days later, also in Terni, the SECUR-EU Consortium held its 2nd General Assembly. The project — "Enhancing Security of European SMEs in Response to Cybersecurity Threats" — focuses on open-source security solutions for SMEs, white-hack testing via the HackOlympics initiative, and improving cybersecurity preparedness across the SME market.

The agenda covered work package progress, Final Review Planning, an architecture and demos workshop, and an open debate on SME training activities and stakeholder involvement — addressing capacity-building strategies and how to maximise the project's reach and sustainability. A Pilot Testing and Evaluation session was also held.

SECUR-EU is coordinated by EXIMPROD ENGINEERING (RO), funded under the ECCC Cybersecurity and Trust Programme (Grant No. 101128029), and gathers 14 consortium partners and 2 supporting organisations from across Europe.

Our contribution

DVLOPER was represented by Carol Bazga and Adrian Batanu, both actively engaged in the pilot use case discussions. Carol also delivered a dedicated presentation on the status of DVLOPER's pilot — the Distributed IDS System Deployed on the Edge for IoT Cyber Attack Detection — covering current implementation progress, technical findings, and next steps within the SECUR-EU validation framework.

4. CRA EUROPE 2026 — Cyber Resilience in Action

4 March 2026  |  Romanian Parliament, Bucharest  |  CYBERFORT Consortium, coordinated by I-ENERGYLINK

The flagship event of the quarter was the CRA EUROPE 2026 conference, held at the Romanian Parliament in the Hall Nicolae IORGA. The event was organised by the CYBERFORT Consortium and coordinated by I-ENERGYLINK, with the support of the Romanian National Cyber Security Directorate (DNSC). It drew over 200 participants and 35 speakers and moderators from across Europe.

The event focused on the practical implementation of the Cyber Resilience Act (CRA) and its implications for SMEs, public authorities, and critical sectors. Three thematic sessions addressed CRA compliance frameworks, the role of standardisation, European policy perspectives, CYBERFORT project outcomes, pilot use case showcases, and the path from compliance to capability. Key representatives from ENISA, DNSC, ELECTRICA, ASRO, Deloitte, and the Authority for the Digitalization of Romania (ADR) were among the contributors.

Dr. Mihai PĂUN (I-ENERGYLINK, CYBERFORT Coordinator) opened the conference, framing the event as a transition point: "CRA EUROPE 2026 is moving from Policy to Practice, from Compliance to Capability, and from Ambition to measurable Cyber Resilience."

Our contribution

Mihai Chihaia, CIO of DVLOPER, participated as a speaker in Session 2 — "Cybersecurity Projects, CRA Compliance & European Policy Perspectives" — as the Manufacturer/Vendor voice on the panel. His intervention addressed three interconnected themes:

• The standards gap as the primary compliance blocker — with Type C product-specific standards still pending publication and SBOM format not yet mandated, manufacturers face the risk of building compliance processes that require rework once final standards are issued.
• The underestimated complexity of SBOM — arguing that an SBOM is not a document but a living, automated process embedded in CI/CD pipelines, particularly challenging for products built on deep open-source dependency stacks (such as DVLOPER's MultiCloud platform, which integrates 30+ OSS tools).
• SME resource asymmetry as the harmonisation gap — large enterprises can absorb compliance costs, while SMEs building digital products cannot staff dedicated compliance teams. EU-funded projects like CYBERFORT and CYBERGUARD are essential complements to regulation.

In a solo intervention later in the session, Mihai also addressed how CRA compliance can become a competitive advantage — positioning it as a market access strategy rather than a cost centre, drawing on DVLOPER's experience serving US-based enterprise clients through Broadcom's partner network.

What Q1 2026 Meant for Us

Across four events in three countries, our teams contributed technically, strategically, and publicly to some of the most important conversations in European cybersecurity today. From SOC architecture and intrusion detection to CRA compliance and SME readiness, Q1 2026 has reinforced our position as an active and relevant voice in the ecosystem. We look forward to continuing this engagement in the months ahead.

In most enterprise deployments, the model is not the limiting factor. The failure appears at the system level, once the AI is exposed to real operational conditions.

In a controlled demo, inputs are predictable, context is bounded, and retrieval pipelines operate on clean, well-structured data. Latency is stable, and responses are evaluated in isolation. Under these conditions, the system performs as expected.

Production introduces a different set of constraints.

Queries are less structured and often underspecified. Input data is distributed across systems with inconsistent schemas and varying levels of reliability. Retrieval pipelines must handle partial failures, timeouts, and conflicting signals. Context windows become a constraint as the system attempts to combine multiple sources into a coherent response.

These are not edge cases. They are the baseline conditions of real usage.

The architecture decisions made during development become visible at this stage. How the system prioritizes sources when signals conflict. How it maintains state across multi-step workflows. How it degrades when a dependency is unavailable. How it handles concurrent requests without compounding latency or reducing accuracy.

Most implementations are not designed for this level of complexity. They are optimized for single-step interactions, not for sustained, multi-step reasoning under load.

The result is predictable. Accuracy degrades as query complexity increases. Latency becomes inconsistent. Failure modes are unclear or poorly handled. Trust declines, and usage shifts toward low-risk scenarios.

The model has not changed. The environment has.

The difference between a working prototype and a reliable system is the architecture that accounts for these conditions — before they surface in production.

Schedule an AI System Diagnostic

Or, if you want to understand how this is built in practice: See how the AI Factory works → https://dvloper.io/ai-factory

How we at dvloper.io build enterprise agentic AI that actually ships, and why the model isn't where your agent lives or dies.

Every enterprise AI program starts with the same enthusiasm and ends with the same question: “Why does the demo look so sharp and the production pilot look like a toddler with a search engine?”

We see this constantly. A team picks a model, wires it to a handful of tools, builds a nice chat UI, and ships something that crushes the happy-path scenarios the product owner demoed. Then it meets real enterprise data, real business rules, real ambiguity, and it collapses. Outputs drift. Trust erodes. The project quietly gets re-labeled as “exploratory” and everyone pretends the roadmap always had that caveat.

The thing nobody wants to say out loud is this: the LLM is not where your agent lives or dies. The model is a commodity. GPT, Claude, Gemini, Llama. Swap them, benchmark them, argue about them on Twitter. None of it will save an agentic system that doesn't understand your enterprise.

The layer that actually determines whether your agent survives contact with production is the one underneath the model. The one that tells it what your enterprise actually means.

That layer is an ontology. And building it properly is what we do at dvloper.io.

What a production-grade enterprise agent actually requires

When we talk about agentic AI at dvloper.io, we mean something very specific: a system that encodes the data, logic, actions, and security of the enterprise into a coherent semantic model, and then lets humans and agents operate on top of it with full fidelity. We call the capability we build for our clients the AI Agentic Factory, and it rests on four things, not one.

Strip away the buzzwords, and an enterprise-grade agent has to do four jobs simultaneously:

• Encode the data of the enterprise. Unify the vast and fragmented sources of truth: CRM, ERP, systems of record, ticketing platforms, document stores, operational telemetry, into coherent objects, properties, and links. Not a dashboard. Not an API gateway. A single semantic model the agent can actually reason over.
• Capture the logic of the enterprise. The rules, constraints, and decision frameworks currently living in someone's head, in a PDF from 2022, or worse, buried in fifteen different stored procedures nobody has touched since the person who wrote them left. Encoded once. Consistent everywhere.
• Model the actions of the enterprise as first-class primitives. Not just “the agent can generate an answer,” but “the agent can write back to the system of record, with the right approvals, the right audit trail, and the right rollback path.” Simple transactions and multi-step workflows, both governed the same way.
• Govern both humans and agents under one security model. Same identity, same permissions, same audit logs, whether the actor is a senior analyst or an autonomous agent. No CISO is going to sign off on “the LLM decided what was allowed.”

None of that is LLM work. All of it is semantic-layer work. And it is exactly what most agentic AI programs skip in the rush to ship a demo, which is exactly why most agentic AI programs stall between demo and production.

Why agents fail without a semantic layer

Let's be specific about what actually breaks when you skip the ontology.

1. The same term means five different things. A “customer” in CRM is not the same as a “customer” in billing, is not the same as a “customer” in the churn model, is not the same as the entity your contract says you owe money to. Your agent sees all five and averages them.

2. Business rules live in humans, not systems. The rule that “we never onboard vendors from jurisdiction X without a Tier-2 compliance review” exists in someone's head and in a PDF from 2022. Your agent has no idea.

3. The agent can't tell when it doesn't know. This is the failure mode that destroys enterprise trust faster than any other. An agent that confidently answers with incomplete information is worse than no agent at all, because you stop checking it.

4. Nothing is explainable. When the agent produces a decision, nobody can reconstruct why. No auditor will sign off on that. No compliance team will let it run unsupervised. No regulator will let it touch a regulated workflow.

5. Every new use case is a from-scratch rebuild. Without a shared semantic backbone, each agent is its own snowflake. Pilots never become platforms. Year two looks exactly like year one except with more sunk cost.

These are not model problems. No amount of swapping from GPT-4 to Claude to Gemini to Llama will fix them. They are architectural problems, and the architecture is the ontology.

How we actually build these systems

Here is the pattern we use at dvloper.io, and what makes the Agentic Factory approach different from “hook an LLM to LangChain and hope.”

1. Ontology-first, model-second

Before we pick the LLM, we model the domain. What are the entities? What are the relationships? What are the rules, constraints, and required properties? What does “done” look like for each workflow? What does every actor (human or agent) needs to know to make a safe decision?

This is boring, unglamorous, diagram-heavy work. It is also exactly what separates the systems that ship from the ones that don't.

2. The agent's job is semantic translation, not answer generation

Once the ontology exists, the LLM's job gets narrower than people expect. It is not “generate the answer.” It is: take the user's request, map it to ontology concepts, identify what is being asked, and route to the right tools.

That is a much more tractable problem for an LLM. It is also much easier to make reliable, testable, and debuggable. Most of what people call “hallucination” in production agents is actually the LLM being asked to do a job the architecture should have handled for it.

3. Tools are first-class citizens, and they are boring on purpose

We build tools as small, deterministic, testable pieces of code that the agent composes into workflows. Boring tools are good tools. They fail predictably. They log cleanly. They don't hallucinate.

The tools that show up in every ontology-driven agent we build:

• The Gap Capture tool. Identifies what is missing before the agent acts. If an onboarding request does not have a jurisdiction, the agent does not guess. It records the gap.
• The Question Generation tool. Turns gaps into targeted follow-up questions, grounded in the ontology rather than generic “can you clarify?” prompts. “Is this vendor operating in a restricted jurisdiction?” beats “Tell me more about the vendor” every time.
• The Assumption Logging tool. When a workflow has to proceed with a temporary assumption, the agent records it explicitly. Every decision becomes auditable. Every assumption becomes a conversation the team can later have.
• The Validation tool. Checks that requests and resolved entities satisfy ontology constraints before any action is taken. Every contract must be linked to a legal entity. Every change request must have a rollback path. Every product must have a capability owner. The ontology says so; the validator enforces it.
• The Reasoning tool. Applies rules over ontology relationships to derive facts the input didn't explicitly contain: eligibility, risk tier, dependency chains, blast radius. This is where ontology stops being a dictionary and starts being an inference engine.
• The Escalation tool. When the agent can't safely complete a task, it routes to a human with full context (gaps, assumptions, partial work, recommended next actions), not a generic ticket with “agent failed, please investigate.”

These are the tools that make the difference between an agent that answers fast and an agent you would actually put in front of a regulator.

4. Observability on top, governance on the side

Every agent call, every tool invocation, every assumption, every escalation, all logged, queryable, auditable. This is not bolted on at the end. It is part of the architecture from day one. When an agent makes a decision six months from now, you can reconstruct exactly why.

5. The platform compounds

This is where the “Factory” in Agentic Factory matters. The first agent we build comes with a semantic model, a tool library, and observability plumbing. The second agent reuses all of it. By the third or fourth use case, the incremental cost of a new agent is a fraction of the first one.

That is when agentic AI stops being a project and starts being a capability.

A real example: agent-driven network operations

Some of our most demanding work lives in network operations: proactive monitoring, configuration validation, incident triage. Real-time, high-stakes, zero-tolerance-for-wrong-answers territory. An agent that confidently pushes a bad change into a production network does not produce a bug. It produces an outage with a name.

What does ontology look like here?

• Entities: devices, interfaces, links, policies, tenants, service paths, SLAs, maintenance windows.
• Relationships: which device serves which tenant, which policy applies to which interface, which link is primary versus backup, which tenant shares which blast radius.
• Rules: what constitutes a valid configuration change, what requires tenant approval, what can be auto-remediated, what must never be touched outside a maintenance window.

A traditional agent asked “Can we push this configuration change?” might confidently answer yes based on syntactic validation alone. That is dangerous.

An ontology-driven agent answers a different question entirely: given the ontology of this network, is this change safe, for which tenants, with what downstream effects, and what assumptions is it making?

It might conclude:

Change validation: Blocked.

Gaps detected:

• Affected tenant SLA window not confirmed

• Rollback path for interface bundle not verified

• Peer link redundancy currently degraded

Questions requiring human input:

• Is this change scheduled inside the tenant's approved maintenance window?

• Has the peer-side team acknowledged the redundant-link status?

Assumptions logged:

• Tenant SLA tier inferred from most recent service catalog snapshot

• Rollback path assumed to be the previously-deployed configuration baseline

Recommended next actions:

• Route to on-call network engineer with full context

• Hold change until peer-side redundancy restored

That is not a chatbot. That is a co-worker with enough context to be trustworthy, and enough self-awareness to escalate when it shouldn't proceed alone.

The business case, said plainly

The reason this architecture is worth the upfront work is not theoretical. It shows up in five places:

Trust. The agent shows what it knows, what it doesn't know, and why. Users stop second-guessing outputs, which means they actually start using them.

Explainability. Every decision is grounded in ontology, rules, and traceable gaps. Regulators, auditors, and internal risk teams can follow the reasoning end-to-end.

Reusability. The ontology becomes a shared asset across every agent and workflow you build. Second use case costs a fraction of the first.

Governance. Assumptions, questions, unresolved issues, and escalations are explicitly captured, not hidden inside model weights you cannot inspect.

Scalability. Different domain agents share the same semantic backbone. Your platform grows as a coherent system instead of a collection of disconnected pilots.

These are not theoretical benefits. They are the reason enterprises that adopt this pattern end up with agentic AI running in production, and the ones that don't end up with a graveyard of demos.

The closing thought

LLMs are excellent at generating language. Enterprise decisions require structure, meaning, constraints, and the discipline to recognize when an answer is incomplete. One of those things is a commodity in 2026. The other is the work.

At dvloper.io, the work is what we sell. The ontology-driven agent is not a demo pattern for us. It is how we ship.

If you are stuck somewhere between a promising POC and a production agent you'd actually trust with a regulated workflow, the missing layer is probably not a better model. It is the ontology underneath.

We would be happy to talk about yours.

Want to discuss where your agentic AI program is stuck, or how an ontology-first architecture would fit your stack? Get in touch at dvloper.io.

Razvan Georgescu, VP of Data & AI, dvloper.io

At some point, every team stops being able to remember everything it has already learned. The knowledge is there sitting in ten thousand Jira tickets, buried in comment threads, resolution summaries, and carefully-written post-mortems of incidents from years ago. All of it is searchable, technically. None of it is findable in the way a human actually asks questions.

New team members spend their first weeks asking questions that have been answered a dozen times before. Senior engineers get pulled off their own work to explain history they’ve already explained, which isn’t just a productivity tax it’s one of the quieter reasons people burn out. Incidents drag on longer than they should because nobody can remember whether this exact symptom has happened before, or whether a similar issue in a different service was already root-caused and resolved.

The organization owns the answers. It just can’t access them at the speed of conversation. That gap between “we know this” and “we can retrieve this” is worth closing. That’s the problem JiraAI was built to solve at dvloper.io.

Why we built our own product layer

Before we wrote a line of code, we spent serious time evaluating RagFlow, the open-source RAG engine that has become one of the most capable platforms in its category. It’s genuinely impressive: deep document parsing, intelligent chunking, multi-modal retrieval, grounded citations, agent workflows, and native Jira support since v0.22.0. For many teams, it’s an excellent starting point. Three concerns ruled out a direct deployment for us.

Access control you can prove

Engineering managers and security leads don’t just want “a chatbot over Jira.” They want to prove that a contractor on Project A has no path through the UI, through the API, or by guessing identifiers to data from Project B. RagFlow’s open-source edition is designed around workspaces, not per-user per-knowledge-base grants. The maintainers confirmed this when they closed the RBAC request in May 2025: granular permission control is a commercial-tier feature. For our use case, this wasn’t a limitation we could work around it was the core of what we needed to deliver.

Roadmap autonomy

Building entirely on a third-party platform means your product’s future is tied to their release schedule and licensing decisions. Owning the application layer while leaning on RagFlow as the retrieval engine underneath meant we could ship the features our teams actually asked for, on our timeline, without waiting for an external roadmap to catch up.

Technology vs. product

A RAG engine does one thing extraordinarily well: retrieve. A knowledge product is the onboarding flow that makes a junior engineer feel supported, the audit trail that satisfies a security review, the dashboard that justifies the budget. None of that ships inside a retrieval engine by default. JiraAI is the product. RagFlow is the engine. Keeping those two things separate, and letting each do what it’s best at, is the most important architectural decision we’ve made on this project.

What JiraAI delivers

1. Real RBAC tied to your existing identity

JiraAI integrates directly with Keycloak (or any OIDC-compliant IdP). Access is enforced at three independent levels: site-wide roles (site.admin, project.admin, project.user), per-user knowledge base grants for contractors and cross-functional contributors, and project-to-knowledge-base mappings that make tenancy clean and auditable. One Keycloak change grants access; one change removes it entirely. MFA, session policies, and password rotation are all inherited JiraAI can’t accidentally weaken them. For a security review, this is the difference between a two-week conversation and a two-day one.

2. An admin dashboard for decision-makers

Every early demo ended with leadership asking the same three questions: Is anyone actually using this? Are the answers good? What are we getting for what we’re spending? The /admin view answers all three adoption by team and project trended over time, per-response helpfulness signals captured directly in chat, and LLM usage tied to specific tickets and projects. It’s a product owner’s view of whether the thing is working, not a RAG operator’s view of embedding health and vector metrics.

3. Jira data understood before it’s indexed

Raw Jira tickets are noisy: triage summaries written before the problem was understood, low-signal comments (“bump,” “retry,” “any update?”), attachments in mixed formats, and resolutions buried in the last reply of a long thread. Feed that directly into a knowledge base and you get answers that reflect the noise.

JiraAI’s ingestion pipeline runs every ticket through an AI enrichment step before it reaches the knowledge base restructuring it into what the problem was, what was tried, what was ruled out, and what finally worked. Atlassian Document Format comments are parsed correctly. A single ticket can fan out to multiple knowledge bases without duplicating the enrichment work. The result is cleaner retrieval and more accurate, more specific answers.

4. Project-centric UX and a resilient pipeline

Instead of navigating a list of opaque knowledge base identifiers, users start from a project, intuitive and familiar organizing unit they already work in every day. The assistant, access controls, and analytics all follow automatically. Behind the scenes, a decoupled producer/consumer pipeline handles incremental Jira polling, enrichment, and fan-out independently. If the downstream is temporarily unavailable, the producer keeps collecting and the consumer catches up. Single-ticket failures don’t affect the batch. Idempotency is enforced at the database level. Reliability isn’t a feature you market it’s the absence of the outages you didn’t have.

How a question becomes an answer

An engineer hits a familiar-looking Kafka consumer timeout and types: “Have we seen this lag spike before, and what was the fix?” JiraAI authenticates them via Keycloak, resolves their project memberships, and queries only the knowledge bases they’re allowed to see the access boundary is enforced at the retrieval step, not just at the UI. Enriched ticket chunks are retrieved, re-ranked, and passed to the LLM with a carefully designed system prompt. The answer streams back with citations to specific tickets.

The engineer clicks through to an eleven-month-old ticket and finds the root cause in three minutes. They mark the response helpful that signal feeds the admin dashboard, where a product owner can see which teams are getting value and which knowledge bases have gaps. Nobody thought about knowledge base IDs, RAG configuration, or which model is powering the response. It just worked, and it was safe, and it was measurable.

The lesson

Retrieval engines don’t ship with the parts that make them products. Access control, audit trails, domain-specific data handling, a UX that fits how engineers think about their work none of that comes in the box, regardless of how good the underlying engine is. A thin interface on top of RagFlow would have passed the demo. It would not have passed the security review.

So we built those parts ourselves and layered them on top of RagFlow’s retrieval quality, which we trust and don’t have to maintain. The hard foundational work is someone else’s problem. The product experience the part our teams open every morning is entirely ours to shape and iterate on.

Further reading

–  RAGFlow on GitHub

–  RAGFlow v0.22.0 data sources, admin UI, parser improvements

Dvloper is entering Phase 3 of a strategic AI collaboration with a Fortune 10 infrastructure leader, evolving an enterprise assistant into a more advanced agentic system designed to reason across complex internal knowledge and support real operational workflows in production environments.

Enterprise AI rarely fails during training. It fails in production.

That reality has shaped our collaboration with a Fortune 10 infrastructure leader, where the goal was never to build another impressive assistant, but a system capable of navigating complex internal knowledge and supporting real operational workflows.

After successfully delivering Phase 1 and Phase 2, we are now entering Phase 3 - the biggest stage of the partnership so far.

From Early Validation To Deeper Operational Value

The earlier phases of this collaboration were centered on building the right foundation: understanding the problem space, shaping the assistant architecture, integrating knowledge sources, and validating how AI could be applied in a way that was actually useful inside a real enterprise environment.

That part matters more than people think.

In enterprise settings, AI is not valuable just because it can answer questions. It becomes valuable when it can work within complex systems, reason through fragmented information, and produce outputs that are relevant, reliable, and aligned with how teams actually operate.

That is exactly where this collaboration has been heading.

With the first two phases successfully completed, with great feedback from the stakeholders of going beyond the initial scope - the project is now moving post foundational capability and into a more advanced stage focused on broader reasoning, stronger orchestration, and deeper operational fit.

What Phase 3 Is About

This next stage focuses on expanding the agentic capabilities of the platform so that it can do more than respond, it becomes a proactive agentic framework instead of a reactive agentic mechanism. It needs to reason across enterprise context, coordinate specialized workflows, and support more structured decision paths in environments where accuracy and traceability matter.

At a high level, this phase builds on the progress already made in areas such as:

• Agent orchestration for more structured task handling
• Context aware reasoning across multiple internal knowledge sources
• Improved routing between specialized flows and capabilities
• Stronger support for complex operational investigations
• A more production minded approach to integration, validation, and rollout

The goal is not to build AI for the sake of AI.

The goal is to build a system that can genuinely support teams operating in complex technical environments, where the volume of information is high, the paths to resolution are rarely linear, and trust in the output matters just as much as speed.

Why This Work Matters

A lot of AI content today focuses on generic assistants and surface level automation. But enterprise reality is different.

Real internal systems are layered. Knowledge is distributed. Processes evolve over time. And the people using these tools are not looking for novelty; they are looking for practical value in their day to day workflows.

That is why this collaboration has been shaped around a more grounded engineering approach.

Instead of treating the assistant like a standalone chatbot, the system has been designed as a more structured, agent driven capability: one that can connect to enterprise knowledge, follow defined reasoning paths, and support users in a way that feels closer to an operational companion than a generic interface.

That distinction is important, especially in larger organizations where adoption depends on whether the solution can fit into real workflows, not just perform well in a controlled demo.

In most large organizations, operational teams deal with high volumes of structured and unstructured information coming from multiple systems that were never designed to talk to each other. The people doing the work are experienced - they know how to navigate the complexity - but they spend a disproportionate amount of time on the repetitive cognitive work: gathering context, cross-referencing sources, triaging what matters from what doesn't. That is not an automation problem. It is a reasoning problem. And that is where agentic AI actually starts to make sense - not as a replacement for expertise, but as a layer that handles the heavy lifting before a decision needs to be made.

What Makes This Phase Different

What makes Phase 3 significant is not only the scale of the work, but the level of maturity behind it.

By this point, the collaboration is no longer about testing whether the idea has potential. That has already been demonstrated through the earlier phases. Phase 3 is about extending that success into a larger, more capable system with stronger real world value.

For our team, this is also the kind of work we care deeply about: combining modern AI frameworks with disciplined engineering, thoughtful architecture, and a strong understanding of how enterprise systems actually behave.

It is one thing to prototype an assistant.

It is another to design one that can evolve responsibly inside a large operational environment.

That is the challenge and the opportunity in front of us now.

Looking Ahead

We are excited to begin Phase 3 and continue building on the trust, momentum, and technical foundation established so far.

This next chapter represents more than just another milestone. It reflects the strength of a partnership built through delivery, iteration, and a shared commitment to building AI systems that are useful, reliable, and grounded in real operational needs.

For Dvloper, it is also a strong example of how we approach enterprise AI, not as a trend, but as an engineering discipline.

The companies that will lead with AI are not the ones moving fastest. They are the ones building systems that their teams actually trust.

My time at the dvloper.io academy was a transformative experience designed to bridge the gap between basic programming knowledge and enterprise-level software development. The primary objective of the program was to familiarize students with real-world applications, full-stack development, and professional workflows, all within a structured Agile methodology emphasizing continuous delivery and iterative improvement.

The curriculum followed two-week sprints, with tasks building on each other and increasing in complexity. Agile practices guided the process: sprint planning to set goals, bi-weekly meetings to stay aligned, code reviews for quality, and retrospectives to reflect and improve. Mentorship was a key part of the academy experience. 

The first month at dvloper.io focused on laying a stable foundation for enterprise-level development. I began by setting up Virtual Machines, installing development tools, and configuring all dependencies required to run complex applications. Understanding the infrastructure behind these systems was equally important, I learned how enterprise applications rely on interconnected services and environments to function reliably. Alongside this, I worked on designing application workflows, planning scalable structures, and mapping how different components would interact. This phase was critical for building core technical skills, developing a structured approach to problem-solving, and learning how to manage tasks efficiently through the two-week sprint structure.

With the technical foundation in place, I moved on to backend development and enterprise data workflows. I focused on writing robust backend logic capable of handling complex business processes and designing REST APIs to facilitate smooth communication across application layers. Integrating these backend components into a cohesive system taught me to think in terms of system architecture and data flow management, reinforcing how enterprise applications are designed for scalability, reliability, and maintainability. By the end of this month, I felt confident tackling enterprise-level backend challenges and understood how backend services support the overall functionality of large-scale applications.

The third month emphasized full-stack development and integration. I shifted my focus to building interactive, responsive frontends and connecting them to the backend APIs I had developed. Testing and refining the end-to-end workflows gave me a clear view of how all components of an application come together to create a seamless user experience. This stage reinforced my understanding of full-stack development and highlighted the importance of integration and user-focused design in enterprise applications. By seeing how each part of the system interacts, I gained hands-on experience in managing complexity in a way that mirrors real-world professional environments.

The final month introduced enterprise DevOps practices, ensuring the applications we built could be deployed and maintained reliably. I learned how to package applications with containerization for consistent environments, deploy and manage them at scale using Kubernetes, and automate testing and deployment through CI/CD pipelines. This phase enhanced my skills in automation, deployment, and scalable system management , all essential for enterprise software development. It also demonstrated how modern development workflows rely on collaboration between developers, operations, and continuous delivery systems to maintain reliability in production environments.

Takeaways

The program provided an invaluable start to my career, equipping me with both the technical expertise and professional skills required in real-world software development. I am now confident to approach other challenges, and continuously improve in a professional environment. 

At dvloper.io, we believe that code quality is not just a nice-to-have. It is the foundation of sustainable software development. As our portfolio grew to include complex platforms like JIRA AI, NationalHR, and Backstage.io, we faced a common challenge: how do we maintain consistent code quality standards across diverse teams and technologies?

SonarQube became our answer, a powerful static code analysis platform that has transformed how we approach quality assurance. In this article, I will share our journey of implementing SonarQube across multiple projects and the lessons we have learned along the way.

The Challenge: Scaling Quality in Microservices

Our flagship project, JIRA AI, is a multi-module Spring Boot microservices application comprising several interconnected services: a core REST API backend, Kafka message producers and consumers, shared utility libraries, and a React frontend. Each module has its own complexity, dependencies, and potential for technical debt.

Similarly, our work on NationalHR and our contributions to Backstage.io required a unified approach to quality that could scale with our ambitions. We needed a solution that would provide consistent standards without stifling the unique requirements of each project.

Our Configuration Strategy

The key to our successful SonarQube implementation lies in a multi-layered configuration hierarchy. At the root of each project, we define core properties: unified project identification, quality gate integration that ensures pipeline failures on violations, and secure environment-based token management. This centralized approach guarantees that all modules inherit the same baseline standards.

Each service module then maintains its own configuration for granular control, including targeted source and test directory mapping, Java version alignment per module requirements, intelligent exclusions for generated code and configuration files, and seamless JaCoCo test coverage integration. We maintain a minimum 80% test coverage threshold across all projects, which has significantly reduced our production bug rate.

CI/CD Pipeline Integration

For JIRA AI, NationalHR, and our other projects, we have implemented sophisticated three-stage GitLab CI pipelines covering build, SonarQube analysis, and deployment. Our configuration features intelligent caching for Maven dependencies and SonarQube results, full Git history access for accurate blame information, and branch-specific analysis with different rules for protected versus feature branches.

A crucial design decision was setting our SonarQube analysis to non-blocking mode. Quality issues are surfaced and tracked without preventing deployments, empowering teams to make informed decisions while maintaining delivery velocity.

The Benefits We Have Realized

Automated Quality Gates: Our quality gates prevent technical debt accumulation by catching issues early. Across all projects, we have seen a measurable reduction in production incidents and maintain code duplication below 3%.

Enhanced Security: SonarQube's vulnerability scanning helps us identify and remediate security issues before production. The OWASP compliance features provide actionable guidance for our security-conscious development practices.

Developer Productivity: With IDE integration and real-time feedback during development, our teams catch issues before they even commit code. Pull request analysis provides automated quality feedback, significantly reducing code review burden.

Lessons Learned

Strategic Exclusions Matter: Do not analyze everything. Exclude generated code, configuration files, and model/DTO classes from duplication detection. This focuses your quality metrics on code that actually matters.

Start with Reasonable Thresholds: We began with achievable quality gate thresholds and gradually tightened them as our codebase improved. This prevented team frustration while still driving continuous improvement.

Leverage Caching: Our caching strategy for both Maven dependencies and SonarQube analysis results significantly reduced pipeline execution times, which is essential for maintaining fast feedback loops.

Conclusion

Implementing SonarQube across JIRA AI, NationalHR, Backstage.io, and our other projects at dvloper.io has been transformative. By combining automated analysis, comprehensive coverage reporting, and seamless CI/CD integration, we have established a culture of quality that scales with our growth.

The multi-module configuration approach provides both unified oversight and granular control, which is essential for enterprise-grade applications. If you are looking to elevate your code quality practices, I encourage you to explore SonarQube. The investment in setup pays dividends in reduced bugs, improved security, and happier developers.

Have questions about our SonarQube implementation? Reach out to us at dvloper.io. We are always happy to share our experiences with the developer community.

About the Author: Bilciurescu Gabriel is a software engineer at dvloper.io, where he focuses on building scalable microservices architectures and implementing DevOps best practices.

The ESTEEC Olympics Hackathon has officially concluded, and the results were nothing short of impressive.

While the energy of a hackathon is often about the "game", this event was rooted in a much larger mission. It served as a promotional platform for the Cyberguard project—a major European initiative where our team holds key development responsibilities.

The Cyberguard Connection

Cyberguard (funded by the European Commission’s Digital Europe Programme) is dedicated to "Fortifying SOCs Against Evolving Cyber Threats." Our day-to-day work in this project involves developing advanced AI-driven technologies to protect critical infrastructure—spanning energy, finance, and healthcare—from sophisticated attacks.

We wanted this hackathon to mirror that level of technical rigor. The goal wasn't just to "spread awareness", but to showcase the intense engineering reality of modern cybersecurity. We challenged participants to step into the shoes of the developers building the next generation of Security Operation Centers (SOCs).

The Challenge: AI/ML SIEM for POS Fraud

We tasked the teams with a highly specific, real-world problem: Building a custom SIEM (Security Information and Event Management) system for Point of Sale (POS) fraud detection.

Participants had to ingest a continuous, high-velocity data stream, analyze it for anomalies, and visualize threats in real-time.

Engineering Under Pressure

To simulate the critical nature of the systems we build at Cyberguard, we introduced strict constraints:

• 30-second live checker: Security is time-sensitive. Once an event hit the stream, teams had exactly 30 seconds to detect the fraud and report it. This forced them to prioritize low-latency architecture over sluggish, heavy processing.
• Real Logic vs. Wrappers: We explicitly banned the "lazy" use of LLMs (simply sending data to a prompt). We demanded genuine algorithmic creativity, hybrid models and custom heuristics that demonstrated true engineering expertise.

From data to decisions

On top of the AI models creation, the hackathon teams delivered on this front with robust dashboards that answered critical business questions instantly:

• What are the top 5 active fraud patterns?
• Which age demographics are being targeted right now?
• How does the current alert volume compare to previous hours?

Summary

This event was a successful extension of our work with Cyberguard. By bringing the complexity of critical infrastructure defense to a hackathon format, we didn't just promote the project—we highlighted the vital importance of integrating AI and machine learning into the fabric of our digital security.

Congratulations to the winners, and thank you for helping us demonstrate what it takes to truly guard the grid.

We’re proud to share that several members of our team won the NASA Space Apps Challenge 2025,  the world’s largest global hackathon for innovation using NASA data.

Their project, AiRo, stood out for its bold approach to one of the most pressing issues of our time: air quality management.

What AiRo Does

AiRo automates industrial air quality management by combining NASA TEMPO satellite data with AI-powered infrastructure analysis.

Traditionally, companies rely on manual environmental consulting - a process that can cost over €57,000 per year. AiRo replaces this with automated, real-time monitoring and reporting for about €10,800 annually, helping organizations save around €47,000 per year while improving environmental compliance and community safety.

The Challenge It Solves

According to the World Health Organization, 99% of people worldwide breathe polluted air. Many organizations still operate reactively - responding to pollution exceedances only after they happen.

AiRo changes that. It shifts industrial facilities from reactive compliance to proactive prevention by continuously analyzing air quality, infrastructure context, and risk factors around industrial sites.

When air pollution levels exceed thresholds, AiRo doesn’t just send alerts - it can call managers directly through AI-powered voice notifications to ensure immediate action.

How It Works

1. Infrastructure Analysis – Uses OpenStreetMap and OpenAI Vision to understand the facility’s surroundings: roads, schools, hospitals, and building density.
2. Environmental Data Integration – Combines NASA TEMPO satellite data (NO₂, HCHO, O₃, AQI) with local measurements and weather data.
3. Contextual Risk Assessment – Models how pollutants move and affect surrounding communities.
4. AI Mitigation Planning – Multi-agent AI systems recommend short-, medium-, and long-term actions with cost-benefit analyses.
5. Automated Reporting – Generates both detailed Markdown reports and executive PowerPoint presentations.
6. Proactive Alerts – Delivers dashboard notifications and AI-initiated phone calls when pollution thresholds are exceeded.

The Impact

For organizations, AiRo means: – Lower compliance costs and fewer consultant hours – Prevention of violations, fines, and permit delays – Access to data that supports grant and tax credit applications

For communities, it means: – Cleaner air – Reduced health risks – Transparent, accessible air quality information

AiRo demonstrates how AI, automation, and NASA open data can come together to protect both the environment and the economy.

Built by the Team at dvloper.io

The project reflects our team’s engineering philosophy: solve real problems with clarity and precision.

AiRo’s technical stack includes React, FastAPI, Kubernetes (K3s), Longhorn distributed storage, and Keycloak SSO, running on Hetzner servers for scalability and performance. Its AI agents leverage OpenAI GPT-5, OpenAI Vision, and Retell AI for data analysis, visual interpretation, and natural-language phone alerts — proving that AI can be both intelligent and actionable.

Why This Matters

Winning NASA Space Apps isn’t just about recognition. It’s about validation that deep tech can create measurable environmental and social impact.

AiRo helps industries become cleaner, smarter, and more responsible and we’re proud of our people who were behind it!

Explore the Project

🌍 NASA: Project Presentation

 📄 Project Report: View Presentation

 💻 GitLab Repository: AiRo on GitLab

At dvloper.io, we believe great systems are never built in isolation.They’re built by teams who see complexity as an invitation to innovate.

Congratulations, Bilciurescu Gabriel-Cosmin, Burea Mihai-Ovidiu, Mitran Andrei-Gabriel, Bazga Mihai-Carol, Pasaroiu Mihai! You did it!

Clarity. Collaboration. Code that matters.