# The most expensive prompt engineer in your company sits on the board [Home](https://3bird.nl/)/The most expensive prompt engineer in your company sits on the board # The most expensive prompt engineer in your company sits on the board It is a quarter to midnight and the managing director is still prompting. Twelfth attempt, and the script finally does what it was supposed to do. A genuine moment of satisfaction. The quarterly plan he was going to start on this morning is still empty. So is the performance review that has been pushed back three weeks running. But the script works. We run into this more and more with clients. Not with everyone, and certainly not with the majority. But among the people who have properly gone down this road it runs deep, and that group is almost always made up of exactly the people with the highest hourly cost in the building. ## Why it feels so good Let us be honest about why this happens, because “lack of discipline” is not the reason. Leadership is a job where you rarely get to see whether something worked. You hire somebody and six months later you find out whether it was a good call. You change a process and the effects show up next quarter, if you can attribute them at all. You have a difficult conversation and whether it helped becomes clear months afterwards. Prompting is the opposite. You type something, you get an answer within ten seconds, you see immediately whether it is better or worse. It gives you the feedback loop the rest of your job withholds. That is not a weakness, that is how people are built. On top of that, it genuinely pays off. A director who has spent a few weeks working seriously with these tools understands what they can and cannot do far better than someone who has only read about them. That understanding is valuable and you should not outsource it. The problem starts afterwards. ## The arithmetic A senior CTO in the Netherlands earns between €14,000 and €18,000 gross per month this year. Add holiday pay and employer contributions and you land around €260,000 a year. Divide that by a realistic number of productive hours, roughly 1,800, and you get about €140 per hour. As a cross-check: an interim CTO here bills between €175 and €350 an hour. Suppose 20 hours a week go into prompting. Across 45 workable weeks that is 900 hours a year. - 900 hours at €140 comes to **€126,000** a year. - The same 900 hours, done by someone at $25 an hour, costs **a little over €20,000**. - At 30 hours a week the gap widens to roughly **€150,000** a year. That is not an accounting trick. That is the salary of two full-time employees, spent on work somebody else could do just as well. ## The number nobody enjoys reading In February this year the US National Bureau of Economic Research surveyed nearly 6,000 executives across the United States, the United Kingdom, Germany and Australia. Sixty-nine percent of those companies now use AI in some form. Then came the question of whether it was delivering anything. Eighty-nine percent saw no change at all in productivity, measured as revenue per employee. There are several explanations for that, and not all of them flatter the technology. But one of them rarely gets mentioned: when your expensive people do the work themselves, the gain gets eaten by whoever is producing it. You save three hours on a task and pay for it with five hours of executive time. On paper you have become more efficient. On the invoice you have not. ## What you should not hand over To be clear, because this is exactly where advice like this usually goes wrong. You do not hand over your judgement. Which problems are worth solving, what is good enough to put in front of a customer, where the company carries risk: that is your job and it stays your job. The first few weeks of learning what these tools can and cannot do are time well spent too. What you do hand over is the execution. Rephrasing it for the twelfth time. Working out why the output is not quite right. Cleaning up, testing and actually shipping what comes out. That is real work, but it is not board-level work. ## Hand it to whom To someone who does this all day and has got good at it. We call them AI-Sitters: developers who direct, review and refine AI-generated work with the discipline production software demands. You say what needs to happen and judge what comes back. They do the twelve iterations. The cost difference is large, but it is not the interesting part. The interesting part is what you get back. ## Nine hundred hours That is what frees up at 20 hours a week. More than half a full-time role, from the most expensive and best-informed person in the company. Those are the customer conversations that never happen. The employee who has been waiting half a year for a serious talk about where they are going. The strategic decision that keeps sliding because there are never two uninterrupted hours for it. The partnership everybody talks about and nobody moves on. None of that goes faster with a better prompt. It only goes faster when you have time for it. ## An honest look If you were thinking about your own week while reading this, go and count the hours from the past month. Do not estimate. Look back through your calendar and your history. If it turns out fine, nothing is wrong and you now have a number to keep an eye on. If it does not, you know exactly what it cost you this year. In forty-five minutes we will look with you at what is actually inside those hours, and what is sensibly worth handing over. [Book a 45-minute call](https://calendly.com/3-bird/45min) or email [contact@3bird.nl](mailto:contact@3bird.nl). ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) [Home](https://3bird.nl/)/Security and privacy by design: the six findings you will not be fixing # Security and privacy by design: the six findings you will not be fixing Two weeks before launch the penetration test comes back. Eighteen findings. Twelve of them are closed within a day: a missing header, an expired certificate, an endpoint returning more than it should. The other six are the problem. Not because they are hard to understand, but because they are not mistakes. They are decisions. The users table holds the national identity number because that seemed useful once. The application talks to the database as a single account that can reach everything. There is not one log line telling you who opened which customer record. You do not fix that in two weeks, because it sits in the design. Which is exactly what security and privacy by design are about. ## The difference between a finding and a design decision A mistake gets patched. A design decision gets migrated, and migration hurts the moment there is production data involved. Take that identity number. Removing it means working out everywhere it ended up: in backups, in exports, in a log file somebody once found convenient, in the search index. Each of those is a separate conversation. Never having stored it means never having the conversation. That is the core of the idea, and it is less lofty than the phrase suggests. This is not about a security culture or a mindset. It is about making a handful of decisions before they get expensive, at the point where they still cost nothing. ## This year it moved from optional to required The GDPR has said since 2018, in Article 25, that you must arrange data protection by design and by default. In practice that often stayed a paragraph in a processing agreement. That changed inside five weeks. On **15 August 2026** the Dutch Cyberbeveiligingswet came into force, the national implementation of NIS2. Around eight thousand organisations fall under it. They have to register with the national cyber security centre, run a risk analysis and take proportionate measures based on it, and report incidents to the CSIRT within twenty-four hours. One detail matters in the boardroom: the board approves those measures and supervises their implementation. That duty cannot be delegated away. On **11 September 2026** the reporting obligations under the EU Cyber Resilience Act took effect for manufacturers of products with digital elements. Actively exploited vulnerabilities and severe incidents have to be reported: an early warning within twenty-four hours, a full notification within seventy-two, and a final report within fourteen days of a fix being available. It runs through the Single Reporting Platform to the CSIRT and is shared with ENISA. If neither applies to you, you are still not clear of it. Your customers do fall under them, and whatever they have to demonstrate gets pushed down into their contracts. It reaches you either way. ## What twenty-four hours actually means That one deadline deserves a moment, because it reads like an administrative requirement when it is a technical one. To report within a day that you are being actively exploited, you have to be able to see it. That means logging you can search, some sense of what normal traffic looks like, and somebody looking. Most organisations reading this discover a breach because a customer rings up, or because spam suddenly starts leaving their domain. Audit logging has therefore moved from something you add later to something the law effectively requires. Not “we log everything” into a file nobody ever opens, but logging that answers one question: who saw or changed what, and when. ## Privacy by design, concretely Set the law aside for a moment. This is what it means when you are designing a system. - **Data minimisation is the cheapest security control there is.** A field you do not collect cannot leak, does not need encrypting, is not in your backup and does not resurface in a subject access request. Ask of every field: what breaks if we do not have this? - **Retention periods belong in code, not in policy.** A retention period in a Word document is not a retention period. A scheduled job that actually deletes is. - **Pseudonymising is not anonymising.** Replace a name with an id but keep the key, and you still hold personal data with every obligation intact. That distinction gets blurred in exactly the conversations where it matters. - **Purpose limitation visible in your data model.** What you need to deliver is separate from what you keep in order to sell. Put them in the same table and you cannot withdraw one without the other when somebody objects. - **Access to production data is a design decision.** Who on your team can run a query against customer records, and is that recorded anywhere? ## Security by design, concretely - **Threat model before the schema is fixed.** An hour with the team at a whiteboard and four questions: what are we protecting, who wants in, how would they get in, and would we notice. That hour is priceless in hindsight. - **Closed by default.** New endpoints, buckets and ports start shut and get opened deliberately. The other way round, somebody always forgets. - **Least privilege, machines included.** Most applications talk to the database as one all-powerful account. That is comfortable while building and it is precisely what an attacker needs. - **Keys with a lifecycle.** Not in the repository, rotatable, and owned by someone. A token with no expiry is a debt you only see when it goes off. - **Assume one layer fails.** That is the whole point of defence in depth: not that every wall holds, but that there is a second one. - **Know what is inside your software.** A current list of your dependencies is the only way to answer, within a day of the next Log4j-style disclosure, whether you are affected. ## Why doing it up front is so much cheaper Up front, these are conversations. Half an hour about which fields you store, an hour on your threat model, a decision about permissions nobody has run into yet. Afterwards they are data migrations, with everything that comes attached: backups to carry along, customers to inform, a supplier who also has it sitting in their system. And with personal data something else arrives that technology does not solve. Data you should never have collected can be deleted, but you cannot undo the fact that it was there. ## How to set this up without building a programme You do not need a security department for this. You need a few fixed moments where the question gets asked. For every new component: which data does this touch, how long do we keep it, and who can reach it. Before a schema is locked: an hour of threat modelling. In your pipeline: a scan for keys left behind in the code. And once a quarter, the question of whether you would genuinely make that twenty-four hour deadline with the logging you have today. That is it. No certification programme, no thick document nobody reads. ## Want to know where you stand? In forty-five minutes we will walk through how your system sits on these points and tell you honestly what we see. If it is in good shape, you will hear that too. [Book a 45-minute call](https://calendly.com/3-bird/45min) or email [contact@3bird.nl](mailto:contact@3bird.nl). ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) [Home](https://3bird.nl/)/Soon nobody will compare three webshops # Soon nobody will compare three webshops This is how someone buys a water filter today. Search, open three webshops, skim the reviews, work out whether that model actually fits their jug, compare prices, add up the shipping, and finally order from the shop that was slightly cheaper or looked slightly more trustworthy. This is how it will go. “Order a new filter that fits my Brita, no more than thirty euros, delivered tomorrow.” The assistant searches, checks the fit, weighs price against delivery time, and pays. The customer sees one proposal and says yes. Something gets sold either way. The difference is who does the choosing, and what they base it on. ## This is no longer a prediction IDC researched it this summer together with WooCommerce, and the numbers are not subtle. Among Fortune 2000 companies, agent adoption grows tenfold heading into 2027. IDC expects roughly five hundred billion dollars of digital spending to shift through agents by 2030. And the line that matters most to a shop owner: merchants who are not prepared stand to lose around a quarter of their addressable market. A quarter. Not because your product is worse or your price higher, but because you were not readable at the moment the choice was made. ## What an agent sees of your shop Almost nothing you put into it. Your photography, your design, your trust badges, your notice that only three are left in stock, your carefully written brand story: an agent does nothing with any of it. It reads your structured data. If it is not in there, it does not exist. Where shops fall down in practice: - **The price is not readable in the page.** It sits in an image, or only appears after JavaScript has loaded it. - **The product description is sales copy.** “Perfect for any kitchen” tells an agent nothing. Dimensions, materials and compatibility do. - **Compatibility is missing.** Exactly the question the customer asked, and exactly what is written down nowhere. - **Stock status is vague.** “Order before 11pm on working days” is enough for a human and useless to a machine. - **Category pages are bare grids.** No text explaining what to look for, so nothing to compare against. ## The protocols, and why you should not wait for them The standards that let agents actually buy are being built right now. Three names keep coming up. **UCP**, the Universal Commerce Protocol, comes from Google and Shopify, with Etsy, Walmart, Target and twenty-odd others behind it. It covers the path from discovery to cart, and since 17 June 2026 you can switch it on yourself through Shopify. **ACP**, from OpenAI and Stripe, handles checkout inside the AI surface itself. And there sits the most instructive warning in this whole story: OpenAI’s own Instant Checkout, the flagship product built on that protocol, shut down in March 2026 after about five months of disappointing sales. The spec lives on. The application did not. **AP2**, the Agent Payments Protocol, cryptographically proves the customer really authorised the purchase. Google started it and handed it to the FIDO Alliance in April 2026, with sixty-plus organisations behind it. These are not competitors. They sit at different layers of the same transaction, and a single purchase can use all three. That still leaves you unable to know which one matters in three years, and the Instant Checkout story shows what happens when you tie yourself to one horse. Happily, you do not have to. Underneath all three lies the same layer, and that one does not change: your product data has to be correct, structured and retrievable from outside. That work is never wasted, whichever protocol wins. ## What you can do this month on WordPress Concrete, and most of it takes hours rather than weeks. - **Check your product schema.** Yoast and Rank Math lay a foundation, but they do not fill in your own product attributes. Run a few product pages through Google’s Rich Results Test and look at what actually comes out. - **Turn on llms.txt.** Yoast SEO generates it automatically from version 22.0, Rank Math from 1.4.0. It is a plain text file on your domain explaining what you sell and where the important pages are. - **Rewrite product copy for machines.** Specifications as a list rather than prose. Compatibility stated explicitly, including what does not fit. That last part feels like arguing against your own sale, but an agent that cannot confirm a fit simply will not propose the product. - **Give category pages some text.** What to look for, which sizes exist, who each option suits. - **Put an FAQ block on product pages** with the questions your support desk already gets. - **Measure it.** Split out traffic from ChatGPT, Perplexity and Gemini in GA4 so you can see whether anything is moving. ## Why this sits differently for WordPress shops In the same IDC research, 65 percent of digital leaders named the rigidity of their platform as the biggest barrier. Closed systems where capability is gated behind a higher subscription tier, and where you cannot get at your own data. On WooCommerce you do not have that problem. You own your data, you can add any field you need, and no vendor is putting an API behind a pricier plan. Right now that is a genuine advantage. The flip side holds just as firmly: nobody is going to do it for you either. Shopify turns UCP on for its entire customer base with one switch. On your shop it happens when somebody sets it up. ## Why not next year Because you will not watch it happen. When search traffic falls you see a chart dip and you go find out why. Here there is no chart. Nothing tells you an assistant considered your filter three times and dropped it three times because nowhere did it say whether the thing fits. Your revenue just drifts slowly toward competitors who were readable, and by the time you notice you are a year behind. And this work is cheap while it is small. It gets expensive the moment it has to happen under pressure. ## Want to know where you stand? In forty-five minutes we will fetch a few of your product pages the way an agent does and show you what is readable and what is not. No story about the future, just what is there now and what we would tackle first. [Book a 45-minute call](https://calendly.com/3-bird/45min) or email [contact@3bird.nl](mailto:contact@3bird.nl). ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) [Home](https://3bird.nl/)/Soon nobody will search for the cheapest flight # Soon nobody will search for the cheapest flight This is how you book a flight today. You open Skyscanner or Google Flights, put in some dates, scroll past twenty options, open four tabs, weigh layover times against baggage fees, decide you would actually rather fly from a different airport, and half an hour later you book something you hope was the best choice. This is how it will go. You tell your assistant: book me a flight to Lisbon on Tuesday morning, no connections, landing before ten, use my Flying Blue number. Twenty seconds later you get one proposal with the reasoning attached. You say yes. That difference looks small. It is the biggest thing happening to websites in the next few years. ## What actually shifts In the first case, you do the comparing. The website has to convince you, so it is built to convince you: good photography, reassuring design, a button that stands out, a note that only two seats are left. In the second case an agent does the comparing, and it works differently. It acts as an orchestrator: it spins up specialised sub-agents to solve individual pieces, say finding the best hotel, checking it against your loyalty points and verifying the cancellation policy, then combines those results into a single answer. All you do is confirm. That agent is immune to your design. It does not see a scarcity banner and does not feel urgency. It wants to know what it costs, what the terms are, whether it is available, and whether it can complete the booking. ## This is not about travel The flight analogy is useful because everyone recognises it, but the mechanism is not specific to travel. Anywhere someone currently compares options before choosing, this is coming. Insurance. Suppliers. Professional services. Asking three companies for a quote. When your customer tells an assistant “find three firms that can do this and request quotes”, the question is no longer whether your website looks good. The question is whether you make the list of three. ## The uncomfortable part Your website was almost certainly built to win a click. Twenty years of SEO practice is about ranking high enough that someone clicks, and then persuading that visitor once they arrive. If there is no click, that model stops working. The awkward bit is that you will not watch it happen. When search traffic drops you see the numbers fall and you go investigate. With agents there is no signal. There is no line in your analytics saying an assistant considered you three times and ruled you out three times because your pricing was not readable anywhere. You simply notice nothing, and that is exactly the problem. ## What an agent needs The practical translation is less exotic than it sounds. Agents need three things, and you probably have two of them half sorted. **Structured data.** Schema.org has been the standard for years for telling a machine what is on your page: this is a product, this is the price, this is availability, this is a service with these properties. For search engines that was useful. For agents it becomes the foundation. **Current information.** A 2024 price list inside a PDF is annoying for a human and worthless to an agent. Anything you want taken into account has to be correct and machine-readable. **A way to do something, not just read something.** This is the big one. In travel it is now said plainly that companies have to become API companies. That applies far beyond travel. If an agent can only read at your site while it can book, request or reserve at your competitor’s, you know how that ends. ## The standards taking shape Several parties are building the plumbing right now. MCP servers for search and shopping. WebMCP and Cloudflare Markdown as protocols for agent browsers. Google is working on UCP, a universal commerce protocol, which has not been adapted to travel yet but almost certainly will be. And underneath all of it sits plain Schema.org. Nobody knows which of these is the standard in three years. That is not a reason to wait, because there is a layer underneath that does not change: your data has to be correct, structured and retrievable from outside. That work is never wasted money, whichever protocol wins. ## What we would do now No large programme, no bet on a single technology: - **Get your structured data right.** It costs little, already helps with ordinary search engines today, and is the base for everything that follows. - **Look at what an agent actually sees on your site.** Not what you see in your browser. Fetch your own pages the way a machine does and check whether prices, terms and availability are in there, or only inside an image or a script. - **Make your key data retrievable.** Start small: one endpoint with your services, rates or availability. You do not have to open up your whole business to count. - **Experiment with one agent protocol.** Stand up an MCP server for a bounded part of your offering and see what happens. That is a week of work, not a quarterly project. ## Why now and not next year Because this work is cheap while it is small, and expensive the moment you have to do it under pressure because a competitor already has. And because falling behind here is invisible. You get no warning. You see no decline. You just get proposed less and less often, by assistants your customers have come to trust, and by the time it shows up in revenue you are a year behind. ## Where do you stand? In forty-five minutes we will look at your site the way an agent would and tell you what is readable and what is not. No pitch about the future, just what is there now and what we would tackle first. [Book a 45-minute call](https://calendly.com/3-bird/45min) or email [contact@3bird.nl](mailto:contact@3bird.nl). ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) [Home](https://3bird.nl/)/Which AI is actually running in your company? # Which AI is actually running in your company? Ask any CTO which AI tools are running in their organisation and you get a list. Then ask five developers what they used this week, and you get a longer list. The gap between those two is what an AI audit is about. At most companies, AI did not arrive through a decision. It arrived through people. Someone took out a Cursor subscription because it helped. Marketing started generating copy. Somebody built an agent that reads the shared mailbox and turns it into tickets. Each of those was a sensible call. Together they add up to an infrastructure nobody designed and nobody documented. ## What you map first An audit starts boring, with an inventory. Three questions, and the answers usually disappoint. **Which tools are running, and what data leaves through them?** Not just the ones on the invoice. Also the free accounts, the browser extensions and the personal subscriptions people use for work. For each one you want to know what goes out and whether your contracts allow it. **Which code was written by AI, and what happened to it?** In most repositories you cannot tell. There is no marker, no separate review trail, no distinction between code a senior worked through and code that went from a model straight into the main branch. **Which keys do your agents hold, and what do those keys allow?** This is the question that most often produces silence. An agent that processes invoices has a token somewhere. It was created once, probably with wider permissions than it needed, and almost certainly without an expiry date. ## Where it goes wrong in practice The patterns we run into are strikingly consistent. - **Keys without a lifecycle.** Human accounts have an onboarding and an offboarding process. Agents rarely do. No rotation, no expiry, and nobody noticing that a token from an abandoned experiment still works. - **Over-permissioned service accounts.** During development you give an agent admin because otherwise you keep hitting permission errors. That almost never gets rolled back. - **Exposed MCP endpoints.** More companies are standing up an MCP server for their own systems so AI clients can reach them. That is a writable API on your production environment. It deserves the same scrutiny as any other writable API, and often does not get it. - **Prompt injection through content.** If your agent reads email, documents or web pages, it is reading text somebody else wrote. Put an instruction in there, and an agent without a clear separation between data and commands may simply carry it out. - **No view of dependencies.** Without a current list of what is inside your software you do not know what you are pulling in. That was already a problem. With models that regularly reference packages which do not exist, it has not got smaller. ## Three layers, in order of urgency The Cloud Security Alliance uses a split that works well in practice, because it separates what you do this week from what is a programme. **Immediate.** Inventory every AI tool in use. Scan your repositories for keys and passwords left behind. Check your dependencies against a current list. This is days of work, not months, and it almost always turns something up. **Short term.** Move security testing to the moment code is created, rather than waiting for the pipeline. Write down where AI assistance is not used without review: authentication, authorisation, cryptography and input validation are the obvious four. Assess the platforms your team uses against your own vendor requirements. **Structural.** Give agents the same lifecycle as employees, including rotation and revocation. Record in your dependency list which parts were AI-generated. And put governance in writing before somebody else does it for you, because the European AI Act is phasing in, and for nearly every obligation the first practical step is the same: knowing what you have. ## What you can check yourself today You do not need us to run the first three checks. They cost an afternoon and usually tell you enough to know how bad it is. **Scan your repositories for leftover keys.** Tools like gitleaks or trufflehog walk your entire git history, not just the current files. That distinction matters: a key removed last year is still sitting in the history, and a repository that was ever public has been public forever. **List your tokens and look at when they were created.** GitHub, your cloud provider and your main SaaS vendors will all tell you. Anything older than a year without a clear owner is suspect. Anything without an expiry date is a debt. **Check what your service accounts are actually allowed to do.** Not what the documentation claims, but what the permissions say. The question to ask yourself is simple: if this account falls into the wrong hands tomorrow, how far does someone get? If none of that turns anything up, you are in better shape than most. If it does, you now know where to start. ## Why a report is not enough The trouble with audits is that they are a snapshot. You get a document, you fix the worst of it, and three months later the situation has moved again. Not through negligence, but because this field simply moves faster than your audit cycle. So we do not hand over a report and shake hands. We put AI-Sitters in place: senior developers who work alongside your team, review AI-generated code before it reaches the main branch, and keep an eye on the permissions your agents accumulate over time. The AI can go as fast as it likes. There is just someone sitting next to it who knows where this breaks. ## Starting at the start If you read the above and thought “no idea how that stands with us” at more than one point, that is your answer. It is not embarrassing. It is where nearly everyone is right now. [Book a 45-minute call](https://calendly.com/3-bird/45min) and we will walk through the three inventory questions together. After that you will know whether a full audit is worth it, or whether an afternoon of tidying up will do. Email works too: [contact@3bird.nl](mailto:contact@3bird.nl). ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) [Home](https://3bird.nl/)/Your prototype works. That’s not the same as finished. # Your prototype works. That’s not the same as finished. It almost always goes the same way. Someone spends a few evenings building something with Lovable, Bolt, Cursor or plain ChatGPT. It works. The demo runs, the first customer is enthusiastic, and then comes the sentence that changes everything: “Can we go live with this next month?” At that moment the question shifts from “does it work?” to “will it hold?”. Those are two very different questions. ## What “it works” actually means A prototype proves one thing: that the happy path works. One user, doing exactly what you expect, with clean input, at a quiet moment, with nobody trying to break anything. Production is everything else. A hundred users at once. Someone pasting an emoji into a phone number field. A payment that fails halfway through. A bot that finds your form and hits it ten thousand times an hour. An employee who clicks the wrong button and wants you to undo it. None of that is a failing of the AI that wrote your code. It simply isn’t what you asked for. You asked for something that works, and that is what you got. ## The numbers are no longer vague Until recently this was mostly developer intuition. It isn’t anymore. Veracode tested over a hundred language models on security-sensitive coding tasks. In 45 percent of cases the generated code contained a vulnerability from the OWASP Top 10, the standard list of most common security flaws. For cross-site scripting it rose to 86 percent. More telling than the number itself: between 2025 and early 2026 it did not improve, even as the same models got measurably better at every other coding benchmark. Security firm Escape.tech scanned fourteen hundred applications built on vibe-coding platforms. They found over two thousand critical vulnerabilities, more than four hundred leaked passwords and keys, and a hundred and seventy-five cases of personal data sitting in the open: medical records, financial details, credentials. At a Fortune 50 company, Apiiro measured what happens when you scale this up. Developers working with AI assistance shipped three to four times as much code. Monthly security findings went from around a thousand to more than ten thousand. The most serious category, paths that let someone grant themselves more access than they should have, grew by 322 percent. That last figure is the interesting one. This isn’t about sloppy typos. It’s about structure, about decisions on how the system fits together, and those don’t get fixed with a quick patch. ## Why this happens, and why it makes sense A language model writing code optimises for code that runs. Not for code that holds up when someone means it harm. It has no picture of your threat model, doesn’t know your GDPR obligations, and can’t tell which of your data is sensitive. There’s a wrinkle on top of that which surprises most people. Roughly one in five times, AI-generated code refers to a software package that doesn’t exist. The model invents a plausible name. Attackers have started exploiting this: they register those invented names in advance, with malicious code inside, and wait for someone to install them. There’s a word for it now: slopsquatting. And the built-in code review those platforms offer? In practice it regularly misses the serious problems, like SQL injection, while dutifully reporting that your indentation is inconsistent. ## What sits between demo and production When we take over a vibe-coded project, this is roughly the list we work through. Not exciting, but it is the difference between a demo and a business asset. - **Secrets and keys.** API keys sit in the source code remarkably often, and not rarely in a public repository too. - **Access and permissions.** Who may see what, who may change what, and is that enforced on the server or merely hidden in the interface? - **Input validation.** Everything arriving from outside is suspect until proven otherwise. - **Dependencies.** Does every package actually exist, does it come from who you think, and is anyone maintaining it? - **Errors and logging.** What happens when something breaks, and can you reconstruct afterwards what went wrong? - **Backups and recovery.** Not whether a backup exists, but whether you have ever restored one. - **Deployment.** A manual step nobody can describe precisely is an outage waiting to happen. The good news: this is bounded work. Usually weeks, not months. And we almost never throw the prototype away. The functionality is often fine. The foundation underneath isn’t. ## Not less AI, but supervision over it Please don’t read this as an argument to stop building with AI. That speed is real, and going back would be daft. What matters is that speed without supervision hands you something that looks finished and isn’t. That’s why we put AI-Sitters on it: senior developers who direct, review and refine AI-generated code with the discipline production software demands. The AI does the typing. A human who has seen this before decides whether it ships. It costs you no pace. It does decide whether you end up with something that impresses in a demo, or something your customers can rely on. ## Sound familiar? Do you have something running that works, but you’re not quite ready to let real customers near it? A forty-five minute conversation is usually enough to establish what’s needed. We look it over, tell you honestly what we see, and if it’s already in good shape you’ll hear that too. [Book a free 45-minute call](https://calendly.com/3-bird/45min), or email [contact@3bird.nl](mailto:contact@3bird.nl). ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) [Home](https://3bird.nl/)/Scaling Engineering Teams: Hiring, Onboarding, and Culture # Scaling Engineering Teams: Hiring, Onboarding, and Culture ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) [Home](https://3bird.nl/)/React vs .NET in 2025: Choosing the Right Stack for Your Next Project # React vs .NET in 2025: Choosing the Right Stack for Your Next Project Stack selection is one of the most consequential decisions a development team makes — and one of the most frequently over-complicated. Every year the landscape shifts slightly, but the underlying decision framework for European commercial software remains remarkably stable. Here is how to think about the React vs. .NET question in 2025, without the hype. ## First, a Clarification React and .NET are not alternatives — they operate at different layers. React is a JavaScript library for building user interfaces. .NET is a cross-platform development framework for building backends, APIs, and services. Most modern applications use both. The real questions are: - **Frontend**: React, Vue, Angular, or something else? - **Backend**: .NET, Node.js, Python, Java, or Go? - **Full-stack**: What is the right pairing for your context? ## React in 2025 React remains the dominant frontend library in European commercial development. Its advantages: - Largest talent pool among JavaScript frameworks in the Netherlands and EU - Mature ecosystem (Next.js, React Query, Radix UI, Tailwind CSS) - Strong corporate backing with stable API evolution - Excellent tooling for both SPA and server-side rendering React’s disadvantages are real: JSX has a learning curve, state management choices can be overwhelming, and the ecosystem moves fast enough that senior React developers need to actively maintain their skills. **React is the right choice when** you need a rich, interactive user interface; you want access to the widest talent pool; or you’re building a product where frontend velocity is the primary constraint. ## .NET in 2025 .NET 8 and 9 have continued the framework’s transformation into a genuinely modern, cross-platform runtime. Its advantages: - Excellent performance, consistently near the top of independent benchmarks - Strong typing throughout the stack reduces runtime errors - First-class support for microservices, gRPC, and messaging architectures - Deeply familiar to the large enterprise market in the Netherlands - Strong GDPR tooling within the Microsoft/Azure ecosystem **.NET is the right choice when** you’re building for enterprise clients with existing Microsoft infrastructure; you need high-performance backend services; or you’re in a regulated industry where the Microsoft compliance story matters. ## The Common Pairing For most 3Bird clients, the optimal pairing in 2025 is **React (frontend) + .NET (backend API)**, deployed on Azure or AWS. This combination: - Maximises talent availability across Europe - Provides strong typing on both sides (TypeScript + C#) - Fits the Microsoft ecosystem that most Dutch enterprises already use - Has excellent tooling for testing, CI/CD, and compliance For startups optimising for speed and a smaller initial team, React + Node.js (TypeScript throughout) remains a strong alternative — particularly for teams that want to share code between frontend and backend. ## When Stack Doesn’t Matter as Much as You Think For most MVPs and early-stage products, the stack is less important than the team’s familiarity with it. A team that knows Django deeply will outship a team learning .NET at speed. If you have strong existing expertise, lean into it. At 3Bird, our recommendations are always contextual. We have deep expertise in React, .NET, Node.js, and Python — and we’ll be honest with you when the answer is “it doesn’t really matter, pick one and move.” The best stack is the one your team can execute on today, with a clear path to scaling it tomorrow. ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) [Home](https://3bird.nl/)/Offshore Development Pitfalls (And How 3Bird Avoids Every One) # Offshore Development Pitfalls (And How 3Bird Avoids Every One) In 25 years of combined experience building and managing offshore development teams, the same failure modes appear with depressing regularity. They are not unique to any country or culture. They are structural problems that emerge from the way offshore engagements are typically set up. Here is the definitive list — and what actually prevents each one. ## Pitfall 1: Requirements Lost in Translation **What happens.** A client shares a requirements document or Figma file. The offshore team builds what they understood, not what the client meant. The gap only becomes visible at demo time. **How we prevent it.** A European PM runs a structured requirements workshop before any sprint begins. Requirements are written as acceptance criteria — testable statements of what “done” means — not feature descriptions. Ambiguous criteria are flagged before development starts. ## Pitfall 2: The Silent Blocker **What happens.** A developer is blocked by a missing API key, an unclear requirement, or a technical dependency. Rather than escalate, they work around it — or silently wait. **How we prevent it.** Daily standups are run by the European PM, not reported via Slack. Blockers are a primary agenda item. The PM’s job is to make it psychologically safe to surface problems early — and to resolve them the same day. ## Pitfall 3: Definition of Done Drift **What happens.** Over time, the sprint definition of done degrades. Code reviews become rubber stamps. QA gates are skipped when timelines are tight. The first three sprints are excellent; sprint eight is a mess. **How we prevent it.** The definition of done is written, versioned, and reviewed in every sprint retrospective. Our PMs have authority to reject sprint completion if DoD criteria are not met — even under timeline pressure. ## Pitfall 4: Technical Debt Accumulation **What happens.** Offshore teams, under pressure to deliver features, accumulate technical debt silently. The client only discovers this when the system becomes too expensive to maintain or extend. **How we prevent it.** Our fractional CTOs conduct quarterly technical health reviews. A technical debt register is maintained and shared with the client. A minimum of 20% of sprint capacity is reserved for debt reduction on engagements longer than three months. ## Pitfall 5: Key Person Dependency **What happens.** One developer becomes the sole owner of a critical system component. When they leave or rotate, knowledge walks out the door. **How we prevent it.** Documentation is a sprint deliverable, not an afterthought. All significant components require at least two engineers to have worked on them within a quarter. Architecture Decision Records capture the reasoning behind key decisions. ## Pitfall 6: Timezone Friction **What happens.** The 4–5 hour timezone difference between Europe and South/Southeast Asia means that questions asked in the afternoon Amsterdam time don’t get answered until the next day. Over months, this compounds into significant lost velocity. **How we prevent it.** Our Nepal-based teams overlap Amsterdam business hours from 09:00–13:00 CET. The European PM is available during full Amsterdam business hours. Critical decisions are never left to async. Every pitfall on this list is avoidable. None of them are inevitable consequences of offshore development. They are consequences of offshore development without investment in process and oversight. That investment is what 3Bird is. ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) [Home](https://3bird.nl/)/Why AI-Generated Code Still Needs Human QA (And Always Will) # Why AI-Generated Code Still Needs Human QA (And Always Will) Every few months, a new benchmark appears showing AI models achieving near-human performance on coding challenges. Every few weeks, a developer posts about shipping a feature entirely with AI assistance. The narrative of “AI replacing developers” has become a recurring theme. It is also, at present, wrong — and dangerously so for anyone building production systems. ## What AI Is Excellent At To be credible about AI’s limitations, we should be honest about its genuine strengths: - Generating boilerplate and scaffolding at high speed - Translating well-specified requirements into working code - Refactoring isolated functions with clear inputs and outputs - Writing documentation from existing code - Generating test cases for known-good requirements For these tasks, AI coding tools are genuinely transformative. A good AI-Sitter can move 3–10× faster than traditional development on these categories of work. ## What AI Consistently Gets Wrong **Security vulnerabilities.** AI models are trained on the internet, which includes a lot of insecure code. SQL injection, XSS, CSRF, insecure direct object references, and hardcoded secrets appear in AI-generated code with uncomfortable frequency. Security review is not optional. **Edge cases in business logic.** AI generates code that satisfies the stated requirements. It does not generate code that handles the requirements you forgot to state. A human reviewer who understands the business domain catches these gaps; AI does not. **Architectural coherence.** AI generates at the file or function level. It does not maintain a model of the entire system. The result is code that is locally correct but globally incoherent — duplicated logic, inconsistent patterns, circular dependencies that emerge only when the system is assembled. **Compliance requirements.** GDPR, accessibility, licence compatibility, and sector-specific regulations require human judgment. AI models do not reliably produce GDPR-compliant code without explicit instruction — and even with instruction, human verification is required. ## The Human QA Layer At 3Bird AI Lab, every generated module passes through: - A senior engineer review for correctness, security, and architecture - Automated test suite execution - Manual QA for business logic and user experience - A compliance check for GDPR and licence requirements This is not a box-ticking exercise. It is the reason our AI Lab output is production-quality rather than prototype-quality. The AI provides the speed. The human layer provides the quality. Neither replaces the other. Both are required — and any product team that skips the human layer in the name of speed will eventually pay for that decision in production. ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) --- Book a free 30-minute consultation: https://calendly.com/3-bird/3bird-oscar-30-minuten-meet Email: contact@3bird.nl | Phone: +31757993038