A field that, just a few years ago, felt stable and full of opportunity now comes with more uncertainty -breaking in is harder, and staying relevant takes constant effort.

We spoke with software engineers who have more than 10 years of experience to hear how they’re navigating these changes.

Thinking back on your career, what’s helped you stay relevant as technologies and trends kept evolving?

Denis: “I was always looking for ways to improve my workflow, so I could spend more time on the interesting, creative parts of the job and less on repetitive, routine tasks. I focused on really understanding problems and possible solutions, which meant building deeper knowledge rather than relying on quick fixes from the internet. I read books, followed blogs, attended both live and online conferences, and learned from experienced people in the industry to get different perspectives and form my own conclusions.

To stay relevant, I focused on real user use cases and the problems behind them, building solutions that create real value.

I also made a point of staying close to the products, users, and solutions over time to see what actually works and what doesn’t, regardless of hype or trends.

Working in teams and collaborating closely helped a lot, as there are always tough questions and healthy discussions that lead to better decisions in the end.”

Marina: “Staying relevant over the years came down to curiosity and hands‑on learning. I regularly read blogs and watch online conferences to keep up with new technologies, but I learned the most by trying things out through small POCs. Experimenting helped me understand problems more deeply and see what really worked.  

Changing teams also played a big role. Working with people who had different backgrounds and experiences exposed me to new ways of thinking and pushed me to grow.  

Finally, working on real products in production environments (especially in larger teams) taught me lessons you simply can’t learn alone. Collaboration, shared ownership, and learning from others helped me continuously adapt as the industry evolved.”

Marko: “For me it’s a combination of continuous learning and a strong focus on fundamentals. I always tried to explore new technologies and different domains, but with an emphasis on really understanding the core principles behind them. That way, the knowledge stays useful even if my career moves in a different direction, and it becomes much easier to build on top of it later.

Just like for the other guys, another important factor was working on real products running in serious production environments, especially in larger teams. Collaboration, communication, and learning from others in a shared codebase bring insights you simply can’t get when working alone. Those experiences helped me grow not only technically, but also in how I approach problems and make decisions in the long run.

I’d describe myself as a cautious early adopter. I enjoy experimenting with new technologies, but I try to understand the fundamentals behind them first, so I can evaluate where they truly make sense and how they contribute real value rather than just following hype.

Finally, self-reflection played a big role. Regularly asking myself what skills I’m missing, how I can contribute more to my team or company, and then actively working towards that has led to many good long-term career decisions.”

Mario: “Talking to other people, watching what others build, and experimenting myself plus exploring open source projects, YouTube videos, and Udemy courses on 2x speed to quickly understand what’s possible with unfamiliar tools. I also follow Hacker News and similar newsletters.

But staying relevant isn’t just about knowing what’s new; it’s about knowing what’s actually worth adopting – and when.

Understanding the high-level concepts and the problem I’m trying to solve is what allows me to pick something that looks like the right tool. After that, trying it out and getting first-hand experience: how it feels under the fingers, and whether it really solves my problem and makes my life easier – is mostly the deciding factor for me, but not the only one. If I’m doing a quick throwaway POC, I can try anything and really find the best tool.

But if I’m working in a team environment where cognitive load is already high, I’m careful not to introduce new technologies every other day just because it’s the new cool shiny thing – even if it actually is the best tool. It’s a tradeoff, and one that needs careful consideration. And sometimes the best isn’t even needed – something that works is good enough.”

In your opinion, is long-term success more about being a deep specialist or a broad generalist? Has your perspective changed over time?

Denis: For long-term success (whatever that is), it’s generally better to develop M-shaped skills. That will take some time, but only with great collaboration and multiple deep expertise areas can you be innovative and versatile, bringing measurable value and not be easily replaceable.

Marina: Earlier in my career, I believed that being a T‑shaped developer was the ideal path and I assumed that trying to learn more than one thing deeply would only lead to superficial knowledge and that focusing on a single specialization was the safest way to grow. Over time, my view changed.

Through real-world experience, I realized it’s possible to build strong, meaningful expertise in multiple areas without losing depth. As systems became more complex, having deeper knowledge across several domains helped me understand the bigger picture better, make better technical decisions, and collaborate more effectively with others.

Today, I believe long‑term success comes from combining depth with breadth – developing strong expertise in more than one area and continuously expanding that range as technology evolves. This flexibility has helped me stay relevant and adapt as roles and technologies have changed.

Mario: I wonder if it’s possible to be M-shaped For a long time, I was a firm believer that T-shaped is the way to go – a broad overview, but with at least one area of genuine deep expertise. And I still think that’s a solid foundation for any engineer.

But over 20+ years, curiosity kept pulling me in different directions: low-level Linux internals, networking, compilers, containers, orchestration, and large-scale distributed systems, working at different layers of the stack. And each time, I went deep enough to solve a real problem. That experience adds up over time.

Understanding the problem and figuring out which layer it needs to be solved in matters more than the technology layer itself, and then it’s about stitching everything together.

Do that long enough, across enough domains, and you naturally grow more spikes. So my view has evolved – I started as a T-shaped believer, and somewhere along the way I became something closer to M-shaped. Not by design, but by following the problems. And if you ask me what I’m an expert at specifically, I’d say solving problems, if that counts as expertise. That’s at least what I currently strive for.

Marko: Today, I’d describe myself as somewhere between T-shaped and M-shaped, maybe N-shaped, still evolving. Early in my career, the T-shaped model made perfect sense, broad knowledge with depth in one area. Over time, as access to knowledge became easier and technologies evolved faster, I realized how valuable it is to develop depth in multiple areas

What ties all of this together is problem-solving. Technologies change, but problems remain. Being able to learn continuously, adapt, and apply concepts from one domain to seemingly unrelated problems becomes incredibly valuable over the long term.

If I were to advise myself 10 years ago or to others today, it would be to stay curious, keep learning, and surround yourself with people you can both learn from and teach. Also, don’t be afraid to broaden your horizons, look for ways to contribute beyond your narrow specialization, pick up complementary skills, and take some risks. Growth often happens outside your comfort zone.

How do you see AI tools impacting long-term developer careers?

Mario: AI impact is real, especially in engineering. We’re much faster at writing code, and I can smart-search unfamiliar codebases and quickly understand how things work (something that used to take a huge effort).

But there’s a price.

The amount of generated code is huge, yet humans still need to review, understand, and own it. AI isn’t the one waking up when something breaks. Creating PRs with AI is easy, being responsible for them is another story.

Our role has shifted to making sure code that looks ok is actually ok – fits the intended architecture, the broader system, the business rules, all the things AI isn’t aware of. The value is the same: understanding whether the code works as intended and preventing it from degrading into a ball of mud nobody can understand or fix at 3am.

What’s changed is how much harder that challenge has become with code being generated at this speed. Young developers are in a tight spot – suddenly expected to skip writing code by hand but still have the same depth of understanding.

And I’m not sure you can skip that part. There’s something about writing code by hand, hitting a wall, debugging it yourself, and feeling the pain of it not working that builds intuition you can’t shortcut. Even if AI is faster and easier. The best advice is to learn the concepts, fundamentals, and engineering best practices that hold regardless of AI.

You need to be able to look at AI-generated code and know whether a for loop is acceptable or a dictionary lookup fits better, that’s software engineering 101. AI can generate the code, but we still need to understand whether it actually fits.

Write as much code by hand as you can. Use AI to review it, ask for other options, and have it challenge your approach, and then actually think through the answers. That way you learn faster while still building real understanding.

And don’t skip debugging AI-generated code step by step; I do it regularly. It’s how you move from just looking at code to actually feeling it. That difference becomes obvious once you try it.

You’ll often be surprised how much you miss just by reading – sometimes it’s “this is not how I thought it worked”, sometimes it’s “I did not expect this at all.” Both are valuable, and both come from actually stepping through it.

Marko: AI tools already have a huge impact on my daily work, from writing code and understanding codebases to reviews, idea generation, debugging, and learning new topics. Overall, I see AI as a strong positive force for developers. It significantly reduces the time spent on repetitive or low-value coding tasks and frees up more space for thinking about architecture, system design, and solving complex problems that truly matter in production.

That said, some things won’t disappear. Understanding the problem and broader context, making architectural trade-offs, communicating well, and taking ownership are still firmly human. When something breaks at 2 a.m., it’s still engineers who make decisions and take responsibility. AI is powerful, but only as effective as the person using it.

For junior developers, don’t skip the fundamentals. Expectations are higher than ever, but strong foundations are key for a sustainable career. The good news is that access to knowledge and AI tools is better than ever. Use AI to accelerate learning, not replace understanding. Give yourself time, build experience, and master the basics—that investment pays off for decades.

Marina: AI tools will significantly change how developers work, but I don’t see them replacing strong engineers. Instead, they will amplify those who understand what they are building. For younger developers, the key is to learn with AI, not just watch AI work.  

It’s important to question AI output, understand why it made certain changes, and how those changes affect the system. Treat AI as a learning partner rather than a shortcut. Blindly accepting generated code can limit growth, while actively analysing and improving it builds real expertise.  

Younger developers should also focus heavily on architecture and system design. When you understand how systems are structured, how components interact, and what trade‑offs exist, AI becomes far more powerful. It’s much easier to ask the right questions (and get useful results) when you already understand the problem space.

Denis: AI tools have made coding skills almost irrelevant. Still, other skills and practices related to quality, such as trunk-based development, TDD, continuous delivery, modularity, cohesion, DDD, etc., are more valuable than before.

AI tools are a powerful amplifier, and they need guidance, so software engineers with those skills will remain relevant and in demand for a long time. Understanding of the (business) problem and the solution shouldn’t be outsourced to the AI. Software engineers still need to understand trade-offs, architecture, and code. 

The post What 4 engineers with 10+ years of experience say about staying relevant in the AI era appeared first on ShiftMag.

Uber engineers aren’t just using AI to write code; they’re rethinking how developers work with it. That shift matters because, despite 93% adoption, productivity gains remain flat.

At the Pragmatic Summit, I listened to Uber’s Director of Engineering, Anshu Chadha, and Principal Engineer, Ty Smith, discuss how one of the world’s largest technology companies is integrating generative AI into its engineering workflow.

Then, they shared:

At Uber, engineers are beginning to assign coding tasks to AI agents much like managers distribute work among their teams.

Say hello to my new colleague – AI

Uber has been using AI for years in systems like its matching platform, but bringing generative AI into the day-to-day work of engineers is a newer step.

According to Anshu, the goal isn’t to replace engineers – it’s to help them get more done.

We’re not pushing for AI to automate all humans in the company. Our goal is to let engineers focus on creative work rather than toil.

Practically speaking, repetitive tasks such as code migrations, upgrades, documentation, and bug fixes are now being handled by AI-powered agents. According to Anshu, it frees engineers to build features and enhance the user experience.

The end of hands-on programming as we know it?

One of the biggest shifts Uber has observed is the transition from traditional AI-assisted coding tools toward agent-based workflows.

Tools like GitHub Copilot made coding faster by helping developers in the moment, but now we’re entering a new era: AI agents that can work independently, tackling tasks without needing someone at the keyboard.

Back in 2022 and 2023, developer velocity saw a modest 10–15% increase. Today, the paradigm has shifted to what we call “peer programming,” where developers can delegate workloads to AI agents and intervene or redirect them as needed.

This approach essentially positions engineers as tech leads directing AI agents. Developers define the goal, while agents execute parts of the work in the background and return results for review.

Uber has built an internal platform that plugs AI agents right into its engineering workflow, mostly on Michelangelo, its machine learning platform. This gives access to models from OpenAI and Anthropic, as well as Uber’s own internal models.

On top of that, they’ve created agent-driven tools that tap into company data (source code, documentation, Jira tickets, Slack) so the AI agents have enough context to actually get work done.

AI tackles toil, but gaining trust is the real challenge

At the conference, a standout demo was Uber’s “Minions” system. Engineers submit a prompt via web, Slack, or command line, and it generates code changes and opens pull requests automatically. Ty says:

You give the agent a prompt and expect a pull request as the output. A few minutes later the system notifies you on Slack that the task is complete and the PR is ready to review.

The platform also helps engineers craft better prompts by suggesting improvements when instructions are unclear, increasing the likelihood that the agent will succeed.

When Uber first rolled out agentic workflows, they found about 70% of submitted tasks were “toil” – repetitive maintenance work developers usually avoid. These predictable tasks are ideal for AI, creating a feedback loop: the more AI handles, the more developers are willing to delegate.

Still, scaling AI isn’t just about technology. Supporting engineers as they adjust from traditional workflows and gain confidence in AI-generated code is an important focus.

Sharing success stories sparks faster AI adoption

Uber found that peer-driven adoption worked better than mandates. Anshu points out:

The most successful tactic has been sharing wins. When engineers see examples from their peers where AI helped them accomplish something impressive, adoption spreads quickly.

But measuring real impact remains tricky.

Uber tracks metrics like developer satisfaction, productivity, and code output, but connecting them to business outcomes is harder. “These are activity metrics, not business outcomes,” Anshu says.

To fix this, Uber is working to track the full development lifecycle (from design to production) to see how AI truly speeds up product delivery.

AI is powerful but EXPENSIVE

Cost is also becoming an issue. Running large language models at scale requires expensive compute resources, and AI infrastructure spending has grown dramatically, Anshu explains:

Since 2024, our costs have gone up at least six times. This technology is amazing, but the cost of AI is too high.

That’s why Uber is investing in AI infrastructure that picks the right model for each task, balancing performance and cost. With the AI landscape changing fast, the company continuously evaluates new tools and updates its stack:

What’s successful this month may be overtaken next month. So we constantly test new tools, gather feedback from developers, and adapt.

This is a fundamentally different approach from the standard coding-assistant model, one that addresses the real constraints. See the broader context: 42% of code is AI-assisted, yet 96% of developers don’t fully trust it.

Uber’s coding agent now writes 1.800 code changes per week

Just one day after we published this article, Praveen Neppalli Naga, Uber’s CTO, shared in a LinkedIn post that agentic software engineering adoption is accelerating rapidly at Uber:

• 1.800 code changes per week are now written entirely by Uber’s internal background coding agent.
• 95% of engineers use AI every month across tracked tools.

Over the past few months, Uber has leaned in heavily, and as Neppalli Naga notes, the results have been phenomenal:

84% of AI users are now working with agent-style workflows, not just tab completion. Usage of Claude Code nearly doubled in two months (32% → 63%), while traditional IDE-based tools have largely plateaued.

He also said that engineers are shifting from accepting suggestions to delegating tasks. Even within traditional IDEs, around 70% of committed code is now AI-generated.

All of this suggests a quiet but significant shift:

Background agents are increasingly writing code autonomously. Uber’s internal coding agent grew from contributing less than 1% of all code changes to 8% in just a few months, with zero human authoring. Engineers review and approve, but the code itself is written entirely by AI.

The post How Uber Engineers Use AI Agents appeared first on ShiftMag.

AI terminology can be confusing, especially when words like agents, skills, tools, and LLMs get used interchangeably.

That’s why I put together this glossary as a quick reference, to explain these concepts and help everyone, technical or not, talk about AI clearly.

Agent Skill

An agent skill is a predefined capability or behavior that an AI agent uses to accomplish specific tasks like searching the web, writing code, sending emails, or reading files. Skills give agents a structured way to interact with tools, APIs, or data sources, making them more reliable and reusable across workflows. Think of them as modular “superpowers” you can plug into an agent.

At a minimum, skills are just folders the agent reads, containing logic, instructions, assets, templates, and more. Most of today’s state-of-the-art agent apps let you create your own custom skills.

MCP

MCP (Model Context Protocol) is an open standard that lets AI agents connect to external tools and data sources consistently. Instead of creating a custom integration for every service (like Slack, Google Drive, or GitHub…) MCP provides a universal “plug-in” format, allowing any MCP-compatible server to communicate with any MCP-compatible AI.

Think of it as USB-C, but for AI tool integrations.

Agent Tool

A tool is a function (code) that an AI agent can execute when it decides to. That’s why each tool has a name and a description, which influence when the model chooses to use it (for example, “Use this function to pull the latest tickets from a Jira project”).

Besides the name and description, the function contains the code that the AI agent runs with the required arguments. For example, the agent could call:

jira_fetch_tickets(project="AI", limit=10)

Tools are also components that power MCP servers. In Open WebUI project, users can even write custom Python tools that agents can invoke.

Large Language Model (LLM)

An AI model within the deep learning spectrum, primarily designed for language understanding and content generation. LLMs excel at processing and generating human-like text.

Token

In Generative AI, a token is the smallest unit of information a language model processes. Depending on the language and the model’s design, a token can represent a whole word, part of a word, or even a single character. Tokens are the building blocks that language models use to understand and generate text.

Context Window

The context window is the number of tokens an LLM can process as input or generate as output. Input and output limits are usually different, with the input capacity typically much larger than the output.
For example, GPT-4o has an input limit of 128.000 tokens and an output limit of 16.384 tokens.

Fine-Tuning

Fine-tuning is the process of modifying a language model’s neural network using your own data. It’s different from simply adding documents to a conversation or adjusting prompts, which don’t change the model’s underlying structure (see RAG for an alternative approach).

Retrieval Augmented Generation (RAG)

Retrieval-Augmented Generation (RAG) is a system that uses a vector database to store ingested data, such as documents, web pages, and other sources. When a question is asked, relevant data is retrieved and combined with the question before being sent to a language model (LLM). The LLM itself doesn’t change, but it “sees” the retrieved information, allowing it to answer based on this additional context.

Prompt

A prompt is the user’s input that kicks off the model’s text generation. It guides the model to produce relevant and coherent responses based on the context or question. Prompts can be simple or detailed, shaping the quality and direction of the output.

ChatGPT

ChatGPT is an OpenAI product built on the GPT family of large language models (LLMs). As a product, it can use different LLMs, such as GPT-4o, GPT-4o-mini, and o1.

AI Agent

An AI agent is a software system powered by LLMs that performs tasks, answers questions, and automates processes for users. They can range from simple chatbots to advanced digital or robotic systems capable of running complex workflows autonomously. Key features include planning, using tools, perceiving their environment, and remembering past interactions, which help them improve performance over time.

Prompt Injection

Prompt injection is a type of cyberattack on large language models (LLMs), where malicious inputs are disguised as normal prompts to manipulate the model’s behavior or output. These attacks can make the model ignore safeguards, reveal sensitive information, or carry out unauthorized actions.

Google Gemini

Google’s family of Large Language Models (LLMs).

Anthropic Claude

Anthropic’s family of Large Language Models (LLMs).

Meta Llama

Meta’s family of Large Language Models.

LLM Parameters

LLM parameters are the components within a large language model that determine its behavior and capabilities. Learned during training, they include weights and biases that help the model understand and generate language. Generally, more parameters mean a smarter model, but they also require more computing power, especially memory (RAM), to run.

Copilot

Copilot is Microsoft’s branding for different AI agents, such as:

• GitHub Copilot, which assists with coding
• Copilot 365, which helps with Office and Windows tasks

System Prompt

A system prompt is a set of instructions or guidelines given to a language model to set its behavior, tone, and limits during a conversation.

Prompt Engineering

Prompt engineering is the practice of designing and refining prompts to optimize a language model’s performance and output. It involves crafting specific inputs that guide the model to produce the desired responses, improving accuracy, relevance, and coherence.

Digital Twin

Digital twins are virtual representations of assets, people, or processes and their environments that simulate strategies and optimize behaviors. In the CPaaS space, this usually refers to AI agents that mimic people using audio and video modalities.

Multimodal

Multimodal refers to the ability of AI systems to process and combine multiple types of data inputs (text, images, audio, video) to perform tasks or generate outputs. This approach allows AI models to understand and create content across different modalities, resulting in more comprehensive and context-aware applications.

Vector Database

Unlike traditional databases that store structured data in tables, vector databases are optimized for operations like similarity search, allowing efficient retrieval of data points that are mathematically close to a given query vector.

This capability is essential for applications such as recommendation systems, image recognition, natural language processing, and other AI-driven tasks where data is represented as vectors. For a common implementation, see RAG (Retrieval-Augmented Generation).

Hybrid Search

Hybrid search combines the strengths of vector search and traditional full-text search to improve the relevance of retrieved results. Vector search captures the semantic meaning of queries, matching based on context and intent, while full-text search ensures precise keyword matches.

By blending these approaches, hybrid search increases the likelihood of retrieving the most relevant documents, even when queries are vague or phrased differently from the source content. This boosts the accuracy of retrieval and enhances the overall effectiveness of the RAG (Retrieval-Augmented Generation) pipeline.

Embedding Model

An embedding model is a machine learning model trained to convert input text into numerical vectors, which can then be used for vector similarity search. Embedding models are a key part of the RAG (Retrieval-Augmented Generation) pipeline, as they transform user questions into vector representations.

The post The Glossary You Must Read If You Wanna Talk About AI appeared first on ShiftMag.

I was skeptical when I first ran OpenClaw, it looked like just another AI tool riding the hype. Turns out, it’s not.

After experimenting with it and extending its messaging, I also found out that much of its core power (its AI agent architecture and human-in-the-loop interactions) can be recreated with off-the-shelf tools like the Agents SDK and Messages API.

In this post, I’ll share what I learned from using OpenClaw, explain why messaging is what makes autonomous agents truly work, and show how developers can leverage existing tools to build something similar without starting from scratch.

The agent that broke the internet 

In just three months, it’s taken off on GitHub, earning 200k stars in 84 days and thousands of forks. By mid-February, SecurityScorecard was tracking over 240k instances running in the wild.

With LLM token costs of $5-50 per instance, the project is already accounting for millions in inference spending, and it’s even causing Mac mini shortages as people rush to self-host OpenClaw. (You can actually run it on much cheaper hardware, which makes the story even crazier.)

The hype around the project is undeniable, even with a steep barrier to entry (users must install and run the server software themselves) and despite ongoing security concerns and reported vulnerabilities. 

Why I think the hype is justified

OpenClaw’s AHA moment is hard to ignore. It shows there’s real demand for autonomous AI agents, ones that free users from being stuck in a chat window on sites like chatgpt.com.

I’ve always felt that calling those website chatbots “agents” was a stretch – they’re more like conversation buddies than AI doing real work for you.

True agents, in my view, should run in the background, acting and reacting on their own without forcing users to stay glued to a single site. That’s exactly the experience OpenClaw delivers.

The “hold my beer” moment

As a developer, I was curious. Running OpenClaw was impressive, but I wanted to know: how does it actually work? And even more, what would it take to recreate its wow factor myself? Let’s break it down.

The first key ingredient is an AI agent, and I mean this in a very specific sense.

As Anthropic puts it, agents are systems where the LLM controls the program’s flow, instead of classic code deciding when to call the LLM. At a high level, agent apps are basically a while loop that calls the LLM and hooks in all the tools the AI might need. With the rise of MCP, connecting these tools has become easier and more standardized.

On the surface this seemed simple, but I quickly got bogged down in a bunch of edge cases and details to implement. Luckly, we don’t need to reinvent the wheel here. There are ready to use SDKs wrapping all the agent logic, recently renamed Agents SDK being a prime example. That got the AI agent part covered. But there was still one secret ingredient missing.

Users still need to approve important actions

Let’s go back to the OpenClaw user experience. Even when freed from a chat website, agents still need a way to stay in touch with their users. 

The human-in-the-loop approach remains essential for responsible AI: no one should discover their agent’s spending spree on a month-end bank statement. Critical actions still need user approval, and important results still need to be communicated. 

That’s why messaging channels are the very first feature highlighted in OpenClaw’s documentation. 

Messaging is what makes autonomous AI agents actually work for you. It lets them check in, keep you in the loop, and get your approval for important actions, without forcing you to refresh a page or babysit a chat window. It’s what gives you peace of mind, convenience, and, most importantly, control.

Cheat codes for messaging

Back to coding.

Connecting to mobile operators or chat services might sound intimidating at first, but I had a secret weapon: I work at Infobip. Luckily, you don’t need that advantage, anyone can pick up the unified Messages API and start sending and receiving messages on users’ phones.

With connectivity sorted, all I had to do was figure out how to hook the agent up to it.

There are few flows:

• First up is passing new messages from users to the agent as prompts; basically, launching new tasks.
• Secondly, the agent needs a way to send out reports. MCP servers work best here, as they are easy to integrate and trigger by LLMs. 
• Finally, sending the agent’s output to the phone and getting the user’s feedback or confirmation. This is the all-important human-in-the-loop part! Historically interpreting free form input from users might have been hard, but these days we can easily pass it to an LLM and ask it to summarize the intent: does the user approve of the suggested action or not? Easy. 

And with that my experiment was over. 

Do a few off-the-shelf components (like the Agents SDK and Messages API) replicate the full OpenClaw experience? Not entirely. But they can help you kickstart a new project, up to the point where you can focus on your core features. And that’s the part that really matters.

It’s time to pay attention to autonomous agents

If you’re already working in AI (or thinking about it) autonomous agents are where things are moving. OpenClaw shows the demand is real, and the tools to build agents that can reason, act, and communicate are already here. Messaging isn’t just nice to have; it’s how your agent stays useful without you having to babysit it. With unified messaging APIs and MCP, sending updates and notifications is easy, so you can focus on shaping how your agent thinks and acts.

The post I Tried Recreating OpenClaw – And The Hype Is Real appeared first on ShiftMag.

Three months ago, I started using Claude Code to handle the repetitive, day-to-day work of product management.

It was an immediate improvement over standard chatbots I have been using for the past few years for handling core PM tasks:

• Deep market, competitive and technical investigations  
• Turning raw customer input into structured change requests  
• Generating high-fidelity specs for the SDLC and user docs

I soon moved from simple tasks to rapid prototyping.

Having coded early in my career (if you know MFC, you know how long ago), it felt natural to create interactive mockups for feature ideas. When ChatGPT came out, I prompted it for Python and JavaScript, copied the code into an IDE, and fed back errors for fixes. This time, it was a different experience: I could get a working prototype in hours and initial feedback within a day.

A dream of autonomous coding, directly applied to my product

Prototyping worked well, but it made me wonder: Could a coding agent take my specifications and produce full, working features?

Answering this would mean a major shift in my workflow.

I would stop generating piles of specifications for the product team to convert into working features and start managing “executable intent” for agentic coding.  My job was no longer overseeing a list of tasks; it was to architect the specific goals, guardrails, and project context an AI needs to turn a requirement into a production-ready feature.

My ultimate vision was autonomous coding applied directly to my product. The transition would start with small, scoped increments and bug fixes to learn the agentic system’s nuances and build trust. Once we prove success on isolated components, we can scale to larger cross-domain features and multi-agent setups.

So I went searching for design patterns that promised HOOTL (human out of the loop, no ongoing human intervention), and soon the name Ralph Wiggum came up (see the side note).

What is the Ralph Wiggium Loop?

Named after the lovably persistent Simpsons character, the Ralph Wiggum Loop is an orchestration pattern for autonomous AI agents.  Popularized by developer Geoffrey Huntley in mid-2025, it shifted AI from “reactive chat” to “autonomous worker.”

Unlike typical one-off prompts, the Ralph Loop runs an agent repeatedly (like a “while loop”) until a task, such as a complex software refactor, is fully complete. It’s become popular because it solves “context rot”: each iteration starts fresh, so the AI doesn’t get tripped up by its previous errors and can keep working for hours without human oversight.

Ralph showed me how, but being naturally skeptical, I wanted to test it first – a “sandbox” to see if the workflow actually worked in a real project before rolling out full autonomous coding in production.

AI built 90% of a feature, I finished the rest

I picked an open-source framework called NiceGUI (a Python framework for building web UIs) as my playground. 

The idea was to implement a new component, an enhanced data table with inline editing, inheriting from the existing table. It had to be a repeatable process enabled by the agentic coding loop, so I decided to build one.

First, I used Claude Code to scout the repository and extract “institutional knowledge” – the specific tech stack, coding patterns, and standards of the project. I fed this context and a detailed feature request into a custom Ralph PRD Factory. This turned my requirements into a JSON-formatted PRD file that the Ralph loop is driven by and that serves as the “executable intent.”

After one day of prep work, I turned the agent loose. In under four hours, it completed the task autonomously – or so it told me.

In reality, I spent a few more hours weeding out UI bugs and minor quirks until it finally felt complete. Still, having the agent take me to 90% was a clear success. The autonomous coding worked.

Redesigning how our product team works

In traditional development, ideas often get lost in translation, passing from PM to designer to engineer to QA, each handoff can dilute or distort the original intent.

When AI builds features from scratch, the old handoff-heavy workflow falls apart. To succeed, teams need to shift from doing manual work to orchestrating the system:

• The PM as Intent Architect – The PM’s output is no longer a ticket; it is the “brain” of the feature. By owning the context engine, the PM ensures the agent has the exact data and guardrails needed to execute. Success is measured by the precision of the context, not the volume of tasks.
• The Engineer as Architectural Oversight – Senior developers can stop spending 80% of their time on boilerplate. They become guardians of the system, focusing on high-level architecture, security, and complex logic that agents cannot yet handle.
• The Designer as Real-Time Reviewer – Instead of static handovers, designers review live agent output as it is generated. They move from static creation to dynamic orchestration, adjusting the visual intent on the fly.
• The QA as Quality Architect – Testing moves from manual bug-hunting to designing “self-healing loops.” They build automated systems to catch failures early, allowing humans to focus on strategy and edge cases.

Let the AI orchestration games begin

This experiment wasn’t just about building a feature in hours, it offered a glimpse into a bigger shift in how we create products. Autonomous agents building features are becoming reality. It’s not a magic solution, we still have a lot to learn about using agentic AI effectively and guiding it toward the results we want.

This shift doesn’t eliminate specialized roles, it moves us away from manual “doing” and toward orchestrating and designing systems.

To succeed, we all need to level up and expand our roles – moving from doing manual tasks to guiding and orchestrating AI. I’m excited about this shift. It’s time to stop just managing backlogs and start shaping the future.

The post It’s Time to Redesign How Product Teams Work appeared first on ShiftMag.

Some time ago, I wrote an article called The Illusion of Vibe Coding. In it, I argued that there are no shortcuts to mastery, and that relying on AI-generated code without deep understanding only shifts problems downstream. That article came from skepticism.

Recently, after seeing early autonomous agent systems like OpenClaw, I realized something important: the skepticism is still there, but my perspective has shifted.

In my view, we are no longer just discussing “better tools for developers.” We are starting to see the outlines of an entirely different operating model for software engineering.

We no longer writing code, we express intent

For years, the industry has framed progress as AI “assisting” engineers: smarter autocomplete, faster refactoring, better suggestions. All useful, but still stuck in the same old mindset – and I don’t think that way of thinking works anymore.

The future of software engineering isn’t just developers using AI tools. It’s autonomous coding agents and humans working together, each guiding the other.

Today, software development is all about execution. Humans break work into tickets, write and review code, test, deploy, and repeat. Even with better tools, the mental load of coordination and context switching hasn’t changed.

In The Illusion of Vibe Coding, I argued that skipping understanding makes systems fragile. I still believe that. What’s different is who I think will do the executing.

I believe autonomous coding agents will take over much of the mechanical work, while humans move up the stack.

Instead of assigning tasks, we’ll define intent: outcomes, constraints, trade-offs. Agents will plan, execute, and consult humans only when uncertainty is high.

Humans are no longer the primary executors, we become the checkpoint. From the agent’s view, we’re part of the control loop, not collaborators.

Karpaty, ex director of AI at Tesla, also notes that as execution shifts to machines, humans’ focus naturally moves toward guiding principles, architecture, and intent. This aligns with what I’ve observed: our role is increasingly supervisory and strategic, not mechanical.

Agents never forget the system, humans do

This shift isn’t just better code generation, it’s context.

Autonomous agents can read entire systems in ways humans can’t: traverse repos, inspect dependencies, analyze history, read docs, and link decisions across months or years.

What we call “tribal knowledge” is mostly a workaround for human memory. Agents don’t forget, avoid legacy code, or shy away from repos. They treat the system itself as the unit of change, not a ticket, file, or pull request.

Trust in software will shift from the output to the process itself

One aspect I think is often underestimated is verification.

I believe autonomous agents won’t just write code and wait for CI, they’ll run tests, add coverage, debug failures, and review their work against architecture.

In The Illusion of Vibe Coding, I warned against blind trust in generated code. Now, I think trust should shift from output to process. CI stops being a gate for humans and becomes a feedback loop agents actively use. Software moves from “written then checked” to continuously reasoned about.

Companies will adopt autonomous agents in different ways

I don’t think companies will adopt autonomous agents uniformly. Instead, I expect a clear split.

• Some companies will deeply integrate autonomous agents into their systems, aligning them with architecture, security, and risk. The advantage won’t be the model itself, but the alignment layer, which will quietly become intellectual property.
• Other companies will use cloud-based agents, prioritizing speed, accessibility, and low overhead. They’ll excel with standard architectures and fast-moving teams, even if they don’t fully grasp the business, often an acceptable trade-off.

Most organizations will likely go hybrid, using cloud agents for experimentation and self-hosted agents for core systems. As today, the most sensitive parts of the business will stay in-house.

So, what does this mean for software engineers?

I don’t believe this future eliminates engineers, but it will force a sorting.

Experts remain essential, shifting from coding to orchestrating autonomous agents, ensuring output is secure, maintainable, and aligned with intent.

I think infrastructure engineers become even more critical – they build, run, and improve the systems autonomous agents rely on. I believe the most important production system won’t be the application itself, but the system that creates and evolves it.

What’s interesting is that this shift is already changing where the bottleneck lives.

Robert C. Martin recently described this succinctly:

In other words, humans are becoming the bottleneck.

Execution can be automated; judgment and responsibility cannot. The middle layer shrinks, and value moves to architecture, risk, and knowing what not to build.

One thing responsibility that stays the same: responsibility cannot be outsourced.

What will happen to interns and junior engineers?

This is the part where I don’t have a confident or comforting answer, and pretending otherwise would be dishonest.

If agents handle most execution, the old path for juniors (doing small tasks to learn) won’t work anymore. That doesn’t doom them, but the way they gain experience will have to change.

I think Anthropic’s research is spot on: struggling and effort are essential for mastery, and removing friction too early quietly erodes learning.

And this isn’t just a junior problem; I think it applies equally to experienced developers.

When agents let us skip hard thinking, growth stalls: juniors may never build fundamentals, and experienced engineers can slowly lose judgment and architectural instinct. The ones who thrive will be those who actively choose to remain experts, even when tools make shortcuts tempting.

Two types of developers will emerge

As I described earlier, two broad roles are likely to emerge, and both will require deep knowledge:

• One path is for engineers who orchestrate autonomous agents. They need a solid grasp of system architecture, can turn business needs into technical solutions, and have the judgment to know if a change is safe, maintainable, and scalable. That kind of judgment isn’t learned by cutting corners, it comes from wrestling with trade-offs, failure modes, and long-term consequences.

• The other path is engineers who build and run the autonomy infrastructure itself. They need deep expertise in infrastructure, security, networking, permissions, observability, and cost management, and in self-hosted setups, also skills in model hosting, fine-tuning, or even training specialized systems.

Both paths lead to highly skilled experts. Neither is shallow.

What worries me isn’t juniors being replaced – it’s everyone getting passive, letting agents do the thinking that actually builds real skill.

My advice hasn’t changed since The Illusion of Vibe Coding: keep learning, keep experimenting, and don’t outsource your understanding. Use agents to amplify your thinking, not replace it. The difference now is urgency, and how we learn must evolve at every level.

Imagine an engineer adding a feature. Instead of just coding, they first understand why it matters, what could break, and how it fits in the system. They might use an agent to propose a solution but review it critically. Over time, they don’t just write better code, they get better at judging designs, spotting risks, and turning vague ideas into solid solutions. That’s the kind of skill that keeps you valuable when execution is cheap.

Machines will execute, humans will supervise and judge

We keep asking how AI will assist developers. That question assumes the old hierarchy stays. It won’t.

In my view, software engineering is heading toward a quiet inversion: machines will execute, and humans will supervise, constrain, and judge, not because humans are weaker, but because machines excel at execution, and humans excel at responsibility.

Vibe coding was never the goal – it was just a step. The future isn’t about coding faster. It’s about deciding, deliberately, what’s actually worth building.

The post My View of Software Engineering Has Changed For Good appeared first on ShiftMag.

Not because developers weren’t already sensing this shift, but because he said it, and because he revealed something many wouldn’t openly admit:

It hurts the ego a bit.

This wasn’t just another AI hot take. A top expert openly admitted that software development has changed in a fundamental way. Karpathy was clear:

This is easily the biggest change to my basic coding workflow in 2 decades of programming and it happened over the course of the few weeks.

Karpathy, in his own words

Karpathy explains how, over the course of just a few weeks coding in Claude, his workflow flipped almost entirely. What was once mostly handwritten code is now largely driven by LLMs, guided through natural language.

I really am mostly programming in English now, a bit sheepishly telling the LLM what code to write… in words. It hurts the ego a bit, but the power to operate over software in large “code actions” is just too net useful.

That sentence carries more weight than it first appears. It openly acknowledges the productivity gains while naming the quiet discomfort many developers feel but rarely articulate. Even for Karpathy, something is unsettling about no longer being the one writing the code line by line.

This shift isn’t about convenience or a slightly better tool. Karpathy describes it as a phase change, not an incremental improvement.

The role of software engineers moves away from writing individual lines of code and toward orchestrating large code actions. LLMs don’t behave like perfect assistants; they act more like eager but sloppy junior developers: fast, capable, and occasionally careless. They don’t ask clarifying questions, they guess. And sometimes they guess wrong.

The result is faster output, but also a different kind of responsibility. Less mechanical, more abstract. Less about syntax, more about judgment.

Community reaction and a bruised identity

The reaction to Karpathy’s post helps explain why it resonated so widely. Some developers see this evolution as liberating, with fewer repetitive tasks, more leverage, and more time spent on meaningful problem-solving. Others see something more troubling: a slow erosion of the craft that shaped their professional identity.

A familiar split emerges: on one side are builders who embrace orchestration, prompting, and verification, on the other are developers who feel that if they’re not writing code, they’re not really programming anymore.

That tension is emotional, not technical. Programming has never been just a job. For many, it’s a source of pride. When that pride is challenged, even by efficiency, it stings.

What makes this moment particularly interesting is that Karpathy hasn’t been blindly optimistic about AI agents. In the past, he’s openly questioned their maturity, arguing that today’s agents are unreliable and far from fully autonomous.

This contrast is important. He’s saying these tools are too useful to ignore, but he’s also clear they’re still messy, fragile, and imperfect. This isn’t hype, it’s real challenges. And challenges are what spark meaningful discussion.

Am I really a developer if I’m not writing code?

This conversation goes beyond the usual AI discourse cycle. If top engineers are moving from writing code to guiding systems, if success is measured by results rather than lines of code, and if pride, not skill, is the main barrier, then something bigger is happening.

We’re not just changing tools, we’re renegotiating what it means to be a developer.

The real question isn’t if this trend will keep going. It’s this: If programming becomes mostly about language, judgment, and style, what happens to being defined by code?

Karpathy’s post doesn’t give answers but shows the tension. Is moving away from manual coding progress or loss? Empowerment or subtle deskilling?

And if top engineers admit it “hurts the ego,” what does that mean for the future of the profession?

By the end of 2025, LLM coding agents reached a level of coherence that triggered a shift in software engineering. Intelligence is now outpacing tools, workflows, and organizational structures. The industry is just starting to catch up, and 2026 is shaping up to be a fast-moving year as development learns to harness this new power.

The post Andrej Karpathy Admits Software Development Has Changed for Good appeared first on ShiftMag.

The Deployment Pipeline is a critical tool for ensuring software quality – and quality is a prerequisite for speed.

So, what is a Deployment Pipeline? How has it helped us improve both quality and speed? And what are, in my experience, the common problems in using and implementing deployment pipelines?

A Deployment Pipeline is a machine that helps us move from an idea to valuable software in the hands of users by organizing software development work. It enables us to go from commit to releasable outcome as quickly and efficiently as possible, in a repeatable and reliable way.

— Dave Farley, Continuous Delivery Pipelines: How to Build Better Software Faster

Before exploring how Deployment Pipelines have helped us, it is helpful to briefly introduce Continuous Integration and Continuous Delivery.

Continuous Integration

Continuous Integration is a software development practice that helps us create and maintain a high-quality codebase that is easy to change and to implement new features.

As Martin Fowler points out, the practices of Continuous Integration are:

• Put everything in a version controlled mainline​
• Automate the Build​
• Make the Build Self-Testing​
• Everyone Pushes Commits To the Mainline Every Day​
• Every Push to Mainline Should Trigger a Build​
• Fix Broken Builds Immediately​
• Keep the Build Fast​
• Hide Work-in-Progress​
• Test in a Clone of the Production Environment​
• Everyone can see what’s happening​
• Automate Deployment​

Kent Beck developed the practice of Continuous Integration as part of Extreme Programming in the 1990s. The book Continuous Integration by Paul M. Duvall, Steve Matyas, and Andrew Glover was published in 2007. While this is nothing new, many software engineers and teams still do not practice Continuous Integration and therefore miss out on the benefits it provides.

Continuous Delivery

Continuous Delivery can further help create and maintain high-quality software. The excellent book Continuous Delivery by Jez Humble and David Farley was published in 2010. and it describes the idea behind continuous delivery in detail, and it introduces “…the central paradigm of the book – a pattern we call the deployment pipeline“.

Continuous Delivery is the ability to get changes of all types – including new features, configuration changes, bug fixes and experiments – into production, or into the hands of users, safely and quickly in a sustainable way.

– https://continuousdelivery.com/

Continuous Integration is a prerequisite for Continuous Delivery.

The minimum activities required for Continuous Delivery, as defined by minimumcd.org, are:

• Use Continuous Integration​
• The application pipeline is the only way to deploy to any environment​
• The pipeline decides the releasability of changes, its verdict is definitive​
• Artifacts created by the pipeline always meet the organization’s definition of deployable​
• Immutable artifact (no human changes after commit)​
• All feature work stops when the pipeline is red​
• Production-like test environment​
• Rollback on-demand​
• Application configuration deploys with artifact​

Deployment Pipeline

The best description of deployment pipelines, and practical advice on how to implement them, I found in another excellent book Continuous Delivery Pipelines, How to Build Better Software Faster by Dave Farley. According to him, automation is the key… and is the engine that drives an effective Deployment Pipeline:

• Test Automation​​
• Build and Deployment Automation​​
• Automate Data Migration​​
• Automate Monitoring and Reporting​​
• Infrastructure Automation​

The simplest deployment pipeline should, after each commit, compile the code (if needed), run all unit tests, create a deployable artifact, execute acceptance tests, and enable deployment to production.

However, a deployment pipeline can do much more, such as:

• Static code analysis
• Enable manual testing
• Performance tests (e.g., latency, throughput, load)
• Data and data migration tests
• Security tests
• Reliability tests etc.

CI practices

I see many teams/companies have a Jenkins job that compiles source code, runs (a few) unit tests, creates an artifact – often a Docker image – and have a separate deploy job/button to deploy to the dev and production environments. And they will say they are “using” CI/CD. But most of them are skipping some of the CI practices and don’t have code in an always-deployable state, even as a goal, yet still think they are “using” CI/CD.

CI practices are not a menu where you can choose what you like and still have all the benefits CI can help you with.

Make the build self-testing

Test-Driven Development (TDD), or test-first development, is still an exception, and developers usually write tests after the code. Those tests are mostly unit tests (developer-oriented) and much fewer acceptance tests (user-oriented) that cover only parts of the functionalities. The test-after approach usually covers less functionality because the code is harder to test, and tests are complex to write and maintain. Such tests don’t provide fast and good-enough feedback to automate “releasability of changes” or “enable refactoring for sustained productivity.” Developers don’t trust such tests, so manual verification and team coordination are needed to decide when code can be deployed, which is never fully reliable, and more bugs reach production.

Everyone pushes commits to the mainline every day

Same as TDD, trunk-based development is still an exception, and almost everyone is using branches and pull requests with many PR reviews at the end of the sprint, so they are not practicing continuous integration by definition. They are missing the benefits CI brings, like “less time wasted in integration” and “enables refactoring for sustained productivity.”

Test in a clone of the production environment​

Some companies have a “static” copy of production, with test data already prepared in a database, where they deploy their applications and run tests. As a result, developers can’t run tests on their laptops, test preparation is complex and slow, and they regularly break other tests. Feature flags can’t be tested, and it takes a long time from commit to getting test feedback. This demotivates developers from writing tests, and over time, this negative spiral creates ‘legacy’ code that is hard to change.

Rarely does any company I know create, on demand, a “clone of production” – with the configuration needed for a suite of tests set up exactly as in production, where the tested application is deployed the same way as in production and then tested to determine the releasability of changes.

Usually, a Jenkins job starts the needed testcontainers during the integration test phase and tests parts of the application – or a “test” version of the application – that differ from the production application. These tests don’t cover the application artifact that will actually be deployed, nor do they test deployment, configuration, or dependencies (e.g., microservices) that aren’t properly mocked. Instead, some fake repository or adapter implementations are used that don’t exist in production.

The application pipeline is the only way to deploy to any environment AND The pipeline decides the releasability of changes; its verdict is definitive​

From what I’ve seen or heard, everyone has a workaround that allows deployment of artifacts that didn’t pass the Deployment Pipeline. Sometimes they create artifacts on their laptop and push them to the repository so they can be deployed. Other times, the pipeline itself allows deployment of code that hasn’t passed all required verifications.

This can happen when a “non-important” or “flaky” test fails, or when a dependency has a critical vulnerability, etc. Usually, the team says these problems will be fixed later, when there’s time, but the new feature is considered urgent and must be deployed ASAP. In practice, the team never has time to fix these issues, workarounds become the norm, and the deployment pipeline turns into a theater.

Keep the build fast

With microservices being so popular, build time shouldn’t be a major problem. Yet it’s common to see builds lasting half an hour or more.

In my experience (mostly with Java), if you create tests – unit tests, acceptance tests, etc. – that can run in parallel, it’s easy to have a deployment pipeline finish in under 5 minutes, excluding deployment. Just run everything in parallel: unit tests, acceptance tests, services with different feature flags enabled or disabled, and static code analysis.

A Deployment Pipeline must be built, not bought

A deployment pipeline automates your software development process and reveals both its strengths and weaknesses. When your practices are strong, the pipeline amplifies them, providing significant benefits. Conversely, if your practices are weak, the pipeline makes this very apparent – it can be difficult or even impossible to implement effectively.

This is why Continuous Integration and Continuous Delivery are so valuable: they encourage good practices and make problems visible early. A Deployment Pipeline is not a product you can buy or outsource; you must build it yourself, leveraging various tools.

In my experience, the best way to achieve both speed and quality in software development is to combine pair or mob programming with test-driven, trunk-based development, supported by a deployment pipeline that automates feedback on key aspects of the process. This approach provides rapid feedback, within minutes, on ideas and experiments through frequent commits and accompanying tests. It allows the codebase to evolve continuously through refactoring and enables the frequent, low-risk release of new features with minimal stress.

The post What It Takes to Fully Benefit from a Deployment Pipeline appeared first on ShiftMag.

The goal? Experiment with ElevenLabs technology and build something – business case optional.

The hackathon ran across two tracks:

• The developer track that focused on agentic workflows, real-time APIs, and enterprise-grade LLM integrations and essentially anything that pushes the technical boundaries of voice-enabled systems.
• The creative track encouraged teams to explore the artistic, unconventional side of ElevenLabs’ voice and sound tools – pushing them in directions unlikely to appear on a typical product roadmap.

While one track raced after technical brilliance, the other ran wild with imagination and creativity. Together, they proved exactly what the event set out to show: Europe’s engineers can innovate across both worlds when given the freedom to experiment.

Talent exists locally, but building globally is key

ElevenLabs’ return to Warsaw with this hackathon was intentional. As CEO Mati Staniszewski noted, this city isn’t just another dot on their global map:

This is where me and my co-founder Piotr Dabkowski first spent weekends building small experimental projects that would eventually evolve into what Forbes called the “multi-billion-dollar voice of AI.”

So, bringing the hackathon to Warsaw wasn’t just about shipping prototypes, it was about returning to the environment that shaped the company’s earliest ideas and inviting a new generation of builders to do the same.

Mati underscored something the broader tech community often underestimates: the talent is here – deep maths and CS backgrounds, strong ownership, and a mindset that gets excited by constraints.

Many of ElevenLabs’ most impactful contributors come from this region, and Mati’s message to founders and engineers was clear – don’t think locally:

Aim global from day one. Iterate in public. Move fast. And believe that teams here can genuinely compete with the sharpest builders anywhere in the world.

What teams created in 20 hours

Many teams gravitated toward conversational agents or creative audio experiments. DevTierUS from the US went with molecular design and drug discovery. Their project tackled a critical problem: how medicinal chemists search for alternative molecular structures without violating patents – an area where AI is already reshaping research workflows.

First, we focused on identifying bioisosteres – chemically modified structures that mimic the biological behavior of patented or expensive molecules. For pharmaceutical researchers, these alternatives are essential for maintaining efficacy while navigating complex intellectual property landscapes.

Despite advances in biotech, many medicinal chemists still rely on outdated tools – manual notes and siloed software. The team saw both a gap and an opportunity. As team member Pranav Iyer put it:

Vertical AI gets a lot of attention, but many fields still run on pen and paper. We saw a chance to bring AI into those workflows.

To build their solution, they kept the stack simple: TypeScript on the front end and Python on the back end. The innovation was in the pipeline. Drawing on teammates’ biotech experience (including one in large-scale drug discovery) they implemented a sequential AI-driven process: identify the molecule, break it into building blocks, and use AI to search massive chemical spaces for viable alternative fragments.

This approach surfaced dozens or even hundreds of substitutes – what once took days or weeks can now be done in minutes. You can check their video demo here and their GitHub on the link.

Another team, UK students now calling themselves HackAvengers, took the hackathon in the opposite direction. Their project combined education, gaming, and immersive voice interaction: a first-person language-learning game powered by ElevenLabs’ multilingual real-time voices.

Since the team shared an interest in games and languages, the concept came naturally, as noted by Natalie Chan:

Almost every hackathon we’ve ever done, we’ve had this underlying theme of games. What’s the best way to combine education and games? Language learning.

These personal experiences shaped the project’s ambition: to make language learning feel like entering a game world, not just completing exercises on a screen.

Technically, ElevenLabs handled voice interaction across 17+ languages, while Anthropic generated the dynamic 3D environments players enter. This was layered with Descartes, providing real-time AI-powered video streaming:

We wanted immersion. People are most engaged with what they can relate to… so we chose a first-person video game.

Their full demo presentation is available here, and you can try the game yourself at this link.

The €10.000 Winners

The hackathon’s €10.000 grand prize went to qForge, a team that turned voice into a fully interactive storytelling engine. The winners started the event with nothing, according to a group member.

Before the hackathon we basically didn’t have any idea. We spent the first one or two hours trying to figure out something.

What united them was a shared background in gaming. Their brainstorming explored D&D-style narratives and tower defense mechanics until one teammate suggested a direction that immediately clicked – storytelling.

The result: a short, voice-driven narrative and, more importantly, the foundation of a game builder anyone can use.

While some team members refined the story, another focused on the underlying engine, giving the project surprising depth for a one-day build. A major challenge – synchronizing sound effects with voice – was solved by defining clear interfaces, schemas, and types through Cloud Code, which sped up development. You can the demo of their game at this link.

A hundred ideas will always beat ten

At the end, Mati reminded everyone that innovation rarely comes from waiting for the perfect idea

Remember what Coinbase’s Brian Armstrong said: action produces information. The more teams build, test, discard, and rebuild, the faster they move toward something meaningful.

He highlighted that even the smartest engineers make the right call only part of the time, but those who create relentlessly – trying a hundred ideas instead of ten – dramatically increase their chances of stumbling onto something exceptional.

The insight resonated because the room was full of people who had just lived that philosophy, shipping ambitious prototypes on almost no sleep. It also shaped the judging.

While many teams delivered polished or highly technical projects, the €10,000 winners stood out for embodying Mati’s principle: originality paired with strong execution. Their concept didn’t play it safe, it showed the future of voice-driven experiences.

In that sense, the hackathon became a snapshot of what Europe’s builders can achieve when they’re given space to experiment. It showed that voice technology is no longer a niche tool, but a creative surface for teams working across science, gaming, storytelling, and beyond. Builder-first hackathons remove rigid roadmaps and replace them with speed, curiosity, and real experimentation. In a short time, teams ship, test, and learn far more than they would in months of planning.

For companies, this creates an unusually honest feedback loop. Builders push the technology in unexpected directions, surface edge cases, and uncover use cases that rarely appear in product meetings. At the same time, these events strengthen local ecosystems, attract top talent, and send a clear signal that serious innovation can happen here. That combination is precisely why more companies should be organizing events like this across Europe.

The post We Should All Do What ElevenLabs Did With Its VoiceAI Hackathon appeared first on ShiftMag.

A couple of weeks ago, while we were having a casual conversation over a cup of coffee, one of our veteran engineers said something that piqued my interest.  

“This reminds me of the time when boiler broke down in the Zagreb office, and production went down.” – he made a casual remark.

“I beg your pardon?” – I expressed my interest, and my left eyebrow rose slightly to signal disbelief. 

“We experienced major degradation of service across all products served over data center in Frankfurt.” – he continued in a neutral tone of voice, as if he was reading the airport announcement for an upcoming flight. 

“You are not being serious!” – I exclaimed in a shocked tone of voice, as if I realized I was late for a flight. 

“Of course I am serious!” – he said.

Here’s the full story.

Boiler in Zagreb crashed the servers in Frankfurt

“You remember the old office building in Zagreb, the skyscraper with the giant advertisement for toilet paper?” – he asked me. 

“Of course I do, I worked there for a couple of years. Very appropriate ad for the state the building was in.” I answered 

“Well, there was an old rusty water heater in the basement, and it broke down” – he said. 

The next thing we know is that we are getting a ton of angry calls from our customers. I don’t remember the details, but it was connected somehow, a boiler in Zagreb crashed the servers in Frankfurt.

“Sounds plausible.” – I stated calmly, convinced he was pulling my leg.

“Who can tell me more about it?” – and provoked him to continue, which he did without hesitation.  

The authorization server went down first

“I think the authorization server was the first to crash; it was handled by One API team. The team was disbanded years ago, but most of the people who worked in the team still work here, so you can try talking to them.” – he gave me names, and I jotted them down in my notebook.  

It made sense that an issue with the authorization server would affect all the products. It is an obstacle all aspiring requests must overcome, whatever their place of origin may be, if they wish to mature and become successful responses one day.

But how does the boiler fit in the picture? Did we start as a water heater provider, and then pivot to communication platform space?

The code of the authorization server I checked out provided no clues, so I sent a Slack message to the former One API team leader. 

“I remember nothing!” she replied and moved on with her duties, ignoring further prompts, so I decided to continue my investigation elsewhere.

Boredom led me into the dark archives of Jira

As coding agents and other AI tools are doing my work now and I have nothing better to do, I started digging through git history and Jira archives.

After a couple of hours I found a clue, there was a ticket with description Reimplement the logging and email adapter, so that we avoid the issues such as the one we had when there was no electricity in Zagreb office.

There was a link to a pull request attached to the ticket; the username of the author belonged to a prominent figure, so I sent a Slack message to our Engineering Director: “We need to talk about a pull request you made to the auth server ten years ago.” Shortly after, he invited me to his office. 

“It was a warm Spring day, the Sun was shining, the birds were chirping, the children were playing and production was down. We were drinking in the pub.” – he started reminiscing, “The production had a habit of crashing each time we went for a beer.”  He confirmed that there was a serious outage and that it was connected to an email server; he couldn’t quite remember how the boiler fit into the story.  

“Why was authorization server sending emails?” – I asked.  

At the time we implemented a brute force attack detection mechanism that could ban or lock attackers. Sometimes a legitimate customer would get banned, so they would contact their dedicated account managers to help them. When a user, or a combination of a username and an IP address to be more precise, was blocked the authorization server would automatically send the data that might come in handy to the account manager.

“I see, so you mean something like detailed description of our current algorithm, automation and telemetry that helps resolve the issue but edited out because of security reasons and not breaching NDA via public magazine article?” – I asked only to show off my understanding of our security infrastructure in hopes he would be impressed and commend me to someone who is responsible for raising my salary.  

“It was nowhere near that complex, we were not operating on this scale, and such issues would not happen very often, unless someone got too enthusiastic with pen testing” – he responded bluntly and with a look on his face that I interpreted as him having no intention to commend my deep understanding of our security infrastructure to someone responsible for the pay raise.

Then he shared a couple of interesting production outage stories from the early days and gave me advice to talk to our first system administrator in the company, since that gentleman was maintaining the email server at the time.  

Let’s pay a visit to our SRE team

As I talked to the system administrator, he shared stories that can put this one to shame: duck taped disks, convincing people to put servers somewhere where rain won’t affect them, crashing the premises of a 3^rd party vendor (euphemism for a guy who has a couple of servers at home and rents them out to small companies) who is putting server offline to make a firmware update during peak traffic time.

He could not remember the boiler issue but recalled there was an unrelated air conditioner incident one summer in the same office building when an air conditioner cooling the centralized control system for other air conditioners overheated because it was installed on the rooftop.  

I decided to pay a visit to our SRE department as their lead engineer was a member of the One API team once upon a time.

The SRE department is taking care that our global platform, spanning several continents and dozens of data centers, works reliably. They are working on early detection and quick mitigation of service degradations that can happen as we make thousands of changes to production every day.

Surely, their lead engineer has nothing better to do than to talk to me about a production issue from a decade ago.  

There was some electrical maintenance in the office building, and right before it someone reconfigured auth server to send e-mails to a standby instance in Zagreb office, twenty-one thousand four hundred and eighty-seven emails were stuck in the queue. Can’t talk now, sharks are eating network cables again.

…he said, hurrying off with his coffee. 

Boiler blew, mail server died, everything froze

I have finally connected all the dots and found someone to confirm the theory. 

Our principal engineer – once a junior contributor to the auth server – explained what happened when he returned from parental leave:

The same thread that banned the user also sent the email synchronously via RPC, with no timeout. When the boiler broke, it tripped the circuit breaker, cutting power to the floor. The mail server was down, and so were we – waiting in the pub for the electricity company. When customers complained, we were one thread dump away from realizing all request-handling threads were stuck waiting on the mail server.

“The circuit breaker broke, but there was no circuit breaker around the call to mail server!” – I joked nerdishly.

“Exactly! After the electricity company fixed the issue, in order to increase reliability someone duck taped the circuit breaker. If we had those things back then, could you imagine what would status page and post incident review look like?” – he asked laughingly as we continued to entertain that thought. 

Status page – Frankfurt: Service degradation across all products 

We are experiencing service degradation across all products due to boiler malfunctions. The plumber is on his way to the office building, and we expect to resolve the problem shortly. We apologize for any inconvenience this may cause. 

Postmortem: Boiler malfunction (incident #420)

Date: April 1, 2010 

Authors: Alice, Bob 

Status: Complete, action items in progress 

Summary: The boiler broke down and all products experienced service degradation for 2 hours 

Impact: A large number of messages never went out, there was a noticeable financial impact, new valve on the boiler and 1000 dollars for one hour of plumbers’ work 

Root causes: Cascading failure due to a water heater malfunction in Zagreb office building, the floor lost electricity, and so the email server went down. At the time the authorization server in Frankfurt was configured to send emails over that email server. The calls to the email server were sent synchronously with no timeout, so all threads were blocked on the call to the email server, and there were no available threads to serve the incoming requests. 

Trigger: Malfunction in the boiler, waiting for the analysis from the plumber. 

Resolution: Authorization server reconfigured to use the email server instances in Frankfurt data center. 

Detection: The customers complained before we detected the issue.  

Action items: 

1. Batch emails and send them asynchronously 

2. Introduce a circuit breaker around RPC call 

3. Duct tape the circuit breaker of the water heater 

4. Put the electrician and plumber’s phone number on speed dial 

Lessons Learned

Don’t couple the production traffic to the boiler.  

Timeline

2010-04-01 (all times UTC) 

• 9:45 – deployment of authorization server in Frankfurt, it starts using mail server in Zagreb due to a configuration mistake 

• 10:32 – the boiler burns out and triggers an issue with electrical supply to the building, the rack with the email server also loses power 

• 10:45 – the office building manager calls the electricity company  

• 10:50 – One API team goes for a beer in the nearby pub 

• 11:05 – a young and enthusiastic application security engineer hears about the new brute force detection mechanism and decides to test it 

• 11:30 – electricians blame the plumbers  

• 11:35 – OUTAGE BEGINS a lot of request handling threads are waiting for response from the email server, authorization server starts throttling incoming requests 

• 11:45 – customers start calling the customer support, the line is busy we are trying to reach the plumber 

• 11:50 INCIDENT BEGINS all of request handling threads are in waiting state, no traffic is processed 

• 12:00 – in the pub One API team jokes about how the last two times they went for a beer production went down 

• 12:05 – plumber answers the telephone and starts negotiating his hourly rate 

• 12:30 – plumber agrees on an hourly rate 

• 12:45 – One Api team notices missed calls from the customer support team 

• 12:55 – One API team rushes back to the office and bumps into team of electricians telling them they can’t go in right now 

• 13:20 – One API team makes a thread dump and figures out the issue 

• 13:35 – the configuration of authorization server is changed 

• 13:45 – OUTAGE MITIGATED the service stars recovering  

• 13:50 – INCIDENT ENDS  

• 15:55 – the plumber enters the building  

• 16:05 – the plumber leaves the building after replacing the valve on the boiler 

The post Postmortem: The Boiler Incident appeared first on ShiftMag.