“Voice AI is an infrastructure problem because voice itself is an infrastructure problem,” says Kosta Pribić, a Senior Principal Engineer at Infobip.

He works with voice services – real-time communications across the globe, across multiple data centers, and for everyone reachable on the planet. Yep, it’s a lot.

That scale makes voice AI a much more complex challenge than developers might initially expect.

Developers can take control of the call in real time

Kosta sees voice AI as a two-layer system. Smaller models built into phones can handle real-time issues like packet loss and background noise. They should do their work quietly in the background, so the device just feels like it works.

Larger models, meanwhile, usually run in the cloud and need access to the audio being exchanged between devices. That’s where Infobip comes in: it provides the communications infrastructure developers need to process that audio in real time.

We give you control over the call. We enable you to interject, do something smart with the media.

He says a lot of the infrastructure behind this, from global data centers to enterprise deployments, was originally built for web pages. But web pages aren’t real-time communication.

So when teams use that infrastructure for voice AI, they end up carrying over decisions that were made decades ago. Those systems weren’t built for a live AI-assisted call, which means developers are often stuck working around constraints they probably wouldn’t choose if they were starting from scratch today.

Biggest challenges are real-time performance and cost

Developers entering voice AI often expect hallucinations to be the biggest challenge. But Kosta says they usually run into a different set of problems first, like custom signaling protocols, real-time delivery, and tricky networking edge cases. Networks aren’t built for this kind of traffic by default, so for developers without a voice background, it can feel like a completely new set of problems to learn.

“The main problem is understanding all of this. It’s completely new,” he says. That’s why Infobip’s first internally built LLM-enabled application was a voice AI troubleshooter. Kosta sees troubleshooting as a practical place to start, because teams first need to understand the communication problems they’re actually dealing with.

From there, model choice comes down to the business case and the margins. Kosta says a large model can make sense when latency isn’t a major concern and the economics work.

If your business case allows for using huge LLMs and you don’t care that much about latency, great, go for it.

But in most cases, he says, latency matters. Teams may need smaller LLMs to process calls, or fast, lightweight models to handle audio. Cost matters too, especially when a model is running on every call, because a large model can become expensive fast.

Voice AI has to be private, reliable, and real-time

People expect voice-enabled communications to be private and confidential, Kosta says. They also expect calls to be as reliable as the telecom services they already use, which he describes as operating at “five nines.” Once that trust is lost, it’s much harder to win back.

For developers who are new to voice, understanding those expectations is part of understanding the system they’re building.

That becomes especially clear in assistive use cases. Kosta points to an Infobip customer using a generative model to create voices for people with damaged vocal cords:

They can speak in a whisper while the person on the other end hears the generated voice. That’s, I think, the most heartwarming implementation I’ve ever done.

In the end, before choosing a model, developers need to understand how a call works, where it can break down, and how much delay and cost the application can handle. Even the best model won’t help if its response can’t make it back to the caller in time.

The post Voice AI Is an Infrastructure Problem, Not Just a Model Problem appeared first on ShiftMag.

We help companies put AI to work in real environments.

We spoke with him about what it takes to move AI agents into production, how developers can make them reliable and secure, and which skills will matter most as AI changes software development.

Production starts with evals

As Luis hinted in the intro, Forward Deploy Engineers (FDE) help companies turn AI demos into real products. So we asked him what developers most often underestimate when they make that jump.

According to him, the real challenge starts when a demo reaches production. A demo can work well in controlled conditions, but production forces teams to understand exactly what works, what does not, and why failures happen.

That is where eval-driven (Evaluation-driven) development becomes important. He says OpenAI uses it extensively in its engagements to track and measure different workflows and tasks:

We have a scientific approach to measure the performance of the models doing a task. When, basically, you clear those benchmarks, those evals, you are good to go to production in a really good and safe way.

The deployment gap is the real challenge

We wanted to understand what makes an AI agent reliable enough for production, rather than something that only works well in a controlled environment.

Luis said it all comes down to “cracking the evals.” As he explained, today’s models already have impressive intelligence, but putting them to work in a company’s own environment requires giving them access to the company’s data, procedures, and tools:

You know, those three things, we kind of call the deployment gap, right? And this is what we’re trying to close as FD, basically.

Agents went from six-minute to 16-hour tasks

But what happens when an agent works on a task for hours rather than minutes? How should developers think about errors, memory, context, and human approval as those workflows become longer?

Luis answered with an example from his own experience. While checking the latest data from METR’s long time horizon benchmark, he was surprised by how quickly agents had improved. In just over three years, they went from handling tasks that would take a human around six minutes to tasks that would take around 16 hours.

That represents a massive jump, he said:

On one hand, you have the models getting better at long-term coherency and persistence, but on the other hand, you also have the harnesses improving a lot. Back in the days, a developer needed to care about context management, memory creation, and all of that. Right now, as I say, with harnesses such as Codex, all that is gone.

For Luis, that progress comes from combining more capable models with more powerful harnesses. Together, they allow engineers and developers to run increasingly complex workflows over much longer periods of time.

Agents should follow the same access rules as employees

When it comes to security, we wanted to understand the safest way to connect AI agents to company data without creating new permission and access risks.

Luis explained it through a familiar workplace example. When a company onboards someone who works in finance, it gives that person access to financial data, but not to HR data they do not need.

He argues that companies can apply the same principle to AI agents, using the same access controls and permission rules they already use for employees:

In the same way that when you onboard an employee into your company, and let’s say he or she is working in finance, you only give access to the finance data. You don’t give access to the HR data, right? So, in the same way, those same principles, those same ACLs, can also apply to AI agents, right?

For him, the principle comes down to giving agents access only to what they require to perform their tasks:

So, in my view, it’s about having the roles, the permissions, and the setup for the agents to only see what they need to see for completing their workflow, basically.

Evals are fundamental to AI development

Finally, we asked Luis what developers should test and measure before releasing an AI agent to real users.

Once again, he came back to evals. He said he keeps returning to the concept because it remains critical and fundamental to AI development:

I think we go back to evals once again, right? And I keep coming back to that concept because it’s absolutely critical and fundamental for AI development, right? If you’re able to put together that representative eval set containing easy cases, medium cases, and also edge cases, and you’re able to highly lean on your skills, on your guardrails, on the prompts you send to the model, that will give you the guarantees that when you deploy to production, nothing will break.

He added that evals also give developers a way to test for regressions when they upgrade to a new model and make sure the change does not break existing workflows:

Furthermore, when you upgrade your model to a new one, you have a way to test regressions and make sure that that upgrade won’t break anything.

System design taste will never go away

Before joining OpenAI, Luis also worked at Google, so over the years he has seen plenty of developers, roles, and career dilemmas up close. That is why, to close the interview, we asked him which skills developers should focus on today to stay relevant in the age of AI agents.

He believes that, in this new era, engineers will no longer create code as their primary output, because code has become very cheap to produce.

Instead, he sees much more value in everything developers build around the model:

I think now, in this new era we’re entering, the primary thing that engineers are creating is not code anymore. Code is very cheap to produce. It’s all about building the system around it, so the system of intent, the guardrails, the constraints for the agent to work reliably, right? So I think creating those harnesses around the model will be absolutely critical.

Luis ended our interview with a simple but sharp statement:

Plus, I always say, like, system design taste will never go away.

The post OpenAI’s Luis Velasco: Code is very cheap to produce, but the system around it isn’t appeared first on ShiftMag.

Small teams are taking over the whole build 

The structure of software teams is one area where Dana already sees a noticeable shift. Larger teams traditionally split these roles among several people, but much smaller groups can now handle them together:

The biggest difference is the empowerment that teams have. Before, you would have teams of 5, 6, 8, 10 people that all had very distinct roles in the software development life cycle, and I think the biggest shift is the enablement that people that are enabled solo, or two or three, can do everything end-to-end.

That shift has also influenced how Netlify organizes product development. Dana says the company no longer relies on sequential handoffs between product managers, designers, and engineers.

Instead, Netlify gives teams more autonomy through a narrative-driven product roadmap. The company sets the broader direction, while individual teams decide how to shape what they build next. 

To stay aligned without introducing additional layers of coordination, Netlify combines familiar tools and routines with AI agents:

We really let our teams have some personal take on what they’re going to build next, but we utilize systems like Linear and stand-ups, and honestly agents to keep us all in line so that we can move at the speed of machines. 

Low-ego leadership 

More autonomous teams also change what Netlify CTO expects from the people leading them. 

When asked which leadership lesson has stayed with her through roles at GitHub, Heptio, New Relic, and Netlify, Dana returned to two ideas, trust people and recognize expertise regardless of title: 

Low ego. You are going to have people smarter than you in the room just because you have the amazing title and you are marked the leader. Your job is to be humble, build connections, and really learn, and be a part of your team and not just mining your team, and I think the biggest lesson is to trust people and allow them to be adults.

That principle becomes even more relevant as the work itself changes and developers increasingly operate alongside AI agents. 

Developer experience is now an agent experience 

When we asked Dana what a great developer experience looks like today, she framed the question around a different relationship between engineers and code. 

For her, the developer’s job is increasingly about enabling agents to act safely on their behalf: 

A great developer experience is an agent experience. No longer should my developers be writing code. They should be enabling agents to do stuff safely and on their behalf. 

That kind of environment also depends on developers being able to understand what those agents are doing. 

Dana points specifically to clarity, signals, and telemetry as the mechanisms engineers need both to help agents complete their work and to understand what they have done once changes reach production: 

A good engineering experience is ensuring that we have clarity, signals, and telemetry so that their agents can get the job done, and so that they can know what the agents did in production. 

From writing code to system design 

If agents take on more of the direct implementation work, Dana sees engineers spending more of their attention at the system level. 
 
She describes that change as a move away from creating code itself and toward designing the environment in which software is built and operated: 

We’ve moved it from creating code to really architecting systems and allowing engineers to do what they do best, which is build trust within the systems.

In that framing, the impact of AI is not limited to making individual development tasks faster. It also changes where engineering judgment is applied. 

Don’t use AI agents to automate bad processes 

Dana is also cautious about one of the most straightforward ways companies can approach AI adoption, taking an existing process and simply inserting an agent into it. 

Instead, she argues that teams should reconsider the workflow itself: 

Agents can’t do everything. They can do everything, but they shouldn’t do everything, and it’s a trap. Don’t start building things on existing workflows. Change your workflows.

That becomes even more relevant as Dana expects engineering roles, tools, and workflows to change significantly over the next few years:

Enable an agent experience, because in two years, our jobs will significantly change, and some of the tools that we’ve been building and some of the workflows will be commoditized. 

That doesn’t mean replacing every existing tool 

At the same time, Dana is not arguing that teams should replace technology simply because something newer exists. 

She specifically points out that tools such as Bash can still have a place when they remain appropriate for the problem. 

Her advice is: “Keep it simple.” 

The post Netlify CTO: “No longer should my developers be writing code” 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.

A few years ago, building an AI app was hard. Today, anyone can put together an LLM, connect a few APIs, and build a strong demo in a day. But turning that demo into a production app is still much harder.

At the AI Engineer World Fair, I talked with Mike Chambers, a Developer Advocate at AWS who focuses on generative AI, about what makes production AI systems different from conference demos. His answer kept coming back to one thing developers often overlook: everything around the model.

It’s not AI, it’s harness

Developers spend a lot of time comparing models, tweaking prompts, and testing frameworks, but far less time on the infrastructure that keeps an AI app running. In his talk, Mike said many production failures don’t come from the model itself, they come from what he calls the harness.

There’s two different types of agents: an agent that I’m using and an agent that I’m building, and we need to think about those very differently.

For developers using coding assistants, the harness is mostly about standards, workflows, and how AI fits into the team’s development process. But for engineers building AI products, it means something completely different, as Mike put it:

You have to think about how you’re actually going to deploy that out to infrastructure and deploy it at scale. And so doing that right and not just putting everything inside of one container, that’s the top tip here.

That distinction matters because a lot of AI talk treats every agent as the same, but Mike says the engineering challenges are very different depending on whether you’re using an AI tool or building one for other people.

Observability needs to be built in early

Today’s AI world is full of impressive demos. They can write code, answer questions, and automate tasks well enough to impress a crowd. But production systems need much more, so I asked Mike what teams usually get wrong when they move from demo to production:

The number one thing is observability, followed closely by evaluations.

Mike said that used to be less important. Teams would build something cool, show it off, and stop there. Now, production AI needs much more discipline from the start.

Modern AI systems, Mike says, work differently from traditional software. Their outputs can vary, their reasoning isn’t always easy to trace, and agents may take several steps to reach a result. That’s why observability needs to be built in early – so teams can understand what the system is doing before they try to ship it to production.

Too often, AI projects are still judged mainly by model quality, when what really matters is whether the system is visible and controllable in practice.

Memory doesn’t have to live inside the agent

Memory is one of the biggest topics in AI engineering, and it’s often treated as essential for useful agents. So I asked Mike what engineers misunderstand most about it.

He said the biggest misconception is that an agent can’t work without memory. Short-term memory is just the current conversation, while long-term memory carries over into future interactions. The key question is where that processing happens:

All of that memory extraction can happen outside of your agent somewhere else because you don’t need it today. You need it tomorrow when the user comes back to the agent again.

Rather than making every agent responsible for managing its own knowledge, developers can separate those concerns into different systems. That keeps agents simpler while still allowing applications to remember previous interactions.

Are multi-agent systems the future?

Another topic attracting plenty of attention are multi-agent architecture. Conference demos often showcase teams of specialized agents working together on different tasks. I was curious whether Mike sees that as the future of AI systems, so I asked him directly.

He said that he doesn’t dismiss that approach, but he sees a different reason for using multiple agents in production.

Multi-agent is super useful because you’re parallelizing the work. When developers build customer-facing AI systems, however, the motivation shifts. Often multi-agent is about separating out context. So it’s actually now becoming more of a context engineering conversation.

Instead of assigning agents to different jobs simply because it’s fashionable, teams should use them to isolate information and avoid overwhelming a single model with every piece of available context. The architecture becomes less about adding more intelligence and more about deciding which agent should see which information.

Engineers need to build a strong intuition for generative AI itself

Mike’s most practical advice had little to do with frameworks or infrastructure.

When I asked him what developers should focus on over the next few years, he didn’t point to another SDK or the latest model release. Instead, he argued that engineers need to build a strong intuition for generative AI itself – what large language models can do, and just as importantly, what they can’t.

New models will keep arriving, but right now, he said, the biggest improvements are happening around the model, in the harness.

His final observation neatly summarizes the engineering mindset he hopes developers adopt:

You want to be using this technology. You don’t want this technology to be using you.

The post We Usually Blame the AI Model, But the Harness Is What Breaks Production 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.

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.

Once again, we brought together some of the finest minds Infobip has to answer tricky questions about the future of software.

This time around, we spoke to four Infobip engineers about how they use AI in their daily work and how they view the AI revolution happening now.

Research, plan, execute

With rapidly changing AI infrastructure, the things that used to be normal in software development are getting different, but some things stay the same.

Petar Dučić, Engineering Director, said that the company’s mantra “you build it, you own it” has remained the same in the AI era. This simply means that engineers are responsible for whatever they build.

Senior IT Research Scientist Ante Kapetanović, added that engineers need to separate their work phases efficiently:

You have to separate your research phase, your planning phase, and your coding implementation, whatever phase. This ultimately means that you own each step of the way. And basically, it is not AI-assisted coding, it is more human-assisting AI.

Engineering is now becoming even more necessary…

It’s true that using AI tools is, in many cases, a cheaper alternative to real people, but Petar pointed out that engineering is now becoming even more necessary, because there’s so many things that can go wrong, and we need real people to check them and undestand what’s going on.

Senior Software Engineer Rino Čala pointed out that there’s three types of mistakes agentic tools make: logical mistakes, code-based mistakes and security mistakes. The solution is, as Rino puts it, just more tests:

So it is definitely important to run tests, to run some local tests, CI tests, and do some static checks as well.

Zvonimir Petković, Staf Engineer, then explained that security issues are the number one flaw with AI software tools:

Security is the main risk with deploying Gen-AI generated code. With the whole Vibe coding setup, nobody looks at the code, and oftentimes we have also non-engineers deploying code. The hiding sensitive data within the source code itself, this is the number one problem.

The second problem for Zvonimir is scalability. Something that is built in a couple days might work fine for a small team, but cannot be scaled to 5,000 people easily.

… and engineers are now more orchestrators than code writers

A stark contrast to the narrative of AI taking away jobs for engineers is that, with more people actively using AI, there’s a bigger need for someone with a technical background to help with not just support, but education.

“We’re slowly becoming context engineers”, added Ante, saying that engineers are now spending a lot of time managing their context in different AI tools. He is personally a big advocate for writing your own code and feels like this is a major part of being an engineer. Still, Ante admits that might not be the case in a couple years.

Zvonimir, interestingly, had a take about exactly that:

The total trend is that in a few years’ time, we’ll have the situation where nobody writes the code manually. Software engineers will be like persons who are the experts in that field, so they will be able to review what gen AI has generated.

In conclusion, as Rino puts it, engineers are now more in the role of orchestrators and organizers than they are code writes, since they spend a lot of time managing AI models to do things properly.

Want to hear more? Check out the video.

Special thanks to our fellow colleagues at Infobip, the publisher of ShiftMag!

The post A Future Where Nobody Writes Code Manually Might Be Closer Than It Seems appeared first on ShiftMag.