Across industries, the conversation around Artificial Intelligence has changed. The question is no longer whether AI will influence the way we work, but how organizations can turn its potential into real, measurable outcomes. At Blip, we've approached this shift as an opportunity to rethink how we solve problems, make decisions and create value. That shift requires more than access to tools; it requires intentional space for experimentation and learning.
This mindset has shaped several internal initiatives over the past few months. From knowledge sharing sessions, to custom training programs, we’ve been creating moments for teams to explore and experiment with these new technologies hands-on, while openly discussing both the possibilities and the challenges they bring.
As we reflect on what we’ve learned so far, one thing is clear: today is the most critical (perhaps the only) moment to act on AI. We must keep pace, continue learning every day and begin reshaping how we work. The cost of waiting is not staying still — it is arriving late to a race that will not slow down for anyone.
Our Approach to AI
As we've started integrating AI into our work, our approach has been deliberate, but not in a top-down, mandate-driven way. We’ve made a conscious choice to treat this first phase for what it is: a learning and adoption phase. That means giving teams the tools and the freedom to experiment without pressure to justify every hour spent or every token used. The question we are asking right now is not what is the ROI of this? It is do our people understand what this technology can do, and are they getting better at using it?
The role of leadership has been less about directing and more about creating the right conditions, specifically for that turning point moment where someone uses an AI tool and thinks, genuinely, this works. Once that happens, there is no going back. That means investing in dedicated AI weeks where teams share what they have tried, hear from engineers and business leaders at the major AI vendors, and see real use cases from peers. Not lectures. Shared experiences that make the technology feel real and worth acting on.
To make sure learning scales beyond events, we put two things in place: a network of AI champions embedded in each team to multiply impact and keep knowledge flowing, and a maturity framework that gives every team a clear picture of where they are and what the next step looks like. Not a scorecard to report upward, but a practical tool for teams to navigate their own progress. We are past the point of convincing people this matters. The foundation is in place. The question of whether AI is worth engaging with seriously has been answered. Now the real work begins.
Early Impact: What Has Already Changed
The impact is not something we are waiting for. It is already here. The most visible change is in what we are shipping. Velocity is increasing month over month, but the more interesting shift is in what is getting done. Work that lived on the shelf for years — legacy migrations, technical debt that was always important but never urgent enough, upgrades we kept deferring because slowing down felt too costly — is finally moving. We are delivering more initiatives than last year, while simultaneously tackling the foundational work we never had capacity for before. Those two things rarely happen at the same time. Now they do.
On the strategic side, initiatives that used to span many months are being cut significantly, allowing us to anticipate important milestones. As teams get increasingly comfortable with AI and start investing more effort upfront, the pace keeps improving. That is not a projection. We are seeing it now.
But the change is not limited to engineering output. It runs across every role. The way we analyze data, prepare for meetings, write and communicate across teams — all of it has changed. People have built their own lightweight tools to automate the repetitive tasks, non-native speakers now write at English graduate level, AI agents handle tasks that used to consume hours and AI has become less of a tool and more of a working layer.
Soon, nobody will talk about "using AI" the same way nobody talks about "using the internet". It will just be how work gets done.
Unlocking Collective Learning
The industry moves at a pace where no single contributor or team can keep up alone. New models, frameworks and patterns appear weekly, and no individual can realistically track all of it. At Blip, we are leaning into this shift by moving away from learning as something we chase on our own time, and toward something teams take on together, integrated into the lifecycle of our software development.
Different teams have leaned into different parts of the AI stack, with each area of focus shaped by the problems they face day to day. Some have gone deep on coding tools such as Claude Code and Cursor, integrating them into daily workflows and pushing on what AI-assisted development looks like in practice. Others have been exploring MCP servers, which allow AI tools to connect to external systems through a common protocol. This opens up new ways to interact with the platforms we already use, from issue trackers and source control systems to observability tools and internal automations. Other teams are focusing less on tools and more on workflow itself, rethinking how a feature gets specified, reviewed and tested when an AI is in the loop.
One risk in all this experimentation is that it can easily stay siloed, with each team relearning the same lessons in isolation. To prevent that, we’ve invested in open forums where teams can share what they tried, what worked and what did not. These take different shapes, from dedicated chat channels where engineers post short demos or small but useful tips, to sessions focused on knowledge sharing and key findings, as well as less structured conversations loose enough to surface half-formed ideas. One outcome of these spaces is that knowledge crosses role boundaries in ways the day to day rarely allows. The way one team uses AI to think through edge cases can change how another team approaches writing requirements, and the way one team uses AI to explore a problem can change how another team thinks about kicking off.
These forums are also where the critical discussion happens, because not every tool is worth adopting and not every workflow translates across teams. Having a place to disagree in public, to flag where an AI-driven approach fails, or to push back on the hype around a new release, is part of what keeps the learning honest. That openness, more than any specific tool or framework, is what makes the shift sustainable as the underlying technology keeps moving.
Challenges and Lessons Learned (So Far)
Technical Challenges
The way engineers work is changing in a significant way. The emphasis is shifting from writing the code to defining the specification: a clear description of what we're trying to build, the constraints we need to work within, and what done looks like. That document has become as important as the code itself, guiding the model during implementation and provides a shared reference point for evaluating the outcome. As a result, validation, discussion and exploration are happening much earlier in the process rather than being squeezed in between development cycles.
Another lesson we've learned is that two things have become increasingly important: critical thinking and a deep understanding of the business behind the code. Current LLMs will occasionally produce wrong answers in a confident tone, referencing code that does not exist or suggesting approaches that do not fit the problem. Catching that requires more than knowing the tech stack. Technical expertise in systems such as Java, Spring Boot and Kafka is still required, but they are no longer enough on their own. More than ever, engineers need to understand the domain deeply enough to judge whether an AI suggestion fits the context, a judgement call that often depends on knowledge that code alone cannot convey.
Business Challenges
The technical challenges are real. The organizational ones are harder.
The first lesson is about bottlenecks. AI accelerates everything, including your weaknesses. Whatever was slowing you down before will slow you down more now. Unclear processes, weak quality foundations, gaps in test automation or CI/CD maturity — all of it gets amplified. You cannot shortcut the fundamentals and expect AI to compensate. If anything, it makes the cost of skipping them higher. There is no AI acceleration without solid engineering foundations underneath it.
The second lesson is one we did not fully anticipate: the human cost of acceleration. There is a very real FOMO pressure building across teams, a sense that the field moves so fast that going offline or stepping away, even briefly, means falling behind. Leaders need to acknowledge that pressure rather than pretend it isn't there.
One could think that with such powerful new ways of working, we would all be working less by now. The reality is the opposite. We are doing more than ever, and the pace has not slowed. If anything, it has accelerated. AI did not give anyone more free time. It raised the ceiling of what is possible and we filled that space immediately. The value is real, but so is the intensity. As leaders, part of our job right now is simply being aware of that, making sure the acceleration does not quietly become exhaustion.
How We’re Creating with AI
New Ways to Create Products
Everyone talks about AI making teams faster, but that’s not necessarily the correct way to look at it.
Speed was never the real bottleneck. The bottleneck has always been clarity: knowing what problem you are actually solving and why it matters. AI does not fix that; quite the contrary — if you go in vague, you come out wrong, faster.
What has changed at Blip is where product work happens and when. Discovery carries more weight now. Before a line of code is written, we can prototype, test assumptions and validate direction in a fraction of the time it used to take. That is only useful if the thinking upstream is sharp.
This puts real pressure on product managers to define the problem clearly, prioritize ruthlessly and set a measurable definition of success before anything gets built. Not as a formality. As the actual job. AI works at both ends: early research and, afterward, checking whether what we built delivered what we said it would.
In practice, this has changed the shape of early product work. Before a spec reaches engineering, we use AI to stress-test it, generating edge cases, surfacing assumptions we haven't stated and drafting alternative framings of the problem. What used to be a one-person exercise over several days now runs in hours, with better coverage. The output isn't a finished design. It's a sharper problem statement.
That matters because it lowers the cost of bringing engineers and designers into the problem earlier. When there's something concrete to react to, even a rough AI-generated prototype or a half-formed spec, the cross-functional conversation is faster and more honest. Engineers catch constraints before the direction is locked and designers challenge assumptions before wireframes exist. The collaboration that used to happen at the end of discovery now happens at the start.
The risk is that all this front-loading starts to look like waterfall, when it shouldn’t. Engineers need to be in the room from day one. Not to build yet, but to challenge assumptions, spot constraints early and shape the direction before the direction is set. Product and engineering thinking together, earlier, is what makes the speed AI offers worth anything.
The teams that get this right will not be the ones with the most tools. They will be the ones who figured out how to ask better questions before they started building.
A Cultural Shift, Not Just a Technical One
The most important thing to understand about this moment is that it is not a technology upgrade. It is an organizational transformation. New tools are the easy part. The harder part is accepting that the way teams are structured, the way roles are defined, and the way work gets done all need to change with them.
We want to deliberately run multiple experiments with different team structures and ways of working, because we do not believe there is a single answer. What we are learning is that team’s topologies matter less than mindset. A smaller team with the right context and the right tools can consistently outperform a larger one still working the old way. The gap will keep growing.
What accelerates that gap is autonomy. Bureaucracy and layers of approval are bottlenecks and AI makes them even more expensive. The real power comes from small, autonomous teams that are close to the business, understand the problem and can make decisions fast. When you put that kind of team together with a supercharged AI, the results are in a different league.
Another important thing to have in mind is that writing code was always just the tool we used to reach the result. As that tool gets cheaper and faster, the engineers who focus on the problem, instead of the syntax, will have the best outcomes.
When it comes to the near future, nobody knows exactly what AI will look like in five years. What matters is whether we are learning, adapting and building the capabilities to navigate whatever comes next.
The most important time in AI is not tomorrow. It's today.
Luis Oliveira, Pedro Cardoso, Pedro Reis
