Four words show up in almost every eCommerce project we take on here at Neuralab: “Just connect it to our ERP.“ They usually drop near the end of a kickoff call, tossed out as casually as asking for the Wi-Fi password.

The word doing all the heavy lifting (and all the damage) there is just. It’s the word that turns a monolithic beast of a legacy system that nobody in the room fully understands into a neat little line item some project manager expects to close in a two-week sprint.

I want to make an argument that sounds painfully obvious once you say it out loud, yet gets completely ignored on most projects: building a new store and connecting it to the systems already running the business are not the same sport. Heck, they’re barely the same project!

A new storefront is greenfield. Clear ground with no legacy baggage. You plan the architecture and data model upfront and mostly hold to the plan. An integration with an existing ERP or CRM is brownfield by default. It’s an archaeological dig into an old system you didn’t build, that’s poorly structured, still running, and troublesome in ways nobody ever bothered to write down. Treat the second like the first and you get an integration that works beautifully in the demo and completely shits the bed the first time a real order does something unexpected.

There is a fix, and it comes down to timing more than technique. I’ll get to it, but first you need to see what you’re actually up against. 

The integration layer breaks because no one owns the handoffs between systems

Let’s start with what the integration layer actually is. The storefront takes the order – the gateway authorizes the cash – the tax engine figures out the state’s cut – the ERP opens a sales order and reserves stock – accounting generates an invoice – the warehouse picks and packs – the CRM logs it all so customer support has something to stare at next week.

Every single one of those systems has an owner. But the handoff between them has no real owner at all. That’s what the integration layer is: the unowned seams. And seams are exactly where the fabric tears, because it’s the one place where two systems that were designed in total isolation have to agree on something in real-time, having never formally met.

Sometimes system takes the money a beat before the order exists

Payment authorization must happen synchronously, meaning the customer needs an immediate response while they are waiting on the checkout screen. The payment gateway typically has up to a minute to confirm whether the transaction is approved or declined. But everything after the payment – opening the ERP order, reserving stock, pinging the warehouse – has to be asynchronous. You simply can’t make a paying customer wait on an ancient ERP API that answers whenever it feels like it. You are accepting eventual consistency by default here, simply because holding synchronous cross-system locks will butcher your conversion rates. 

So, the confirmation page fires the instant the payment clears, telling the customer “you’re all set” a beat before the system actually knows if it can deliver on that promise. Without explicit architectural patterns to handle that gap you’re just playing infrastructure roulette.

Most of the time, this gap closes in milliseconds and nobody’s the wiser. But sometimes it doesn’t. The payment clears, but the queued job to create the order times out or drops on the floor without a sound. Now you’ve taken their money with no order behind it.

That failure rarely hits the dev team first. Instead, an account manager has to act as human middleware – cross-referencing payment logs, re-typing order data into the ERP, and calling the warehouse floor to check on a shipment. Forcing humans to manually heal a cracking system is the most expensive bottleneck of a poorly planned integration.

The fixes here aren’t exotic but they do need to be explicitly planned, and budgeted upfront, a line item almost nobody includes until after their first major post-launch fire drill.

The old system is the business’s memory, not clutter

Any ERP or CRM that’s been running a real business for a few years has grown a thick layer of weird behavior that exists nowhere in its documentation. By that I mean a product-code field that silently clips at forty characters, so anything longer has been quietly losing its last digits since 2019. Or a nightly cron job that only works because some guy manually restarts it every Tuesday. Or an “order status” column that encodes five completely different business meanings depending on which department touched it last.

An outside team scoping a connection to that system on day one is just looking at a facade. They can read the API docs and see the tables, but they cannot see which of those unmapped load-bearing walls their integration is about to lean on. So the scope gets written against the version of the system that exists on paper, not the one coughing in production.

There’s a concept worth borrowing here: The Lindy effect. The longer something has already survived, the longer it’s likely to keep going. That 15-year-old ERP is still there precisely because too much depends on it for anyone to risk ripping it out. Its longevity is proof of its necessity.

When you arrive with a shiny new tech stack, the temptation is to treat the old system as dead weight and a dumb obstacle overdue for replacement. Resist that instinct! The old system has survived contact with the actual business for a decade and a half. It knows things your new build doesn’t know yet, encoded in all those annoying quirks you keep tripping over. Treat it as a battle-tested opponent rather than a nuisance and try to untangle its accumulated weirdness.

Build first, audit second, integrate last

Put the greenfield and brownfield halves together and the most common planning error becomes glaringly obvious. Clients, and plenty of agencies, scope the new build and the integration as one single piece of work. Same estimate, same timeline, same assumption that they’re the same species of task.

They are not, and if you bundle them together you actively poison the integration.

When you write that combined scope, the new platform’s data model doesn’t even exist yet. Its catalog structure, content architecture, and the actual shape of the data are completely unsettled. So you’re designing an integration against a guess, layered on top of the fog already surrounding the old ERP. Guess wrong on either end, and you’re in for massive rework right when the deadline is breathing down your neck – which is exactly when developers start reaching for shortcuts that become those fragile seams everyone has to live with afterward.

The fix is a sequencing decision, and it’s almost boringly simple:

Build the new thing first. While that’s happening, send an analyst into the existing systems to do a pure audit. Figure out what the system actually does and where the unmapped walls are. Once the new platform is close to finished and its data model is a fact rather than a weekly weather forecast, then you scope the integration. Now both ends are known.

I’ll be honest, we learned this the expensive way at Neuralab. Years ago, we used to bundle the two into one scope to give a client a tidier number upfront. We’d then spend all that “saved” time back with massive interest during the last three weeks of the project, desperately discovering what the old system actually does.

Question the legacy workflow before you automate it

Even if sequenced right, integrations are the hardest work we estimate in Neuralab because there’s a quiet trap that inflates the scope from the inside.

A client has an existing, complicated internal process. The natural instinct for both the developer and the business analyst is to lock onto that process and faithfully rebuild it in the new system, because a concrete process sitting in front of you is a satisfying puzzle to solve.

The question almost nobody asks is whether that process still needs to exist at all. Was half of it just scaffolding for a limitation the new system doesn’t even have? Faithfully cloning a bad process that shouldn’t survive the migration just relocates the waste into a more expensive place and bills you for the move.

We saw this clearly with one of our large pharmacy clients. Their original plan was to manage and edit all rich product details such as marketing copy, attributes, or extended specifications inside their legacy ERP, and then force all that content downstream to the web store. But standard ERPs are notoriously bad at managing complex eCommerce datasets and rich visual content.

Instead of building a fragile, over-engineered integration to force an old ERP into doing a PIM’s job, we redrew the architectural boundaries. The ERP stayed strictly in its lane: holding SKUs, core titles, pricing, and stock quantities. Meanwhile, WooCommerce became the single source of truth for rich product content. It was essentially functioning as a lightweight PIM for all media and marketing data. 

By questioning the legacy workflow instead of blindly automating it, we saved months of painful integration work and gave their team an architecture that actually fits how they work today. 

The seams between systems need their own memory.

So how do you actually wire this stuff together? Point-to-point custom code between each pair of systems is the wrong default. It works great right up until the day an order gets stuck, a client asks what happened, and your honest answer is that the event passed between two systems and vanished into the ether.

What actually holds up is an explicit orchestration layer sitting in the middle – whether that’s an event pipeline like n8n which we heavily use, a separately hosted application with its own logging and event-handling capabilities, or a messaging platform such as Kafka, Amazon SQS, or RabbitMQ.  Its job is to own the sequencing, handle retries, and log every single event as it passes, so the whole flow can be inspected on its own.

When something breaks, you shouldn’t need write access to the ERP and an open database console on the storefront just to reconstruct the story. You should have one central place that already holds the receipts. Intentional middleware is the architecture our team defaults to now (usually reaching for custom applications or n8n to drive it). But the tool is just execution! The principle is the real point: the seams between systems deserve their own memory, because nobody else is taking notes.

The “J” word comes last

The client isn’t wrong to want a “just.” A boring, invisible connection nobody ever thinks about is exactly what a good integration looks like from the outside. That simplicity is the finish line – you only reach it after someone goes down into the old system, maps the weak walls, and quietly absorbs the complexity so the business doesn’t have to.

So don’t argue with the person who says it, take it as the brief. Do enough excavation upfront so that a year from now, connecting to that ERP genuinely is simple, and the manual re-keying, the spreadsheets, and the cron job someone babysits every Tuesday become an old war story instead of your next Monday.

The post The phrase that ruins every eCommerce project: “Just connect it to our ERP.” appeared first on ShiftMag.

As companies move more of their knowledge into AI applications, PDFs, scans, reports, and invoices are becoming key data sources. The real challenge is preserving enough structure and context for AI systems to understand them properly.

Document extraction is becoming key in AI applications

For much of the history of enterprise software, documents typically sat at the end of a process. An application generated a report, invoice, or contract, and the PDF was the finished product. Mancinelli believes AI is changing that relationship:

Documents used to be the output – for example, a PDF you’d print or send out. Now they’re also a structured input that powers AI systems.

More precisely, the challenge for developers is turning documents that are often unstructured or semi-structured into structured information that downstream systems can use.

An LLM can ingest raw text, but simply extracting characters from a file does not always preserve what makes the original document meaningful. A heading has a different role from a paragraph. A value in a table depends on its row and column. A number beside “Total” means something different from the same number appearing somewhere else on the page.

That is why document extraction is becoming an important preprocessing layer in AI applications. The goal is not just to recover text, but to give models cleaner, better-organized context.

Bad PDF parsing can lose information that even a stronger model cannot recover

Anyone who has tried to build a production pipeline around real-world PDFs quickly discovers that documents are far less predictable than API responses or database records. Mancinelli points to three recurring problems:

First are complex layouts: you can have headers, tables, and different formats in the same document, and that creates a huge challenge for systems. Second is poor OCR, which can produce messy output. Third is the loss of context.

This distinction becomes especially important with RAG systems and other LLM-powered applications. If a document is badly parsed before it reaches a model, a more powerful model cannot necessarily recover information that was lost earlier in the pipeline.

For developers, that means data quality becomes an architectural issue rather than simply an AI-model issue.

Document processing depends on the use case

Where document processing happens is another architectural decision that becomes more important as AI moves into regulated and data-sensitive environments.

Mancinelli argues against treating cloud and self-hosted processing as an either-or decision. The right model depends on the application, its infrastructure, and the type of data involved.

For organizations working with particularly sensitive documents, processing files within their own environment can reduce the amount of data that has to move outside their infrastructure. Cloud services, meanwhile, can lower the infrastructure burden and make experimentation easier in some projects.

It’s not one or the other; each solution has its own merit. It depends on the use case.

That may sound obvious, but it becomes a meaningful engineering trade-off once document pipelines start handling contracts, financial records, healthcare documents, or other sensitive enterprise information. Privacy requirements, latency, scalability, and operational complexity all have to be considered alongside extraction accuracy.

A powerful SDK is useless if developers struggle to integrate it

There is also a more familiar developer problem: integration. No matter how sophisticated a document-processing engine is, developers eventually have to put it into a real application, maintain it, and debug it.

For Mancinelli, good documentation is therefore one of the most important characteristics of a production-ready SDK. Practical examples matter as well: developers should be able to see realistic implementations and adapt them instead of building every integration from scratch.

He also points to higher-level APIs as a way of reducing unnecessary implementation complexity:

The point is particularly relevant as AI infrastructure becomes more fragmented. Developers already have to connect models, vector databases, data sources, evaluation systems, observability tools, and application logic. Adding another complicated layer to the stack can quickly increase both development and maintenance costs.

A useful document SDK therefore has to solve two problems at once: the difficult underlying document-processing problem and the developer-experience problem surrounding it.

Data pipelines will become increasingly important

Predicting what software development will look like several years from now is difficult, and Mancinelli avoids picking a single technology that will dominate.

Instead, he expects data pipelines to become increasingly important as companies process larger and more complex collections of information.

One thing is sure: the complexity of the data is going to increase, and the amount of data is going to increase as well. That means data management pipelines will become even more critical.

For developers working with AI, that may be the more practical takeaway.

“The industry tends to focus heavily on what happens inside the model: larger context windows, new reasoning capabilities, faster inference, and increasingly capable agents. But production AI systems also depend on everything that happens before a prompt reaches the model”, Mancinelli said.

If the input is incomplete, badly extracted, or stripped of its structure, even an advanced LLM starts from a disadvantage.

As enterprise AI matures, document processing may become less a peripheral PDF problem and more a core part of the AI data stack, one where developers have to think carefully about structure, privacy, deployment, and, above all, context.

The post AI Is Only as Good as the Document Pipeline Behind It appeared first on ShiftMag.

Last autumn, I had the chance to speak with Dana Lawson, CTO at Netlify, for ShiftMag. This year, I was thrilled to learn that she’ll be joining us as a speaker at Infobip Shift in Zadar – and ShiftMag readers can get a special discount.

Ahead of her talk, I wanted to talk to her about Hot App Summer, Netlify’s community challenge that encouraged developers to ship one AI-assisted or vibecoded app every day for 30 days in June, because it’s a great example of how AI is changing the way we learn, build, and experiment with software.

Netlify got 1.000.000 users in three weeks

Netlify recently crossed 16 million users, adding 1 million of them in just three weeks. For Dana, the milestone itself is less interesting than the pace of growth – and what it says about who is building software today:

The number is exciting, but the pace tells the real story: it points to a fundamental shift in how software gets built.

As Netlify’s CEO Mett Billman in his post says, when Netlify crossed 10 million users, much of the growth was driven by developers discovering the platform through coding agents.

That wave hasn’t slowed, but the audience is expanding beyond professional developers: finance teams are building dashboards, sales teams are creating prototypes for prospects, and customer success teams are shipping tools they once would have needed engineering to build.

AI is lowering the barrier to software development to the point where building is no longer reserved for people with deep technical expertise. Someone with an idea, a spreadsheet, and an internet connection can increasingly turn that idea into working software in hours.

We can now learn by shipping

That shift was on full display in Hot App Summer, which started as a “build one app a day” challenge and grew into a community where people publicly shared their projects and experiences. As Lawson put it, “People were not competing, they were inspiring each other.”

What stood out to Dana most was what that revealed about how people learn today:

People learn by shipping. You can build something on Monday, discover what you still don’t know on Tuesday, improve it on Wednesday, and then repeat the process.

As she put it, you learn more from thirty imperfect apps than from one perfect tutorial, because every project exposes something new to solve.

Now, even small problems can be solved with software

Looking back at the projects created during challenge, Dana points out that most were not attempts to build the next billion-dollar startup:

Many focused on solving small, everyday problems – from time management and business processes to family coordination and content creation.

That part of the software market has often been underserved because custom solutions were not always worth building financially.

AI suddenly makes these niche problems economically viable to solve.

Engineers are not disappearing, their role is expanding

Netlify’s CTO believes this lower barrier to entry points to a much bigger shift across the industry: computer literacy is changing. It used to mean knowing how to use technology, but today it also means knowing how to create with it.

This allows experts from different fields to solve problems in their own areas without waiting for someone else to create the tools they need:

A CFO can build a forecasting system, a teacher can create a classroom tool, a small business owner can create their own software instead of waiting for someone else to build it.

In her view, more people creating software does not make engineers less important and at Shift in Zadar, she is going to challenge the idea that AI makes professional engineers less valuable. Her point is the opposite: as more people start building software, strong infrastructure, security, and engineering practices matter even more:

Engineers are not disappearing, their role is expanding. They are becoming the people who build platforms, guardrails, and systems that allow millions of others to develop software safely.

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

The post Netlify’s CTO: You learn more from shipping 30 imperfect apps than from one perfect tutorial appeared first on ShiftMag.

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:

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; engineers on steroids are now expected. But no matter how advanced they are, engineers are still single-threaded by human design.

Processes built around the development cycle are complex. The architecture 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, across the industry, are treating 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.

Across the industry, AI-assisted engineering is forcing us to rethink the trade-off between speed and structure. This is no longer just about managers assigning tasks; it is about designing a human operating model where AI amplifies human capability, rather than replacing it.

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 adapt how teams are structured and how work is prioritized, the human side of the system can quickly become overloaded.

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.

Teams are being asked to change 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, whole industry needs a collaborative sanity check. We do not need actions to be solved, but to hear and see the real load people are holding. And yes, my 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 views expressed in this article are those of the author and do not necessarily reflect the official position of the company.

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.

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.

Fortunately, there was no production incident; most issues were detected during internal testing. It is always better to learn on someone else’s mistakes, this article will help you learn on mine.

The architecture in place

The service orchestrates WhatsApp campaign delivery through an asynchronous, scheduler-driven pipeline. Campaign destinations enter the system via an API and are persisted to MS SQL Server. Two background schedulers handle the processing. The first retrieves unscored destinations, invokes a scoring service to evaluate delivery priority, and assigns each destination to a bulk: either appending to an existing one or creating a new bulk when capacity is reached.

The second scheduler manages the delivery lifecycle: it polls the external Bulk Scheduling System for status updates, submits ready bulks for sending, and coordinates priority by pausing lower-scored bulks while higher-priority ones are in flight. MS SQL serves as the central state store, maintaining campaign metadata, bulk assignments, and processing status throughout the pipeline.

Insert record in batches

When you expect a heavy load, don’t insert data one by one. We learned this when a client started sending their campaign as separate HTTP requests—one message per request, all belonging to the same campaign. Our controller accepted a list of messages, but a single-element list is still a list, right? The service started returning HTTP 500 errors due to waiting too long for an available database connection.

We solved this by introducing Kafka as a buffer between the API and the database. Incoming requests get published to a topic and then consumed in batches, enabling batch inserts into the database. A nice bonus came from how Kafka handles partitioning: by setting the message key properly, we ensured that all requests for the same campaign land in the same partition—and get processed together.

Of course, the implementation should still handle lists properly. One caveat: Hibernate does support batch inserts (feel free to check), but not when you use an IDENTITY primary key generation strategy. With IDENTITY, the database generates the ID on each insert.

To get true batching, we bypassed Hibernate and used plain JDBC.

override fun submitCampaign(campaignRequest: CampaignRequest) {
    val message = campaignRequest.messages[0].message
    val campaignId = campaignRequest.parameters.campaignId ?: "no-campaign-id"
    val topicKey = "${message.channelId}-${message.from}" +
                   "-${campaignRequest.parameters.templateName}-$campaignId"
    val messageBatches = campaignRequest.messages.chunked(maxMessagesPerBatch)

    messageBatches.forEach { batch ->
        val batchRequest = CampaignRequest(
            messages = batch,
            parameters = campaignRequest.parameters
        )
        campaignRequestProducer.send(ProducerRecord(TOPIC_NAME, topicKey, batchRequest))
    }
}

@KafkaListener(
    topics = [TOPIC_NAME],
    containerFactory = KafkaConsumerConfiguration.BATCH_LISTENER_FACTORY_BEAN
)
@Timed
fun processRequests(
    records: List<ConsumerRecord<String, CampaignRequest>>,
    ack: Acknowledgment
) {
    val groupedByCampaign = records.groupBy { it.key() }

    for ((_, recordsGroup) in groupedByCampaign) {
        val campaign = findOrCreateCampaign(...)
        val destinations = recordsGroup.flatMap { it.value().messages }.mapToDestinations(campaign)
        storeCampaignDestinations(destinations)
    }

    ack.acknowledge()
}

@Transactional
override fun batchInsert(destinations: List<CampaignDestination>) {
    if (destinations.isEmpty()) return

    val sql = """
        INSERT INTO cds.campaign_destination
            (campaign_id, destination, external_message_id, content, failover)
        VALUES
            (?, ?, ?, ?, ?)
    """.trimIndent()

    jdbcTemplate.batchUpdate(sql, destinations, destinations.size) { ps, dest ->
        ps.setLong(1, dest.campaign.id)
        ps.setString(2, dest.destination)
        ps.setString(3, dest.externalMessageId)
        ps.setString(4, dest.content)
        ps.setString(5, dest.failover)
    }
}

Now Kafka took the big chunk of stress, the database can easily handle the load.

Too complex queries

A query that’s too complex can take too long to execute, especially without proper indexes. Think about what data you already have in the application and use it to simplify things. In our case, we needed to find bulks that still had space for more recipients. The original query joined the destinations table to count how many each bulk contained, filtered by several conditions, and used a HAVING clause to check capacity.

@Query("""
    SELECT cb, COUNT(cd) FROM CampaignBulk cb
    LEFT JOIN CampaignDestination cd ON cd.campaignBulk = cb
    WHERE cb.campaign = :campaign AND cb.priority IN (:priorities) AND cb.waitUntil > :nowWithBuffer AND cb.bulkStatus = 'CREATED'
    GROUP BY cb
    HAVING COUNT(cd) < :maxBulkSize
""")
fun findNotFullAndNotExpiredBulks(campaign: Campaign, priorities: Set<BulkPriority>, maxBulkSize: Int, nowWithBuffer: Instant): List<BulkWithCount>

The problem? A join on an unindexed column, filters without indexes, a COUNT, and a HAVING clause. Combined, it was too much for the database. The query took ages and locks escalated to entire tables. It quickly turned out that we already knew the destination count during processing. So we denormalized: we added a destinationCount column to the CampaignBulk table and updated it whenever destinations were added. The new query and supporting index look like this:

@Query("""
    SELECT cb FROM CampaignBulk cb
    WHERE cb.campaign = :campaign
      AND cb.priority IN (:priorities)
      AND cb.waitUntil > :nowWithBuffer
      AND cb.bulkStatus = 'CREATED'
      AND cb.destinationCount < :maxBulkSize
""")
fun findNotFullAndNotExpiredBulks(
    campaign: Campaign,
    priorities: Set<BulkPriority>,
    maxBulkSize: Int,
    nowWithBuffer: Instant
): List<CampaignBulk>

CREATE NONCLUSTERED INDEX idx_campaign_bulk_count_filter
ON cds.campaign_bulk(campaign_id, bulk_status, destination_count)
INCLUDE (id, priority, wait_until, bss_bulk_id, api_key_id, creation_date, last_status_change_date);

After these changes, the query performs well.

Concurrency: when more isn’t always better

We all want to process data as fast as possible. Especially in the world of virtual threads; you can spin up thousands of them and feel good about how concurrent your application is. But the database doesn’t share that enthusiasm. Under the hood, you have a limited Hikari connection pool. Run too many concurrent operations and your queries start timing out. Worse, when multiple threads hit the same table and the same dataset, you’re heading straight for lock contention.

Here are a few things to consider when you need to control concurrency.

Use shedlock

ShedLock is a library that ensures scheduled tasks run only once across multiple application instances. It works by creating a lock record in a shared storage—typically a database table—before executing a task. When a scheduler triggers, it tries to acquire the lock by inserting or updating a row. If another instance already holds the lock, the task is skipped.

The lock is released after execution or after a configured timeout, preventing deadlocks if an instance crashes mid-task. In our case, we wanted to avoid the same campaign being processed by a couple of instances at the same time.

Shedlock helps a lot here. Feel free to check the full ShedLock documentation.

val config = LockConfiguration(
    Instant.now(),
    LOCK_NAME_FOR_PROCESS_CAMPAIGNS + campaign.id,
    Duration.ofMinutes(5),
    Duration.ZERO
)

val lock = lockProvider.lock(config)

if (lock.isPresent) {
    try {
        singleCampaignService.processSingleCampaign(campaign)
    } finally {
        lock.get().unlock()
    }
}

Limit your concurrency with a semaphore

A Semaphore lets you limit how many threads can execute a block of code at the same time. In our case, each scheduler iteration could potentially process dozens of campaigns in parallel; especially with virtual threads, where spawning new threads is cheap. But each campaign processing involves multiple database operations: reads, updates, and inserts. Letting all of them run at once would exhaust the connection pool and trigger lock contention.

We introduced a Semaphore with a fixed number of permits to cap the number of campaigns processed concurrently. Before processing a campaign, a thread must acquire a permit. If all permits are taken, the thread waits, but with virtual threads, this isn’t a problem.

When a virtual thread blocks, it gets unmounted from its carrier thread, freeing it to run other virtual threads. So waiting for a permit doesn’t waste OS resources like it would with traditional platform threads. Once processing is done, the permit is released.

This keeps database load predictable and prevents the connection pool from becoming a bottleneck.

private val semaphore = Semaphore(10)
private val executor = Executors.newVirtualThreadPerTaskExecutor()

fun processCampaigns() {
    val campaigns = campaignRepository.findAllToProcess()

    campaigns.forEach { campaign ->
        executor.submit {
            semaphore.acquire()
            try {
                processSingleCampaign(campaign)
            } finally {
                semaphore.release()
            }
        }
    }
}

Use query hints

When multiple threads query the same table, the database decides how to handle locking. Sometimes those defaults work against you in different ways. Locks escalate, threads wait on each other, or worse, deadlocks occur. SQL Server lets you guide this behavior with query hints. Here are the ones we found useful:

• UPDLOCK – reserves update locks on selected rows, so other threads can’t select the same rows for processing.
• READPAST – skips rows that are already locked by other threads instead of waiting for them to be released.
• ROWLOCK – suggests that SQL Server use fine-grained row-level locks instead of page or table locks.
• NOLOCK – reads rows without acquiring shared locks, allowing it to read data that other transactions are currently modifying. This means it won’t block writers and won’t be blocked by them but it can return dirty data that might be rolled back, or even read the same row twice or skip rows entirely if data is being moved during the scan.

Think about your access patterns. Are multiple threads competing for the same rows? Are you okay with skipping locked data or reading uncommitted changes? The right combination of hints depends on your specific use case but knowing they exist can save you from mysterious slowdowns and deadlocks.

Process data in batches

Even with ROWLOCK hints, SQL Server can escalate locks. When a single transaction acquires too many row locks on one table, SQL Server may convert them into a table lock for efficiency. This is called lock escalation, and when it happens, your “harmless” operation suddenly blocks everyone else.

We learned this the hard way. Our scoring scheduler fetched all unscored destinations for a campaign in a single query, which sometimes includes tens of thousands of rows. With UPDLOCK to prevent other threads from picking them up, SQL Server decided it was cheaper to lock the entire table. Suddenly, other threads couldn’t read or write to the destinations table at all. The whole pipeline stalled, waiting for one greedy query to finish.

The fix was simple: fetch in batches. Instead of selecting all unscored destinations, we now use TOP(n) and iterate until there’s nothing left to process.

SELECT TOP(400) cd.*
FROM cds.campaign_destination cd WITH (UPDLOCK, READPAST, ROWLOCK)
WHERE cd.campaign_id = :campaignId
  AND cd.bulk_id IS NULL
  AND cd.id <= :maxId

Each batch locks only a few hundred rows, commits, and moves on. This keeps the lock count well below the escalation threshold and lets other threads continue their work.

For more details on lock escalation, see Microsoft’s Troubleshooting explanation.

Final thoughts

The database is not an implementation detail you can ignore. I hope these lessons save you some debugging time.

Have you faced similar challenges? I’m curious how others handle these problems.

The post How Convenient JPA Defaults Broke Our Kotlin Microservice appeared first on ShiftMag.

What’s the worst type of project?

Sure, the term “worst” means different things to different people, but most of the engineers agree: the worst types of projects are the ones that aren’t set up well by humans, not the ones that have big technical requirements. And, as you can probably guess, human-designed flaws are much more creative.

For example, one engineer highlighted that the worst project for him was working with family members who were not familiar with software development at all, affecting expectations, realisations and everything in between.

Another situation was a client project that took four months, with progress going smooth up until the last month. Nikola Buhiniček, Engineering Manager, said:

The client changed the scope significantly without much warning. We had to abandon a lot of the work we’d already done and come up with new features and opportunities. It felt like compressing two and a half months of work into one month before the deadline.

Another type of projects that drive engineers crazy are legacy code projects without real instructions on how to approach them, as explained by Edvin Teskeredžić, Senior AI Software Engineer:

We had this old legacy project, basically 10-year-old code which needed to be maintained. It was also all internal libraries but there was no documentation. The documentation simply lived in the heads of senior engineers, so you had to kind of figure it out yourself, and you couldn’t Google it because it was all internal libraries.

What’s the best, then?

In contrast, the best projects tend to be tied to others as well, only this time it’s about great teams and good colleagues. For some engineers, the best projects are those where leadership has a clear vision and that vision is clearly shown to the teams.

Other engineeers, such as Filip Bolčić, Full-Stack Engineer, highlighted teamwork as the best part of the projects they’ve worked on. For example:

Everybody’s insight was really valuable, and I had a great mentor from whom I learned a lot. It was just a really meaningful project for us, we felt really good working on it.

On the other hand, Nikola noted that sometimes, the best projects are the most challenging ones. He explained the process of adding the automations feature to Productive was one of the more challenging and interesting ones he worked on:

It was such a different feature from what we used to do, and I was given the opportunity to build it. In the end it was one of the best features we have. The usage is growing up from month to month. I’m really happy that it was something that I built like two years ago, and it’s still growing so fast.

It all comes down to the human factor

The hardest thing to fix as an engineer might not even be software-related, according to Hrvoje Rančić, Senior Software Engineer:

My posture. I had really terrible back pain from sitting too much during the COVID era. I think this is a very dangerous job because it involves a lot of sitting, and sitting is the new smoking, so I encourage everyone to move more if you’re a software engineer.

Ergonomics aside, Software Engineer Emin Mulaimović said that some of the biggest recent challenges he had were related to LLM’s:

We had this unstable LLM prompt which basically means you ask the same question and it gives different answers, and the answers are not marginally different. To fix that you just need to rephrase the question over and over and over again until it worked. And then when it worked you didn’t learn anything, you didn’t have fun fixing it, you’re just glad it’s over. Some bugs are fun to fix; this one wasn’t.

On the other end of the spectrum, the toughness of a task comes down to a personal mistake by the engineer themselves, and there’s rarely anything you can do but to fix it. That’s exactly what happened to Filip:

I remember working on a really big-scale production application and accidentally just deleting a lot of important stuff from the database. I was really young in my career and I remember being really stressed out about this, but the project manager protected me and we were able to restore a backup of this database, so in the end everything was good, but it was really stressful for me.

And to further drive the point home, sometimes the fix isn’t even tough, but so time-consuming you think you’re going crazy, as evidenced by Olga Koroleva, Engineering Manager:

I made a bug in the code where entries to the database were written wrong, and I had to manually fix thousands of them. After that, I always double-checked and triple-checked everything.

Make sure to check out the entirety of the video to find more about the best and worst projects, and the challenges of software development!

Special thanks to our engineering colleagues at Infobip, Nikola Buhiniček (Engineering Manager, Productive) and Filip Bolčić, (Full-Stack Engineer, Ars Futura).

The post Developers are the reason behind best (and worst) parts of software development appeared first on ShiftMag.

In a recent conversation with a few Infobip engineers, we asked whether that promise holds up in practice – and the answer was clear: AI can generate code fast, but it still cannot understand the problem, define the boundaries, or own the consequences.

That part remains the developer’s job.

AI should be a tool for accelerating clearly defined tasks

Better context and clearer specifications make useful, maintainable, and secure output far more likely. As Zvonimir Petković, Staff Engineer, explained:

The quality of the code ultimately depends on the context given to the GenAI agent and the model underneath. The software engineer is still the one writing the specifications, and the better the specification and context, the better the code produced.

To maintain quality, he says, we need to isolate the code into smaller segments and check each one. Effective work with coding agents is less about one large prompt and more about small, controlled iterations.

That may mean changing the architecture, refactoring a component, or requesting a more precise implementation of a single interface. František Lučivjanský, Senior Principal Engineer, described a similar workflow:

I work with AI in smaller chunks. I give it a small part, review the result, and steer the agent: “This is not correct; do it this way.” I may also define the architecture differently – for example, by asking it to refactor one part first. These slow iterations help me maintain the same quality I would achieve manually.

Working in smaller chunks helps developers preserve a mental model of the system and review decisions while the code is still easy to change. AI serves as a tool for accelerating clearly defined tasks.

AI doesn’t create technical debt, people do

Faster code generation naturally raises questions about technical debt. Teams have more code to understand, test, and maintain, but AI did not create technical debt. Debt grows from deadlines, trade-offs, and decisions that prioritize short-term delivery over long-term maintainability.

For Tvrtko Ivasić, Application Security Intern, the answer is not to relax established controls, but to reinforce them:

We should preserve the standards established in the past: the security pillars, the SDLC pipeline, code review, SAST, and the rest of the process. If anything, the bar should be even higher because the code is now generated by AI rather than written by an engineer.

AI-generated code should go through the same SDLC as human-written code: code review, automated tests, SAST, and dependency checks.

František Lučivjanský notes that agents don’t remove the pressures behind technical debt, but they can help manage it more deliberately. They can also spot duplication, suggest refactors, write tests, or explain legacy code, but the value still depends on the engineer reviewing the output.

Vibe coding might evolve into agent engineering

Vibe coding may be enough for a hobby project or proof of concept, but problems begin when the same workflow reaches production without additional controls. Engineers may not need to write or memorize every line, but they still need to understand the architecture, system boundaries, scalability, and failure modes, enough to delegate implementation without delegating responsibility.

Asked whether vibe coding is a sustainable approach to software development or merely a short-term productivity boost, Zvonimir argued that it is likely to evolve:

Vibe coding is not just a short-term boost or a passing trend. “Dark factories” may represent the ultimate direction, with workflows that incorporate vibe coding and require us to look at the code less and less. I think it will evolve into agent engineering, and that is how software will be built in the future.

Companies that adopt this workflow may ship faster without sacrificing quality, spending less time on routine code and more on specifications, architecture, evaluation, and automated controls. The key is to understand where vibe coding creates speed, where it introduces risk, and how AI agents fit into proven software engineering principles – because responsibility for what reaches production remains unchanged.

Special thanks to our engineering colleagues from Infobip, the publisher of ShiftMag!

The post AI Helps Ship Faster, But It Doesn’t Do the Thinking appeared first on ShiftMag.

Join us on the beautiful Croatian coast

Speaking of sneak peeks, reading this article makes you eligible for a discount on Infobip Shift tickets. You’re welcome.

To kick things off, I had the opportunity and pleasure to talk with one of this year’s speakers,Teresa Wu. In addition to her work as the VP Engineer at JPMorgan Chase, Teresa is also a Google Developer Expert (GDE), an accomplished public speaker and mentor.

She has worked with many talented developers on various apps and projects over the years, and she enjoys exploring the world of multi-platform development, the fun of continuous delivery, and following a product from development to release.

Her experience makes her the ideal person to talk to about today’s tech landscape, especially in the era of AI. So we did just that, and also talked about the perspective of an experienced mentor and public speaker. Teresa also shared some hints of her upcoming talk at Shift!

AI accelerates multi-platform development

Throughout her career, Teresa has worked in front-end development, cloud technologies, and multi-platform products.
Currently, she is most inspired by multi-platform development, which she finds very exciting because, by using a single codebase combined with AI-powered automation, we can significantly speed up code generation and easily adapt user interfaces for iOS, Android, and web platforms:

In this way, traditional barriers between platforms are removed and the time needed to bring a product to market is significantly reduced. This allows engineering teams to overcome technical limitations and fully focus on rapidly delivering value to end users.

AI is nothing without people!

When asked how she sees the impact of artificial intelligence on the daily work of software engineers, Wu notes that AI is constantly evolving, creating a kind of feedback loop in which what we build today becomes training data for tomorrow’s systems:

AI frees us from routine and repetitive tasks, but it still relies on people when it comes to defining rules, guiding processes, and creating new patterns of thinking. That is exactly where human creativity, experience, and judgment remain irreplaceable.

Professional growth is impossible without enthusiasm

As a mentor and experienced public speaker, Teresa believes that sustainable professional development is almost impossible without genuine interest in what you do. That’s why she tries to find technology or projects that truly interest her, whether within her job or outside of it, and to find personal motivation in them:

For me, public speaking is not just an opportunity to present knowledge; it is a way to explore new ideas and build a network of friends and professional contacts. When you align your learning with what truly drives you, professional growth becomes a natural and fulfilling consequence.

Shift conference as an opportunity to expand knowledge

For Wu, this will be the first time speaking at (or visiting) Infobip Shift. She decided to participate because the event brilliantly combines cutting-edge technologies and a vibrant community of experts, and is especially looking forward to the unique atmosphere of a large tech festival in Zadar.

In addition, the opportunity to explore a beautiful destination while connecting with a global network of developers represents the perfect personal motivation for gaining new ideas and inspiration.

Much more than just code!

As she points out, Teresa’s main goal is to gain a new perspective on how engineering teams use AI-based automation:

Beyond technical talks, I place great value on people and conversations. What I especially appreciate about Shift is that it’s not just about code, but about the unique energy of thousands of developers trying together to understand what the future brings. I want to bring that inspiration into my everyday work as well.

Sneak peek of the Shift talk

Without revealing too many details, I asked Teresa to hint at the topic of her talk and what can attendees expect to learn or take away from it:

• Problem: Engineers responsible for software releases spend up to 40% of their time on manual processes and overly large change packages.
• AI-driven transformation: Moving from simple code-writing assistance to an autonomous “Release Pilot.”
• Data-driven decisions: Replacing subjective “go/no-go” decisions with an AI index that evaluates stability signals and system observability.
• Implementation plan: A 90-day migration path that significantly reduces manual work and enables faster, more efficient software delivery.

Want to hear Teresa live? Purchase your Shift ticket and use code MAG15 for a discount!

The post Great Developers Are Curious, Creative, and Ready for AI appeared first on ShiftMag.