How Blacklane Built an AI-Native Engineering Organisation
June 1, 2026
When you speak with the CTO of a company navigating a major acquisition while simultaneously running one of the more mature enterprise AI transformations in the European tech sector, you expect a certain composure. What you might not expect is the sheer candour about what worked, what did not, and the quiet admission that even senior leaders are still working out what the next decade looks like, for their businesses and for their children.
This conversation with Dirk Daumann, CTO at Blacklane, the global chauffeur service recently agreed to be acquired by Uber, covers the full arc of an AI transformation: the governance challenge that came first, the four-area framework they built to structure it, the surprising role that an enterprise search tool played in unlocking company-wide adoption, and a clear-eyed view of how product and engineering roles are likely to merge.
Blacklane's journey with AI did not begin with a strategy deck. It began organically, as it did in most organisations, with individuals.
"It started with individuals just adopting single use case AI tools or foundation models like ChatGPT on their own, sometimes on their personal subscriptions, to draft and summarise documents, emails, etc. We addressed this first by giving them secure access to a wide variety of self-hosted LLMs behind an LLM proxy, so confidential data wasn't leaving the company or training a foundational model. But pretty quickly it became clear that the real value for our people was not using foundational models trained on public data only, it was the foundational models combined with our company knowledge: emails, Google Docs, all of it. So a RAG needed to be put in place."
Tool selection became its own significant workstream. Questions around EU AI Act compliance, data hosting location, access restriction within LLM-connected tools, and the shadow procurement risk of teams signing up independently for AI tools or AI add-ons to existing SaaS tools required dedicated attention.
"Governing that, right, not that everybody just signs up for any random AI tool, was needed to not just ensure compliance with EU AI Act and data privacy but also actually create value with AI. Our take was early on to provide a platform instead of single use AI tools on top of existing SaaS tools.”
This is a pattern that comes up consistently across the organisations we have spoken with for Signal 2026: governance is a core part of an AI strategy. The instinct to reach for tools is human; the discipline to establish what is and is not acceptable and actually valuable before those tools proliferate is where the work begins. For Blacklane, that meant deciding on platform vs single use tools early on and establishing an AI policy, acceptable use guidelines, and a framework for evaluating use cases before committing to build them.
Blacklane structured its AI programme around four distinct domains: Workspace, Engineering, Product, and Operations. Each was treated separately, with different approaches, maturity curves, different tooling, and different expectations about what success looked like. A small central AI team was established to act as an internal hands-on consulting, enablement and governance function rather than a sole delivery team. Their mission was to transition Blacklane to an AI-First company by leveraging genAI technology safely and effectively. Their remit was tool selection and governance, proof-of-concept evaluation, delivering AI training for all employees and building community programmes to drive adoption and new ways of working in all departments. The team was built from internal volunteers who raised their hands, combined with a small number of targeted external hires with AI application engineering backgrounds, and supported by external specialists.
"We created an initial strategy and charter for this team, announced it and then we had a number of very passionate people that moved into this role and took it from there. Our AI team is one of the most impactful teams in Blacklane in the last 12 months."
The four areas played out differently in practice.
Engineering showed naturally strong adoption moving from code pilot to assisted coding and, ultimately, produced the clearest returns. The journey tracked what many engineering organisations have experienced: Copilot for code completion, Cursor as an intermediate step, then Claude Code as what Dirk describes as "probably the biggest step change". Today, some engineers run multiple parallel agents on Claude Code simultaneously. By now, 100% of pull requests involve some form of assisted coding.
"We are now transitioning the complete software development lifecycle onto Claude Code, using agentic workflows. In Product Management, Design, etc."
Workplace, the company-wide layer, delivered what he considers one of the highest-impact interventions: deploying an enterprise AI platform called Glean, which connects language models to the company's knowledge base across Google Drive, Slack, Jira, Salesforce, Snowflake, and other tools. It also provides the possibility to build agents and automate some of their workflows in natural language, also as a non-tech person. With over 300 employees and approximately 330 weekly and 250 daily active users, the adoption rate is striking.
"People really use it daily. That is a game changer."
The ability to access internal knowledge and reason over it has materially changed the way Blacklane works. Information retrieval at every level changed completely.
"Who implemented this functionality and when in the app, how does this work, what did this team work on last week. I do not need to have a human proxy to get this information but actually focus on collaborating with people on business problems."
This also meant roles changed. Instead of manually crafting documents for information updates, Glean provides the means to access any information.
"Glean-it became the new term in Blacklane. As a fun project we even built a page ‘Let me Glean that for you’. It’s for all people who find it more convenient to bother you with their question rather than ask Glean. If someone gets a question they input the question in the tool, then send them the link back with the answer from Glean."
Product was where AI moved from internal productivity tool to something guests and chauffeurs experience directly, in the form of a new UX layer, and the surface area is broader than a single feature. The most obvious is guest support and self-service, where an AI assistant pre-answers and triages chats and now handles common booking actions end-to-end: confirmations, cancellations, edits. The numbers are material: AI involvement has improved CSAT by roughly 10 points since rollout. For edits specifically, around a third of edit-related contacts are now swiftly and fully resolved by the AI bot ensuring the guest resolution is fast and frictionless. In parallel, further applications of AI bot and voice initiatives are being explored for the chauffeur partner dedicated support function at Blacklane. The behind-the-scenes AI sits within Blacklane's marketplace. Demand forecasting and price-adjusted forecasting are first-party ML models that sit in the core of the platform, optimising supply sourcing. Dispatch optimisation is being used to improve already high standards of pickup reliability and reduce rejections.
"This is really at the core of our business and helps us continuously improve the luxury experience we stand for as a brand."
The bigger product bet looking to the longer-term future is in how AI supports concierge-level service across the entire journey.
"The idea is to stop thinking about AI as a support add-on bolted onto the side of the product," Dirk notes. "It becomes the way guests interact with us, end to end."
The candid bit, he is quick to add, is that not every product bet has been a clean win. The AI chat was initially built on a third-party solution and helped us prove that guests welcome self-serve when the experience is fast and reliable, but the non-native UI created a brand gap that did not hold up to our standards, which is part of what is driving the move toward an owned concierge experience.
Operations proved the most promising but also the hardest.
"Being a service-focused business, we have quite an operational heart and identified a number of use cases early on, ran POCs, and quickly realised there were a few conditions that may not yet be met that make this really hard to scale and get the operational efficiency out of it."
Some initiatives really provided the expected value and drove efficiencies, eliminated arduous operational processes completely or helped to rethink ways of working. Some also simply failed. One example stood out: a manual process performed by few people was identified as a candidate for AI automation, but the implementation and compliance with the EU AI Act made it uneconomical.
"The whole implementation is so complex and, in the end, needs a human in the loop. To comply with the EU AI Act would cost us much more to automate this, it would never pay back. Just let the humans do it. It is fine."
This kind of disciplined abandonment is, in practice, one of the harder organisational behaviours to develop.
As Blacklane saw strong adoption in Engineering with Claude Code, one of the more striking questions arose: why not extend Claude Code across the complete SDLC - product requirements documents, RFCs, epic breakdowns, etc? Dirk built an agent to review PRDs and RFCs submitted by his team to get the TL;DR of those documents and also critique and provide feedback and found that it consistently identified improvements and alternative viewpoints that had not been considered. The response was not to continue using the agent as a reviewer, but to flip the process entirely.
"Why do we not just use it to write the PRD in the first place? We can flip the thinking – instead of the PM writing a draft and refining it with AI, why not draft with AI and refine it by challenging it as a PM... Actually, Claude becomes your colleague to challenge you on your thought process - but you get a much more complete picture. And then you can pump that into the engineering agent, the builder agent, and it gets a more complete picture as well. The iterations, edge cases, decisions taken are all in there."
The downstream effect is a meaningful reduction in the back-and-forth between engineering and product that typically consumes weeks of elapsed time during development cycles. The PRD becomes not just a requirements document but effectively the initial prompt for an agentic build process.
The logical extension of this is now in motion at Blacklane. Product managers are being brought onto Claude Code, using a set of sub-agents to handle product strategy, PRDs, UX prototypes, ticket breakdown, analytics, etc. to do the classical "PO" tasks that currently sit with PMs and senior engineers. The future ambition is a complete agentic software development lifecycle, from strategic intent to deployed feature, with human review at key decision points rather than at every step. The agents integrate with a number of MCPs with clear guardrails on their role and scope.
When asked about resistance to AI adoption within engineering, Dirk pushed back on the assumption that it maps cleanly to seniority or function.
"It is more personality. People that are curious and open to change, some people are just like rockets and really curious about the topic. They share and discover new ways of working constantly, and it is really exciting to see. You clearly see productivity gains on those people. And some are more reluctant and do not know how to approach this topic. Bottom line, becoming AI first requires re-wiring your brain to change how you work and approach your day to day tasks. Not just in engineering but across the board. It is not unusual to see quite a few people struggling with this to be honest."
The change adoption curve is real, and at Blacklane it was managed through community rather than mandate. Early adopters showcased their workflows, a chapter-style community of practice was established to share best practices, MCP server configurations and agent designs circulated through the organisation, and the rest followed. The few who did not engage remain a minority. The identity dimension, the question of what their role actually is now, proved to be a topic in many roles.
"Especially less technical people. Some clearly see a path forward; roles are changing but there is still a purpose for me. And some are more in a place of pessimism, thinking I will not have a job anymore."
Dirk attributes some of this anxiety to the volume of media coverage on the topic, a point worth sitting with. The signal-to-noise ratio in AI discourse is genuinely poor, and leaders who have not yet built direct experience with the tools are disproportionately exposed to the noise.
The interview process at Blacklane has been redesigned. Classical coding assessments have been removed. Candidates are now required to use assisted coding tools as part of the process, and the evaluation criteria have shifted accordingly.
"We are more looking for product-focused engineers. Because the coding is becoming less important. We adopted interview process to be based on assisted coding, so we can have a meaningful conversation about system design, challenging the output of AI, see critical thinking signals…”
The broader view on the future shape of teams was characteristically honest about its uncertainty, but directionally confident. Roles are changing. Dirk, as CTO, can imagine possible scenarios where classical product owner tasks and engineering converge into a single function, while product managers will focus more on the strategy and identifying investment areas.
"We are probably moving into a prototype-first model, where you create a prototype as an artefact with options, show the stakeholder, and iterate. The planning and design phase before is completely changing."
Teams may not be dramatically smaller, he argues, but they will be more focused and more independent. More teams, fewer people per team, less coordination overhead between them.
Asked what excites him most about where AI is heading, Dirk points not to a specific technology but to the compounding freedom it creates.
"We can improve our product, build features in a much faster way, and experiment with things. And that is kind of addictive."
He offered a vivid illustration: exploring a new feature that has been in discussion for a while. Using the subagents, he went from framing the problem to a working prototype in a day. In another instance, a 300-slide knowledge download presentation was built in two days using Claude Design.
"You are not writing documents anymore or filling boxes in PowerPoint anymore. Here is an idea, build me a prototype or here is what Glean says about this topic, build me a slide, and you get the slide. All this annoying work is gone. You can just focus on the topic and outcome. That is the addictive part."
On the 10 to 15 year question, the composure gave way briefly to something more candid.
"I am slightly concerned about it.”
The concern is not purely professional. Like many of the leaders we have spoken with for this report, his thoughts moved quickly to his children, and what they should be investing their time and energy in learning, in a world where even the question of what software engineering means is in flux.
“The speed that we are moving creates such a huge level of ambiguity. It is really hard to say what things look like in 10 or 15 years."
The conclusion he lands on is historical rather than predictive:
"There have been many revolutions over hundreds of years. There is always change and there is always a solution. There are new roles emerging, new jobs emerging. There is always a place for human brilliance somewhere."
It is not a triumphant answer, but it is an honest one.
For CTOs and senior engineering leaders earlier in this journey, there is a rough recipe here worth extracting. Segment the problem: workspace, engineering, product, and operations have different adoption dynamics and different ROI timelines. Build a central team whose job is to enable rather than build. Let early adopters lead community formation rather than trying to mandate adoption from the top. Accept that some use cases will fail and that stopping them early is the right outcome. Pay attention to governance, because the governance questions do not get easier once tools are in use. And redesign how you hire, because the skills that made a great engineer three years ago are not the same skills that make a great engineer now.
The mindset shift, from using AI as an add-on to being AI-first in how you approach problems, is ultimately the hardest and most important change. Everything else is tooling.
"If you really want to advance on the maturity curve, you need to change your mindset about how you approach work on a day-to-day basis."
Join our newsletter and stay ahead!