Nicky Pike

Developer Relations

Between November 21 and 23, 2025, attackers compromised hundreds of npm packages and over 25,000 GitHub repositories in a single weekend. They didn&#39;t breach a firewall. They didn&#39;t exploit a zero-day in production infrastructure. They poisoned trusted npm packages with preinstall scripts that harvested GitHub tokens, cloud credentials, and CI/CD secrets from developer workstations before any security scanner could run.

The attack, dubbed Shai-Hulud 2.0, was the most aggressive software supply chain compromise of 2025. Organizations including PostHog, Zapier, AsyncAPI, and Postman <a href="https://blog.checkpoint.com/research/shai-hulud-2-0-inside-the-second-coming-the-most-aggressive-npm-supply-chain-attack-of-2025/">reported infected JavaScript SDK packages</a>. The malware registered infected machines as rogue GitHub Actions runners, giving attackers persistent remote access to developer environments.

The organizations that contained the damage fastest had one thing in common: their developers were not building on local laptops.

<h2>The assumption that failed</h2>

Every organization hit by Shai-Hulud 2.0 had invested in security tooling. They had EDR agents, dependency scanners, network monitoring, and secret management policies. None of it mattered, because the attack exploited a structural assumption baked into modern development workflows: that developer workstations are trusted execution environments with persistent access to sensitive credentials and source code.

This assumption made developer endpoints the most valuable target on the network. A compromised developer machine provides immediate access to GitHub tokens, cloud provider keys, SSH keys, and direct access to source repositories. According to <a href="https://www.sonatype.com/press-releases/q2-2025-open-source-malware-index">Sonatype&#39;s Q2 2025 Open Source Malware Index</a>, the total volume of open source malware surged 188% year-over-year, with 55% of discovered threats specifically designed to steal sensitive information from developer environments.

The Shai-Hulud preinstall script executed before the package installation completed, which meant vulnerability scanners and Software Composition Analysis tools never had a chance to flag the payload. By the time security tooling could examine the package, credentials had already been harvested and exfiltrated. Detection-based approaches failed not because of misconfiguration, but because the attack ran inside a trusted operation: <code>npm install</code>.

<h2>From detection to architectural isolation</h2>

The organizations that recovered from Shai-Hulud 2.0 in hours instead of weeks shared an architectural pattern. They had already separated development environments from developer endpoints, moving code, credentials, and build artifacts into centralized, governed infrastructure.

This is the core shift: instead of trying to detect malicious behavior on endpoints that are structurally exposed, you <a href="https://coder.com/blog/cdes-provide-security-benefits-to-both-organizations-and-developers">eliminate the conditions that make the attack possible</a>. No persistent credentials on the laptop means nothing to harvest. No source code on the local filesystem means nothing to exfiltrate. No long-lived environment state means no foothold for persistence.

Cloud development environments (CDEs) enforce this pattern by design. Workspaces operate in isolation from developer endpoints and from each other. Credentials are injected dynamically with defined TTLs through secrets management integration, not stored as files in ~/.aws or ~/.ssh. Network egress controls restrict which external services a workspace can reach, blocking the kind of arbitrary outbound connections Shai-Hulud relied on to exfiltrate data.

<a href="https://www.darkreading.com/cyberattacks-data-breaches/supply-chain-worms-in-2026-what-shai-hulud-taught-attackers-and-how-to-prepare">Dark Reading reported</a> that supply chain worms in 2026 will be faster, broader, and harder to contain. The defensive response has to be structural, not incremental.

<h2>What architectural defense looks like in practice</h2>

Coder&#39;s cloud development environment platform addresses each Shai-Hulud attack vector through infrastructure-level controls rather than endpoint-level detection. The approach follows a <a href="https://coder.com/docs/tutorials/best-practices/security-best-practices">security best practices framework</a> grounded in workspace isolation, controlled package sources, and dynamic credential management.

Workspace isolation eliminates persistence. Coder workspaces can be configured as ephemeral (destroyed after each session) or persistent with defined rebuild cycles. In either model, malware installed during a compromised npm install is confined to a single workspace. The rogue GitHub runner that Shai-Hulud used for persistence becomes ineffective because nothing survives workspace termination.

Controlled package sources block the initial attack vector. Workspace templates enforce network egress controls that block access to public registries like <a href="http://npmjs.org">npmjs.org</a>, mandating that all dependencies come from vetted internal mirrors such as Artifactory or Nexus. If the malicious package never reaches the workspace, the preinstall script never executes.

Dynamic credentials limit blast radius. Instead of long-lived tokens stored on disk, Coder integrates with secrets management platforms like HashiCorp Vault to inject credentials at workspace startup with 1-hour TTLs. Even if a workspace is compromised, the attacker gets credentials that expire within the hour rather than keys that persist until someone manually rotates them.

Infrastructure as Code ensures consistency. All workspace configurations are defined in Terraform templates maintained through GitOps review. This eliminates the snowflake machine problem where every developer laptop has a different security posture. Policy becomes engineering rather than documentation.

<h2>The proof: containment speed separates outcomes</h2>

The gap between organizations that contained Shai-Hulud 2.0 quickly and those that spent weeks auditing distributed machines came down to one factor: whether development environments were centrally managed. According to <a href="https://www.microsoft.com/en-us/security/blog/2025/12/09/shai-hulud-2-0-guidance-for-detecting-investigating-and-defending-against-the-supply-chain-attack/">Microsoft&#39;s December 2025 guidance</a>, the recommended response included rotating all developer credentials, auditing every GitHub App and OAuth application, and checking package-lock.json files across every project.

For organizations with developers on local laptops, that meant touching every machine individually. For organizations running centralized <a href="https://coder.com/blog/securing-developer-environments-key-takeaways-from-our-august-webinar">development infrastructure with defined security boundaries</a>, it meant updating a template, triggering workspace rebuilds, and remediating the entire developer population in hours.

That gap between hours and weeks is not theoretical in a supply chain attach scenario. When a compromised dependency surfaces, organizations running <a href="https://coder.com/">Coder</a> can remediate across the entire development fleet with a single template update, pushing security patches to all workspaces centrally in minutes. There is no laptop-by-laptop forensic exercise, no racing to determine which machines pulled the affected package. And because source code never lives on the endpoint, there is nothing for an attacker to exfiltrate even if a compromised dependency runs before the patch lands.

<h2>What this means for your next board conversation</h2>

Supply chain attacks will keep targeting developer endpoints because that is where the credentials live. The <a href="https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem">CISA alert on the original Shai-Hulud compromise</a> and Microsoft&#39;s follow-up guidance both point in the same direction: the structural fix is to remove sensitive assets from the places attackers can reach them.

The question for security leaders is not whether to make this transition, but how quickly. The full technical analysis of Shai-Hulud 2.0 and Coder&#39;s defense architecture is in our whitepaper: <a href="https://coder.com/demo">Shai-Hulud 2.0: Defending the Software Supply Chain</a>.

Organizations that contained the damage from Shai-Hulud 2.0 had one thing in common: their developers were not building on local laptops. Here's how Coder closes attack-vectors by moving security to the infrastructure.

Your Developers' Laptops Are the Softest Target In Your Security Stack

Last week I came across a LinkedIn post that instantly put me on the defensive. 

A GIF of a three-story house frame collapsing in high winds. Caption: &quot;I propose &#39;vibe carpentry&#39; is the analog of vibe coding. Vibe carpentry enables non-builders to put up a home in a fraction of the time and cost... these non-builders were seen starting another house the next day... on the same site.&quot;

Here was someone using fear tactics to kill something I genuinely believe could democratize software development and improve both developer productivity and experience. The house collapse was meant to make us picture chaos, incompetence, danger lurking around every corner if we let &quot;regular people&quot; touch code.

But as I stared at that collapsing frame, something clicked. This person had accidentally provided the perfect argument for why citizen development works. They just didn&#39;t realize it.

<h2>The DIY Blueprint: How a Trillion-Dollar Market Got Built Right</h2>

Here&#39;s what that LinkedIn post conveniently ignored: &quot;Vibe carpentry&quot; isn&#39;t some hypothetical disaster waiting to happen. It&#39;s the $775 billion DIY market, heading toward $1.09 trillion by 2033.

Home Depot and Lowe&#39;s didn&#39;t stumble into retail dominance. They realized a gap in traditional construction that had lasted for years. Millions of people had problems that didn&#39;t need a licensed contractor but were too complex for a hammer and hope. These homeowners weren&#39;t looking to construct subdivisions on the weekends. They wanted to install ceiling fans, fix leaky faucets, and build deck railings without waiting three weeks for someone to call them back.

The genius was recognizing that there&#39;s a vast middle ground between &quot;call a professional for everything&quot; and &quot;wing it with YouTube and prayer.&quot;

Sound familiar? Most people using AI to write code aren&#39;t trying to architect payment systems for Fortune 500s. They&#39;re building inventory trackers, automating Excel reports, and creating simple dashboards that have been sitting in IT backlogs since the Obama administration.

<h2>The Three Pillars That Enable Democratization (Without the Disasters)</h2>

Watching both the DIY construction boom and the AI coding revolution, I&#39;ve noticed the same three pillars that prevent disaster while unlocking massive capability:

<h3>Pillar 1: Tools That Make Failure Obvious</h3>

Modern power tools don&#39;t just make work faster. They make mistakes harder to hide. A GFCI outlet will trip if you wire it wrong. A laser level shows you immediately if your shelf is crooked. The feedback is instant and obvious.

The biggest enabler was YouTube becoming the world&#39;s largest technical college. Suddenly, you could watch someone install the exact faucet you bought, see their mistakes in real-time, and learn from their corrections. Sure, you&#39;ll find videos where someone&#39;s wiring looks like they used spaghetti for guidance, but the more you watch, the higher your ability to spot good technique from questionable shortcuts.

AI coding tools work the same way, just faster and more personalized. GitHub Copilot flags security vulnerabilities as you type. Claude can explain what each function does in plain English and walk you through the logic. Cursor catches syntax errors before you even run the code. These aren&#39;t just productivity boosters. They&#39;re safety nets that make problems visible before they become disasters.

Just like YouTube tutorials, AI can occasionally give you questionable advice, but it&#39;s providing vastly more information than any single tutorial ever could. Ask Claude to explain why it chose a particular approach, and it&#39;ll break down the reasoning in ways that help you understand not just what to do, but why. The more you work with these tools, the better you get at recognizing when their suggestions make sense and when you need to push back or ask for alternatives

<h3>Pillar 2: Natural Boundaries That Match Risk</h3>

Here&#39;s where the construction analogy really gets juicy. DIY enthusiasts aren&#39;t stupid. They know the difference between replacing a light switch and rewiring a house. The tools, the permits, the complexity, even the price of materials create natural boundaries that keep people in their lane. Absolutely, we see people that try to take on more than they are able, but I think we can all admit that those are the exceptions, not the rule. 

The same boundaries exist in software development. A marketing manager using Claude to analyze campaign data isn&#39;t attempting to build a stock trading system. The complexity, the compliance requirements, the sheer scope of enterprise systems create natural guardrails.

Most citizen development happens in what I call the &quot;ceiling fan zone.&quot; Complex enough to require skill, simple enough to be safe, valuable enough to be worth doing.

<h3>Pillar 3: Professional Partnership, Not Replacement</h3>

The DIY boom didn&#39;t kill contractors. It created better customers. Someone who&#39;s installed their own flooring understands why foundation work costs what it does. They can have intelligent conversations about project scope and make better decisions about when to DIY versus when to call in the pros.

Business users who learn to work with AI become better partners with IT teams. They understand why security reviews take time. They can prototype solutions quickly and articulate requirements more clearly. Professional developers get freed up from the routine stuff while citizen developers handle problems that match their skill level.

<h2>Why Fear Tactics Miss the Real Risk</h2>

That house collapse wasn&#39;t caused by Home Depot existing or people wanting to perform simple home maintenance tasks themselves. It was caused by someone attempting structural work without understanding load-bearing principles, permit requirements, or their own limitations (and in this post&#39;s case, a healthy dose of hurricane strength wind).

The real disaster isn&#39;t people using tools above their skill level. It&#39;s organizations that refuse to create proper frameworks for citizen development, then act shocked when someone builds something mission-critical in a weekend without any oversight.

Let me paint a picture for you.  An operations manager needs inventory tracking automation. Traditional route? Wait six months for IT resources and spend $50K on a custom solution. Meanwhile, problems pile up, opportunities get missed, and frustration builds. AI-assisted route? Work with Cursor over a weekend to build something functional, run it past IT for a security review, then iterate based on feedback.

Is his solution production-worthy or something you&#39;d ship to customers? No, but honestly who cares? It solves the immediate need &quot;good enough&quot; and provides a feedback loop on requirements and thought processes that his developers can now polish and fine-tune. Instead of starting from scratch with abstract requirements, the development team gets a working prototype that&#39;s already handling real data and real workflows. They can focus their creativity on interesting problems like performance optimization, elegant UI design, and robust error handling rather than burning cycles on basic CRUD operations and figuring out what the business actually wants.  

Which scenario actually reduces risk? The one where problems get solved quickly with appropriate oversight, or the one where mounting pressure eventually leads to cowboy coding, or questionable workarounds (Shadow IT anyone?) because the official process failed?

<h2>The Economics That Make This Inevitable</h2>

IT backlogs don&#39;t just delay projects. They kill innovation. I&#39;ve watched companies spend more on project management overhead than the actual solutions would have cost to build.

When every small automation or request requires a business case, three meetings, and a development sprint, you create inverse incentives. Important but &quot;small&quot; problems don&#39;t get solved. Business users start finding workarounds that make the original problem look simple by comparison.

The DIY construction market didn&#39;t grow because people love Home Depot or have ego-driven visions of being better than an experienced contractor. It grew because traditional construction had created blockers to simple solutions. The same dynamics are driving citizen development adoption.

<h2>What the Fearmongers Get Backwards</h2>

The LinkedIn post that started this whole thing tried to make us picture incompetent amateurs bringing down the house. But the most successful DIY projects aren&#39;t the ones that look professionally perfect. They&#39;re the ones that solve real problems immediately, even if they&#39;re not magazine-worthy.

That deck railing might have visible screws. That closet organization system might be built from basic lumber instead of custom millwork, but they work and provide a sense of satisfaction on completion.  They produce outcomes that get done in a weekend instead of next spring, and they often cost a fraction of hiring it out.

The same principle applies to citizen development. That AI-generated dashboard might not win design awards, but it gives the sales team visibility they&#39;ve needed for months. That automated report might be basic, but it frees up five hours of manual work every week.

Perfect is the enemy of done and done is rarely perfect.

<h2>The Blueprint for Getting This Right</h2>

Six months from now, the companies thriving will be the ones that figured out how to harness citizen development safely. The ones clinging to gatekeeping will be wondering why nimble competitors keep eating their lunch.

The blueprint is already proven. Create good tools with built-in guardrails. Provide relevant information and knowledge in a consumable manner. Establish natural boundaries that match risk levels. Build partnerships between citizen developers and professional teams instead of treating them as threats to each other.

The DIY construction market didn&#39;t happen by accident. It happened because someone realized that the gap between &quot;do nothing&quot; and &quot;hire a professional&quot; was enormous, profitable, and completely addressable with the right approach.

AI-powered citizen development is following the exact same pattern. The tools are getting better, the guardrails are getting smarter, and the economic pressure is getting stronger every quarter.

Next time someone shows you a collapsing house frame as an argument against democratizing development, ask them this: Would they rather live in a world where only licensed contractors can change a light bulb, or one where people can tackle appropriate projects with good tools and reasonable oversight?

Because that&#39;s really what we&#39;re choosing between.

What&#39;s your experience been with AI coding tools? Have you found your &quot;ceiling fan zone&quot; where the complexity feels just right, or have you ventured into &quot;structural engineering&quot; territory where you probably shouldn&#39;t have been?

A LinkedIn post unfairly compared Vibe Coding to untrained carpentry, but the analogy actually strengthens the case for citizen development.

Deconstructing the 'Vibe Carpentry' Comparison

Dave Ahr

Staff Sales Engineer

Last week, I was at an AI DevSummit event and had a conversation that got me thinking. A bright young engineer had just asked me: &quot;How do we use AI to convert millions of lines of legacy code into a cloud-native architecture?&quot;

It was a great question, but it gave me the impression that he wasn&#39;t inquiring about AI in a realistic way. He imagined feeding COBOL systems from the 1980s into ChatGPT and getting back a perfectly architected microservices ecosystem. I pictured him attempting to upload a mainframe dump and expecting Claude to spit out a containerized app that somehow understood why the accounting module still thinks it&#39;s 1999.

If modernization were only that simple, we&#39;d all be sipping cocktails on beaches instead of debugging legacy code that predates most of our junior developers.

That conversation forced me to really think through where AI fits in this messy world of legacy modernization. In short, it&#39;s not where most people think, but it&#39;s way more useful than you might expect.

<h2>The Fantasy vs. The Reality</h2>

To be clear, the hard reality is that AI isn&#39;t a magic button that turns legacy spaghetti into cloud-native perfection. I&#39;ve watched too many demos where vendors wave their hands and claim their AI can &quot;transform any codebase.&quot; What they don&#39;t mention is that the demo probably used a clean, well-documented Node.js app, not the Franken-system that&#39;s been keeping your company alive since Clinton was president.

AI doesn&#39;t understand your company&#39;s risk tolerance, your customer SLAs, or why that weird edge case in the payment processing module exists because Bob from accounting needed a &quot;quick fix&quot; for a regulatory requirement in 1997. (Bob retired in 2015, but his code lives on forever.)

The real challenges in application modernization aren&#39;t technical problems. They&#39;re architectural puzzles wrapped in business constraints and tied up with organizational politics. Where do you draw service boundaries when the original architects drew them with crayons? How do you handle data consistency across distributed services when your current database thinks foreign keys are a suggestion? What gets modernized first when everything is &quot;mission-critical&quot; according to at least three different VPs?

These aren&#39;t coding challenges that AI can solve for you. They&#39;re judgment calls that require understanding your business, your team, and your appetite for 3 AM phone calls.

Once you&#39;ve made those strategic decisions though, AI becomes your secret weapon for the actual implementation work.

<h2>Where AI Actually Delivers Results (Finally, Some Good News)</h2>

While AI isn&#39;t technical fairy dust that will solve all your problems, that doesn&#39;t mean it&#39;s not genuinely useful. It excels at the grunt work that makes experienced developers update their LinkedIn profiles. I&#39;m talking about the soul-crushing, mind-numbing tasks that everyone avoids until they absolutely can&#39;t anymore:

Code archaeology: Remember that time you spent three weeks tracing a customer ID through seventeen different systems just to figure out why Mrs. Henderson&#39;s account showed a negative balance? AI can map those dependencies across millions of lines in hours, not months. Need to find business logic scattered across 47 different implementations and document exactly how they differ, AI is there for you.

Pattern recognition at scale: Beyond mapping dependencies, AI excels at spotting the inconsistencies that drive developers crazy. Your legacy system probably has the same date validation logic implemented twelve different ways, and at least half of them think February has 30 days. AI spots these patterns instantly and suggests standardization approaches that would take humans weeks to identify.

Mechanical transformations: Once patterns are found, they now need to be standardized. Converting deprecated API calls, updating syntax patterns, extracting common functionality into shared libraries. This is where AI delivers that 2-3x productivity boost everyone talks about. You get a really patient assistant who never complains about doing the same boring task 10,000 times in a row.

Documentation and code understanding: Lastly, nobody likes writing documentation, and most of us are terrible at it, but AI actually enjoys this stuff. It&#39;ll read through that mess of undocumented legacy code and explain what it&#39;s doing in plain English. AI can generate better documentation for a 15-year-old module in an hour than the original developer wrote in six months. (To be fair to that developer, they probably assumed they&#39;d remember what the code did. We&#39;ve all been there!)

AI isn&#39;t replacing the complex, creative thinking that makes software development interesting. It&#39;s handling the boring, repetitive work so you can focus on the problems that actually require human insight and creativity.

<h2>Setting Up for Success: The Technical Foundation (Without the Buzzword Bingo)</h2>

To get really serious about AI-assisted modernization, you need the right infrastructure, and no, I don&#39;t mean buzzword-laden enterprise solutions. I mean actual, practical stuff that works.

Any enterprise worth its salt isn&#39;t pumping proprietary code into public models like ChatGPT, for justifiable reasons. You&#39;re essentially contributing your business intellectual property to a public model that your competitors might benefit from. Also, these models learned from millions of lines of both brilliant and terrible code, and they can&#39;t tell the difference between a Stack Overflow hack from 2009 and production-quality architecture. The result is that, while AI can be a force multiplier in software development, it requires guidance on what good looks like and validation of its outputs.

So what do serious modernization efforts really need?

Private model deployment: Host your own models internally. CodeLlama, StarCoder, and other open models work great for this. Yes, it requires more setup than clicking &quot;subscribe&quot; on a SaaS offering, but your security team will stop hyperventilating.

Fine-tuning on your codebase: Generic models think your 20-year-old naming conventions are bugs waiting to be fixed. Fine-tuned models understand that <code>CustomerAcctMgmtSvc</code> isn&#39;t a typo. It&#39;s just how your company abbreviated things before anyone heard of clean code principles.

RAG integration: Connect your AI to your actual knowledge sources: code repositories, documentation wikis, that one Confluence page where someone documented the database schema in 2018. Instead of having all that tribal knowledge scattered across multiple systems, bring them into a single, intelligent interface. This turns AI from a confident guesser into an informed assistant with perfect recall.

Secure development environments: Platforms like Coder provide isolated, monitored workspaces where AI can safely play and test code transformations without accidentally pushing changes to production. Think of it as a sandbox where your AI can play without breaking actual things. In a worst case scenario where AI runs off the rails, you can simply delete the environment and start over.

<h2>The Multi-Model Strategy That Actually Works (No, One Size Doesn&#39;t Fit All)</h2>

Here&#39;s where most teams face-plant: thinking there&#39;s one AI model to rule them all. It&#39;s like hiring one person to be your architect, security expert, QA engineer, technical writer, and coffee maker. Sure, they might be competent at one of those things, but the coffee&#39;s probably going to be terrible.

Tools that try to do everything usually suck at most things. Smart teams build specialized model pipelines instead:

Code Analysis Model: Your code detective. It&#39;s a smaller, faster model that constantly scans your codebase, building dependency graphs, and identifying complexity hotspots. It runs in the background like a really obsessive auditor, creating a living map of your system. It&#39;ll tell you things like &quot;this module is called by 47 other components but hasn&#39;t been updated since Obama&#39;s first term.&quot;

Transformation Model: The heavy hitter that generates new code. This larger model gets trained on your architectural patterns and cloud-native examples. It only spins up when you&#39;re ready to modernize a component, kind of like a powerful build server that you only pay for when you&#39;re using it. Feed it context about your payment processing logic, and it&#39;ll know how to extract payment methods into separate services while keeping compliance checks centralized.

Test Generation Model: Your paranoid friend who assumes everything is broken until proven otherwise. This model focuses on creating thorough test suites to validate that your modernized services behave exactly like the legacy code they&#39;re replacing. The last thing you want is to discover that your new microservice handles leap years differently than the COBOL it replaced.

Security Scanner: Your personal field CISO that understands your compliance requirements and spots vulnerabilities in both legacy and modernized code. Who wants to spend their free time reading OWASP guidelines or compliance documentation? So why not offload this to a model that enjoys this stuff?

These models working together as a system or &quot;team&quot; is where the real power lies. The analysis model identifies that payment processing component buried in your monolith. The transformation model gets that context and knows exactly how to extract it while maintaining backward compatibility. The test model generates edge case tests based on actual data patterns it found. The security scanner makes sure nothing gets exposed that shouldn&#39;t be.

Don&#39;t panic about infrastructure costs. Multiple models don&#39;t mean massive GPU bills. Your analysis model runs on modest hardware since it&#39;s mostly doing classification work. The transformation model only fires up when you&#39;re modernizing code. You&#39;re not paying for idle compute time on expensive models you&#39;re not using.

<h2>The Prompting Philosophy That Changes Everything (Or: How to Talk to Your Robot Buddy)</h2>

Once you&#39;ve got your AI pipeline humming along, the next big issue teams run into is treating AI like Google and thinking it knows your needs with just five words of context. They&#39;ll type &quot;Convert this COBOL to microservices&quot; and expect magic. That approach guarantees generic, unusable output.

Think of AI as a really smart junior developer with perfect memory but zero context about your actual business. You wouldn&#39;t tell a new hire to &quot;modernize the entire payment system&quot; on their first day. You&#39;d have a conversation, maybe buy them coffee, explain the weird quirks of your system.

Try this approach instead:

<pre><code>You: &quot;Analyze this module and explain what business capability it provides&quot;
AI: &quot;This handles customer payment validation and fraud detection...&quot;

You: &quot;What other systems depend on this functionality?&quot;
AI: &quot;I found 23 service calls from the order processing system...&quot;

You: &quot;How could we extract this into a separate service while maintaining backward compatibility?&quot;
AI: &quot;Here&#39;s an API contract that preserves existing behavior...&quot;
</code></pre>

This iterative, pair-programming approach produces dramatically better results because you&#39;re providing the context and constraints that AI needs to make good decisions. The AI has the technical knowledge and infinite patience, but it needs your guidance to understand what you actually want and how it fits into your specific business context.

Skip this conversation step, and you&#39;ll spend weeks debugging AI-generated code that doesn&#39;t quite work. If you embrace AI as a pair-programming partner, you&#39;ll consistently get functional solutions faster.

<h2>The Trust Problem (And How to Solve It Without Therapy)</h2>

The technical stuff usually isn&#39;t the biggest hurdle. The real challenge is convincing stakeholders to let AI touch code that&#39;s been running mission-critical business processes since before social media existed. I get it. That COBOL system might look ancient, but it&#39;s probably processed billions of dollars in transactions without breaking. It&#39;s like that old Toyota in your driveway – ugly, but it starts every morning.

The solution? Start stupidly small and let the wins build your case. Pick one well-contained module that everyone complains about but nobody wants to fix. Maybe that monthly report generator that takes three hours to run and occasionally crashes when someone looks at it wrong. Set up your AI pipeline, modernize just that piece, and measure everything: time saved, bugs introduced, developer satisfaction, how many fewer 2 AM phone calls you get.

Use those metrics and war stories to build confidence for larger transformations. The teams that figure out this human-AI partnership early get a massive advantage over those still debating whether AI is &quot;safe enough&quot; for production code.

<h2>The Human Element: Why Architects Still Matter (And Why You Shouldn&#39;t Panic About Job Security)</h2>

What I really wanted that young engineer to understand is that AI isn&#39;t replacing architects and developers. It&#39;s making us more effective at what we&#39;re actually good at. It&#39;s not a potion of Unicorn tears that will solve everything for you. AI works best as a capable research assistant who never gets tired, doesn&#39;t need coffee breaks, and won&#39;t judge you for asking the same question three different ways.

AI handles the mechanical work brilliantly, but humans drive the strategic decisions that actually matter. Which components get modernized first when everything is allegedly &quot;mission-critical&quot;? How do you phase the migration to minimize business risk when your CFO has nightmares about downtime? What happens when the new microservice needs to handle 10x the load of the legacy system, and your database starts crying?

These are the problems that separate senior developers from junior ones (AI agents), and they&#39;re not going away anytime soon.

Teams won&#39;t win by simply using the fanciest AI tools, but by learning, and understanding, the boundaries between roles and responsibilities within the human-AI working relationship. Developers focus on architecture, creative problem-solving, and understanding business requirements. AI handles the repetitive implementation work, documentation, and the kind of code analysis that would take humans weeks.

You don&#39;t need 10x productivity on everything. Getting 3x productivity on the right things means your best people can work on problems that actually require human insight and creativity.

<h2>Looking Ahead: Your Practical Modernization Playbook</h2>

Ready to stop talking about AI modernization and actually start doing it? Here&#39;s your step-by-step playbook, tested in the real world where things break and budgets matter:

1. Start with assessment (but make it smart): Use AI to map your current system and identify modernization candidates. Look for well-isolated components with clear business value, not the scary monolith that everyone&#39;s afraid to touch. Better to discover how many dependencies exist before you start refactoring.

2. Build your model ecosystem gradually: Start with one specialized model, get it working well, then add others. Don&#39;t try to boil the ocean on day one, or you&#39;ll end up with a very expensive system that does nothing particularly well. Think minimum viable AI pipeline, not skynet for code.

3. Establish trust through ruthless measurement: Gains and progress are only as good as your ability to prove them through facts. Measure and track everything. Time savings, code quality, system performance, developer happiness, number of 3 AM phone calls are all important metrics that will help teams provide confidence, but more importantly, know where to adapt and pivot when needed. You need real data, not just enthusiastic testimonials from early adopters.

4. Scale appropriately: Use the lessons learned and wins and apply them to increasingly complex components. Every success builds credibility and desire to tackle bigger projects. Attempting to scale entire application redesigns based off a component refactor is a recipe for getting called into your manager&#39;s office for a dressing down. Be thoughtful, be programmatic, and scale when within your learned guardrails.

You aren&#39;t looking for perfection, you are looking for progress. If your expectation is that AI is a magic wand that will always give you perfect results, prepare to be disappointed. AI is a tool that will perform the grunt work so humans can focus on the decisions that actually matter for the business.

That conversation with the young engineer reminded me why I love this field, even after debugging legacy code that predates my career. The tools keep improving, but the fundamental challenge remains the same: how do we build systems that serve real human needs? AI just gives us better methods to tackle that challenge.

The companies that figure out this human-AI partnership will modernize faster, with fewer bugs, and with developers who actually enjoy coming to work. The ones that wait for AI to get &quot;smart enough&quot; to do everything will still be running COBOL in 2035, probably wondering why their competitors keep eating their lunch.

I know which camp I&#39;d rather be in. What about you?

A practical guide to AI-assisted legacy modernization that separates hype from reality. Learn where AI delivers real value, how to build effective human-AI partnerships, and implement strategies that actually work in enterprise environments.

AI-Assisted Legacy Code Modernization: A Developer's Guide

Whiteboard design sessions and cloud development have always lived in separate worlds, until now. I recently sat down with Romain Courtois, one of the creators of pad.ws, who&#39;s merging these experiences to create what he calls &#39;the whiteboard IDE.&#39; Our conversation revealed how his journey from Minecraft player to platform builder offers views into the future of development.

<h2>The Minecraft Kid Who Built a Developer Platform</h2>

Like many in his generation, Romain Courtois got his start in the digital world through Minecraft. &quot;I&#39;m your basic Minecraft kid,&quot; he explains. &quot;I spent my early days on all kinds of servers, building all kinds of stuff.&quot; This gaming experience sparked an interest in coding that eventually led him to a unique educational path.

Rather than pursue a traditional computer science degree, Romain enrolled at <a href="https://www.42network.org/">42</a>, France&#39;s famous tuition-free, teacher-less coding school. At 42, students learn through peer programming and community-based projects, which is an approach that deeply influenced Romain&#39;s development philosophy.

&quot;The way it&#39;s built, they call this &#39;peer learning&#39; because you don&#39;t have teachers or any schedule. You just come in and do projects with your peers,&quot; Romain explains. &quot;This approach, I feel, is very aligned with how the internet actually works. Everything is built on peer exchanges and people contributing to open source code.&quot;

After honing his skills at 42, Romain worked at Salesforce and Heroku managing databases, which gave him valuable experience in networking and infrastructure. However, he soon realized the corporate world wasn&#39;t his final destination. &quot;I felt like I wasn&#39;t really made for a job in a corporate,&quot; he admits. &quot;I was drawn to entrepreneurship, building on my own and seeing how it goes.&quot;

<h2>The Birth of pad.ws: Combining Whiteboards and IDEs</h2>

Pad.ws emerged from a simple realization: developers constantly switch between design tools and coding environments. Romain and his friend, Alex Tyrode, wanted to merge these experiences.

&quot;I built <a href="https://pad.ws/">pad.ws</a> with a friend, and we call it the whiteboard IDE, because it merges two ideas that we love,&quot; Romain explains. &quot;He loves the whiteboard, the infinite canvas, and the note-taking aspect. Meanwhile, I love the cloud development aspect.&quot;

When searching for cloud development solutions, Romain first experimented with other options but found they didn’t fit his needs. &quot;At first, there was this GitHub Codespaces, which was really promising. But in the end, it had a lot of limitations because it wasn’t self-hostable,&quot; he explained. His journey led him to Coder, an open-source platform for cloud development environments that offered the flexibility he needed.

&quot;What took the longest was to actually understand that I needed Coder instead of Code Server,&quot; Romain admits. &quot;Developers always love to have minimal dependencies. We try to not install much. But sometimes you just need that extra abstraction on top.&quot;

The distinction matters: Code Server lets you run VS Code in the browser, while Coder manages the entire development lifecycle with supporting infrastructure.

For the whiteboard component, they chose <a href="https://excalidraw.com/">Excalidraw</a> for its flexibility and MIT license, though they eventually needed to fork it to add customizations for better embedding capabilities. &quot;It&#39;s mostly around the embeddings,&quot; Romain explained. &quot;Excalidraw is really focused on drawing stuff, but it wasn&#39;t designed with our level of embedded content in mind. We had to customize some things to accommodate that.&quot; Despite needing these modifications, Romain emphasized that &quot;Excalidraw has been flawless so far. It&#39;s amazing.&quot;

<h2>The Magic Behind pad.ws: Cloud + Canvas + AI</h2>

Romain demonstrated pad.ws&#39;s capabilities, showing how it combines CDEs with an infinite canvas for drawing and planning. But what truly stands out is how pad.ws integrates AI into the workflow.

In one impressive demo, Romain showed how he used the canvas to design a system architecture, which he could then share with an AI agent for feedback. &quot;I can just take a screenshot of this and give it to any model,&quot; he explains. &quot;The models are actually really good at computer vision. I can ask, &#39;What do you think? Am I missing something?&#39;&quot;

This approach changes how developers interact with AI. Instead of just using AI for code generation, pad.ws positions AI as a helpful coding partner in the design process. As Romain puts it: &quot;I&#39;m able to concentrate on the important aspects of what I&#39;m doing. I can focus on the architecture and the flow of how that application is going to go.&quot;

In practice, this means a development team could use pad.ws to collaboratively design a system architecture on the canvas, receive AI feedback on potential flaws, and immediately start implementing the code all in the same workspace. For example, a frontend developer and backend developer could simultaneously work on their respective components while seeing how their pieces fit together in the bigger picture. This eliminates those &#39;I thought you were building it differently&#39; moments that often hinder traditional development workflows.

Romain believes that while AI can be a powerful coding partner, the human still drives the process: &quot;Your prompt&#39;s doing the coding, but your AI is doing all that typing for you.&quot;

<h2>The Community Approach: Open Source All the Way</h2>

Since its initial reveal, pad.ws has gathered significant community interest, amassing over 2,000 GitHub stars in just a month. Romain attributes this to the project&#39;s vision rather than its current state.

&quot;People are convinced by the vision more than the actual product so far,&quot; he acknowledges. &quot;This gives us unlimited motivation to build the actual vision, but we also understand that we&#39;re not quite there yet.&quot;

True to his peer-learning roots, Romain has made pad.ws fully open source and welcomes contributions. &quot;Every contribution is welcome. The project might seem a bit daunting, but it&#39;s really just a simple Fast API backend and React frontend with nothing particularly complex.&quot;

His roadmap focuses on making pad.ws a true team workspace: &quot;Our current focus is to make it multiplayer. We want people to be able to just draw in the same canvas and, ideally, access the same dev environment simultaneously.&quot;

While a paid SaaS option may come later, Romain is committed to keeping the self-hosted version free: &quot;That’s the kind of internet I want to build.&quot;

<h2>Lessons for Developers: The Vibe Matters</h2>

Beyond the technical details, Romain shared some refreshing takes regarding development culture. When asked about the intensive work schedule (he and Alex code about 15 hours daily), Romain shifted the focus from productivity to enjoyment.

&quot;In this formula, the vibe coding, I think people are too focused on the coding aspect. The vibe is what&#39;s important,&quot; he explains. &quot;You need to spend good time with your partners, and that&#39;s how you build good software. You develop good ideas and find clever solutions not by reading a lot or working excessively hard, but by simply having a good time.&quot;

This focus on enjoyment extends to how they interact with AI. &quot;Once in a while, we just throw some jokes and nonsense in the prompts just because it makes us laugh,&quot; Romain shares. &quot;Claude never really laughs at my jokes, but I do, so I don&#39;t care.&quot;

For developers looking to build on existing open-source projects, Romain offers two pieces of advice:

<ol>
<li>&quot;Just go open source. There&#39;s no good reason not to be open source. You can monetize. You can find everything that you fear that you won&#39;t have, but open source is the way if you want people to just see your software and use it.&quot;</li>
<li>&quot;Just ship it. Don&#39;t wait for perfection. Ship something that has flaws, ship something that contains bugs. You ultimately want people to tell you where the bugs are rather than spending time finding them yourself.&quot;</li>
</ol>

<h2>Looking Forward: What&#39;s Next for pad.ws</h2>

As pad.ws continues to take shape, Romain&#39;s vision extends beyond just creating another development tool. He wants to fundamentally change how developers access computing resources.

&quot;What I hope to build is an IDE that allows anyone in the world to simply open a browser, access Linux, and do whatever they want with it,&quot; he explains. &quot;We don&#39;t know exactly what people will create with this capability, but that&#39;s precisely what makes me excited about it.&quot;

With team-based features on the horizon and a growing community of interested developers, pad.ws represents a fresh take on what development environments can be in an age where AI is changing how we build software. Just as Minecraft taught a generation of kids to create worlds block by block, pad.ws is enabling developers to build software with the same spirit of creativity and togetherness. Those blocks have now changed into lines of code, architectural diagrams, and intelligent assistance. For Romain, the journey from placing digital blocks in a game world to creating a platform where developers can build together feels like a natural evolution. Perhaps this signals how our digital pastimes are shaping the tools of tomorrow.

For those interested in trying pad.ws or contributing to the project, you can find Romain on Twitter (@romdot2), TikTok (@cyclotruck), or Discord through the pad.ws GitHub repository.

How has your experience with games or other creative hobbies influenced your approach to development? What aspects of your current workflow would you most like to see with a fresh take? Share your thoughts in the comments!

Meet Romain Courtois, the creator of pad.ws who's re-thinking development workflows by combining infinite canvas whiteboards with cloud development environments. Discover how gaming roots and peer learning shaped a new approach to collaborative coding.

AI-native Development

Secure Environments for 2,500+ Developers

Nicky Pike

Explore the latest from Nicky

Your Developers' Laptops Are the Softest Target In Your Security Stack

Deconstructing the 'Vibe Carpentry' Comparison

AI-Assisted Legacy Code Modernization: A Developer's Guide

Building Blocks to Code Blocks: A Minecraft Player’s Solution to Better Team Coding

Related content

Using Claude Code with Coder Workspaces

Introducing Coder Agents

Self-Hosted Doesn’t Always Mean What It Implies