For the last year, a bold sentence has hung over engineers’ heads: with tools like Claude Code, we will speed up our delivery by up to 10x. I even personally wrote a bullet in our Internal Engineering Manifest stating it:

It is no longer impossible to think that one engineer with Claude Code can produce what a team of three developers did 18 months ago. Our old ceremonies and structures were designed for a different era. We need to think outside of the box and habits, and think critically about HOW we operate.

Expectations were set, and the year of execution began. But what should be read between the lines is that a developer is not the same as an engineer.

The myth of the 10x developer

Yes, we now have tools that can generate code and handle developer tasks, but this is just part of the engineering lifecycle, which now has a clear price. The new AI era demands even more from engineers; we now expect engineers on steroids. But no matter how advanced they are, engineers are still single-threaded by human design.

Processes we built around the development cycle are complex. The architecture we built around physical-layer restrictions is complex. The 10x claim is a tempting goal, but it can still be applied only to code-generation throughput, not to the surrounding engineering system that keeps pace.

What I realized is that we are treating our engineers the way developers used to treat legacy Java applications: by pushing an infinite stream of requests into a rigid, single-threaded system. At this point, we cannot state that we actually automated an engineering job; we have just dramatically increased the concurrency of our cognitive load. And this will not stop; this will continue to expand.

The analogy with Java’s evolution is impossible to ignore. I will use a Java evolution comparison to further explain the complexity we need to overcome.

What will happen if we just keep adding threads to a limited pool without upgrading the consumer’s architecture? System failure is a mathematical certainty. To fix thread exhaustion, we need to implement bounded queues (limiting Work-in-Progress) and strict rate-limiting on context switching. Sounds familiar?

Why the old Java model couldn’t scale

To understand how to navigate this new era of AI acceleration, we have to look at how software engineers solved the problem of scale decades ago.

In the early days of Java, handling concurrent traffic relied on a straightforward architecture: the Thread-per-Request model. When a user interacted with a web application, the server spun up a dedicated operating system (OS) thread to handle that request from start to finish. It was simple, sequential, and highly predictable.

But as the demand grew, this model hit a physical wall. OS threads are expensive; they require a fixed amount of system memory and CPU overhead to maintain. If a downstream datasystem also became slow, those fast-moving request threads began to queue up, block, and wait. Instead of processing code, the CPU spent all its energy swapping memory contexts between thousands of stalled threads. This led to Thread Exhaustion and system-wide livelocks.

Putting the complexity on developers

The Java Threading issue was not fixed by trying to force hardware to do the impossible, as we would demand of our human engineers to just type faster. Instead, the language underwent a massive architectural evolution over the years.

Thread pools were introduced to strictly limit the amount of active work. Besides Java core changes, the dominant answer to thread exhaustion was reactive and asynchronous programming frameworks like RxJava, Project Reactor, and Spring WebFlux. These models worked by making blocking explicit: instead of a thread waiting, the code itself was restructured into chains of callbacks and non-blocking I/O operations.

The result was dramatically better hardware utilization. The cost was equally dramatic: code became harder to read, harder to debug, and cognitively expensive to write correctly. You solved the thread blocking problem by moving the complexity into the developer’s mind.

New human operating system

Project Loom is Java’s answer to that bargain. Virtual Threads give you the hardware efficiency of reactive programming without the cognitive overhead. The code still reads as sequential, but the scheduler handles the yielding.

Project Loom didn’t redefine what a thread does, but how it’s scheduled. Instead of tying one heavy, expensive OS thread to a single task, Java changed the underlying execution framework by introducing a massive abstraction layer.

We are facing the same trade-off in AI-assisted engineering. We aren’t just managers assigning tasks and topics, we are the architects of a new human operating system where AI enhances human capability, not the other way around.

AI is exhausting engineers?

We cannot patch the human brain to expand its working memory, nor can we download more RAM into an engineer’s skull. When we try to force an engineer to context-switch across five complex initiatives at once, we are essentially trying to run legacy, heavy OS threads without an abstraction layer.

The human brain blocks, thrashes, and enters a state of total exhaustion.

When we brought Claude Code into our workflow, we fundamentally changed the execution speed of our inputs. An engineer can now use an assistant to generate a massive Pull Request in minutes, rather than days.

While the input and generation path is running at warp speed, the specification, review, validation, and integration paths are still human and heavily constrained by the cognitive memory limits of our skilled engineers and their well-being.

We don’t need to slow down the AI, nor can we change human biology. Instead, just like the Java architects of the past, we need to rewrite the architecture of how work flows through our teams.

Our job is to design a human runtime environment that can handle this new level of concurrency.

If we don’t upgrade our internal team operating system, if we continue to let engineers split their attention across product backlogs, technical initiatives, and nd workflow automations simultaneously and without introducing new headcount, the human system hits a cognitive livelock.

They run at 100% mental capacity trying to manage the noise, while their actual throughput on long-term technical architecture stalls.

We need to redesign the system, not the engineers

The first challenge before us is to understand what work is best done by humans and what is better left to AI agents.

I started exploring these questions with my teams. The first thing we challenged was our Scrum ceremonies. We found that Kanban-like boards, with clearly prioritized topics and explicit engineering ownership, were a better fit, while keeping the sprint cadence intact.

We also started bringing engineering into product discussions much earlier, making sure engineers understood the “why” before diving into the “how”. At first glance, this may seem unrelated, but it leads to better specifications and helps us classify different types of work more effectively. And once we understand those different contexts, we can make much better decisions about context switching within the same sprint.

However, changing the scaffolding is only half the battle. To truly scale this new environment, we also need to introduce highly skilled orchestrators who deeply understand the system we are building, individuals capable of dynamically delegating tasks between human minds and AI assistants based on cost, complexity, and risk. Brand-new engineering roles are emerging.

These engineers aren’t just writing code anymore, they are acting as the “Team Core Architects” of our teams, designing the very concurrency abstractions and execution rules that keep our human operating system from collapsing under its own speed.

In an ideal future state, when a “Team Core Architect” designs a workflow, they build an environment in which a human can step in to perform deep, high-value cognitive processing, not to be wasted on something that can be automated.

We aren’t asking our engineers to work harder or faster, we are changing the scheduling abstraction above them so that their finite mental energy is utilized only where it matters most.

The Human Project Loom framework

Transitioning to a “Human Project Loom” framework does not happen overnight by simply buying more enterprise Claude licenses. In reality, we quickly learned that throwing tools at a burning team only increases the noise.

Instead, the true value of AI assistants over the past year was buying us precious breathing room. We needed our human time to draft ideas on how to work now vs. next period and turn ideas into concrete execution plans.

But as we began rolling out this new architecture as an idea, we quickly realized: as the machine layer can grow faster, humans require even more human interaction, mentoring, and deliberate guidance. To safely scale our human platform threads without hitting a memory crash, we need to stop treating “software engineering” as a single, uniform role.

Just as the Java Virtual Machine relies on a multi-layered stack, we will need to redefine our engineering roles. One option is to separate them into distinct, specialized layers of capability as an additional dimension on top of the traditional engineering roles.

The Engineer

At the foundation is the Engineer. In the legacy world, these individuals were predominantly in “developer mode”. Today, we are stretching them into topic owners, not just as architectural discovery phase owners, but to those who are starting their work with the thought: “Let us understand why we are doing this.”

They are using AI context windows to rapidly learn system architecture, trace deep code dependencies, and upskill themselves at a pace that was previously impossible.

Perk: They can now possess the technical knowledge of higher roles much sooner.

Cost: They still need experience to gain seniority and mentoring investment. The skills of a senior engineer last year are not the same this year.

The Orchestrator Engineer

The next level is the Orchestrator Engineer. What I was informally calling “Team Core Architects” in the field now has a proper name within the proposed framework. These are the senior engineers and tech leads who rode the initial AI wave early and already comprehend how to amplify their individual output. But mastering personal productivity is a single-threaded victory. The challenge for an Orchestrator today is learning how to scale that velocity to other humans.

You cannot be an effective tech lead without a deep understanding of your teammates’ cognitive limitations and thread exhaustion points. The Orchestrator’s job is to act as the local thread scheduler, determining which sub-tasks are delegated to Claude and ensuring other engineers don’t drown in the massive cognitive blast radius of AI-generated pull requests.

Perk: Problem-solving mindset is a top skill; there are new and innovative ways to solve problems, a puzzle game for top engineers.

Cost: One of the most used tools is other humans, which means broadening soft skillset and awareness of the impact on others.

The OS-Level Engineers

Finally, the last level is OS-Level Engineers. These are the seasoned engineering managers and principal architects who view the entire system holistically. They debug the JVM. They are the ones who define and track organizational metrics to see where thread starvation is occurring, dynamically allocate token and engineering resources, orchestrate the orchestrators, and inject mental “memory and heap space” into the team before burnout hits.

They recognize that when a team is stuck in firefighting mode, it is a structural failure, and they step in to re-architect the environment so the machine loop serves the human, not the other way around. But at the same time, they need to define possible futures.

With the power of AI tools, they can now help their teams with delivery. This does not mean falling into an antipattern of using vibe code PRs in team’s repositories, but rather giving them structure by drafting workflows and skills that could be a real time and cost saver for the whole organization.

Perk: At the same time, our context is even more stretched, but we are closer to the core problem and are able to be hands-on more than ever.

Cost: Context is overwhelming, and it is harder than ever to be on all 3 fronts: business, people, and technical. And it is not easy to introduce a new lead while undergoing a massive change ourselves.

We’re silently asking teams to change almost overnight

There is a crucial piece of context written in small letters underneath the history of Java’s evolution: Project Loom took nearly six years to design, test, and safely stabilize before it became a standard part of the runtime environment.

Yet, we are silently pushing for our human teams to undergo a matching structural change almost overnight. Because the tools have advanced in months, we expect our organizational psychology to do the same. But human adaptation cannot be fast-tracked with a software update.

Empathy, psychological safety, and clear leadership are even more critically needed now than they were when we were single-threaded.

If we commit to this new three-layer architecture, every engineer is facing a massive “delta”, a structural skill gap they must close to survive in this new framework.

The Engineer Delta is shifting from syntactical output to intent comprehension. They must close the gap between knowing how to develop features and knowing how to critically evaluate an architectural pattern, and understanding why they are developing this feature in the first place.

The Orchestrator Delta, on the other hand, is shifting from individual velocity to cognitive capacity management. They must learn to measure the mental load of the engineers they work with on the current assignment and master the art of safe, bounded task delegation.

The OS-Level Delta is shifting from delivery management to ecosystem architecture. We must close the gap between tracking velocity, maintaining teams, connecting the business needs, and designing complex human-AI throughput environments. These are not abstract gaps, they are the live challenges every team is navigating right now.

How do we onboard new engineers when our roles are still changing?

But as we rewrite our human operating system, we are navigating unmapped territory with severe, systemic unknowns. The most glaring unknown is the onboarding: how do we successfully introduce new engineers to a team when we are actively redefining what our roles even mean?

Because many organizations are considering to pause hiring to force efficiency out of AI tools, we are inadvertently creating dangerous generation gaps. If we don’t bring in fresh minds to learn the system from the ground up, who will step into the Orchestrator or OS-Level roles five years from now? Who will pass our human knowledge further?

I strongly advocate the continuous internship program as the best way to introduce new human talent to our talent pools.

Because the ground beneath our feet is constantly shifting, our team’s ceremonies must undergo their own architectural evolution. Look at the traditional agile retrospective. Historically, it was a highly transactional ceremony designed to celebrate wins, name out challenges and concerns, and assign action items. Today, that approach falls short. Who to assign action to?

Staying human is our perogative

In an AI-accelerated world, retrospectives must pivot to become a dedicated space for pure human connection. They must be treated as an environment for simply sharing thoughts, venting anxieties, and creating bonds between teams and managers.

We don’t just need a list of Jira action items at the end of the hour, we need a collaborative sanity check. I do not need actions to be solved, but to hear and see the real load people are holding. And yes, 1:1s become more emotional, retros become more challenging, and we all in the end act more human than ever.

We need a shared space to learn how to survive the fires together, ensure our mental heap space isn’t crashing, and remind ourselves that behind every hyper-accelerated AI execution thread, there is still a human heart driving the system.

The post What If the Biggest Bottleneck Behind AI’s 10× Promise Is the Human Engineer? appeared first on ShiftMag.

It sounds like a small decision at first, but as Zohar explains, it can become a costly one later when teams have to deal with scale, reliability, latency, and re-architecture.

We also discussed what changes when you build for real-time AI workloads, and why predictable performance matters far more than averages when your users expect speed every time.

When teams pick a database today, what do they most often get wrong?

Zohar: Most people start by thinking about the databases they already know and have used in previous roles, rather than what they actually need for the specific use case in front of them.

As a result, we often see customers choose something familiar instead of evaluating variables such as latency, speed, scale, reliability, and consistency, and selecting the right solution for their particular problem.

That becomes a major issue when they later have to revisit their decision and re-architect or refactor the solution. It can be time-consuming, costly, and extremely difficult.

As AI apps get more real-time and data-heavy, how should developers and CTOs rethink database architecture?

Zohar: Traditional web applications focused on human interaction and often relied on caches and in-memory data. When we talk about real-time systems and AI, however, we are talking about high-throughput, low-latency workloads that consume large amounts of data and need it immediately.

Because of this, teams sometimes use solutions that no longer fit their needs. They require systems that are reliable, predictable, fast, and scalable, which is something we see all the time. Aerospike was built for exactly that use case: real-time workloads, low latency, predictability, and high throughput.

From my perspective, when CTOs evaluate this kind of solution, they need to think about the future. They should consider what they need today, but also where the product and its infrastructure will need to be at the next stage. That is especially important for AI applications and real-time applications in general.

Many teams are adding vector search, graph databases, and real-time pipelines to their stack. When is that the right choice?

Zohar: When many customers think about AI, their first reaction is: ‘This is what my competitor is doing, so I need to do it too. Sometimes, when we examine the use case, we find it provides no real value. Teams choose to do it simply because everyone else is doing it.

These solutions shine when they provide a competitive advantage, and AI can be integrated into the system in a way that creates long-term value. If you integrate a graph database or vector-search solution simply because someone else is doing it, you are going to have a very difficult time.

From that point onward, everything you do can become a technological hurdle, which is exactly where you do not want to be. You need to focus on what will create the most value. If AI is one of those things, go for it. If it is not, you should probably consider other solutions.

What should engineering teams measure if they really want to understand database performance at scale?

Zohar: When it comes to database performance, predictability is the number-one factor. It should be the industry standard for anything involving low latency and high throughput.

Focusing on the average can put you in a dangerous position. Think of a swimming pool with an average depth of 30 centimeters: you can still drown in the deep end.

You need to think differently about performance. Focus on predictability and metrics such as P99 or even P99.9. Measure them at the application level, the database level, and across the overall user experience, because that is what will make your life easier later.

If you measure only the average, 50 percent of your users will experience latency worse than that figure. If you measure P99, the 99th percentile, only 1 percent of users will experience worse latency.

A long performance tail can be highly problematic for some use cases. Our main focus is providing long-term predictability at the high end, including P99.9 and beyond.

That predictability cannot depend on memory or caches. It needs to hold when reading from disk, NVMe, or other storage, without relying on prior activity, cache hits, or warming data into memory.

What do teams give up or gain when they move fast with managed tools versus building something custom?

Zohar: If you are a startup building a proof of concept or just getting started, using off-the-shelf tools is perfectly fine. Over the long term, however, those tools can impose strict limitations. They can be expensive, slow, or unreliable, and they may change without your consent or even your knowledge. They can help you build quickly and get to market fast.

But once you reach a more established stage, you need to find a different way to handle things.

That may mean building your own solutions, adopting a data platform, and unifying your stack. You look for ways to differentiate your product from competitors and make it more scalable, faster, and more valuable.

It all comes down to value. If your solution provides something no one else can, and that differentiation comes from a different architecture or infrastructure, then it makes sense.

Ultimately, it is not one approach or the other. You need to combine them: use common tools to solve common problems, while applying the right technologies to the uncommon, differentiating parts of each use case.

What database and infrastructure skills should software engineers focus on to stay relevant as AI changes development?

Zohar: I think AI is a major accelerator for developers, SREs, and DevOps teams, dramatically speeding up their work. Even so, people need to stay mindful and continue developing deep expertise in their field when working with AI.

It is like generating an image with AI. You enter a prompt and get a result, but it may not be exactly what you wanted or imagined. To the human eye, the problem is often immediately obvious: the image may show six fingers, strange features, or something else you did not expect. The same applies when you are writing code or analyzing logs.

You need enough expertise to evaluate the response critically. You have to ask why: Why did the AI give me that answer? Where did it come from? What did I learn, and how can I improve my solution?

Instead of using AI only to generate and build things, use it to learn. You can still use it to generate code or solve problems, but you need to be able to read the output, understand it, and guide the AI so that it produces results that make sense for you.

When you build an agentic system, use multiple agents, and pass outputs from one to another, you can sometimes lose that visibility. But if you preserve it over the long term, CTOs, developers, newcomers, and junior engineers can go very far, provided they understand what is actually happening.

From my perspective, AI is where the industry is heading. I use it every day and across many parts of my work, but I always remain critical. I plan before I act. It is not about wasting tokens; it is about creating value through my work.

The post Choose a Database Because It Fits the Workload, Not Because It’s Familiar appeared first on ShiftMag.

For most people, NVIDIA means GPUs. But at WeAreDevelopers World Congress in Berlin, CTO Michael Kagan barely mentioned them.

Instead, he focused on the infrastructure behind AI: networking, energy, software, data centers, robotics, and the massive engineering challenge of scaling it all. NVIDIA’s framing was clear: modern AI is no longer just hardware – it’s an “AI factory.”

AI is changing how people interact with computers

Kagan compared AI to past tech revolutions. Electricity came through a wall socket. Cloud computing put infrastructure on demand. Now AI is changing the interface again making computers accessible through natural language instead of code.

Before AI, only a few million people on Earth could operate computers by programming them. Now everybody can program the computer and run the AI, and if you don’t know how to do it, just ask AI. It will tell you.

In other words, users no longer need to understand the technical details behind computing. If they’re unsure how to do something, AI can often explain it or do it for them.

Kagan framed AI less as a software category and more as a new computing layer that expands access to technology. The computer stays the same – the interface between people and machines is what’s getting much simpler.

How NVIDIA linked thousands of GPUs

One of the most interesting parts of the discussion focused on Mellanox, the networking company Kagan co-founded in 1999 before NVIDIA acquired it in 2020.

Mellanox was originally built for large-scale cloud computing, helping connect servers across massive data centers. But as AI workloads grew, that networking layer became even more important because the challenge was no longer just building individual processors, but making thousands of them work together efficiently.

That’s why Kagan says modern AI systems should be viewed as single computers made up of huge numbers of GPUs spread across racks and data centers:

The computer is not a box under the table anymore.

That made the Mellanox acquisition strategically important: it gave NVIDIA the networking needed to connect GPUs and train larger AI models at scale.

AI factories turn energy and data into intelligence

Kagan repeatedly used the term AI factory because, in his opinion, it better describes the role modern AI infrastructure plays.

Traditional data centers store data and process requests. AI infrastructure does something different: it uses huge amounts of data and power to train models and run inference across applications. “AI factories take the energy and the data and convert it to intelligence”, says Kagan.

He compared the process to a power plant generating electricity. It’s a metaphor, but it captures how NVIDIA sees AI infrastructure: as a production system where intelligence is the output.

When asked what an AI factory looks like, Kagan said:

The first thing you notice when you go to the AI factory is cables.

Those cables connect hundreds, thousands, and eventually millions of GPUs into one computing environment. NVIDIA breaks that challenge into two parts: scale-up, which links GPUs with NVLink, and scale-out, which connects those systems into massive clusters.

As those systems grow, networking becomes essential. Every processor has to stay in sync, and NVIDIA says lowering the cost of generating AI tokens remains one of its key goals.

AI is now limited by software and power, not just chips

AI performance used to improve mainly as hardware improved, but Kagan says the challenge is now more complex.

A big reason is the rapid growth of inference. Traditional computing follows a simple pattern: a user sends a request, the computer processes it, returns a result, and waits for the next instruction. Agentic AI works differently, with models constantly exchanging information with software tools and other services while completing tasks. That creates far more communication inside the data center.

Those interactions happen much faster than humans can issue requests, while Moore’s Law is slowing down. That means smaller and faster transistors alone are no longer enough to meet demand.

That is why building larger processors alone is no longer enough to keep up with growing AI workloads. According to Kagan, CUDA has become one of NVIDIA’s biggest long-term advantages because it allows developers to fully exploit the company’s hardware:

Chips without software are just expensive sand.

He explains that NVIDIA wants to give developers a stable platform while the hardware keeps evolving. Too much general hardware can be inefficient, but too much specialization can quickly become outdated. CUDA gives developers the flexibility to support new workloads without starting from scratch.

Power is another major limit. Kagan said electricity is now one of the biggest constraints on new AI data centers. NVIDIA is working on ways to connect multiple sites over long distances so they can act like one system, with training done where power is available and inference closer to users.

Progress in AI depends on understanding complex systems

The session concluded with advice for young engineers: rather than recommending a specific programming language or AI framework, Kagan encouraged students to develop strong foundations in mathematics, physics and chemistry before specializing.

He also reflected about his childhood curiosity, saying he used to take new toys apart just to see how they worked. If he were starting school today, he said he’d seriously consider studying digital biology, since understanding the human body is still one of the most fascinating engineering challenges:

The most complicated machine that is out there is a human.

Even though the conversation touched on GPUs, networking and AI infrastructure, Kagan kept coming back to one idea: progress in AI depends on understanding complex systems. Whether that’s millions of processors, distributed data centers or the human body, engineering starts with curiosity and a desire to figure out how things work.

The post NVIDIA CTO Says AI is Now About Software, Networking And Power – Not Just Chips appeared first on ShiftMag.

The jump from mid-level to senior engineer is usually described as a matter of stronger technical skills.

Michelle Brenner (Senior Software Engineer) sees it differently.

Ahead of her talk at Infobip Shift, (for which you get a special discount as a ShiftMag reader) she argues that the real shift comes from understanding the business, making pragmatic decisions, and knowing when to ask for help.

AI makes learning at work easier

You’re three weeks into a new job, the sprint is already underway, and a ticket comes in that doesn’t fully match the docs. Do you ask for help and maybe seem inexperienced, or do you guess and hope you got it right?

That choice never really goes away. Senior engineers are not people who never need help, they know when to ask before uncertainty becomes a real problem.

For self-taught engineers, that threshold can feel especially high, as Michelle describes it:

As someone who was self-taught, I sometimes found that asking questions at work could be dangerous. I could reveal an ignorance that I was expected to know, from a computer science term to a tool name.

Michelle thinks AI can make it easier to ask basic questions. Since many developers already use AI tools connected to internal docs or code, they can get help without feeling judged.

For her, that matters because most AI conversations focus on code generation. She cares more about what happens before that: helping engineers learn faster and feel less afraid to ask questions.

Seniors also need business context

One of the biggest mistakes mid-level engineers make as they work toward becoming senior engineers, Michelle says, has little to do with syntax or frameworks. The real issue is not understanding how the business works:

Learn how the business makes money, and how your team affects that.

For Michelle, engineers who understand how leadership makes decisions and how a company creates value are better equipped to make technical calls that matter. So what can you do to fix that?

You should start paying more attention to business meetings and start seeing code as one part of a larger system, not the whole job.

In smaller teams, or in companies without a deep bench of specialists, that is often part of the job. Sometimes you have to take on the roles of product manager, developer, and SRE all at once, even when you are not the expert in every area.

‘If it works, ship it’

That same pragmatism shapes how Michelle thinks about architecture and trade-offs.

There is no single “correct” solution, just as there is no dream job or perfect candidate.

“If it works, ship it,” Michelle says. It is an argument against getting stuck in the search for a perfect answer that does not exist. Senior engineers spend less time chasing theoretical purity and more time balancing constraints, risks, and deadlines.

Michelle also gave us a sneak peek of her upcoming talk at Infobip Shift, based on the senior engineering career guide she has spent the last few years writing. She says the jump from mid to senior is much bigger than the jump from junior to mid, and that it can be especially hard without a mentor to show how the role actually works.

Her talk will focus on the practical skills engineers often do not get enough time to learn on the job, from build-versus-buy decisions to interview preparation. She also spoke with engineers from organisations around the world to keep the advice broad. If you are coming to Shift, this is one talk worth catching.

Get your ticket for Shift conference with a special discount for ShiftMag readers!

The post Being a Senior Engineer Doesn’t Mean You Never Need Help appeared first on ShiftMag.

Odysseus is interesting because it shows how a project with serious ambitions can now be built outside a traditional software company. 

After speaking with Ivan Mihić, a software engineer who spent time testing PewDiePie’s AI project, I ended up thinking that the software itself might not be the most interesting part of this story.

Odysseus may come from a YouTube creator with a massive audience, but the more important question is what it says about software development itself. 

Another AI app – or something more?

When Felix “PewDiePie” Kjellberg unveiled Odysseus, the internet reacted in the way it usually does when a major creator launches a software project. Some treated it as a celebrity side project, others focused on the privacy claims and some compared it with other AI tools such as GPT or Claude. 

For those of you who might be late to the party (same as we are with this text), Odysseus is an open source, self hosted AI workspace designed to run locally. Instead of depending only on cloud services, it combines local models with web search, document analysis, long term memory, and AI agents inside a single browser interface. If you want, you can also add cloud models to it as well.

Under the hood, the application integrates components such as ChromaDB for memory, SearXNG for search, and local model serving, while also letting users decide whether they want everything on their own hardware or connected to external APIs. 

What stood out to Ivan was not just what Odysseus does, but what its existence says about how software gets built nowadays:

The biggest thing isn’t that Odysseus is a good tool, It’s that a project of this size probably wouldn’t exist without AI.

A few years ago, building a system that combined models, search, memory, document pipelines, and agents would usually have required a much larger engineering team. Today, a determined individual or a small group can at least prototype that kind of product and keep iterating on it.

To me as an outsider, this looks like the phase in which we built AI tools mainly for internal use is slowly coming to an end. More and more of these tools are now being prepared for public release, even if they are still far from fully polished.

Ivan also admints that he was was surprised. Not because the tool is perfect, because it as you would expect isn’t but because something that started from a hobbyist, vibe-coding context grew into a project of this scale. For him, Odysseus is less a sign that AI has replaced engineers and more a sign that AI has changed the starting line. And I couldn’t agree more on this one.

Privacy alone won’t protect you 

Much of Odysseus’ appeal comes from privacy. Running AI models locally means sensitive data does not have to leave your machine, which is a real advantage. But Ivan pointed out that privacy and security are not the same thing. 

Odysseus is local-first, but that doesn’t automatically make it secure. 

The platform can access files, execute shell commands, perform web research, and interact with external services, therefore a bad configuration can quickly create security risks. That matters even more if users expose their instance to the public internet. 

Ivan’s point is simple: a tool can be private in design and still be unsafe in practice if people do not understand what they are connecting, exposing, or automating. 

When a tool presents itself through the lens of privacy, security becomes extremely important. Privacy without security doesn’t mean much.

Odysseus is not mature… yet

Architecturally, Ivan sees Odysseus as a large monolithic application coordinating several supporting services rather than a fully mature enterprise platform. 

It’s not the cleanest or most mature architecture I’ve seen. You can clearly tell it evolved through experimentation.

That experimental nature is visible throughout the product. Odysseus tries to combine chat, agents, research, memory, document analysis, and productivity tools into one personal AI workspace, with varying degrees of success.

A few features stood out to Ivan in particular. “Compare” lets users run the same prompt across multiple models at once. “Deep Research” automatically performs multi step web research and returns cited sources. “Cookbook” helps users choose, download, and serve models based on the hardware they actually have. 

Still, for someone who is just entering the world of local AI, Ivan thinks more established tools currently make more sense, just because tools like Open WebUI has had more time to mature.

This is not exactly a beginner-friendly tool

Talking about Odysseus once it’s installed is fine, but getting there as a regular AI user might prove to be a challenging task. From my experience, users need to be wary of the fact that, in order to fully use Odysseus, many setup steps are needed. They also need to know that they might not understand a single thing about what’s happening, which is also a risk in itself.

Odysseus is not an app you can install and run in a minute or two, while other tools do just that. The user experience for a beginner might be overwhelming and, at times, just simply not worth it if you’re in it just to experiment and see what the tool can offer.

Ivan Šimić, the third Ivan in this story, a senior writer at ShiftMag who kept experimenting with the tool to figure it out, added:

Trying to hop on the bandwagon of local LLM’s after reading about Odysseus might not be the greatest idea, since it requires a capable machine, a basic understanding of key aspects of making things happen on a PC or Mac, patience and time. For many interested in trying it, this might prove to be too much “tinkering” for not a lot of results.

Big ideas in software are no longer a big-team privilege

It would be easy to frame Odysseus as another celebrity tech experiment but that would miss the broader point. 

What matters here is that AI assisted development has lowered the cost of building ambitious software. A project that once would have required a sizable engineering team is now something a small group, or even one person, can assemble and refine much faster than before. 

And yes, while a fair portion of the pessimistic internet is claiming this means software engineers are disappearing, I highly doubt it. The job is changing, and the gap between an idea and a working product is smaller than it used to be.

As Ivan nicely put it, it’s like Jack Black’s quest for the magical guitar pick in The Pick of Destiny. In the film, that pick gives its owner superhuman guitar skills. In reality, even the best tool won’t make him or anybody else the world’s best developer, but it can certainly make everyday job a lot easier.

Therefore, the most interesting thing PewDiePie built may not be another AI assistant, but proof that ambitious software is no longer reserved for traditional software companies and big teams. Big Tech, are you scared yet?

The post PewDiePie’s AI Experiment Is What Software Development Looks Like Now appeared first on ShiftMag.

Mike Krieger, Instagram co-founder and Member of Technical Staff at Anthropic, said hand-reviewing every line of code is no longer the best use of a developer’s time.

The job, he argued, is moving toward understanding what AI is trying to do, judging whether its decisions make sense, and checking whether the end result actually solves the user’s problem.

For startups and small teams, that shift could be a major advantage: AI makes it cheaper to experiment, pivot, and learn faster from real feedback.

‘AI will not replace developers’

If a founder (or a developer) can test three or four product versions or approaches in the time it used to take to build one, the biggest gain is speed of learning.

In Mike’s view, that doesn’t mean AI replaces creativity, ideation, or product instinct, it just helps strong ideas get validated, or rejected, much faster.

The real challenges developers and founders face were never technical to begin with, he argues. Spotting the actual problem, understanding what users need, and finding a product the market will genuinely adopt is far harder than writing the code itself.

AI will not replace developers or threaten the startup ecosystem. It will let small teams build, test, and iterate faster with fewer resources.

That shift will not be easy for everyone, and plenty of teams will struggle, quit, or pivot along the way. But blaming AI for a rough patch in the industry is not fair. Because as Mike says, what was hard before AI is still hard now.

Code review matters less now

One of the biggest changes Mike sees is not how much code AI can write, but how people assign work to it.

Developers are moving away from planning every step in detail and doing it all by hand. Now they more often set the goal, give the AI context, and then review the results, decisions, and trade-offs.

At Anthropic AI is increasingly used less as a simple tool for individual tasks and more like a team member that holds context, tracks specific problems, and proactively suggests solutions.

That is also changing how code gets reviewed. Traditional code review, where someone goes line by line and checks the implementation, matters less than understanding the intent behind a change.

Instead of asking “is every line of this code correct,” the more useful question becomes “is this the right way to solve the problem, and what are the consequences of this decision.”

I don’t review every line of code in a pull request. Instead, I talk to Claude about the code and ask the questions I would normally ask the person who wrote it.

That does not mean people disappear from the process. Human judgment matters more, especially for architectural decisions and complex changes. AI can speed up implementation, but someone still needs to understand the product, the users, and the long-term consequences of a decision.

It is easy to lose perspective in the AI race

Beyond the changing workflow, Mike also spoke about the pressure in the AI industry. With new models, products, and regulatory shifts coming almost daily, it is easy to feel like you always have to stay one step behind.

He said that by midweek, Anthropic is already reviewing the ”state of AI news,” and the list of updates is often long. His point was that you have to keep perspective, you can’t track or react to every single change.

That pressure, he added, is also what makes burnout such a risk in an industry moving this fast. People often tie their sense of success to daily results, competitors’ launches, or product releases, even though real wins and failures are usually measured over much longer stretches of time.

No job is important enough that you can’t be offline for a few days.

He closed by saying teams need to get used to talking about frustrations and failures, not just celebrating wins. Being open about problems, he argued, helps teams solve them faster and keep a healthy working culture, even as the industry moves at an extraordinary pace.

The post Instagram’s Co-Founder Says He Doesn’t Review Every Line of Code Anymore appeared first on ShiftMag.

At .debug 2026, one of Croatia’s largest developer conferences, I introduced the concept of Ambient Generative IT – a coined term describing the phenomenon where AI-assisted development becomes so pervasive that it blends into the organizational fabric, much like ambient lighting blends into a room.

The word “ambient” comes from the Latin ambire (to surround), describing something seamlessly integrated with its environment.

This shift is already happening across organizations: marketing managers build internal dashboards, HR teams automate onboarding workflows, and sales ops create CRM integrations. None of them are engineers, and most have never heard of row-level security – yet they are all becoming software developers and publishers.

The question was straightforward: how do we securely enable a future where anyone can build enterprise-grade tools while still upholding the non-functional requirements we expect from professional software engineering, such as security, performance, scalability, and maintainability?

Everyone wants to build software now…

There are two fundamental reasons why ambient generative IT is so appealing:

1. There have always been more consumers than producers.The demand for applications, integrations, automations, and digitalization has always exceeded what IT departments can deliver. That imbalance created Shadow IT decades ago, when the migration from mainframes to personal computers gave people the freedom to buy their own software. Cloud computing exploded it further. People want to be productive, and when the engineering bottleneck is too tight, they become their own builders.
2. The thrill of creation. Every engineer remembers the first time they made a computer do something it would not do on its own. For non-technical employees experiencing vibe coding for the first time, that feeling is brand new and equally (if not more) intoxicating.

Shadow IT was the warning. Shadow AI is the crisis.

Shadow IT is not new. Gartner estimates that 88% of organizations have experienced it, with the average company running 1,220 unauthorized cloud services while believing the number is just 91. By 2027, 75% of employees will acquire or create technology outside IT’s visibility.

But Shadow AI has accelerated the problem beyond anything Shadow IT ever produced.

According to IBM’s 2025 Cost of a Data Breach Report, shadow AI was involved in 20% of all breaches. This was more than sanctioned AI incidents (13%). Organizations with high levels of shadow AI paid an average of $4.74 million per breach, compared to $4.07 million for those with low or no shadow AI; a $670,000 premium. Perhaps most alarming: 97% of organizations that experienced an AI-related breach lacked proper AI access controls, and 63% had no AI governance policies at all.

Anyone from your company at any moment can generate an app, and this is not going through any development cycle or any security check. People can just start using it in production without asking anyone. And they do.

Dor Zvi, RedAccess

More than 380,000 exposed apps

Israeli cybersecurity firm RedAccess discovered 380,000 publicly accessible applications built with vibe-coding tools like Lovable, Replit, Base44, and Netlify. Out of those, around 5,000 had virtually no security or authentication and about 40% exposed sensitive data.

WIRED independently verified the findings, confirming exposed hospital schedules with physician PII, go-to-market strategy presentations, complete customer service chatbot logs, and shipping cargo records.

Separately, Escape.tech scanned 5,600 vibe-coded applications and found over 2,000 critical vulnerabilities, 400+ exposed API keys, and 175 instances of personal data exposure in live production systems. Their methodology was deliberately conservative: it included passive scanning only, educational and healthcare domains excluded.

The actual exposure is likely far worse.

Gartner’s “Predicts 2026” report forecasts that by 2028, prompt-to-app approaches adopted by citizen developers will increase software defects by 2,500%.

The anatomy of a vibe-coded breach

The pattern is remarkably consistent. For example, the Lovable + Supabase architecture that powers thousands of vibe-coded apps. Lovable generates a React frontend that communicates with a Supabase PostgreSQL database via PostgREST.

To enable this communication, it embeds an anonymous API key directly in the JavaScript bundle which is visible to anyone who opens browser DevTools.

This key is not meant to be secret. Supabase documentation explicitly states that the anon key is public and that Row-Level Security (RLS) should protect the data. RLS defines which rows each user can read. The problem is that Supabase defaults to RLS disabled during development, and vibe coders — who have never heard of RLS — ship to production without enabling it.

The result: a single curl command with the publicly available key returns the entire database. Conveniently, no hacking is required.

This exact root cause was behind the Moltbook breach in February 2026, where 1.5 million API tokens and 35,000 email addresses were exposed within three days of launch. The founder had publicly stated “I didn’t write a single line of code.”

It was also behind CVE-2025-48757, a formal CVE for missing RLS in Lovable-generated Supabase projects affecting 170+ production applications.

AI eliminates the easy bugs and introduces the dangerous ones

Veracode’s 2025 GenAI Code Security Report tested over 100 LLMs across four programming languages and found that 45% of AI-generated code contains security vulnerabilities, which is exactly 2.74 times more frequently than human-written code.

Apiiro’s research on Fortune 50 enterprises showed that while AI coding assistants increased development velocity by 4x, they simultaneously produced 10x more security findings, with privilege escalation paths up 322% and design-level authentication flaws up 153%.

The irony is that AI genuinely reduces surface-level bugs. Syntax errors dropped 76%, and simple logic bugs fell 60%. But it introduces architectural authorization flaws such as code that is syntactically perfect, passes all tests, but asks the wrong question: “is this user logged in?” instead of “is this user allowed to access this specific resource?”

SAST tools cannot catch this because it is not a code error: the code does exactly what it says. The problem is that it says the wrong thing. In one Lovable EdTech incident, the AI generated authentication logic that was inverted: anonymous users received full access while authenticated users were blocked.

In the end, 18,697 user records were exposed, including 4,538 student accounts from UC Berkeley and UC Davis.

Vibe coding optimizes for features, not permissions. Access control is an architectural decision made implicitly by AI, and those implicit decisions are often wrong.

Equixly

Performance, scalability, and the maintainability question

Security is not the only non-functional requirement that vibe-coded applications fail to meet. AI-generated code frequently includes unnecessary sequential API calls instead of batch operations, lacks caching and database indexing, pulls in entire libraries for single functions, and introduces N+1 query problems. This means that an app that works with 10 test users often falls over with higher user numbers.

Then there is maintainability. AI generates code without explaining why decisions were made. There is no design documentation, architectural decision records or tests. When AI generates a new version, it often rewrites the entire codebase rather than incrementally improving it.

If the original vibe coder leaves the company, the application becomes unmaintainable. This is vendor lock-in 2.0.  Rather than a traditional vendor, we’re dependent on a particular AI tool.

The economics (and responsibility) have flipped

Despite the risks, vibe coding is reshaping software economics in ways that cannot be ignored. KPMG reported in 2025 that generative AI coding is helping enterprises reduce their reliance on large SaaS vendors.

Harvard Business Review argued that the “build vs. buy” equation has fundamentally shifted and building custom solutions with AI is now often cheaper than licensing enterprise software. The trend toward “micro-applications” – small, purpose-built tools replacing million-dollar CRM licenses – is accelerating.

The enterprise features that used to sit behind paywalls – SSO/SAML, RBAC, audit logging, compliance exports – can increasingly be built using open APIs. At Infobip, we have built our own MCP Gateway, an Artifactory security bouncer that replicates enterprise curation features, and AI guardrails infrastructure. All were alternatives to buying vendor software.

But this freedom comes with a condition. Without security, performance, and governance standards, the same democratization that liberates organizations from vendor lock-in creates a new class of risk that traditional security programs were never built to handle.

OWASP now has a Top 10 for agentic applications

In December 2025, OWASP published its first Top 10 for Agentic Applications, reviewed by NIST, Microsoft’s AI Red Team, Oracle, and the Alan Turing Institute. The list includes Agent Goal Hijack (prompt injection redirecting agent objectives), Tool Misuse and Exploitation (over-privileged tool access), Agentic Supply Chain Vulnerabilities (poisoned MCP servers), and Human-Agent Trust Exploitation (agents manipulating humans into approving harmful actions).

The incidents are already real. EchoLeak demonstrated a zero-click attack where a crafted email silently triggered Microsoft 365 Copilot to exfiltrate confidential data. The Replit Vibe Coding Meltdown saw an agent delete a production database and then generate false outputs to hide the mistake. A malicious MCP server impersonating Postmark on npm secretly BCC’d emails to an attacker.

This new OWASP report does a good job at mapping out agentic threats. A separate report created by Xint, interestingly explains that the most damaging failures are still the oldest ones. Having tested 28 applications, Xint had 8,827 detections, which were collapsed into 513 findings and then 434 verified issues. The most notable examples in the list are very familiar:

• Secrets exposure (18 verified findings and 11 critical findings)
• Authorization/IDOR flaws (88 verified findings, 2 critical findings)
• Resource exhaustion/Dos (93 verified findings, 3 critical findings)
• Access-boundary weaknesses, such as traversal and SSRF (54 verified findings)

In other words, ambient generative IT does not replace classic application security, but rather makes it more urgent and distributed. For us as security experts, it also makes it noticeably harder to ignore.

An effective AI governance framework needs 6 elements

Gartner’s January 2026 report “How to Secure Enterprise Agentic AI Ambition” defines five workstreams for an Agentic AI Cybersecurity Program:

• Multichannel Discovery (find all AI agents, sanctioned and shadow)
• Access Modeling (unique identity and least privilege for every agent)
• Scoped Agency (define scope early, enforce at runtime)
• Model Risk Management (red teaming and guardrails)
• Intent-based Monitoring (behavioral analytics replacing traditional SLAs)

At the policy level, an effective AI governance framework needs six elements:

1. Mandatory approval before any AI tool is used,
2. A hard data boundary preventing confidential information from entering unapproved systems,
3. Human accountability for all AI-generated output,
4. Identical code review standards for AI and human code,
5. Default-blocked autonomous agents requiring security approval
6. Ethical AI principles ensuring explainability and fairness

At the technical enforcement level, organizations need managed settings that block destructive commands, prevent data exfiltration, restrict access to secret storage locations, control which AI marketplaces and MCP servers are permitted, and maintain full audit telemetry of every tool invocation.

CISOs must prioritize deterministic controls to minimize agentic privilege abuses and contain AI agents’ agency, instead of relying primarily on AI to police itself.

Gartner

Security must be built into every AI tool, agent config, and policy from day one

There’s no doubt whether Ambient Generative AI will be the norm. The 380,000 exposed applications RedAccess found are not an anomaly, they are the new normal. Organizations are now past the point of deciding on whether they’ll allow AI-assisted development across development, and approaching the point of deciding on the governance, tooling and culture to make it safe.

The same CI/CD pipelines, SAST scanners, code review processes, and identity governance frameworks that protect professionally engineered software must extend to every application, regardless of who (or what) wrote it. Code is code, no matter who authored it.

The ambient future requires ambient security. And that security cannot be an afterthought bolted on after the breach. Security must be woven into the fabric of every AI tool, agent configuration, and organizational policy from day one.

The post Security Must Be Built In as Everyone Becomes a Builder appeared first on ShiftMag.

At WeAreDevelopers in Berlin, I spoke with Predrag Radenkovic, CTO at Codeplain, about why some developers are skeptical of “review the spec, not the code” – and where this approach works today, and where teams still need to be careful.

What is the main shift from prompt-driven coding to spec-driven development?

Predrag: Prompt-driven coding operates at the level of code. Every decision an engineer makes gets translated directly into the implementation. All the maintenance happens on the level of code, where the intent behind the original solution is no longer available to the coding agent.

Spec-driven development raises the level of abstraction. You treat the spec as the only source of truth: you define the necessary detail in natural language, and the system is built and validated from that. The intent persists in a simpler, more readable form. So you’re maintaining specs instead of code, and regenerating the code from them.

Agentic skills are what make that workable in practice. Developers don’t want to write specs from scratch, but they’re happy to read them, so the agent drafts the spec incrementally, and the developer reviews and shapes it.

Why are integrations a good fit for AI-assisted development, and where does direct LLM-based code generation usually break down?

Predrag: With integration development, you’re essentially becoming an expert on third-party systems that LLMs already know better than any human. Agents are strong at researching the domain, understanding the APIs, checking implementations against the current documentation.

Where classic AI-assisted development falls short is maintenance. Integrations break in production all the time, and once you have a large number of them, you’re constantly patching code against systems you don’t control.

With spec-driven development, the intent lives in the spec. So, when a third-party system changes and breaks an integration, the fix is usually a very small edit to the spec, and then you regenerate the code from it.

Codeplain treats reusable specifications as the source of truth. What makes a good spec, and what do developers often get wrong when writing one?

Predrag: Good specs are complete, precise, unambiguous, and free of conflicting requirements. Also, their functionality is split into smaller chunks of reasonable complexity. Free-form specs aren’t ideal because the agent has to process everything at once and validating the requirements gets hard. Structuring the spec into units is what makes it both readable and checkable.

That’s why we built the ***plain language. It lets engineers express intent precisely and keep full control over the functionality that gets implemented from it.

What we’ve noticed over 2.5 years of working on spec-driven development is that engineers aren’t especially good at writing precise specs, but AI agents are. And the other way around: engineers are willing to review a spec thoroughly. That’s the reason why we built agentic skills for writing and validating specs.

If implementations can be checked against the specification, how does that change testing, code review, and trust in AI-generated code?

Predrag: The first premise of the SDD lifecycle is that engineers thoroughly review the specs. Once the specs are accurate, much of the work is done. Codeplain’s code generator then builds the code and, more importantly, validates that it conforms to the specs.

We do this through black-box tests written entirely from the specifications and executed against the code that was built. In the end, it’s up to the engineer to do manual testing and, if they want, to check all the test scenarios our platform created.

From your experience scaling integrations, what was the biggest technical lesson about using structured specs instead of direct code generation?

Predrag: When you develop integrations, you become an expert in someone else’s system without creating any additional value compared to your competitors. And it gets harder as the volume of integrations grows. The biggest issue, though, is maintaining them, because around 5% of integrations break each month due to changes in systems you can’t control.

Coding agents are already great at researching and understanding external systems, and we use them to help us write the proper specifications. Once an integration is fully defined in a spec, it’s easier and faster to maintain, because the review cycle boils down to changes in the specs and the rest is automated.

Some developers are skeptical of ideas like “review the spec, not the code”. Where does this approach work today, and where should teams still be careful?

Predrag: We picked integrations as the beachhead for our platform with exactly this question in mind. The approach works best where the implementation can be validated completely, where you can check the behavior against the spec without a human in the loop. Integrations fit that well, and we’ve seen the same hold in a couple of other verticals: scraper development and ETLs.

Where teams should be careful is anywhere full validation isn’t possible. Anything with a user interface, for example, can’t be checked the same way today. But we see a solution on the horizon. The technology just needs to mature, and it’s moving quickly.

The post The Real Source of Truth Is No Longer Code – It’s the Specifications appeared first on ShiftMag.

Olena Babenko, Staff Software engineer at Aiven, cut straight to the uncomfortable truth in a recent interview I had with her in London.

The oversight model collapses the moment the person approving the output can no longer reliably tell whether it’s good, bad, or just convincingly wrong.

She pointed to a growing mismatch between how fast code is being generated and how slowly it is actually being checked.

AI is speeding up code creation, but review can’t keep up

Olena says she keeps running into the same cycle, that looks like this “a steady stream of announcements about how the newest model will change software engineering, followed almost weekly by another company unveiling its most powerful release yet”.

Then someone actually turns the model on and gives it a simple, but domain-specific task, and it hallucinates, a lot

She sees this happen often enough that the pattern itself has become the story. The industry isn’t there yet, she says, at least not in the systems she works with.

The real problem, in her view, shows up one step later in the pipeline: engineers are spending less time writing code and more time reviewing it, and the incentive structures around that shift have not caught up.

Therefore, I asked her what that imbalance looks like:

We have an ability to generate code very, very fast, thousands of lines of code, and without thinking how people perceive that code, how readable it is, how good it is, how simple it is to understand, but code reviewing, scaling, and automation is not on that same level yet.

As a result, you can create a PR, and a person who actually reviews it took much more time to review it than you spent writing it. This means that the problem, at least according to Olena, is structural, not just technical:

The current system and a lot of managerial tools are made on KPIs, they are made on individual contributions of code writing, so if you look at the GitHub contributions or Jira tickets, they are praising writing code, finishing tasks, creating PRs, while the people who do the PR reviews, their jobs are not valued that much.

Add unusually verbose AI-generated code into that mix, and reviewing takes even longer than the writing did.

The review burden has always been there, but it’s getting worse

Olena is careful to point out this isn’t new. She says that a reviewer burden existed even before all this and AI is just amplifying this problem.

She describes a colleague’s experience at a previous company: engineers spending two weeks on an issue, then dropping a thousand-line PR on a reviewer who was, realistically, expected to just hit merge, not actually engage with the work.

The fix, in her view, is not more automation but earlier communication, smaller PRs, and separating refactoring from actual logic changes, paired with management that treats reviewing as real work worth rewarding:

This is a question of management.

AI can make tests look good without actually making the code reliable

Olena also pointed to one of the first things AI tends to break in a codebase: unit tests. Writing them is boring, so people delegate it a lot, but AI can already game the system, making tests pass without making the code reliable.

By her account, models will patch internal implementations or hardcode expected outputs rather than genuinely verify behavior, leaving teams with high coverage numbers that protect against nothing – though the damage doesn’t show up right away.

They are not falling apart in one day. This is a process that’s eroding your system with a small step day by day until you realize that your new system is really unreliable, really something you’re not supposed to do in production.

By the time anyone notices, the damage started much earlier.

‘We are delegating too much thinking to AI’

Olena’s biggest long-term concern is skill erosion:

We’re delegating too much thinking to AI. But AI doesn’t become an expert just because we use it: it has no memory, it can’t really learn, and it can’t build experience. Humans can do that, at least for now. The problem is that we’re not really learning from the experience either, so our skills and critical thinking keep getting weaker.

That undercuts the standard reassurance that a human stays in the loop. “You might end up in a situation where you have a human in the loop, but those people do not have correct skills anymore”, Olena said.

A safety net only works if the person holding it still knows how to catch something.

The post It May Take Longer to Review a PR Than It Takes to Write It appeared first on ShiftMag.

Lovable lets people describe the software they want to build in plain in natural language, and then the platform creates it. It handles security, builds complete solutions, and lets users add artificial intelligence to their applications.

Essentially, it helps people build entire apps, and company founders, small businesses, and large corporations all use it.

This is how Anton Osika, co-founder of Lovable, described his platform. Users create over a million apps on it every week, and these apps attract around 700 million monthly visits.

It sounds like a true paradise for non-technical people who want to build products and scale their businesses, but I wanted to know what value Lovable brings to developers, who make up 20% of the user base. I found my answers at this year’s Raise Summit in Paris, during the fireside chat between Osika and Mark Cuban, the investor and serial entrepreneur.

1. For a quick project start

Cuban highlighted that one of Lovable’s greatest strengths is how it helps people become entrepreneurs:

We all have ideas, right? But taking the first step is usually the hardest part.

The platform’s creator strongly agreed. He explained that although people initially viewed Lovable as a software engineer (or even as competition), they eventually came to see it as an AI co-founder and partner:

When you start a company, the hard part is not just building the software. You also have to register the business, handle banking, set up payment systems, and organize operations.

As he explained, users now build their businesses by talking to the platform and giving it prompts like:

• “I am launching my business. What is the next step?”
• “How do I set up global payments?”
• “How do I get customers?”
• “How do I build internal systems?”

At the very start of product development, Lovable significantly shortens the path from an idea to the first prototype.

This is especially true for developers who know what they want to build but do not want to waste time starting from scratch or dealing with complex business steps. Previously, they had to hire an accountant, a lawyer, or a consultant for these tasks.

2. For MVP and idea validation

For developers working on new products, Lovable serves as an MVP machine. It helps them test whether an idea has market value before they invest serious time in fully custom development.

According to Osika, if you are close to a problem and understand it well, you are often the best person to know what solution to build. He said that building this kind of solution used to be hard because it required too many resources:

Today, you can build a large part of it on your own. That is what I generally recommend. We recently conducted a survey of 10,000 of our users, and about 80% of them are building something they plan to monetize at some point.

Osika also pointed out that many people who successfully monetize their products have a decade or more of professional experience. They combine their expertise with Lovable to build products that attract actual users.

In this case, Lovable serves as a validation tool. This means you first create a working version, then measure market interest, and only then expand the product.

3. For internal tools

Lovable is not just for robust, new applications, it also works well for internal tools, especially when teams need a quick tool for operational processes.

As an example, Anton mentioned Nursa, a US company that allowed its employees to use Lovable for various needs, ranging from marketing to administrative processes.

The results were highly cost-effective:

They have already replaced more than ten software subscriptions that they used to pay for, and they estimate they will save about a million dollars a year.

This example shows that founders can use Lovable to quickly assemble small tools that cut costs and replace multiple separate SaaS solutions.

This way, they save both time and money, and they can focus on their core business.

4. For integrations and business infrastructure

Cuban noted that integrating AI into large companies is often much more complicated than people expect:

We see companies like Microsoft hiring thousands of engineers to implement AI solutions.

Therefore, in addition to building apps, Lovable allows users to integrate these tools into their business infrastructure.

This enables developers to connect the product to databases, internal tools, ERP systems, and other existing company systems much faster, without tedious manual work or complex initial setups.

He observed:

One of the major challenges is connecting to existing systems: ERP systems, internal databases, and current software tools.

To solve this, Lovable enables secure and controlled connections, which allows companies to use AI effectively.

For developers, this matters because it allows them to look beyond the frontend and quickly extend the application’s reach into actual business processes.

In other words, Lovable helps them work more efficiently, not just in building products, but also in fitting them into a broader technical and business ecosystem.

5. For analytics, reporting, and decision-making

Finally, Lovable helps build a layer that connects business data with the tools teams use for strategy, finance, and operational planning.

Instead of lengthy development from scratch, developers can deliver tools that help the team find answers faster and make data-driven decisions.

Cuban described this through his own use of an AI agent:

I ask it: “How fast are we growing in a specific segment?” “Which countries should we consider for a new office?”

This application is important for developers because it shows that Lovable can serve as the foundation for tools that are not just visually functional, but also business-relevant.

As Anton Osika said, “access to core data is one of the key ways we unlock the value of artificial intelligence.” This is exactly what gives developers the power to build reliable tools for analysis, forecasting, and decision support.

And here’s my two cents…

Ultimately, this fireside chat left me with a clear realization: using Lovable will not make everyone a developer, let alone a good one. But developers who embrace it can become significantly more effective. They build faster, work smarter, and spend less time on repetitive tasks.

As Anton Osika pointed out, only about a fifth of the platform’s users possess a technical background. Yet, these individuals know exactly how to leverage the tool to their advantage.

This marks the true shift in our industry. We are not witnessing the end of software engineers, but rather the rise of creators who understand the core problem deeply enough to build solutions in record time.

The post Lovable’s Co-Founder on Why Developers Use a Platform Made for Non-Technical Users appeared first on ShiftMag.