Last year, we published a detailed introduction to Picnic on The Global Move. Picnic is one of Europe’s largest online supermarkets, operating across multiple European markets with an engineering organization of around 400 people working across software, data, ML, robotics and supply-chain technology.
This time, I talked with Picnic CTO Daniel Gebler about how AI is changing engineering inside the company, where the bottlenecks are moving, and what this means for the engineers Picnic wants to hire.
When I asked Daniel why Picnic is still hiring engineers while AI is making them more productive, he corrected the premise of my question:
We’re not hiring despite AI. We’re hiring because of the edge AI gives us.
This article is about what happens to software engineers when writing code is no longer the main constraint.
At Picnic, AI already helps engineers write and review code, prototype ideas and run more experiments. But one of the interesting things they learned is that producing more code and making more releases doesn’t necessarily create more value. As one bottleneck disappears, another one shows up.
At the same time, AI allows Picnic to work on problems they couldn’t justify spending engineering time on before, as well as much bigger technical challenges.
Daniel is optimistic about where engineering is going, but the job is clearly changing. So we also tried to make this interview useful as a guide: what a Product Engineer looks like in 2026, which skills are becoming more important, how Picnic is changing its interviews, and how engineers can prepare.
Plus some behind-the-scenes detail: why 25 million of Picnic’s 50 million lines of code were written by analysts rather than engineers, why they pulled back on AI-driven release velocity, and why Daniel thinks 10x more experiments is worth far more than 10x more releases.
Everybody calls itself an AI company these days. And the reality is that everybody is using AI tools in a significant way.
But an AI operating model is different. It means changing the way you build your products, your software stack and the way you run your operations. Everyone is basically in a transition phase right now. The reason I call it a transition phase is that the North Star of what it means to be fully AI-transformed is a moving target.
The North Star from a year ago is totally different from where we are now. And if you look forward, the way we build products and how we run our business will change even more in the coming years.
One thing that makes me really excited to be in software engineering is that a few years ago there was this narrative that nobody would need software engineers any longer. Software engineering was basically a done deal because coding would no longer be the limiting factor.
There is some truth in the second part. Pure implementation tasks, where you have a fully fledged specification and need to translate it into code, are something AI coding tools can already do really well. But there is so much more that software engineering needs to do. I think the role of a software engineer has become wider and broader, and actually even more exciting.
I can’t really relate to the line of thinking that everything was better when we didn’t have AI coding tools and that these tools are just creating slop.
Historically, we had a world that was split relatively clearly between engineers and non-engineers. There was a relatively small group of people who could build software and a much larger group that couldn’t.
That boundary is now becoming much more of a spectrum. While, until now, we had around 50 million software engineers worldwide, we are moving towards a new reality where hundreds of millions or maybe even a billion people are able to design, build and run software products.
That doesn’t mean everyone becomes the same type of engineer. There will still be hardcore platform engineering. There will be Product Engineers. There will be people prototyping things and people building smaller tools at the edge of a product portfolio. These are very different forms of engineering.
But the boundary between who can and cannot create software is becoming much more fluid.
In fact, all our engineering flows have changed. The degree of change is just very different between workflows.
Classical feature implementation has changed massively. We have started systematically setting up AI factories. We have moved our engineering process towards loop engineering, trained a large part of the organization to work this way, and thought about new onboarding programs to bring engineers coming from university into these loops as quickly as possible.
What hasn’t changed much is software design thinking. If you have a business challenge you’re trying to solve, you still need to think about the components of the solution and the concepts you want to model. At least for now, this is still to a large extent an engineering task that you cannot simply outsource to a tool.
If you’re building a new functionality and specify the requirements in enough detail, a coding assistant can give you a pretty decent solution. But a feature is only the beginning. At Picnic, a feature typically goes through 7 to 10 iterations to reach product-market fit, and another 10 to reach product-scale fit.
That means we can actually be slower in the beginning. We’re looking for the fundamental solution that allows us to become much faster in phases 2 and 3.
This comes partly from the fact that Picnic is a software and hardware company at the same time. We build an e-commerce app, but we also build robotics and automation solutions for warehouses and operate a large physical supply chain.
You can iterate much more slowly in physical operations. You cannot easily refactor a building, and you cannot refactor a robot in a short amount of time. A lot of our thinking has therefore been about moving as much hardware logic as possible into the software stack. The automotive industry went through a similar shift when cars increasingly became products that could improve through software upgrades. We are making a similar shift in supply chain, robotics and fulfillment.
We measure pull requests, features, lead-time and releases on a regular basis, and we’ve seen significant improvements, especially in pull requests (+18% in avg) and lead-time (-35%) per engineer, team and product.
The increase is not as drastic as some AI companies report. That is intentional: making twice as many releases doesn’t mean you create twice as much value.
This sounds obvious, but we can actually observe it very quickly. Customers visit our store at least once a week, many of them multiple times per week, and we have millions of customer interactions. With every release, we get feedback very quickly.
What we’ve seen is that if you push too hard on purely increasing the number of releases or pull requests without putting enough effort into the steps before that, thinking about what should be built, then there is no value in those releases.
But at some point we pulled the handbrake because the value we were creating wasn’t increasing at the same rate. So now we’re using more AI tools for prototyping and design.
The real value isn’t making more releases. The real value is making better releases.
The world has enough apps. Most companies have enough releases. The major transition toward regular daily or weekly releases already happened with Agile, continuous integration and continuous delivery. The opportunity now is to dramatically accelerate how many things you can test before deciding what deserves to become a product.
We have built a prototyping pipeline where we can run many experiments on small sets of customers and evaluate them efficiently. If we’re running multiple A/B tests, we can make sure those groups don’t overlap and create a much more efficient evaluation cycle.
Our goal is to get another 2x, 5x or 10x in those kinds of experiments. That is probably the biggest lever we see.
There is another layer to this. Our technology stack is currently around 50 million lines of code, organized in roughly 100 services around our shopping app, logistical planning, supply chain operations and robotic picking.
What stands out is that nearly 20 million lines of code have been built by analysts. In other words, our technically minded analysts contribute to our system stack as edge developers.
They are developing smaller satellite tools that are enormously valuable. For instance, it might be a tailored service for one particular city, an optimization of a specific flow in a warehouse, or something needed only for a specific group of customers.
In the past, these are exactly the kinds of problems where engineering economics mattered enormously. Something can be useful without being useful enough to justify putting scarce Software Engineering capacity behind it.
AI changes that equation. AI tools allow edge developers to build these kinds of solutions much faster and with less effort.
At the same time, we have a platform approach around them. If something created at the edge becomes relevant for many customers, or for a large part of the operations, we migrate it from the edge into the core product.
So experimentation doesn’t only happen inside the tech and engineering organization. It is our native way of working across all of Picnic where as a result small high-value point solutions emerge if there is a promising customer case or business value attached to it and over time graduates to become part of the overall Picnic Platform if it proves to be useful for everyone.
If implementation gets cheaper, where does the bottleneck move?
If you look at engineering as a sequential process, you start with figuring out a customer need, translating that into a solution direction, defining requirements and designing the solution. Then you have implementation, review, rollout, scaling and operation.
Pure implementation has obviously become much faster. Historically, when we did business planning, one of the limiting factors was simply how many engineering hours we had available in a quarter. Which ideas could we actually build with the engineering capacity available?
Over the last year, that constraint has started to change. As implementation gets dramatically cheaper, the bottleneck has started moving from pure implementation toward review capacity.
Take a simplified example. If implementation takes ten hours, reviewing and iterating around that implementation might take another eight. You have 18 hours in total. If most of those ten implementation hours disappear, the eight hours of review remain.
So the next question becomes how to make review more efficient.
We have set up AI review tools as well. Our current approach is to do the implementation with Claude and the review with Codex. Essentially, we check our code through another LLM than it was built.
That works pretty well for us. It is definitely not the cheapest approach, but we’re happy with it.
But the transition goes further than review.
Pure functional engineering is becoming very fast and, to some extent, can be automated with AI tools. The non-functional side of engineering, including scalability, security, resilience, robotics integrations and other system properties, remains much more context-specific.
Getting a piece of software to function according to a sufficiently detailed specification is something an AI system can do very well. But a production system has to do much more than function. It needs to scale. It needs to survive failures. It needs to be secure. It needs to interact with other systems. And in our case, sometimes it needs to interact with robots, warehouses and physical operations.
These properties depend heavily on context.
For an AI tool to work with context, you need to be able to serialize or codify that context. Most organizations, including Picnic to some extent, have a lot of context that exists as communal knowledge. It’s in people’s heads. It’s part of how you work. It was never documented, and in some cases there is no realistic way to document it precisely enough.
That kind of context is still an area where humans have a huge advantage.
This is particularly important when you’re building systems connected to physical operations. In robotics, for example, you cannot assume that every individual component will always behave correctly. You need to design the whole system around failure and resilience.
When we started Picnic in 2015 software engineering looked very different: A Software Engineers took a specification and wrote a well-crafted piece of code: easy to extend, low technical debt, scalable, resilient and without security flaws.
We still expect that, but we also know that a lot of this can now be done with AI coding tools.
The major shift we’re going through is from Software Engineering (i.e. focus on crafting code) to Product Engineering (i.e. focus on designing systems). Engineers need to capture a large part of what was traditionally the Product Owner’s responsibility: translating a business problem or requirement into a solution.
Initially, that was a little scary for some engineers. It brought them much closer to the business, and this translation work was new to them. But I’ve never seen so many excited engineers.
When working with the teams you can clearly feel the energy that is unlocked when you are moving from Software Engineering to Product Engineering.
The biggest difference is ownership and pride in what you’re building. A traditional Software Engineer could be proud of the software that was deployed, that there was no incident, that nobody complained that it didn’t scale, and the system worked.
A Product Engineer can meet a customer who says: “This is a cool new feature. I used it three times yesterday and I’ll use it even more today.” You can directly contribute to the success of the business.
Andrew: I see this shift elsewhere too. Even here on Substack, when its Software Engineers record a short video themselves to introduce a feature they’ve built directly to the platform’s users. The distance between the person writing the software and the person actually using it seems to be getting shorter.
The industry has talked for a long time about technology not being a cost center and engineering creating real lasting value. Everybody agreed with that idea, but in reality, many organizations still treated engineering like a cost center.
I think the old vision behind the Agile Manifesto from 25 years ago is finally becoming real through the move from Software Engineers to Product Engineers with AI tools.
It also means more responsibility. If everyone has increasingly powerful engineering tools, everyone needs to understand much better what they’re actually building. Organizations have historically had a lot of narrow, siloed thinking. AI pushes in the opposite direction.
Boris Cherny from Anthropic has described work through 5 archetypes connected to different stages of a product’s lifecycle rather than simply traditional functional titles.
We are increasingly thinking about teams through the lifecycle of what they’re building. There are moonshot prototype ideas and people working on them. Other people take ideas into scale. Others grow them. And eventually there are teams cleaning things up and sunsetting things that are no longer needed.
The organization starts following the lifecycle of the product itself.
We are not hiring despite the AI age. We are hiring because of the AI advantage.
The potential of what we can do with Picnic at the interface between physical and digital becomes much bigger with AI.
You can see this through two lenses. The first is that we can tackle much bigger problems than before. One of our big ambitions, for example, is working towards a highly autonomous supply chain: from logistics, to picking, to delivery at the doorstep of the customer, running as close to fully autonomously as possible.
That is a class of challenge that would not have been possible to tackle without AI engineering and AI engineering tools.
But the other side is just as interesting. Because AI engineering tools allow us to build solutions more efficiently, we can work on much smaller ideas that still have an impact at scale.
In the old world, engineering was always a bottleneck and was expensive. There were many ideas where you simply couldn’t make the business case because the cost of engineering the solution was too high.
AI changes the economics of that long tail. When the cost of producing a solution becomes low enough, a huge set of smaller opportunities becomes worth capturing.
These can actually be beautiful engineering problems. Long-tail solutions often need to be very well crafted because otherwise the economics doesn’t work.
So AI expands engineering in both directions. We can work on much bigger ambitions that previously weren’t technically realistic, while solving much smaller problems that previously weren’t economically realistic.
That gives us more reasons to hire engineers, not fewer.
Recruitment is probably one of the disciplines that has changed most dramatically.
We historically had a process similar to many large technology companies: CV screening, a screening call, take-home assignments and then on-site interviews.
One thing has become very clear: asynchronous technical evaluation has very little value now. If you give somebody an assignment to complete at home and send the solution back, they can create a very good solution using modern AI tools.
And we don’t want to prohibit people from using these tools. They should use them. So the question becomes: how do you evaluate whether someone is fit for the way engineering is changing?
Nobody actually knows exactly what AI engineering will look like in a year. We know roughly how it works now, and we’re working very hard to keep up with it, but the workflow will continue changing.
There are nevertheless some underlying principles. As an engineer working with AI today, you increasingly do two important things.
First, you specify what the AI tool should do. You define problems and guide the engineering process. Second, you evaluate, review and give feedback on what the tools produce.
We now evaluate these things in face-to-face sessions. We look at whether someone can work effectively with the current generation of AI tools, but also how open and flexible they are to evolving that way of working further.
Some of what engineers do manually today will probably be taken over by AI too. Prompt writing may change. Parts of evaluation may change. Parts of what we currently call judgment may change.
If you imagine engineering as a large cycle, AI is gradually taking over more of the center. That makes the things on the outside of the cycle more important: designing solutions, deploying them, operating software and understanding the system as a whole.
If I had to summarize the most important skill for an engineer going forward, it would probably be systems thinking in all its facets.
Engineers need to be able to reason systematically and analytically about existing systems, truly understand new problems, and design solutions that fit the target architecture while creating a foundation for future capabilities (even when the longer-term direction is only partly known). That remains a core part of engineering.
And when we interview someone, we’re interested not only in the final answer. We want to understand how you reason over the code and how you arrive at your judgment.
We see a lot of AI-polished resumes now. They become very clinical: tech stack, percentages, performance improved by 98%. Probably because everyone has been told that a good resume needs numbers.
But we’re people too. We look at those numbers realistically.
What we’re trying to understand is what you actually changed in your previous role. Maybe you improved something for the end user, brought an idea, owned a project, or spotted a problem and didn’t just flag it, but took ownership and solved it. It doesn’t have to be a 20% revenue increase. It can be something you changed for your team, product or customer.
If you owned a feature or flow end to end, that’s one signal. If you worked with suppliers, warehouse teams or other non-technical parts of the business, that’s another, because you’ve had to think about where your system meets the rest of the company.
Another thing worth knowing about Picnic: every resume is still reviewed by a person. We don’t have automatic rejection. So there isn’t much value in over-optimizing your resume. Make it accurate and human.
Sometimes candidates apply to the same position again and get rejected again, and assume it must be an auto-rejection. Usually, not enough has changed in their experience for us to make a different decision. Apply again when there has been some meaningful change in your experience or skills, not every month.
We also actively look for engineers on LinkedIn. So one way to meet a Picnic recruiter is simply to have a profile that helps us find you.
Keep your current role, employment dates and main areas of expertise up to date.
When you apply directly to Picnic, your resume is still the main thing we look at. But we may also check LinkedIn, and conflicting information between the two can create unnecessary confusion.
LinkedIn doesn’t need to be a copy of your resume. You can use it to add another angle: projects you’re interested in, technologies you’re exploring, the kind of engineering problems you enjoy.
Even early in your career you definitely have interesting things to show: what you study, what side projects you work on (university projects too), what internships you do, your grades, international scores or other achievements that show your continuous ambition to do something more.
GitHub is nice to have. It’s definitely not a must-have.
It becomes more interesting when it tells us something we wouldn’t otherwise know about you. Maybe you want to learn a technology that you don’t get to use at work, so you build something yourself. Maybe your growth at your current company has slowed down, but you’re still experimenting and learning outside of it.
Open source can be especially interesting because it shows what you’re curious about and where you choose to spend your time. Meaningful contributions can help you stand out.
But GitHub for the sake of having GitHub doesn’t change much. And if the rest of the application is generic and everything looks generated, an open-source project isn’t suddenly going to change our whole impression.
A cover letter is optional. Please don’t add one just because you think you’re supposed to.
It becomes useful when there is something we cannot understand from your resume. Maybe your last role ended a year ago and it’s not clear what you’ve been doing since. Maybe your profile doesn’t quite match the vacancy, but you have a good reason why you think you’re a strong fit. Or maybe there is something in your experience that connects particularly well with what Picnic is building.
We actually read cover letters, so this context can help.
How can someone demonstrate product ownership rather than simply implementation experience?
We want to see that you understand why you’re building something, not only how you built it.
Think about the end user. That might be an external customer or somebody inside the company. Did you understand what they were trying to achieve? Did you make suggestions? Did you have an opinion about the technology or product? Did you question the status-quo instead of simply implementing the solution you were given?
Maybe you spotted a problem yourself, took ownership and solved it instead of just flagging it to somebody else. That tells us much more about product ownership than simply saying you implemented a feature. Show us that you can think it through!
We see candidates from all over the world, and sometimes the company they worked for is well known in their market but completely unfamiliar to us. That’s not a problem.
Whether it’s an unknown company in Singapore, a small startup in the UK, or a large corporation in Latin America, zoom out before going into the technical details. What does the product do? Who uses it? What was the goal? And where did your work fit into that?
You don’t need a famous company name. Give us enough context to understand what you were building and how it makes it relevant for the role you’re applying at Picnic now.
Yes, of course.
But we’re not looking for one particular AI tool that everyone has to know. Even inside Picnic, different teams use AI differently, and the whole industry is still figuring out these workflows.
What we want to see is that you’re moving with that change. Are you using AI in your work? Are you learning? Have you changed the way you work compared with a year or two ago? It can be coding with AI or using it somewhere else in your workflow. The exact tool is less important.
What we want to see is that you’re moving with that change. Are you using AI in your work? Are you learning? Have you changed the way you work compared with a year or two ago? It can be coding with AI or using it somewhere else in your workflow. The exact tool is less important than the reasoning behind it: why did you choose this tool or approach over another one?
We are changing how we work at Picnic, and we want to see that candidates can change how they work too. Being able to adapt to what is happening in your company and in the industry is probably the most important AI signal we’re looking for right now.
I still think a solid academic education is very beneficial. For the core implementation tasks it is maybe a bit less essential now, but for real product engineering it is becoming essential in many ways, so I’m still a big fan of it.
The interesting part of this transition is that nobody knows how the final AI engineering model looks like. Some things engineers are doing today will probably be automated tomorrow. The boundary between engineering, product and other roles will continue changing, and the way we evaluate engineers will have to change with it.
What is already clear is that making implementation cheaper doesn’t remove engineering problems. It changes which problems are worth solving and where engineers create value.
Lenny’s Podcast: How to scale products and teams.
The Coming Wave by Mustafa Suleyman: Tech, risk and responsibility.
Cognitive Revolution Podcast : On the frontier of AI.
Picnic’s Engineering Blog : How Picnic’s engineering teams build and operate technology.
Anthropic Engineering: Probably the strongest practical source of agentic engineering today.
Exploring Generative AI by Martin Fowler: How to start applying generative AI in real software organisations.
Latent Space Podcast: It goes deep on agents, developer tools, model infrastructure, inference economics and the emerging AI engineering discipline.
One Useful Thing by Ethan Mollick: Particularly interesting for leaders. Explaining how individuals, teams and organisations should actually work with AI (and why adoption is fundamentally a management and operating-model challenge.)
I hope you enjoyed the conversation and that it gives you a positive signal about where software engineering is heading. At least at Picnic, the story isn’t that AI makes engineers unnecessary. As Daniel put it, they are hiring because of AI, not despite it.
What does this mean for you? If you’re open to relocating to Amsterdam, Picnic is definitely worth checking out. The engineering team is international, English is enough for all tech roles, and Picnic supports international hires with relocation to the Netherlands.
A quick favor: if you enjoyed this episode and this format, which is new for me but very exciting to explore, send me a quick message with your feedback. I’d love to know what worked and what you’d like to see more of.
P.S. If you’d like me to cover engineering and hiring with your engineering leadership in one of my next articles, send me a quick message at andrew {at} relocate.me.