Why would you, as a developer, fly halfway around the world to hear something you could Google in minutes?

“Because there’s more to it than just getting plain information,” says Mark Hazell, organiser of Devoxx UK and co-founder of Voxxed.

Some things just can’t be replicated online

Conferences feel like one of the few places where simply showing up still counts. In a way, they’re a throwback, a reminder that not all value happens behind a screen.

And that’s precisely what makes them stand out: remote work offers undeniable flexibility, but it often fragments our attention. It’s hard to find real focus, especially if you’re trying to keep a healthy work-life balance. At a conference, that changes, as Mark points out.

Simply not being distracted by incoming mail or slack messages is worth its weight in gold in terms of the knowledge you take away.

The person next to you might be facing the same problem, or they might have already solved it. That kind of closeness makes learning immediate, practical, and way faster than online.

Many people tell me they watch a session on-demand from Devoxx UK and wish they could be in the room so they can chat with others who are facing similar challenges or are even further along in finding solutions.

But conferences are expensive…

Let’s face it: conferences aren’t cheap. Between tickets, flights, and hotels, the costs add up fast. And with companies tightening budgets and cutting back on travel, that expense really matters. If you don’t get real value in return, it can quickly feel like a waste of both time and money.

Mark doesn’t deny it. Instead, he reframes the question: if you take your team to the right conference, you’ll see a strong return.

The keyword here is well-chosen:

I do think it’s key to research up front and find the conference that accelerates learning and problem solving in ways truly relevant to those attending. That way, instead of weeks of trial and error, your team can spend a day or two at the conference and return with practical techniques, ideas, and tooling suggestions that boost productivity and quality.

Picking the right conference is all about fit. How long will your team be out? Is the ticket worth it? Will they meet people facing similar challenges? That’s where the real value is, says Mark. Plan ahead, and early bird tickets, flights, and hotels cost a lot less than last-minute bookings.

Big stages or small communities?

It might seem that large flagship conferences have the upper hand with bigger budgets, bigger names, and more production. And in some cases, that’s true, Mark admits: “If a conference is run by a large company with deep pockets, it can be more financially resilient.”

But that’s not the model Devoxx relies on, its strength comes from the community: they rely on a big team who volunteer their time and help them pull together all of the content, shape how the event looks and feels, and execute it on the ground.

In fact, many of today’s most respected conferences began as small, grassroots initiatives, including Devoxx itself, which grew from the London Java Community.

And for Mark, the real distinction isn’t size – it’s about quality and intent:

Whatever the size of the event, the content has to stay balanced and neutral. Without that, scale doesn’t mean much.

When people feel welcome, real connections follow

Modern conferences sit at the intersection of learning, hiring, and business. Sponsorships and recruitment are part of the reality, especially in expensive cities like London. But Mark doesn’t see it as a trade-off between developers and companies:

I prefer the notion of weaving strands together to create a fabric that everyone is part of.

That means creating an environment where attendees benefit from sponsors being present and sponsors benefit from genuine interaction with the community.

That same philosophy extends to how Devoxx grows by creating real opportunities for first-time speakers, helping them gain experience and build confidence. Many return to mentor the next group, creating a self-sustaining cycle that supports the broader developer community.

When there’s no barrier, people talk more freely, ask more questions, and connect naturally, Mark says.

Our philosophy is to create an environment where everyone is equal (sorry speakers, that means no private room out back to go hang out in), everyone is welcome and everyone is respected. This is noticeable and means the event has this really special, open vibe to it.

As Mark puts it, when people feel welcome and respected, they talk, share, and enjoy themselves, and meaningful connections naturally follow. “Sure, we do stuff like hosting evening socials, a party, a pub quiz,” he says, “but it’s really the collective buy-in from everyone to welcome and respect each other that makes all the difference.”

ShiftMag is recognized as a friend of the Devoxx UK conference.

The post Tech Conferences Aren’t Dead. But Why We Go Is Changing. appeared first on ShiftMag.

How are CTOs feeling about AI?

According to Andy Skipper, founder of CTO Craft, they’re experiencing fear, uncertainty, and doubt.

And if the technical leaders of companies are feeling that way, what can the rest of us expect? Certainly, we dream of productivity boosts and an AI El Dorado – but that’s not the reality.

That’s why we sat down with Skipper to talk about how CTOs should manage expectations for AI, and how to navigate the hype versus reality.

Stakeholders and investors are watching CTOs closely, and the pressure is rising

Many CTOs, Skipper notes, are navigating intense pressure from non-technical stakeholders and investors alike, especially with the massive resources being invested in AI and LLM technologies.

He’s a bit careful about this:

AI is not going to reduce costs or increase productivity in the way some non-technical people think just yet. It’s getting there, but it’s not there yet.

At the same time, Skipper points out a surprising upside: AI is giving engineering leaders a chance to reconnect with the code and architecture without writing all the code themselves:

One of the things you have to accept as an engineering leader is that you are going to get further away from the code the more senior you become. AI gives people an opportunity to get back to architecture and development work, even if they aren’t coding themselves.

CTO role can be isolating

When Skipper became a CTO for the first time, he quickly realized just how isolating the role could be. There was nowhere for tech leaders to share challenges, get support, or navigate the non-technical side of the job.

That gap inspired him to start CTO Craft, now a community helping senior engineering leaders navigate team dynamics, strategy, and AI.

When I was a CTO for the first time, I didn’t have somebody who I could talk to about the issues I was seeing or compare notes with people who had similar challenges. That’s what CTO Craft is all about – helping people understand where the challenges come from and understand they’re not alone in having those challenges.

As a coach and mentor, Andy works closely with CTOs around the world, helping them deal with issues like burnout, communication with nontechnical stakeholders, and, lately, how to adapt in the AI era.

The most common CTO mistake? Always chasing the newest technologies

Many first-time CTOs struggle with burnout, overextending themselves to shield teams from stress, and balancing hands-on coding with high-level responsibilities. He explains:

A lot of the people that I work with directly are suffering from burnout. First time CTOs commonly miss out self-preservation. And usually that’s a combination of too much expectation of their own energy levels, their own abilities, backlogs…

And after overextending themselves, first-time CTOs often make another common mistake: chasing the newest technologies. While adopting the latest tools and frameworks can seem exciting, Skipper warns that it’s not always the best choice for fast-moving teams trying to scale.

“Using bleeding-edge tech can slow you down, make systems harder to maintain, and even complicate hiring because the talent pool for newer technologies might be limited,” he explains.

As a coach, Skipper says these are just some of the recurring challenges he sees among engineering leaders, alongside a range of other operational and people-related issues.

Engineering skills alone won’t make you a CTO

For aspiring engineering leaders, Skipper highlights that growing into a successful CTO requires more than technical excellence: commercial understanding, communication, coaching, and vision-setting are just as crucial:

The difference between a good engineering manager and a great CTO is understanding how technology drives business success, while still inspiring and guiding your teams.

But technical and business skills are only part of the picture. Motivation and team management are equally critical. Skipper stresses that not everyone is motivated by the same things, and leaders need to understand individual drivers:

Having a vision in the first place is very important. But when it comes to actually bringing individuals along on the journey, they all need to be worked with differently. You can’t just set it and expect everyone to be motivated.

He also warns against a common mistake among CTOs: trying to shield their teams from the challenges of a pivot or rapid change. While the instinct is understandable, it often backfires and drains the leader’s emotional energy. Instead, transparency and realistic communication are key:

Being transparent, being realistic, measuring your words, not being super negative about everything, but still being realistic, I think all these things are really important.

The need for a support network, not another tech stack

Skipper believes resilience and peer support are crucial for engineering leaders navigating the complexity of the CTO role. Sharing experiences and learning from others can help leaders realize they’re not alone when facing difficult decisions.

Looking ahead, however, he admits that the pace of technological change makes it hard to predict what the role will look like in the future.

Five years from now, I honestly have no idea what the role of a CTO will look like. The way we build software is already changing rapidly, especially with AI. But the fundamentals like setting a vision, communicating it clearly, and connecting technology with business outcomes, will always remain essential.

For Skipper, that uncertainty makes peer support crucial: it helps leaders adapt, learn, and navigate a fast-changing profession.

Ultimately, he believes the most important skill for CTOs is the ability to keep learning and tackle challenges without going it alone.

*Infobip, the global communications API leader that launched ShiftMag, was an Event Partner at CTO Craft 2026.

The post CTOs Face Pressure to Deliver AI Gains, but Productivity Isn’t There Yet appeared first on ShiftMag.

Honestly, even today, it still sounds a little… absurd.

That is, until I heard directly at the Pragmatic Summit in San Francisco that’s happening right now inside OpenAI.

Vijaye Raji and Thibaut Sottiaux from OpenAI say AI is shifting development from manual coding to guiding AI teams (setting goals and guardrails) while speeding up work and keeping core roles essential.

Close the laptop. Join the meeting. Come back to finished code. 

Raji’s (CTO, Applications, OpenAI) been at OpenAI for only six months, and already he’s seen Codex go from just a tool, to an extension, to an agent… and now it actually feels like a teammate.

Inside OpenAI, they recently launched something called a Codex Box.

Basically, engineers can grab a dev box on the server, fire off prompts, and let the system run things in parallel while they just work from their laptop. Sounds amazing, right?

Some engineers are using hundreds of billions of tokens per week across multiple agents – not for fun, but because that’s just how they build now. Raji said:

Software development inside OpenAI isn’t a single-threaded human loop anymore. It’s parallel. And that is going to become the new normal.

Designers and PMs are writing code. What’s going on?

Sottiaux (Engineering lead for Codex, OpenAI) described how the Codex team works today.

“It changes constantly. Almost week to week,” he said. “We look for bottlenecks, solve them, and then a new one pops up.”

At first, the slowest part was code generation, then it became code review, and now the friction often comes from understanding user needs faster – parsing feedback from Twitter, Reddit, and SDK experiments and turning that into product direction.

Speed up coding, and suddenly reviews become the bottleneck. Fix reviews, and CI/CD slows things down. That rhythm has become normal. Instead of debating every trade-off in design docs and discarding alternatives, teams try multiple implementations in parallel and focus on what actually works.

“Trying things is cheaper,” Sottiaux added. “So we try more things.”

And the rules? They’re blurring. Designers are shipping more code, PMs are writing and testing ideas, and it’s not that roles disappear – everyone’s capabilities are expanding.

Usually the problem is the prompt, not the system

What about long-running, autonomous tasks?

AI coding tools might seem like advanced autocomplete – type a few words, get a few lines back. Helpful, yes, but still reactive. Sottiaux challenged that:

Give the model a meaningful, well-defined objective, and it doesn’t just respond – it runs, for hours.

Inside OpenAI, the model runs on its own for hours, sometimes producing full reports. Engineers review the results, pick what works, and feed it back – this isn’t just suggestions anymore, it’s delegated execution.

There was also an unusually honest anecdote shared during the discussion: a researcher admitted that whenever he thought he was smarter than Codex, it turned out the problem was the prompt, not the system.

The bottleneck isn’t typing speed – it’s defining the goal clearly.

AI tools accelerate work and ahape AI-native engineers

During weekly analytics reviews, teams don’t assign follow-ups, they just trigger Codex threads. “Twenty minutes later, the answers are ready before the meeting even ends,” one leader said.

In high-severity incidents, Codex gets effectively paged into calls to help figure out what went wrong and suggest the fastest recovery. “It’s like having small consultants working quietly in parallel,” they added.

So what does this mean for junior engineers?

OpenAI is hiring new grads and running a strong internship program, believing the next generation will be AI-native and comfortable with these tools from day one.

At the same time, strong foundations, guardrails, and code reviews remain essential. As they put it, “Foundations will never go out of fashion.”

Engineers will guide AI teams, speeding up code without touching every line

Vijaye has spent more than two decades in the industry. He has lived through the rise of developer tools, the shift to higher-level abstractions, the mobile wave, and the social platform era. In his view, none of those transitions felt quite like this one.

What makes the current moment different isn’t just what the technology can do, it’s how quickly it is evolving. The speed of change, he suggested, is on another level entirely.

And Sottiaux expects that pace to accelerate even further.

In the near term, I anticipate another order-of-magnitude jump in development speed, enabled by networks of agents collaborating toward large, shared goals. Instead of a single assistant responding to prompts, entire clusters could work together on complex builds.

As systems get more complex, engineers stop checking every line of code and start setting constraints, guardrails, and validating outputs. It’s less about manual control and more about guiding the system, and working through a single assistant that coordinates all the agents behind the scenes.

Whether this ends up being the smartest leap in the industry or a step we rushed into too quickly, only time will tell.

The post OpenAI Shares How They’re Turning Engineers into AI Team Leads appeared first on ShiftMag.

“If AI can replicate almost anything quickly and cheaply, what’s the point of building anything at all?” Chip Huyen asked at the start of her talk at the Pragmatic Summit.”

And that question carries weight because she isn’t a casual AI observer: she’s an ex-Netflix researcher, former NVIDIA core developer, and an author who explores AI engineering.

She told us a personal story: after building a product, someone recreated it with AI almost immediately.

That moment forced her to confront hard questions – if anything can be copied, where’s the moat, the incentive, or the point of the effort?

“I built a product – and someone copied it with AI”

After she built a product, someone emailed her a clone generated with AI. The message read: “I love what you’ve built. So I used AI to recreate exactly that. And here’s the link.”

She described her reaction bluntly: “I’m flattered. But also, why the f**k?“

That moment crystallized a new reality: if replication requires minimal effort, traditional defensibility weakens. Technical execution no longer guarantees leverage. She framed the shift clearly:

If you can describe a software, then AI can build it for you. The constraint moves upstream. The critical question no longer asks how to build, but what to build.

The real advantage comes from context

But Chip pushed back against the idea that AI erases all opportunities.

Common problems are quickly handled by AI, but challenges with nuance and context remain – and those are where real value lies.

She illustrated this with chatbots: U.S. users expect instant replies, while in parts of Asia, waiting signals respect. These nuances matter. As AI handles common solutions, advantage goes to those who master context (cultural, behavioral, or domain-specific) where generic automation fails.

Engineering culture is changing

Workflows built around humans writing code (pull requests, line-by-line reviews, mentorship) don’t work the same when AI generates large chunks.

Junior developers may disengage, and even seniors wonder “How do I give feedback to my AI?”

The focus moves from polishing code to designing instructions and systems. Mentorship now teaches structured thinking in a human–AI–human loop.

And Chip didn’t have an answers about job displacement or copyright, she acknowledged uncertainty.

I do think it’s a bit scary and I don’t really know what the futures look like but builders still shape tools that affect labor markets, creative industries, and institutions.

When AI acts, who’s accountable?

As AI systems move beyond code editors, the risks grow. Chip drew a hard line: if AI acts in the real world (like a car hitting a pedestrian), mistakes can’t be undone.

The question isn’t if AI can act, but whether it should without strict limits.

Engineers now must build guardrails, monitoring, and escalation paths from the start – autonomy demands containment.

Enjoy building, but choose wisely what to build

Chip closed on a personal note:

Fundamentally, I enjoy building. It just brings me joy.

In an environment where execution becomes cheap, intrinsic motivation gains weight. She compared building to music that creates tension and resolution, and to assembling Lego sets for friends. Not every project requires a moat. Not every product needs revenue logic.

Her final reframing carried strategic weight. If replication becomes trivial, the advantage may belong to those who decide what deserves to exist. Vision, context, and responsibility define the new frontier. Execution follows.

The post Chip Huyen: To Build or Not to Build – When AI Can Do It All? appeared first on ShiftMag.

She presented her latest research, Measuring Developer Productivity & AI Impact, based on three months of data collected through February 1.

The research surveyed 121.000 developers across 450+ companies. A striking 92.6% of them use an AI coding assistant at least once a month, and roughly 75% use one weekly. Clearly, AI isn’t just a side experiment anymore, it’s part of the workflow.

Here are the top takeaways I found most compelling from Laura’s research.

The 10% productivity plateau

The first thing most people think of with AI assistance is saving time. According to the research, developers say they’re saving about 4 hours a week – pretty much the same as Q2 2025, with Q4 2025 numbers sitting around 3.6-3.7 hours.

It looks like the time-saving boost has leveled off. Productivity shows the same pattern: it jumped around 10% when AI first took off, and since then, it’s stayed steady at that level.

What’s really shifting is the amount of “AI-authored code” – that is, code that gets merged into the main repository or production environment with little to no human intervention. Laura breaks this down using the latest data:

Looking at about 4.2 million developers between November 2025 and February 2026, AI-authored code now makes up 26.9% of all production code – up from 22% last quarter. Daily AI users are also hitting a milestone: nearly a third of the code they merge, which passes review and goes into production, is written by AI.

One example Laura loves to highlight is how AI is speeding up the onboarding process:

Looking at the data quarter by quarter, from Q1 2024 through Q4 2025, onboarding time has been cut in half. Specifically, we’re measuring it by the “time to the 10th Pull Request (PR).”

This metric (widely seen as a key sign of successful onboarding) has now been cut in half. Because of that, Laura sees AI as a powerful tool for getting people up to speed, whether it’s new hires, engineers switching projects, or even non-engineers stepping into technical workflows.

The faster someone gets up to speed, the longer the productivity boost lasts, usually for at least two years. This points to a bigger trend: AI is helping developers get up to speed faster, reducing mental load, and making it easier to onboard into complex codebases.

In struggling organizations, AI exposes flaws instead of fixing them

Laura also pointed out a part of the research that looks at how AI impacts company performance. This segment analyzed data from 67.000 developers between November 2025 and February 2026, and the findings are strikingly divided.

Some companies are dealing with twice as many customer-facing incidents, while others see a 50% drop.

The difference comes down to how AI is used: in well-structured organizations, AI acts as a “force multiplier,” helping teams move faster, scale with higher quality, and boost reliability. In struggling organizations, AI tends to highlight existing flaws rather than fix them. Based on this, Laura concludes:

Transformation is uncomfortable. Organizations that were ready to quit their cloud or agile transformations are now giving up on AI transformation, too. It’s difficult to look at an entire organization and realize that something fundamental must change to see a real impact on the bottom line.

According to her, adoption alone doesn’t guarantee results, just using the tools doesn’t automatically improve an organization:

This is really a management problem. The hype made it sound like just trying AI would automatically pay off. But so far, most tools have been used for individual coding tasks. To see real impact, we need to use AI at the organizational level, not just for single tasks.

Laura also touched on the most popular AI tools among developers, specifically highlighting Codex:

The Codex desktop app launched on February 2 and has already topped one million downloads, with a 60% growth rate just last week. They recently rolled out GPT-5.3 Codex. Inside OpenAI, 95% of developers use Codex, and those users submit roughly 60% more Pull Requests each week.

As a real-world example, Laura highlights Cisco, where 18.000 engineers use Codex daily for complex migrations and code reviews. This has cut their code review time in half. But Laura cautions that AI won’t fix deeper organizational issues unless you tackle those problems head-on, and that starts with acknowledging they exist.

Since organizations remain constrained by human and systemic friction, Laura notes:

I am skeptical of any technology’s promise to improve performance without addressing those underlying constraints. If we don’t solve our systemic issues, we’ll just “carry them into space with us.” The real question isn’t how to colonize Mars, but how to achieve actual organizational impact.

DevEx is more important than ever

To wrap things up, Laura revealed the secret to success for those who are “winning” with AI:

1. They set clear goals and measure results.

2. They recognize that Developer Experience (DevEx) matters more than ever.

3. AI succeeds when factors like fast Continuous Integration (CI), clear documentation, and well-defined services are in place.

At the end of the day, getting real organizational results means treating AI as a company-wide challenge. The research shows the barriers aren’t technical, they come down to change management and leadership support. Laura sums it up:

Successful organizations experiment by tackling real customer problems. Exploring Mars sounds exciting, but it’s not sustainable – it’s expensive and distracts from the core business. Focus your experiments on the customer to drive meaningful results. After all, somewhere, something incredible is waiting to be discovered.

The productivity gap isn’t unique. Read why 84% of developers use AI, but most don’t trust it. The trust issue is part of the equation.

The post This CTO Says 93% of Developers Use AI, but Productivity Is Still 10% appeared first on ShiftMag.

From his experience leading AI product teams, Andrew Mende (Senior Product Manager, Machine Learning at Booking.com) explained what it truly takes to ship LLM-based products in production.

Making AI products reliable requires new workflows

For Mende, the buzz around AI is a rare shift, like the rise of smartphones. But what does it mean for product teams?

This moment unlocks new ways of solving customer problems that were previously impossible due to technical constraints.

He was clear: traditional product management approaches often fail with AI-driven products.

LLM-based systems behave differently, demand new workflows, and bring new types of risk.

Unlike deterministic software, LLMs are probabilistic (identical inputs can produce different outputs), making experimentation easy but production readiness challenging, and forcing teams to rethink how they test, evaluate, and monitor features.

One of the biggest traps, Mende explained, is confusing a successful prototype with a scalable solution:

It’s easy to paste a prompt into ChatGPT and see results; much harder to make it reliable across thousands of real customer inputs.

Teams need structured datasets, big tables of real customer examples, to track accuracy, spot regressions, and see if changes actually work. Without them, it’s all guesswork.

Focus on accuracy, cost, and speed

Mende’s practical approach to model selection focuses on accuracy, cost, and latency: start with the most capable model to see if the problem can be solved, then move to smaller or faster models to optimize performance.

This requires testing multiple configurations (context size, prompts, and parameters) since even small changes affect results. Beyond the model, context selection, prompt instructions, and external tools are critical:

For example, when a customer asks about a specific order, the system should fetch real-time data instead of relying on static knowledge. This combination of LLMs and tools turns simple prompts into full systems, but also increases complexity and maintenance costs.

LLMs can transform how users interact – if teams build the right infrastructure

Mende concluded his How to Web lecture by saying LLMs shine by transforming user interaction: for the first time, digital products can understand plain language, turning customer requests directly into actions.

This shift brings digital experiences closer to human conversations and enables new product patterns that were out of reach just a few years ago.

The challenge now, Mende explained, is not whether LLMs work, but whether teams are willing to build the evaluation, monitoring, and infrastructure required to make them truly useful.

The post Forget the Model, It’s Workflows That Make LLM Products Run appeared first on ShiftMag.

As one of the largest and most popular developer conferences in Europe, this event brings together thousands of developers from around the world on the Croatian coast. It offers hands-on sessions, live coding, and valuable networking opportunities in a vibrant, global setting.

A call for speakers is now open, welcoming creative thinkers and experienced developers to share their insights. Here’s what our participants are most excited about:

• Practical solutions and actual use-case scenarios.
• Fresh and beneficial insights (coding techniques, methodologies, perspectives).
• We’re all about live coding!
• Engage, entertain, and surprise us.
• Present your thoughts, challenge our beliefs, or motivate us.
• English is the medium of communication for the event.

The call for speakers is open till 22 May 2026 and will be reviewed by a committee from the Developer Ecosystem of Shift. Speakers will have the chance to present practical solutions, fresh coding techniques, and challenge the audience with new perspectives.

For more information and to submit a proposal, visit the official Infobip Shift Conference website.

The post Want to speak at Infobip Shift 2026? Here’s your chance! 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.

Around 80 developers descended on the Infobip Zagreb campus for the third SheepAI hackathon. Split into 20 teams, we spent nine intense hours building AI-powered tools to address one of the most stubborn problems of the modern web: information overload.

From Silicon Valley inspiration to Croatian innovation

SheepAI was founded by Viktor Gabaj (Software Engineer, Bugatti Rimac), Tonči Žilić (Product Strategist and Startup Business Consultant), and Domagoj Vuković (Software Engineer, VK Media) after they experienced the hackathon culture firsthand in the United States.

Determined to capture that same spirit in Croatia, they organized the first SheepAI hackathon in December 2024 with less than a month of preparation. With a successful follow-up in Zadar and now Zagreb again, it has grown into an established event in the Croatian scene.

9 hours, 20 teams, 1 goal – help AI filter information reliably

This edition was sponsored by Fonoa, Infobip, Farseer, Ignit, and ABC Bootcamps, with prizes including cash awards and participation in the ABC startup bootcamp in Silicon Valley.

Engineers from Fonoa presented the challenge: how can AI help users navigate the flood of online information without falling victim to hallucinations? We were tasked with building solutions around TheHackerNews.com, a cybersecurity news site. This was also a chance to demonstrate practical AI applications in a domain where accuracy is critical.

We had nine hours to build our solutions and submit a complete package: source code, a one-minute video demo, and a presentation. The judges then shortlisted seven teams for live demonstrations before selecting three winners.

The top prize went to Cyber Shepherd, built by Ivan Židov and Luka Minđek. Their solution scrapes the news, categorizes threats, and allows users to subscribe to specific categories, with notifications delivered through channels like Slack.

The project demonstrated technical skill and smart use of AI tooling to ship a polished product in a single day, impressing everyone (including the judges) – a well-deserved win!

Insights from the trenches

While the judges deliberated, we heard from two speakers with firsthand startup experience. Davor Tremac (CEO, Fonoa) shared lessons from his journey through several startups, including Uber, before founding and scaling Fonoa, with particular focus on the why and how of landing enterprise clients. Luka Mijatović (CTO, Farseer), offered a look into the company’s evolution, tech stack, AI integration strategy, and what lies ahead.

High-intensity fun

Well-run hackathons are always high-intensity affairs: a chance to meet and compete (in a friendly manner) with dozens of interesting, creative, and highly skilled people. SheepAI delivered on all that. It was exhausting, bursting with creativity and fun! And as the cliché goes, the true prize was indeed the new friends we met along the way.

Overall, the SheepAI hackathon was a blast, and I know I’ll be looking forward to the next one!

The post Inside SheepAI Hackathon: 80 Developers vs. Info Overload appeared first on ShiftMag.

At the Web Summit conference, Andrew Filev, CEO of Zencoder – a company that achieved a $2.25B exit – debunked that myth. He called it blind hustle, a mindset that destroys long-term innovation and sustainable growth.

For engineers and founders navigating fierce competition, Filev argues that success depends not on the number of hours worked but on the quality, focus, and sustainability of effort. He calls this approach the smart grind.

The toxic cult of 996

Filev highlights how overwork has become normalized, especially through the infamous “996” schedule, 9 AM to 9 PM, 6 days a week, a routine common in hyper-competitive tech markets.

This panic-driven culture often disguises itself as passion but ultimately stunts professional growth.

Creative output peaks only within a certain range; beyond that, productivity nosedives. Those extra hours often add little value and instead drain the energy needed for rest, reflection, and strategic thinking.

Many skilled engineers fall into what Filev calls the “over-engineer’s trap,” where they chase hours instead of impact. In doing so, they trade clear, strategic thinking for the illusion of productivity, creating overly complex solutions when simpler ones would suffice.

Even stepping away can feel difficult. Filev recalls taking vacations yet constantly feeling pulled back into work, a cycle that slowly erodes creativity. Innovation, he argues, depends on perspective – and perspective only comes when you truly disconnect.

The “smart grind” mindset

Instead of chasing blind hustle, Filev promotes the smart grind, which drives lasting, industry-defining success.

The myth of the “overnight success” fuels burnout. Filev explains that every transformative company, including his own, grew from years of consistent, intentional work. Real progress demands a sustainable pace, not a desperate sprint.

I’d rather work in a way that increases the law of probability that success finds me.

True success isn’t a lottery. It’s the outcome of steady, high-quality decisions that compound over time.

Think clearly and direct AI effectively!

Shift your focus from how long you work to what you work on and how you approach it.

Start by recognizing patterns, study market trends, and your team’s performance to make smarter, more informed choices.

Then, guide your direction by ensuring every hour of effort supports your long-term strategy instead of reacting to short-term, low-impact tasks.

Filev warns that AI could amplify the blind hustle mindset. As automation handles more tasks, the real advantage belongs to people who can think clearly and direct AI effectively. Burnout dulls that ability, leaving even talented teams ineffective as AI “bosses.”

The edge no longer comes from working longer, but from maintaining the mental clarity to make high-impact, strategic decisions. Filev’s message is simple:

The $2.25B exit didn’t come from sleepless nights at the office. It came from years of disciplined, well-rested, high-quality decisions. True innovation and lasting success come from sustainability, not sacrifice.

The post Zencoder CEO: Hustle Hype Didn’t Drive Our $2B Exit – Sustainable Work Did appeared first on ShiftMag.