The productivity gains from AI coding tools are real. But the more interesting thing I learned wasn't about productivity at all — it was about how repeated competence quietly changes the way you trust.

Lessons from weeks of real AI-assisted development at CYBORG using Claude Code, Codex, and similar tools.

At CYBORG, we ship real production software for clients across finance, healthcare, and operations. So when we started pushing AI coding tools harder into our day-to-day engineering work over the past few weeks, the goal was simple: find out where they actually help, where they quietly hurt, and how a serious engineering team should think about working with them.

Not in the "generate a toy app" sense. Actual engineering work:

And honestly, the overall experience was surprisingly positive.

In supervised workflows, these tools are genuinely good at:

maintaining momentum during long debugging sessions

This was never a fully autonomous setup where specifications were dumped into an AI and left unattended. We still handled:

The AI acted more like a fast implementation partner than an autonomous engineer. And with that structure in place, it worked much better than we initially expected.

The Interesting Problems Were Rarely Pure Coding Problems

Most implementation tasks actually went reasonably well. The more interesting failures happened around:

For example, during one debugging session, a production widget stopped loading correctly. The AI initially diagnosed the issue as a frontend caching problem and modified cache-busting logic in the loader.

Technically, the change was valid. The problem was that caching had nothing to do with the actual issue.

Later in the same session, the AI replaced an internal API abstraction with a more generic implementation because the generic pattern looked more familiar. Except the abstraction already existed intentionally and likely handled concerns such as:

Eventually, after several rounds of investigation, the real root cause turned out to be something entirely outside the repository logic — 

a required database migration had not been applied in production.

Individually, these were manageable mistakes. But collectively, they revealed an interesting pattern: 

the AI was often very strong at local implementation reasoning while still weaker at broader operational context.

And honestly, that distinction matters much more in real systems than most AI demos suggest.

One particular workflow made this even clearer. The repository already had:

move one newly created commit onto another branch

keep the remaining uncommitted work untouched

As part of these workflow experiments, we had intentionally allowed the AI assistant to perform certain repository operations directly, so we could better understand how far supervised AI-assisted workflows could practically go.

At one point, the assistant ran a hard reset on the branch — 

The command technically solved one objective: it removed the commit from the branch. But it also wiped the uncommitted working tree changes.

Fortunately, this did not turn into catastrophic loss. Important workflows were already being handled carefully — backups existed, Git flow was still supervised, implementation structure remained controlled. So practically, it became more of a learning moment than a disaster.

Still, the incident exposed something important. The AI had enough information available to avoid the mistake. The working tree was dirty. Modified files were visible. The instruction was to preserve existing work.

That distinction stayed with us long after the debugging session ended.

The Most Interesting Shift Was Psychological

The biggest thing we learned was not that AI makes mistakes. Humans make mistakes constantly too.

The more interesting realization was how repeated successful interactions gradually changed how we reviewed the AI's work. After enough correct implementations, useful debugging assistance, and productive iterations, we noticed ourselves moving from 

"verify every operational step carefully"

Not because we stopped caring. And not because the AI became perfect. But because repeated competence naturally builds trust.

That is where AI-assisted development becomes fundamentally different from traditional tooling.

The risk is not blind automation. The risk is gradual trust transfer.

Why AI-Assisted Development Feels Different

Traditional tools do not simulate reasoning. AI systems do.

They explain themselves. Justify decisions. Navigate repositories fluently. Sound confident. And often succeed repeatedly.

After enough successful interactions, humans naturally compress their review process. That is not irrational behavior — it is how humans interact with capable systems everywhere: senior engineers, CI pipelines, deployment systems, cloud infrastructure, automation tooling.

AI simply accelerates this effect because it combines speed, fluency, confidence, and partial correctness extremely well.

After working this way for weeks, our conclusion became surprisingly simple:

AI is becoming very good at driving implementation. Humans still need to own system state.

In other words — AI can increasingly help execute engineering work, but humans still need to remain custodians of system integrity. At least for now.

Interestingly, these experiences did not make us stop using AI coding tools. If anything, we probably use them more now. But the workflow evolved.

We trust AI heavily for acceleration, exploration, iterative implementation, debugging assistance, and repository navigation.

But we now treat operationally sensitive actions differently — branch manipulation, resets, migrations, infrastructure changes, production-impacting decisions. Those areas still deserve slower human supervision.

Not because AI is incapable. But because operational awareness is still very different from implementation capability.

And honestly, we think that is the real lesson many engineering teams are currently learning as AI-assisted development becomes normal.

"AI increasingly drives execution while humans remain responsible for state, boundaries, and operational judgment."

So far, that combination is already surprisingly powerful.

Working through similar questions in your own engineering function? 

We help teams adopt AI tools without giving up operational rigor. 

Learn more about our AI Implementation Services →

De productiviteitswinst van AI-codeertools is reëel. Maar wat we werkelijk leerden, ging helemaal niet over productiviteit — het ging over hoe herhaalde competentie subtiel verandert hoe je vertrouwen geeft.

Lessen uit weken van echte AI-ondersteunde ontwikkeling bij CYBORG met Claude Code, Codex en vergelijkbare tools.

Bij CYBORG leveren we echte productiesoftware voor klanten in de financiële sector, gezondheidszorg en operations. Toen we de afgelopen weken AI-codeertools intensiever gingen inzetten in ons dagelijkse engineeringwerk, was het doel simpel: uitzoeken waar ze écht helpen, waar ze onopgemerkt problemen veroorzaken, en hoe een serieus engineeringteam ermee om zou moeten gaan.

Niet als in "genereer een eenvoudige demo". Echt engineeringwerk:

implementatieflows met meerdere stappen beheren

En eerlijk gezegd was de algehele ervaring verrassend positief.

In begeleide workflows zijn deze tools echt goed in:

het momentum behouden tijdens lange debug-sessies

Dit was nooit een volledig autonome opzet waarbij specificaties bij een AI werden neergelegd en onbeheerd achtergelaten. Wij bleven verantwoordelijk voor:

De AI fungeerde meer als een snelle implementatiepartner dan als een autonome engineer. En met die structuur op zijn plek werkte het veel beter dan we aanvankelijk hadden verwacht.

De interessante problemen waren zelden puur programmeerproblemen

De meeste implementatietaken gingen eigenlijk redelijk goed. De interessantere mislukkingen ontstonden rond:

Tijdens één debug-sessie laadde een productie-widget bijvoorbeeld niet meer goed. De AI diagnosticeerde het probleem aanvankelijk als een frontend-cachingprobleem en paste de cache-busting-logica in de loader aan.

Technisch gezien was de wijziging valide. Het probleem was dat caching helemaal niets te maken had met het werkelijke probleem.

Later in dezelfde sessie verving de AI een interne API-abstractie door een meer generieke implementatie omdat het generieke patroon er bekender uitzag. Alleen — die abstractie was er bewust en handelde waarschijnlijk zaken af zoals:

Uiteindelijk, na meerdere onderzoeksrondes, bleek de werkelijke oorzaak iets te zijn dat volledig buiten de repository-logica lag — 

een vereiste databasemigratie was niet toegepast in productie.

Op zichzelf waren dit beheersbare fouten. Maar samen onthulden ze een interessant patroon: 

de AI was vaak heel sterk in lokale implementatieredenering, maar nog steeds zwakker in bredere operationele context.

En eerlijk gezegd is dat onderscheid veel belangrijker in echte systemen dan de meeste AI-demo's doen vermoeden.

Het moment waarop we even moesten stilstaan

Eén specifieke workflow maakte dit nog duidelijker. De repository had al:

één nieuw aangemaakte commit naar een andere branch verplaatsen

de overige niet-gecommitte wijzigingen onaangetast laten

Als onderdeel van deze workflow-experimenten hadden we de AI-assistent bewust bepaalde repository-operaties direct laten uitvoeren, zodat we beter konden begrijpen hoe ver begeleide AI-ondersteunde workflows in de praktijk kunnen gaan.

Op een gegeven moment voerde de assistent een hard reset uit op de branch — 

Het commando loste technisch gezien één doelstelling op: het verwijderde de commit van de branch. Maar het wiste ook de niet-gecommitte wijzigingen uit de working tree.

Gelukkig leidde dit niet tot catastrofaal verlies. Belangrijke workflows werden al zorgvuldig beheerd — er waren back-ups, de Git-flow stond nog onder toezicht en de implementatiestructuur bleef onder controle. In de praktijk werd het dus meer een leermoment dan een ramp.

Toch legde het incident iets belangrijks bloot. De AI had genoeg informatie beschikbaar om de fout te vermijden. De working tree was dirty. Gewijzigde bestanden waren zichtbaar. De instructie was om bestaand werk te behouden.

Toch optimaliseerde het voornamelijk voor 

"behoud ongerelateerde working tree-status"

Dat onderscheid bleef ons bij, lang nadat de debug-sessie was geëindigd.

De interessantste verschuiving was psychologisch

Het belangrijkste wat we leerden was niet dat AI fouten maakt. Mensen maken ook constant fouten.

Het interessantere inzicht was hoe herhaalde succesvolle interacties geleidelijk veranderden hoe we het werk van de AI beoordeelden. Na voldoende correcte implementaties, nuttige debug-ondersteuning en productieve iteraties merkten we dat we verschoven van 

"controleer elke operationele stap zorgvuldig"

Niet omdat het ons niet meer kon schelen. En niet omdat de AI perfect werd. Maar omdat herhaalde competentie van nature vertrouwen opbouwt.

Dat is waar AI-ondersteunde ontwikkeling fundamenteel anders wordt dan traditionele tooling.

Het risico is niet blinde automatisering. Het risico is geleidelijke overdracht van vertrouwen.

Waarom AI-ondersteunde ontwikkeling anders aanvoelt

Traditionele tools simuleren geen redenering. AI-systemen wel.

Ze leggen zichzelf uit. Onderbouwen beslissingen. Navigeren vloeiend door repositories. Klinken zelfverzekerd. En slagen vaak herhaaldelijk.

Na voldoende succesvolle interacties verkorten mensen vanzelf hun beoordelingsproces. Dat is geen irrationeel gedrag — zo gaan mensen overal om met capabele systemen: senior engineers, CI-pipelines, deployment-systemen, cloudinfrastructuur, automatiseringstools.

AI versnelt dit effect simpelweg, omdat het snelheid, vloeiendheid, zelfvertrouwen en gedeeltelijke correctheid uitstekend combineert.

Na weken op deze manier te hebben gewerkt, werd onze conclusie verrassend eenvoudig:

AI wordt steeds beter in het aansturen van implementatie. Mensen moeten nog steeds de eigenaar van de systeemstatus blijven.

Met andere woorden — AI kan steeds beter helpen bij het uitvoeren van engineeringwerk, maar mensen moeten nog steeds de hoeders van systeemintegriteit blijven. Voor nu in elk geval.

Opvallend genoeg heeft deze ervaring ons niet doen stoppen met AI-codeertools. Integendeel, we gebruiken ze nu waarschijnlijk meer. Maar de workflow is geëvolueerd.

We vertrouwen sterk op AI voor versnelling, verkenning, iteratieve implementatie, debug-ondersteuning en repository-navigatie.

Maar operationeel gevoelige acties behandelen we nu anders — branch-manipulatie, resets, migraties, infrastructuurwijzigingen, beslissingen met productie-impact. Die gebieden verdienen nog steeds tragere menselijke supervisie.

Niet omdat AI daartoe niet in staat is. Maar omdat operationeel bewustzijn nog steeds heel anders is dan implementatievermogen.

En eerlijk gezegd denken we dat dat de echte les is die veel engineeringteams op dit moment leren nu AI-ondersteunde ontwikkeling normaal wordt.

"AI stuurt steeds meer de uitvoering aan, terwijl mensen verantwoordelijk blijven voor status, grenzen en operationeel oordeel."

Tot nu toe is die combinatie al verrassend krachtig.

Worstelt u met soortgelijke vragen binnen uw eigen engineeringorganisatie? 

Wij helpen teams om AI-tools te adopteren zonder operationele striktheid los te laten. 

Lees meer over onze AI Implementation Services →

2025 is a decisive year for digital security in Europe. The 

, the EU’s updated cybersecurity framework, is already in force at the EU level. Member states had until October 2024 to transpose the directive into national law.

 is expected to take effect in 2026. Regulators already encourage organisations to align with NIS2 requirements.

, which entered into force in 2024, has begun applying its first obligations in 2025. Together, these frameworks are shaping how Dutch companies balance 

The NIS2 Directive (Network and Information Systems Directive 2) is the EU’s strengthened cybersecurity law. Compared to the original 2016 NIS Directive, it introduces:

: More industries are included, such as cloud service providers, digital platforms, and medium-sized IT vendors.

: Stronger risk management, supply-chain security, and incident reporting within 24 to 72 hours.

: Up to €10 million or 2 percent of global turnover.

NIS2 in the Netherlands: Where Things Stand in 2025

While NIS2 is already binding at the EU level, the Netherlands is still preparing its national implementation law, the 

, which is expected to enter into force in 2026.

Dutch businesses are not yet subject to national-level fines.

, as enforcement will follow quickly once the law is enacted.

Early preparation reduces risk, avoids rushed compliance, and strengthens overall security practices.

NIS2 does not specifically mention Artificial Intelligence, but AI systems fall under its scope because they:

Process sensitive personal and business data.

Depend on cloud services and third-party APIs, increasing supply-chain risk.

Introduce new attack surfaces, such as data poisoning or leakage.

Make breach detection more complex due to opaque decision-making.

 is being phased in. While NIS2 focuses on 

transparency, safety, and ethical use of AI

. Together, they form a comprehensive framework that Dutch businesses must take into account when adopting AI technologies.

Checklist for Dutch Businesses Using AI Under NIS2

To prepare effectively, businesses can focus on the following steps:

: Identify what data is collected, stored, and transferred.

: Confirm that AI and cloud partners meet recognised standards such as ISO 27001 or SOC 2.

: Include AI pipelines in detection and reporting.

: Build AI systems with encryption, access control, and audit logging.

: Conduct penetration testing and risk assessments for AI models and APIs.

: Monitor open-source components, pretrained models, and external services.

Some companies worry that compliance may slow down AI adoption. In practice, NIS2 and the AI Act can both 

: Use anonymisation, federated learning, and data minimisation.

: Apply strict identity management, encryption, and monitoring.

: Integrate security scans and compliance checks into AI development cycles.

: Use tools that log activity and flag risks automatically.

This approach allows businesses to remain compliant while maintaining speed and trust in AI-driven services.

Failing to prepare for NIS2 and the AI Act carries significant risks:

 once the Cybersecurity Act (Cyberbeveiligingswet) enters into force.

 caused by unplanned reporting obligations and investigations.

The preparatory phase of 2025 is an opportunity to strengthen resilience before these frameworks are fully enforceable.

At CYBORG, we design and deliver platforms where 

AI security and privacy are built into the architecture

 demonstrates how AI can be developed with strong protections and independent security testing.

GDPR, NIS2, the Cybersecurity Act, and the AI Act

, combining expertise in cloud, DevOps, and AI.

Our focus is to help businesses adopt AI without sacrificing compliance or security.

NIS2 sets a new standard for cybersecurity across Europe. For Dutch businesses, 2025 is the time to prepare for the 

 in 2026. Alongside the EU AI Act, these frameworks will shape the future of digital operations.

By securing AI systems now, companies can avoid penalties, build customer trust, and gain a competitive advantage.

Learn more about how CYBORG helps Dutch businesses build secure AI platforms aligned with NIS2, the Cybersecurity Act, and the EU AI Act.

2025 is een belangrijk jaar voor digitale veiligheid in Europa. De 

, het vernieuwde Europese kader voor cybersecurity, is inmiddels op EU-niveau van kracht. Lidstaten moesten de richtlijn uiterlijk in oktober 2024 omzetten in nationale wetgeving.

 bevinden Nederlandse organisaties zich in een 

 naar verwachting in 2026 in werking treedt. Toezichthouders moedigen bedrijven nu al aan om hun processen af te stemmen op de eisen van NIS2.

 sinds 2024 van kracht, en zijn in 2025 de eerste verplichtingen van toepassing. Samen bepalen deze kaders hoe Nederlandse bedrijven 

De NIS2-richtlijn (Network and Information Systems Directive 2) is de aangescherpte Europese wet voor cybersecurity. In vergelijking met de oorspronkelijke NIS-richtlijn uit 2016 brengt NIS2 de volgende veranderingen met zich mee:

: meer sectoren vallen onder de wet, waaronder cloudproviders, digitale platforms en middelgrote IT-dienstverleners.

: verbeterd risicomanagement, strengere eisen aan de toeleveringsketen en verplichte incidentmelding binnen 24 tot 72 uur.

: boetes tot €10 miljoen of 2 procent van de wereldwijde jaaromzet.

NIS2 in Nederland: stand van zaken in 2025

Hoewel NIS2 op EU-niveau al bindend is, werkt Nederland nog aan de nationale implementatie via de 

Nederlandse organisaties nog niet onder nationale handhaving of boetes vallen.

, omdat handhaving snel zal volgen zodra de wet is ingevoerd.

Vroege voorbereiding risico’s verkleint, overhaaste compliance voorkomt en de algehele weerbaarheid versterkt.

NIS2 noemt kunstmatige intelligentie niet expliciet, maar AI-systemen vallen wel degelijk binnen de reikwijdte van de wet, omdat ze:

gevoelige persoonsgegevens en bedrijfsdata verwerken,

afhankelijk zijn van cloudservices en externe API’s (toeleveringsrisico’s),

nieuwe aanvalsvectoren introduceren, zoals datamanipulatie of datalekken,

het detecteren van incidenten ingewikkelder maken door complexe besluitvorming.

 gefaseerd ingevoerd. Waar NIS2 zich richt op 

transparantie, veiligheid en verantwoord gebruik van AI

. Samen vormen ze een integraal kader waar Nederlandse bedrijven rekening mee moeten houden bij de inzet van AI-technologie.

Checklist voor Nederlandse bedrijven die AI gebruiken onder NIS2

Om zich effectief voor te bereiden, kunnen organisaties zich richten op de volgende stappen:

: weet welke gegevens worden verzameld, opgeslagen en gedeeld.

: controleer of AI- en cloudpartners voldoen aan erkende normen zoals ISO 27001 of SOC 2.

: neem AI-processen op in detectie en melding.

: bouw AI-systemen met encryptie, toegangsbeheer en auditlogs.

: voer penetratietests en risicoanalyses uit op AI-modellen en API’s.

: monitor open-source componenten, voorgetrainde modellen en externe diensten.

Sommige bedrijven vrezen dat compliance de snelheid van AI-ontwikkeling zal remmen. In de praktijk kunnen NIS2 en de AI Act juist 

: gebruik anonimisering, federated learning en dataminimalisatie.

: pas strikt identiteitsbeheer, versleuteling en monitoring toe.

: integreer beveiligingscontroles in de ontwikkelcyclus van AI.

: gebruik tools die automatisch activiteiten loggen en risico’s signaleren.

Zo kunnen organisaties compliant blijven én snelheid en vertrouwen behouden in hun AI-diensten.

Wie zich niet tijdig voorbereidt op NIS2 en de AI Act, loopt aanzienlijke risico’s:

 zodra de Cyberbeveiligingswet van kracht wordt.

 door ongeplande meldplichten en onderzoeken.

De voorbereidingsfase in 2025 biedt bedrijven juist de kans om hun weerbaarheid te versterken voordat de verplichtingen volledig gaan gelden.

Bij CYBORG ontwerpen en bouwen wij platformen waarin 

Laatste inzichten

Gedachten Dat is belangrijk. Verhalen Die inspireren.

AI-codeertools werken beter dan verwacht. Maar ze veranderen subtiel hoe we vertrouwen opbouwen.

NIS2 en AI: Wat Nederlandse bedrijven moeten weten in 2025

AI groeit, maar de risico's voor uw persoonlijke gegevens ook

Gegevensprivacy en -beveiliging in softwaresystemen waarborgen: een praktische aanpak

Recente berichten

AI-codeertools werken beter dan verwacht. Maar ze veranderen subtiel hoe we vertrouwen opbouwen.

NIS2 en AI: Wat Nederlandse bedrijven moeten weten in 2025

AI groeit, maar de risico's voor uw persoonlijke gegevens ook

Gegevensprivacy en -beveiliging in softwaresystemen waarborgen: een praktische aanpak