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.

Put together, they form a consistent picture – not an official ladder, but a very real one that shows how engineers grow, gain influence, and move from writing code to shaping entire systems.

Compensation reveals the real hierarchy

At its core, Adobe uses a P-level system (Professional levels) that maps engineering growth from entry-level roles to company-wide technical leadership.

Adobe doesn’t hand out impressive titles quickly. But behind the modest titles, what’s actually expected of you keeps growing at every level. The ladder looks flat from the outside. From the inside, the gap between levels is real.

If titles are understated, compensation isn’t: across multiple sources, total compensation for software engineers at Adobe ranges from roughly $150K at the entry level to well above $500K at the top of the individual contributor track.

The numbers matter, but so does the curve. Pay grows steadily through early and mid-level roles and then jumps sharply after senior. That’s where Adobe starts paying for influence, not just output.

Senior level: where leverage begins

At P10 and P20, the job is straightforward: ship code, learn the systems, and figure out how Adobe builds and scales things. The goal is to become someone the team can rely on.

By P30, something shifts. Engineers stop executing tasks and start owning problems (taking a feature end-to-end), making real technical calls, and thinking about why something should be built, not just how.

At P40, the job changes for real. Senior engineers design systems, not just features. They cross team boundaries, shape architectural decisions, and lead bigger initiatives. For many, this is a long-term home – the next step demands a fundamentally different kind of growth.

Staff: the real career breakpoint

The jump from Senior (P40) to Staff (P50) is the most important one on the ladder. Same title family, completely different job.

Staff engineers operate as technical leaders without formal authority. They define architecture, guide technical direction, and shape roadmaps across teams. At Staff, you’re measured by what others can build because of you and compensation starts to reflect that.

Beyond Staff, engineering becomes increasingly strategic. Senior Staff engineers (P55) operate across domains, aligning engineering efforts with business goals and driving initiatives that span multiple teams.

Principal engineers (P60) move to a company-wide level of influence. They define technical vision, tackle ambiguous problems, and shape decisions that impact entire product lines. At this level, engineering is less about building and more about direction-setting.

Cross-company level mapping

One useful way to understand Adobe’s ladder is to map it against more transparent systems at companies like Microsoft. While titles and expectations vary slightly, the underlying progression is broadly aligned across Big Tech. Adobe’s levels tend to appear slightly compressed in naming, but comparable in scope, especially from Staff level onward.

The important nuance is that while the mapping is directionally accurate, scope matters more than exact title equivalence. A P50 at Adobe may operate closer to a strong L6 at Google or even edge into L7 territory, depending on the organization, reinforcing the idea that Adobe’s ladder is less about labels and more about impact.

What Adobe actually values?

One pattern runs through the whole ladder: scope drives everything.

• Early levels – Can you execute?
• Mid levels – Can you own?
• Senior – Can you design systems?
• Staff+ – Can you influence outcomes across teams?

That’s the real progression. The ladder feels invisible from the outside because titles aren’t the point — expanding impact is.

Adobe’s ladder stands out for how quietly it operates. No playbook, no loud framing, just one consistent logic: as you grow, you move from writing code to shaping systems to shaping decisions. At the top, one question defines everything: how much of the company changes because of your work?

The post Let’s Take A Look Inside Adobe’s Complete Career Ladder appeared first on ShiftMag.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

But there’s a price.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Just introducing new tools isn’t enough to make a real impact. What truly matters is how teams work -how they build, collaborate, and keep learning along the way, says Parsons.

He explained why many engineering leaders struggle with AI adoption, and how teams can move beyond just using AI tools to creating workflows where AI truly becomes a collaborator.

AI tools can’t be treated like any other software

Generative AI has sparked huge expectations across engineering teams. Many organizations assume that introducing tools like code assistants or LLM-powered platforms will instantly boost productivity.

But Parsons argues that the real hurdle isn’t the technology itself, it’s how well the organization understands and adapts to using it.

For CTOs and engineering leaders, this often leads to a common mistake: assuming developers can adopt AI tools as quickly and easily as they would a new IDE or software library. In reality, the shift goes much deeper:

It’s a fundamentally different way of working. You can’t simply give engineers an AI tool and expect them to start using it effectively right away. It requires time, experimentation, and a real shift in how teams approach development.

Unlike traditional software, AI is inherently non-deterministic – running the same prompt can yield different results. Teams may see promising outcomes in internal tests and assume it will behave consistently in production, only to find that real users often produce very different results.

People (not frameworks) drive organizational success

Parsons’ perspective on AI adoption is also shaped by his experience scaling engineering teams. During his time at Gower Street, he helped grow a small team into an organization of more than 50 people.

Early in that journey, he focused heavily on building the most efficient team structures and processes. Over time, however, he realized that organizational success depended much more on people than on frameworks:

If your engineering manager and product manager aren’t speaking to each other, introducing a weekly meeting won’t fix the problem.

The key to AI success? Track everything

Parsons starts with a surprisingly simple recommendation for AI adoptation: log everything. Every interaction, every model response, and every step in the AI pipeline should be recorded. These logs form the backbone for understanding how the system really performs in the real world.

From there, teams can go through the logs manually to see which responses are helpful, which are accurate, and which might cause problems.

At the beginning, the responses are often not that good. Sometimes they’re okay, sometimes quite bad, and occasionally surprisingly bad.

This hands-on review helps teams refine prompts, tweak workflows, and boost successful responses. Parsons suggests tracking AI performance just like engineering efficiency, using metrics like positive interactions and fewer errors.

You should explore meta‑prompting

One technique Parsons believes more leaders should explore is meta‑prompting – using AI to improve the prompts themselves.

Rather than trying to write the perfect prompt from the start, Parsons recommends letting the AI lead the conversation, asking one clarifying question at a time. This lets the model gather context gradually and deliver much better results.

Over time, teams can keep improving prompts by asking the AI what extra information it would have needed earlier, refining them step by step.

Parsons sees this iterative approach as part of a bigger shift: AI is evolving from a simple assistant into a collaborator, increasingly guiding problem-solving and asking questions like a coach.

We’ll start giving AI tasks and letting it run for some time without us being involved.

That shift will mean rethinking how teams collaborate with machines. Parsons points out that even the communication tools teams rely on may need to evolve to accommodate AI as an active participant in discussions and workflows.

The post Many Engineering Leaders Are Getting AI Adoption Wrong appeared first on ShiftMag.

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

Making AI products reliable requires new workflows

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

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

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

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

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

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

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

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

Focus on accuracy, cost, and speed

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

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

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

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

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

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

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

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

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

It hurts the ego a bit.

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

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

Karpathy, in his own words

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

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

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

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

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

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

Community reaction and a bruised identity

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

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

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

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

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

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

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

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

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

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

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

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

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

For centuries, painters thrived because society depended on their ability to capture reality. But when a better tool arrived – the camera – the ground beneath them shifted. The craft didn’t disappear, but the meaning of value changed forever.

“We’re facing something similar,” said Tejas Kumar (Developer Advocate, IBM) at the Shift conference in Kuala Lumpur. Citing tools like Cursor, Lovable, Bolt.new, Vero, and Windsor, he reminded developers that coding agents are already writing software faster (and often more reliably) than humans.

Developers must rely on first-principles reasoning

The data backs this up. Job openings across S&P 500 companies dropped sharply after ChatGPT’s release. Yes, market cycles and the zero-interest-rate hiring bubble played their part, but the trend points to something bigger: the profession is being reshaped, and developers need to understand how to stay relevant in the years ahead.

To navigate this landscape, Kumar argued, developers need to lean on first-principles reasoning. The term gets tossed around often in tech circles, but it’s rarely defined clearly. He offered a straightforward explanation:

First-principles reasoning means starting from what is invariant – the parts that never change – and building your understanding from there.

Invariants are the fundamental laws of reality – things like gravity, light, or the rising and setting of the sun. They remain constant, no matter what tools we create.

Returning to the Renaissance analogy, Kumar explained that both painters and cameras are simply different ways of capturing the same invariant: light. The tools change, but the underlying truth stays the same.

This approach, he argued, helps us understand the deep value of AI.

The goal isn’t to cling to the tools we’ve always used but to identify the underlying invariant that AI supports. In this case, it is reclaiming time and human agency – giving developers the freedom to focus on meaning while delegating repetitive work to machines.

The invariant in AI? It gives us back lost time

The point became unmistakable when Tejas demonstrated a multi-step AI agent in real time. Without typing a single keystroke, he watched as the agent opened Chrome, searched for the event schedule, parsed the results, and added the correct session to his calendar.

While my hands were off, what could I have been doing? I could’ve been at the gym. Out on a run. Playing with children I don’t have yet – but pray for every day. I could have been doing something meaningful. Instead, I’ve outsourced this tedious work to my agent- and in return, I get back life.

AI does not simply automate tasks. It returns lost hours and makes room for creativity, rest, curiosity, and focus. That, he argued, is the true invariant AI addresses.

Breakthroughs don’t need new toys – they need new tricks

As the keynote wrapped, Kumar recounted the telescope’s origins. In 1608, Dutch glassmakers used clear spyglasses horizontally to scan the horizon. A year later, Galileo pointed the same tool upward, unlocking new worlds.

“He literally saw Jupiter. He saw Saturn,” Tejas said. “A tool used differently became the telescope we know today.”

This story illustrates a timeless lesson: transformative breakthroughs often come not from inventing new tools, but from using existing ones in unexpected ways. In today’s era of open-source models, MCP servers, frameworks like LangFlow, and an unprecedented supply of freely accessible AI technologies, Kumar posed a question to developers that was simple, but profound:

How are we using these tools and how might we use them differently to achieve more, or even discover entirely new possibilities?

In the age of AI you need to be CREATIVE

Tejas invited developers to embrace the moment rather than fear it. Never before have engineers had access to such a vast array of powerful open-source tools. LangFlow itself, he reminded the audience, is fully MIT-licensed and easy to self-host, letting anyone build scalable agents through a visual interface.

But his message went beyond tools or licenses. It was a call to creativity, a call to agency – a reminder for developers to lift their gaze, imagine new possibilities, and see where these tools can take us when used in unexpected ways.

The post How Developers Can Leverage AI Today appeared first on ShiftMag.

Alex Shershebnev (Head of ML/DevOps and DevRel, Zencoder) explains that this gap becomes obvious once developers try using AI in real production systems, where even a logical-sounding model output can trigger unexpected and potentially harmful effects if it interacts directly with live infrastructure.

He warned that letting an LLM act without limits – like querying databases or deploying code – could cause serious damage, from wiping data to pushing faulty code.

The key challenge, therefore, is to bridge this intelligence gap safely.

Enter MCP – a bridge between AI and infrastructure

To address this problem, the industry has turned to the Model Context Protocol (MCP), introduced by Anthropic in late 2024. MCP standardizes how LLMs connect with external tools, APIs, and systems in a secure and transparent manner. The protocol defines two core entities:

• MCP Client – usually the LLM or AI agent that determines which tools it needs to fulfill a task.
• MCP Server – the component that exposes a curated list of available tools and safely executes operations when requested.

This structure allows LLMs to extend their functionality beyond text generation, performing actions like fetching monitoring data from Grafana, reading error logs from Sentry, or triggering CI/CD pipelines without requiring unrestricted access.

Even major players like OpenAI have adopted MCP, underscoring its growing importance as an interoperability and safety standard.

Clear parameters drive accurate tool execution

Shershebnev detailed how MCP servers present resources as tools, each defined by a name, parameters, and a clear description. The MCP client (LLM) can then select and execute the appropriate tool to retrieve or modify data.

This exchange follows a predictable, auditable flow: upon initialization, the server exposes a list of all available tools, and the LLM requests specific actions based on user input. The server executes the operation, returns the results in a standardized format, and the LLM incorporates them into its response.

Alex emphasized that MCP’s design makes it language-agnostic and easy to integrate. Developers can quickly connect their existing systems by importing a lightweight MCP library and defining tool endpoints. This opens a path for automating repetitive DevOps tasks such as branch creation, ticket management, and incident reporting.

Through live examples, he showed how MCP agents can automatically handle Jira tickets, open branches, and even query Kubernetes clusters to diagnose pod issues, all without leaving the IDE. However, these same capabilities also amplify the potential for misuse if the setup is not properly secured.

MCP servers inherit all the vulnerabilities of traditional servers

“Great power comes with great responsibility,” Alex noted when addressing MCP’s dual nature. MCP servers, while powerful, inherit all the vulnerabilities of traditional servers: package hijacking, malicious dependencies, open ports, and unpatched libraries.

On top of that, they introduce new, AI-specific risks.

The most prominent among them is prompt injection, a scenario in which a malicious payload hidden inside text, code, or a web page manipulates the LLM into performing unintended actions.

Another class of attacks he called “shadow tools” exploits naming collisions: a malicious tool is registered under the same name as a legitimate one, tricking the LLM into executing unauthorized operations. These vulnerabilities highlight how tightly coupled AI logic and system control have become, and why simple sandboxing or API tokens are no longer enough.

Alex also referenced industry data showing that even advanced AI providers detect only a portion of injection-based threats, meaning some attacks still slip through. The takeaway for developers: assume partial protection and plan defense in depth.

Deploying MCP safely requires careful controls

Alex emphasized that deploying MCP safely requires careful planning and strict boundaries: “You can’t treat MCP as just another tool in your stack. Every action an agent takes must be controlled, monitored, and limited to what is strictly necessary.”

According to him, developers should define precisely which tools are accessible to the LLM, ensuring that only allowed operations are permitted.

Agents should operate with the principle of least privilege, confined to staging or read-only environments rather than production. He also mentioned the importance of input sanitization, explaining:

Never feed raw, unfiltered content directly to the model. Use intermediary layers to clean and summarize information before passing it along. Every MCP call and response should be fully auditable, with detailed logging of tool identifiers, inputs, outputs, and timestamps.

For critical operations, such as deployments or database changes, Alex recommended incorporating human approval steps to prevent unintended actions.

MCP lets AI act in the real world – but only under controlled boundaries

Finally, Alex urged teams to combine traditional DevSecOps measures with MCP-specific precautions.

Dependency scanning, code signing, and supply-chain verification remain essential, and simulation through red-team exercises can reveal vulnerabilities from prompt injections or shadow tools before they reach production. “These measures are not optional,” he said, “they are prerequisites for responsibly integrating AI into DevOps pipelines.”

Alex concluded by reminding the audience that the MCP represents a major leap forward for AI-driven automation. It allows LLMs to interact meaningfully with the real world, enabling developers to build faster, smarter, and more context-aware systems. However, without strict governance and defensive design, the same flexibility can easily become a security liability.

MCP is not just a technical framework; it’s a blueprint for trust boundaries between human developers, AI agents, and production infrastructure:

As organizations begin adopting these tools, the line between code generation and code execution will blur, and the teams that succeed will be those who treat AI not as an omnipotent engine, but as a collaborator that must operate within precisely defined limits.

To see these principles in action, Infobip offers their own MCP servers for its communication APIs and has released an open-sourced OpenAPI MCP framework that developers can use to expose any OpenAPI-described service to AI agents securely. 

The post MCP Lets AI Actually Do Stuff Safely – But Only If You Watch It Like a Hawk appeared first on ShiftMag.

But speed isn’t everything. These tools still need guidance, context, and careful oversight.

In this article, Birgitta Böckeler (Distinguished Engineer, Thoughtworks) shares practical strategies for using AI responsibly, helping developers harness its power without sacrificing quality or maintainability.

Clean code makes AI shine

In their early days, tools like GitHub Copilot mostly acted as advanced autocomplete assistants, predicting the next few lines of code. Today, AI has leveled up to agents that can tackle multi-step tasks – refactoring files, running tests, or even updating entire repositories.

AI agents can now fix failing tests, optimize dependencies, and even propose small architecture tweaks. Still, as Birgitta points out, these time-saving powers come with their own set of headaches:

Developers now need to give clearer context, define their goals more precisely, and double-check AI outputs with extra care.

Because these systems lack persistent memory, developers keep session notes or hand-offs to track project state. Birgitta Böckeler notes that AI assistants work best in modular, well-structured codebases where context and dependencies are clear.

In contrast, legacy or entangled systems often cause the AI to misinterpret relationships or overlook hidden dependencies. As a result, productivity improvements depend heavily on the specific context in which they are implemented.

Claims of 80% faster development rarely hold. AI speeds up small tasks, but big architecture, integrations, and testing still need human expertise.

AI can produce code fast, but it needs human oversight

Böckeler also addressed the growing gap between the hype surrounding AI and what it can actually do.

Many online demonstrations show AI building games or applications in mere minutes, but these impressive-looking outputs often exaggerate reality. In most cases, they produce only basic scaffolding or boilerplate code rather than fully functional, production-ready solutions, reminding developers that human oversight and refinement are still essential.

The quality of AI-generated code still depends on professional oversight, since trade-offs, compatibility concerns, and maintainability are inherently contextual and beyond the AI’s current reasoning capacity.

For example, an AI might correctly adjust a memory limit when a process fails, but it can miss deeper dependency conflicts. It may also merge methods incorrectly if compatibility rules are unclear or generate rigid test cases that complicate debugging instead of simplifying it.

Don’t blindly trust AI-generated code

To help developers navigate these realities, Böckeler proposed a useful mental model:

AI assistants should be treated like junior developers. They are fast, capable, and eager to help, but they can also be overconfident and prone to mistakes.

Understanding their limits is key; like mentoring a new team member, trust must be conditional and context-dependent. Blindly accepting AI-generated code can lead to subtle bugs and long-term maintainability issues.

The hidden pitfalls of AI-generated code

Drawing from her own experience, Böckeler emphasized several recurring pitfalls:

• Superficial fixes: AI often suggests quick solutions that don’t address deeper architectural problems.
• Problematic test cases: Generated tests can be too brittle or too vague, sometimes requiring as much debugging as the original code.
• Reinforcing poor design: In messy or poorly structured systems, AI may perpetuate suboptimal design choices, increasing future maintenance costs.
• Increased code churn: Studies show more rework is needed on AI-generated commits, often within weeks.
• Unexpected debugging effort: Developers frequently spend more time fixing AI outputs than initially anticipated, highlighting the need for careful oversight and management.

This is why Böckeler recommends a proactive, disciplined approach: AI-generated code should never be accepted at face value but reviewed and thoroughly tested. Checkpoints and version control help roll back unwanted changes, and breaking complex tasks into smaller steps improves AI accuracy.

At the team level, quality control should remain a shared responsibility – automated tests and pull requests aren’t enough.

Monitoring quality metrics and integrating AI gradually helps prevent long-term risks to maintainability and security. Above all, expectations must remain realistic: AI cannot guarantee fixed productivity gains or eliminate the need for experienced developers.

The key lies in responsible use

In closing, Böckeler said that AI coding tools have become a permanent fixture in software development. They are robust, adaptable, and increasingly embedded in professional workflows, but their actual value depends on how responsibly they are used.

Developers must learn not only how to operate these tools, but also how to supervise, evaluate, and sustainably integrate them.

The challenge ahead lies not in automation itself, but in ensuring that it enhances productivity without compromising quality, maintainability, or team cohesion.

The post Treat Your AI Assistant Like an Overconfident Junior Developer appeared first on ShiftMag.

When your “code” is a neural network with billions of parameters, traditional debugging tools barely scratch the surface.

So, the real challenge has shifted from fixing deterministic code to making sense of probabilistic behavior.

To explore this, we spoke with Zvonimir Petkovic, Senior Software Engineer at Infobip.

AI-assisted debugging – helping hands or crutches?

When asked how AI is reshaping debugging, and whether it’s making developers sharper or just more reliant on automation, Zvonimir says it all comes down to mindset: it depends on whether a developer has truly embraced AI coding in a “vibe” way or not.

Regardless, AI tools often make debugging easier – even if you never tell Cursor to “pls fix this.”

But when AI is doing more of the heavy lifting in debugging, what happens to a developer’s critical thinking? Here’s how Petkovic sees it:

It comes down to mindset: for most people, the process offers a learning opportunity, but whether they actually benefit depends on having the time and will to dig in – or whether the project’s pace leaves no room for deeper exploration.

Why AI struggles with legacy code

When asked about the biggest challenges of using AI for debugging – particularly around accuracy and understanding context – Zvonimir points to one major issue: legacy projects.

Greenfield projects are easy, but try debugging a years-old, messy, poorly documented codebase, and it quickly turns into a nightmare.

Petkovic also noted that AI models have limits when it comes to context – they can’t always understand everything at once. That’s why context engineering is more crucial than ever.

We also asked Zvonimir how junior developers fare with AI-assisted debugging compared to senior engineers – does it speed up their learning, or risk slowing down their skill development? He explained:

GenAI has proven a major boost for juniors or developers transitioning to a new stack. In most cases, it helps them learn faster, without having to call a senior every time they hit a problem.

The dark side of AI autonomy? Bugs and tech debt

Debugging isn’t just about fixing bugs. It’s also about keeping code secure and products reliable. Zvonimir pointed out the risks of leaning too heavily on AI to automatically fix problems.

AI-generated code can quickly become a mess and a major source of technical debt if left unchecked and the same goes for automated bug fixes, especially when you push AI autonomy beyond what’s safe today.

He also warned about the risks of a Git-connected AI agent that automatically merges PRs and performs code reviews without a human in the loop. Today’s models are much more capable, but still far from fully autonomous.

GenAI coding assistants won’t replace your principal engineers

Finally, Petkovic shared his thoughts on whether AI can really grasp the intent behind code well enough to spot deeper logic or architectural bugs:

With enough context (code and docs) GenAI assistants won’t replace your principal engineers, but they can help them see problems from new angles and iterate faster.

Looking ahead, one big question is the balance between human and AI-driven debugging: could we ever reach a point where the process is fully automated?

It’s heading in that direction. GitHub is rolling out more AI-driven debuggers that not only triage problems based on code and comments but also attempt to propose solutions.

“With GenAI models becoming better and better, and with context improving with different sources expandable by the MCP, I see these becoming just better over time. Still, it’s hard to say how quickly they will be totally independent, even though some major companies are allowing this sort of action in isolated projects,” Zvonimir concluded.

The post Debugging in the Age of AI Isn’t About Fixing Broken Code appeared first on ShiftMag.