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.

Digging through portals and LinkedIn profiles is a total drag. That’s why we at ShiftMag launched a handy guide that packs the career ladders of major tech corps into one place! We already tackled Amazon, and today, Microsoft is on the menu!

To build this guide, I cross-referenced multiple sources: Microsoft’s official career site, Levels.fyi compensation data, LinkedIn profiles of current and former Microsoft engineers, and publicly reported industry data including salary leaks and engineering blogs.

Where sources conflicted, I noted the discrepancy rather than picking one arbitrarily. Compensation figures reflect self-reported U.S. data from Levels.fyi and should be treated as estimates, because they vary by location, team, and negotiation.

Microsoft’s engineering levels

In Microsoft, there are a number of standard job titles. Entry-level engineers start at L59–60 (SDE I) and progress through mid and senior roles up to L67–68 (Distinguished Engineer / Technical Fellow). The ladder splits into two tracks: management (Engineering Managers) and individual contributor (IC).

L59–60 – Software Engineer (SDE I)

Entry level for new graduates or engineers with under two years of experience. Engineers implement features, write and debug code on well-scoped tasks, and work under close mentorship. The primary focus is learning systems and coding practices.

L61–62 – Software Engineer II (SDE II)

Mid-level engineers with roughly 2-5 years of experience. They own more complex features end-to-end, write scalable code, and begin mentoring SDE Is. They influence design decisions within their projects but still receive technical guidance from seniors.

L63 – Senior Software Engineer (Senior SDE)

Engineers with approximately 5+ years of experience who own multiple features or projects and set technical direction within their domain. Senior SDEs lead design discussions, ensure long-term maintainability, and partner closely with product and engineering leads.

L64 – Principal Software Engineer

A senior IC role typically reached after 8-12 years of experience. Principal SDEs lead large components or entire technical domains, architect systems, and drive technical strategy. Some external sources label L64 as “Staff Engineer,” but Microsoft’s internal title is Principal SDE.

L65-66 – Principal Engineer II / Partner-Level

Principal-level engineers with broader organizational scope. These roles sometimes straddle IC and management tracks, with titles including Senior Principal or entry-level Architect. L65 is often where the formal “Principal” designation begins internally.

L67-68 – Distinguished Engineer / Technical Fellow

Top-tier IC roles focused on company-wide innovation and long-term technical strategy. Distinguished Engineers (L67) have deep domain impact across the organization. Technical Fellows (L68) are among the most senior technical positions at Microsoft and are extremely rare. These levels are not promoted into on a fixed timeline, they are typically nomination-based and require demonstrated impact at scale.

Cross-company level mapping

The table below shows rough equivalents across Google, Meta, Amazon, and Microsoft. These mappings are approximate – scope, expectations, and compensation vary significantly by company even at equivalent titles.

Compensation

Microsoft’s total compensation (base salary + bonus + RSU grants) rises steeply with each level. The figures below reflect U.S. median total compensation as reported on Levels.fyi. These change frequently and vary by location, team, and negotiation.

Compensation data sourced from Levels.fyi. Figures are self-reported estimates and should be treated accordingly.

A note on RSUs: Microsoft grants RSUs on a 4-year vesting schedule with a one-year cliff, after which shares vest quarterly. At senior levels (L63+), RSU grants make up an increasingly large share of total compensation – often exceeding base salary at L65 and above. Annual refresh grants are awarded through Microsoft’s performance review process (called “Connects”).

The post Microsoft Engineering Levels and Salaries: The Complete SDE Career Ladder (L59–L68) appeared first on ShiftMag.

Welcome to the engineering hierarchy of one of the world’s biggest tech companies, with nearly 200K employees… and I’ll be your guide.

Since Amazon doesn’t publicly publish an official breakdown of its career levels, I reviewed various sources such as Dev.to articles and salary websites.

To start with, AWS is famous for a decentralized, high-ownership environment where engineers don’t just write code, they must run what they build. Understanding the AWS career ladder is essential for any developer looking to enter the ecosystem that powers over a third of the cloud.

The AWS leveling system

Amazon (and by extension AWS) uses a structured leveling system that spans from L1 to L12. However, most software engineers operate between L4 and L8, with higher levels reserved for a very small number of highly influential technical leaders.

While some companies hire engineers at lower levels, AWS typically starts its professional software engineering track at L4.

Level 4: Software Development Engineer I (SDE I)

The SDE I position at Amazon serves as the foundational entry point, typically designed for recent college graduates or engineers with limited professional experience. At this stage, the primary focus is on building a robust technical baseline. You are responsible for hands-on coding and debugging within well-defined tasks, contributing to the development of small features that integrate into larger projects.

While you are expected to deliver high-quality code, you aren’t expected to do everything yourself. AWS has a heavy emphasis on mentorship at this level. Because of that SDE I engineers receive significant guidance from seniors to help them navigate complex systems and understand specific development tools and practices. It is a period of incremental skills development.

Level 5: Software Development Engineer II (SDE II)

SDE II engineers are often the backbone of the company’s engineering organization. At this stage, it’s all about being fully self-sufficient. SDE IIs are expected to manage their own workloads with minimal supervision, prioritizing tasks effectively to deliver consistent, high-quality results.

Beyond just executing tasks, SDE IIs begin to take ownership of larger systems and components. They are responsible for designing and implementing solutions that specifically meet Amazon’s high standards for scalability, performance, and reliability. This is also the level where your influence begins to expand beyond your code, you start acting as a mentor to L4 engineers and begin coordinating on cross-functional projects.

Level 6: Senior Software Development Engineer (SDE III)

The Senior SDE role is an advanced position reserved for experienced engineers who have demonstrated strong technical and leadership capabilities. At this level, the scope of responsibility expands beyond individual contributions to owning larger systems and leading complex projects.

Senior SDEs are expected to design scalable architectures, make high-impact technical decisions, and guide the work of other engineers on their team and adjacent teams. Their influence is significant, though typically focused within a team or a group of closely related teams.

Level 7 & 8: Principal and Senior Principal Engineer

Levels 7 and 8 represent the elite tier of engineering talent at AWS. As a Level 7 (Principal Engineer), you move into a strategic role, shaping the technical direction across multiple teams or an entire organization. They work closely with senior leadership and are responsible for solving complex, high-impact problems that affect large parts of the business.

The Senior Principal Engineer (L8) sits at the pinnacle of technical innovation. These engineers define long-term technical vision for major areas of AWS, often influencing hundreds of engineers indirectly through architecture, standards, and strategic initiatives.

Level 10: Distinguished Engineer / VP

Beyond Level 8, the roles become extremely rare. It’s reserved for a small group of engineers with company-wide or industry-level impact. These roles focus on setting long-term technical direction, solving the most complex architectural challenges, and influencing Amazon’s strategy at the highest level.

Level 10 is reserved for world-renowned visionaries and thought leaders who have a remarkable track record of technical excellence. They are responsible for identifying future technology trends and anticipating market shifts years before they happen. They set the architectural principles and technical standards that position Amazon as a continued leader in the industry. As mentors to the company’s highest technical leaders, they foster a culture of innovation that ensures AWS remains at the cutting edge of what is technologically possible.

What makes AWS levels different?

1. Leadership Principles (LPs) as a metric

Technical ability alone is not enough for promotion. Engineers are evaluated against Amazon’s Leadership Principles, which are used as a framework to assess impact, decision-making, ownership, and long-term thinking. As engineers progress through levels, they are expected to demonstrate these principles with increasing scope and consistency. Promotion depends on how well your work maps to multiple principles, not just one.

2. The power of the “Doc”

AWS is a famously “silent” company. They don’t use PowerPoints, they use 6-page memos. Your ability to move from L5 to L6 depends heavily on your writing. Can you argue your architectural choices in a structured, data-driven document? If you can’t write, you can’t lead at AWS.

3. Total Compensation (TC) structure

AWS compensation is uniquely structured compared to Google or Meta. While they have recently increased base salary caps, a large portion of your wealth comes from RSUs (Stock) with a 4-year vesting schedule:

• Year 1: 5%
• Year 2: 15%
• Year 3: 40%
• Year 4: 40%This “back-loaded” vesting is designed to reward those who stay and grow through the levels.

AWS salary expectations (2026 estimates)

To provide an accurate picture of what these roles pay, we analyzed the latest 2026 data aggregates from Levels.fyi and 6figr.com, which utilize verified salary stubs from engineers in major tech hubs. Compensation at AWS varies significantly depending on team, location, and negotiation, but follows a consistent structure of base salary, bonus, and stock (RSUs).

Note: These figures reflect top-tier offers in high-cost US markets. For European hubs like Dublin, Luxembourg, or Berlin, expect a 15-25% reduction in base cash, though stock grants remain aggressive.

Is the climb worth it?

The AWS ladder is demanding and often associated with a high-performance culture. Engineers who progress through it tend to develop strong ownership, system design skills, and operational discipline.

While experiences vary by team, time at AWS is generally seen as a strong signal of technical capability and execution, particularly at senior levels. For those who align with its culture, the system offers a clear path for growth.

The post Inside the AWS Hierarchy: Engineering Levels Explained appeared first on ShiftMag.

If you haven’t heard of MCP (Model Context Protocol), it’s a standardized way for AI models like GPTs and agents to connect to real-world tools – such as APIs, databases, and internal systems – without having to build custom integrations from scratch.

At the MCP Dev Summit North America, I heard from its co-creator David Soria Parra, Member of Technical Staff at Anthropic, that the question is no longer how to use MCP, but rather what breaks under load?

There are roughly 110 million SDK downloads per month across tools like OpenAI Agents, LangChain, and other frameworks, and they are all speaking the same protocol. For comparison, it took React years to reach that scale. MCP did all that in under a year and a half.

That demand explains the speed of adoption. Teams weren’t looking for another framework, they needed a practical way to connect models to real systems without rebuilding the same integrations over and over.

MCP gave them a shared interface for that. But standardizing the interface doesn’t remove the underlying complexity.

Don’t blame MCP – blame the implementation

Once you stop focusing on how to connect AI to tools, you’re dealing with everything that comes after: context management, tool selection, authentication, latency, and how it all behaves beyond a demo, when it’s actually running in production.

The first thing that usually breaks is context. In most MCP setups, the simplest approach wins: expose a set of tools, pass them to the model, and let it decide. That works in demos, but in production it quickly becomes inefficient. David called this out:

People continuously complain about context bloat in MCP and end up blaming MCP for it. But the interesting part is that we already know the mechanisms to work around context bloat. This is called progressive discovery.

So, according to David, the issue isn’t the protocol itself, but the way it’s implemented:

Tools come with metadata: descriptions, parameters, schemas. Across dozens of integrations, a significant portion of the context window is consumed before the model does any actual reasoning. In some cases, just listing available tools can take more than 20% of the context window.

What makes it worse is how models behave under pressure. With too many tools, selection gets unreliable – overlapping capabilities and weak signals lead to irrelevant or suboptimal tool calls.

More context doesn’t help, it just makes things less reliable. David explained how to “fix” this:

The idea behind progressive discovery is not to take all the 20, 50, 100 tools from an MCP server and naively dump them into the context window, but to use a more modern mechanism like tool search to load tools only when they’re needed.

Progressive discovery changes the model from a static consumer of tools into something closer to a query-driven system. Instead of being aware of everything upfront, it retrieves what it needs at the moment it needs it, similar to how search or retrieval systems work.

MCP supports that pattern, but it doesn’t enforce it. And that’s the gap most teams run into: the protocol scales, but naive implementations don’t.

What about infrastructure?

Infrastructure is what most teams underestimate. MCP solves the connection, not how it behaves in a real system. Protocols define interfaces, they don’t handle reliability, scaling, or operations. And that’s exactly what breaks as usage grows.

This shows up first in transport. Streaming HTTP works in controlled setups, but under load it gets hard to manage – connection state, coordination, throughput all start to matter. That’s why things are moving toward stateless communication. Until then, teams have to build around it.

The deeper issue is that MCP doesn’t define how systems should behave once a connection is established. It doesn’t define:

• How calls are retried.
• How failures are handled.
• How systems recover when something breaks mid-execution.

And in production, those are the problems that matter. David points to this indirectly when talking about where MCP is heading:

In my mind, 2025 was about figuring out whether something like MCP is needed in the ecosystemm, and the answer is a resounding yes. But 2026 will be about making sure it’s ready to help people productionize agentic systems.

The focus has shifted from whether MCP works to what’s needed around it in real-world conditions. That means things MCP doesn’t include: retries, observability, backpressure, coordination between agents hitting the same services.

Without that, MCP behaves fine on its own, but the system around it doesn’t. And that’s what you see in most early setups.

How Duolingo and Uber use MCP

If there’s one takeaway from the MCP Dev Summit in New York, it’s that I didn’t see anyone using MCP on its own.

Across talks from teams like Duolingo and Uber, the pattern was pretty consistent: MCP solves the integration layer, but everything around it still has to be engineered, constrained, and operated.

At Duolingo, the first issue wasn’t scale or performance, it was adoption. Setting up MCP servers meant manual config, credentials, and environment-specific setup, and the barrier to entry was high enough that few engineers bothered.

Instead of rethinking MCP, they focused on reducing friction. They built a central interface to discover and configure MCP servers – an internal “app store.” Behind the scenes, they standardized hosting, added shared auth, and built tooling to turn services into MCP-compatible endpoints without starting from scratch.

With thousands of engineers, services, and agents interacting through MCP, the lack of structure quickly became a risk, as Meghana Somasundara (Agentic AI Lead) and Rush Tehrani (Senior Engineering Manager) at Uber shared:

Without a central framework or guidance, everybody was trying to solve the same problems in silos.

Their solution was a control layer on top of MCP – a central gateway for all interactions, backed by a registry defining what tools exist, how they’re described, and who can access them. Tool definitions are auto-generated from existing services, but still reviewed, scanned, and governed before exposure.

In the end, teams reduce how much decision-making is left to the model. Instead of letting it freely choose between tools, they scope what’s available and pre-set key parameters to reduce ambiguity and improve reliability, especially where mistakes matter.

As Meghana and Rush pointed out, “these things can hallucinate and maybe not pick the right tool.”

So in production, it’s not about trusting the model to make the right choices – it’s about reducing the number of choices it has to make. MCP defines the interface, but reliability comes from everything built around it.

The post MCP Co-Creator Explains Why MCP Needs More Than the Protocol to Scale appeared first on ShiftMag.

Even with years of experience in leadership and change management, I couldn’t escape the familiar phases of change, this time with AI adoption. And that’s natural. Whenever something new arises, our first instinct is fear, especially when it could solve years of “only ifs.”

Yes, the tech industry is in a storm, and being an engineering lead has never been harder. Everyone is looking to you for answers, direction, and vision.

At first, I was in denial, thinking AI was for someone with fewer responsibilities. But then I realized the real question was:

What can I do to help my teams adapt to AI?

The answer was simple: push myself through the change and proactively lead my team’s transformation. Needless to say, it wasn’t easy.

Chapter 1: Denial

Even without an assistant, I am a top performer; I do not need to perform better.

Last year, AI tools arrived in our workspaces, but most of us were still in denial. They made for good morning coffee talk, but using them daily? That felt unreal.

Yeah, right. That will not happen. It’s not that I don’t want to learn something new, but I already have a ton on my plate: five teams to lead, acting as PM for a few products, and coaching a few prospective managers. On top of that, there are parallel technical initiatives I need to oversee. I simply don’t have time to play with shiny new tools,that’s for people not juggling ten parallel topics.

You can see how easy it is to fall into the trap of your own perspective. The painful truth is: even if you keep delivering at your current pace, without adopting AI tools, you won’t be able to keep up in a few months.

How can you tell if you’re stuck in denial?

Start by asking yourself three crucial questions:

1. Did I hear about a change? New trends in the industry? Internal reorganization? Anything that could be classified as a disruption topic? Actively listen to all sources of information.
2. Am I feeling like the ‘only one who is overstretched, with no time for anything’? It could mean you’re blinded by your own perspective.
3. Am I criticizing the change – openly or secretly? Together with the two above, a possible diagnosis is denial.

You don’t want to stay in this state for too long. As a proactive leader, your next step should be to take the time to investigate.

Chapter 2: Anger

I don’t want you! You are not my assistant!

And suddenly you realize the change is real. Your doubt becomes reality. Every topic is now an AI topic, and it’s irritating. It should feel new and interesting, but you feel pushed into it, without the chance to choose. Already overstretched, your natural response is another primary feeling: anger.

I could sense that state of mind in many of my peers and engineers over the last year. It’s not easy to force yourself into a positive mindset instantly.

The message I want to share is this: it’s okay to feel negative, but staying in that state too long can undermine your results. Spend as little time as possible in it, learn to let it go, and give it a try.

Chapter 3: Bargaining

Ok, let’s see what I can really do.

Keeping an open mind is valuable for anyone, no matter their rank or role. As an engineer, rolling up your sleeves should be natural.

So, aside from trying it out of curiosity, I decided to dive deeper and explore architecture and try the tools. Engineers usually transition quickly, but if they get stuck, you can help by highlighting the positive aspects. I used the opportunity to innovate and learn as a positive hook.

Chapter 4: Depression 

I need to relearn everything again – more work for human me… again.

Reality strikes. 

I’ve opened a new Pandora’s box. So much to adapt to, while still maintaining old performance. AI should help me, not add more work. Will I ever escape this loop?

Leading through this phase is about providing support and reminding people of the positive outcomes. 

Chapter 5: Acceptance 

We’re friends now. Sorry I was so mean before.

With the knowledge comes the acceptance.  

Yes, that was a big change, but I found a couple of good use cases quickly. Claude code amazed me, and I even saw a few valid Copilot use cases, even though I despised it at first. I started thinking about all the cases I could explore, and my inner engineer took over.

Now it’s easy to bring others on board and help them through the change. And stay transparent, sharing the doubts you’ve faced and showing the human side.

So, how does a true leader approach AI?

Remember: ignoring changes around you is risky for any organization. It’s natural to fall into denial, but as a leader, it’s crucial to recognize it and take action.

Being aware of the steps that individuals, teams, or the organization need to push through (and helping them do it) is a key leadership skill.

The post As an Engineering Manager, I couldn’t ignore AI if my teams are to survive appeared first on ShiftMag.

It’s a question many engineering teams aren’t ready to answer honestly.

Partly because the answer changes depending on who you ask, and partly because the two emerging answers point in completely opposite directions.

Iain Bishop, CEO of Damilah Technology and a former CTO with over two decades of experience, believes that “there are uneven gains with AI at the moment.”

Some teams are moving fast – shipping more, experimenting, shaping decisions, and owning outcomes. Others are still treating AI like a smarter autocomplete, focusing on infrastructure and reliability. The gap between these groups, Iain believes, is only going to grow.

Soon, devs won’t jus use AI – they will coordinate it

Most teams today are still operating in what Iain describes as the copilot phase. 

AI sits alongside developers, helping them generate code, suggest improvements, or speed up repetitive tasks. It’s useful, but it doesn’t fundamentally change how work is structured, though that could change soon, Iain believes.

What we’ll see over time is a move from a copilot model to an orchestration model.

In that world, developers don’t just use AI, they coordinate it. Instead of writing everything themselves, they manage multiple AI agents, assign tasks, validate outputs, and connect everything into a working system. The role shifts from execution to direction.

You’re still accountable, no matter how smart AI becomes

As tools become more powerful, there’s a growing temptation to push more responsibility onto them. Iain sees that as a dangerous path:

If AI is just like a co-worker, it isn’t truly autonomous and we remain accountable no matter how powerful the tools are.

The risk isn’t that AI will take control. It’s that teams will give it up too easily: 

If we allow AI tools to operate completely autonomously, we lose that accountability. And that’s the wrong approach.

This means developers aren’t becoming less responsible, they’re becoming more. They’re accountable not just for what they write, but for what they orchestrate.

AI’s first impact won’t be mass layoffs, it will be role compression

AI’s first big impact won’t be mass layoffs, it will be role compression. “In the coming years, teams will shrink, and people will need to wear multiple hats,” Iain says.

The lines between traditional roles are starting to blur: you’ll see more product engineers build AI-driven solutions. At the same time, deep technical expertise won’t disappear; if anything, it becomes even more critical, Iain explains.

There will always be a need for systems engineers who understand what good code looks like.

As AI generates more code, someone still needs to ensure the architecture makes sense.

Iain sees two clear paths:

1. Toward product – understanding users, business needs, and delivering end-to-end solutions;
2. Deeper into systems – architecture, design, and scalability.

“The risk is for engineers who stay in the middle,” he says. “With AI handling more execution, being just kind of technical and kind of product-aware may no longer be enough.”

Structuring AI lets teams move fast without losing control

Most companies aren’t struggling with what AI can do, they’re struggling with how to manage it, Iain says: “There’s a rapid pace of change, and companies need to get control of what’s happening.”

The instinct is to lock things down (limit tools, restrict access, add heavy governance) but engineers will find ways around it.

A more sustainable path is to structure how AI is used. Iain points to orchestration platforms, where standards, design systems, and governance are built into AI workflows. This lets teams move fast without losing control, and ensures organisations don’t have to choose between speed and consistency. Control comes not just from systems, but from people understanding the tools they’re using.

Knowing how to use new models won’t come automatically

With all the focus on automation, one skill is quietly becoming critical: communication.

Iain says that for teams new to AI, it’s about more than prompts – it’s understanding models, structuring context, and guiding outputs into something usable.

Prompt engineering is really about creating the right context to get the best response.

This changes how developers work. Instead of writing everything, they guide systems, shape inputs, and validate outputs. Models will keep improving, that’s inevitable, but knowing how to use them well won’t be automatic.

The post Some Engineering Teams Won’t Be Ready for AI Orchestration – and It Will Cost Them appeared first on ShiftMag.

A developer uses Copilot to write 30 lines of code in 10 minutes, but then spends 45 minutes reviewing it – checking for bugs, edge cases, and code that doesn’t match team standards.

The time saved during writing gets completely eaten up during validation. And this is exactly what happens repeatedly across teams trying to adopt AI at scale.

At the Pragmatic Summit, Laura Tacho (CTO at DX) shared some interesting research on AI in coding:

Almost 93% of developers use AI assistants every month, and about 27% of production code now comes from AI. Yet, despite all this, overall productivity has barely budged – staying around a 10% boost since AI tools arrived.

AI adoption is everywhere…

The numbers are clear:

• 92.6% of developers use AI coding assistants monthly
• 75% use them weekly
• 26.9% of production code contains AI-authored segments

84% of developers use AI tools, according to Stack Overflow’s 2025 survey. Adoption is now standard – the numbers are probably even bigger now.

…Yet work isn’t moving any quicker

The gap between adoption and productivity appears first as a trust problem.

46% of developers don’t fully trust the output, and that skepticism has a reason: reviewing AI-generated code frequently requires more effort than reviewing human-written one.

The DX AI Measurement Framework (published by vendor DX but structured as an industry standard) identifies this directly:

Code generated by AI may be less intuitive for human developers to understand, potentially creating bottlenecks when issues arise or modifications are needed.

This is why productivity hasn’t jumped. Developers might write code faster with AI, but they end up spending the same time checking, fixing, and making sense of what AI produces. In the end, the overall development cycle doesn’t get any shorter.

Sonar’s research confirms the pattern at scale: 42% of committed code now includes AI assistance, yet 96% of developers say they don’t fully trust AI-generated code. And this is exactly what we see: output is everywhere, but the confidence in it is not.

Why productivity has stalled?

That 10% productivity bump comes down to a workflow mismatch.

Teams started using AI to write code faster, but didn’t adjust how they review, test, or integrate it. In other words, writing got quicker, but everything that comes after stayed just as slow.

The DX research notes a broader context relevant here: most organizations see their biggest bottlenecks not in code generation, but:

In the outer loop, or in human factors like collaboration, alignment, and the ability to do deep, focused work.

AI addresses one specific problem, and that’s code-writing speed. But, as we can see, the overall development cycle has other constraints.

Teams that actually see productivity gains from AI usually do two things: they figure out exactly where AI adds value, and they tweak their workflows to make the most of it. Teams that just deploy AI without changing how they work? They get adoption, but no real boost in productivity.

The 10% productivity ceiling sticks because the time spent validating AI-written code cancels out the speed gains. Most teams focus on writing faster, but few have optimized for faster validation.

It’s an obvious obstacle, but maybe also an opportunity.

The post AI Hasn’t Made Developers Faster, It’s Made Their Review Queues Longer! 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.

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

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

Some things just can’t be replicated online

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

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

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

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

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

But conferences are expensive…

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

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

The keyword here is well-chosen:

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

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

Big stages or small communities?

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

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

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

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

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

When people feel welcome, real connections follow

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

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

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

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

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

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

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

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

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

Remember the first time AI showed up at your company? That meeting where everyone (tech experts, managers…) threw around terms like LLMs, RAG and AI agents like they were yesterday’s news, and you sat there thinking:

Wait… what does any of that even mean?

If you’re not totally fluent in AI lingo, it usually means you end up using tools without really understanding how they work.

My colleague already wrote a full AI glossary, but I just want to cover the basics – and, of course, throw in some pop culture along the way.

3 concepts for beginners to onboard

1. Artificial Intelligence (AI)

AI is any system that does “smart” work. That can be rule-based (“if X then Y”), statistical, or learned – like recognizing patterns, making decisions, understanding language, or spotting anomalies.

Pop Culture Reference: Imagine JARVIS from Iron Man – not the suit, but the agent behind it: interpreting Tony’s questions, pulling relevant info fast, and suggesting next steps.

Business Reference: AI can classify customer requests, predict leads most likely to convert, detect fraud, recommend next steps, or draft content – often at a speed and scale no human team could match.

Key Insight: AI isn’t magic. It’s a pattern engine that works best when the goal is clear, the data is relevant, and humans remain in the loop for judgment, ethics, and edge cases.

2. Machine Learning (ML)

ML is a branch of AI where systems don’t follow long lists of hand-written rules. Instead, they learn patterns from examples and make predictions or decisions based on them.

Pop Culture Reference: Think Doctor Strange practicing spells. At first, he barely makes a spark. After thousands of repetitions, his hands “learn” the exact motion and timing to open a portal.

Business Reference: ML powers churn prediction, lead scoring, fraud detection, demand forecasting, and recommendation engines.

Tradeoff: ML can outperform rule-based logic at scale, but it’s only as good as the data it learns from. Biased, messy, or outdated data leads to biased predictions – the equivalent of “casting yesterday’s spell.”

3. Large Language Model (LLM)

LLMs are ML models specialized in language. LLMs are trained to predict the next token in context, which lets them generate text, summaries, answers, and other language outputs.

Unlike a normal database, an LLM doesn’t “look up” facts by default, it generates plausible responses, which can sound confident even when wrong.

Pop Culture Reference: Think of the Sorting Hat in Harry Potter. You give it cues (values, experiences, preferences), and it produces a fluent, confident answer: “Gryffindor!” or “Slytherin!”

Business Reference: LLMs excel wherever language is work: customer support, sales follow-ups, knowledge Q&A, meeting notes, content drafts, and cleaning up messy inputs. Best results come with clear context, constraints, and human review for high-stakes decisions.

6 AI terms you need to know

Prompts – Be careful what you wish for

A prompt is your “three wishes” moment with a genie (think Aladdin). Vague wishes lead to weird outcomes. The clearer and more specific your prompt, the closer the AI gets to what you meant.

Training Data – No train, no gain

Training data is everything Neo downloads in The Matrix (“I know kung fu”). It’s the massive pile of examples AI absorbs to recognize patterns and perform skills later, except here it’s language, facts, and human responses.

Inference – Let’s get stuff done

Inference is when AI actually produces an answer on demand. Training is studying and practice; inference is taking the test or doing the real work. The model calculates the most likely next words or best output based on what it learned.

Think of JARVIS answering Tony’s question in real time. All that training compressed into a single, instant response. That’s inference: not learning, just delivering.

Hallucination – You will not believe what happened…

Hallucination occurs when AI gives a confident, polished answer that is wrong or partly invented. It’s like that friend who exaggerates every story and even a trip to the bakery becomes an epic saga.

Fine-Tuning – Make it yours

Fine-tuning is giving a general AI extra, targeted training so it learns your business context – your terminology, tone, and common tasks. It won’t guarantee perfect rule-following on complex decisions, but it gets the model significantly closer to how your team thinks and communicates.

Like training a Pokémon: a newly caught random Pokémon can battle, but one with complementary Nature, specific move set, and EV trained for your team’s strategy – performs much more reliably.

Retrieval-Augmented Generation (RAG) – It’s leviOsa, not levioSA!

RAG lets AI answer using your trusted information (FAQs, policies, docs, CRM notes) instead of guessing.

Think Hermione Granger. When a question arises, she doesn’t just “vibe” an answer, she finds the right book, locates the passage, and explains clearly. That’s RAG: “look it up first, answer second.”

2 solutions to rule them all

1. AI Workflow – when the path is clear, pave it

An AI workflow is a system where LLMs and tools are orchestrated through predefined steps. The AI handles language – generating, summarizing, classifying – but the logic of what happens next is written by humans in advance.

Pop Culture Reference: Think of the Fellowship of the Ring. Everyone has a role, a route, and a plan: cross the mountains, destroy the ring, protect the hobbits. Each member executes their part. When the plan works, it works perfectly. But if the mountain is blocked by a snowstorm (Caradhras), the Fellowship has no flexibility – they need to find a different path entirely.

Business Reference: Workflows shine for predictable, repeatable tasks – summarizing support tickets into a CRM, routing inbound emails to the right team, generating weekly reports from your data. They are fast, consistent, and easy to audit. Use them when the goal and the steps are clear.

2. An AI agent is like mission-driven automation

An AI agent is a system where the LLM itself decides what to do next – it dynamically directs its own process, selects tools, adapts when something fails, and keeps going until the goal is reached. Unlike a workflow, the path isn’t predefined: the model figures out the steps. Think of it this way: an agent is an LLM using tools in a loop, autonomously, until the job is done.

Pop Culture Reference: Think Harry, Hermione, and Ron hunting Horcruxes in Deathly Hallows. There’s no fixed plan – they have a mission, gather information, change tactics when something fails (tent camping, anyone?), and improvise through obstacles no one predicted. That’s an agent: goal-driven, tool-using, self-directing.

Business Reference: Give an agent an objective (e.g., build a competitor feature table), and it decides the steps – what to search, what to read, how to structure the output – iterates when something is incomplete, and delivers results. Best for complex, open-ended tasks where the steps can’t be fully predicted in advance.

If you’ve made it this far: congratulations!

You now have a mental model for AI jargon. You don’t need to memorize 11 terms; you need to understand what you’re buying, building, or using.

• When someone says LLM, think “language engine.“
• When they say RAG, think “library-first, answer second.“
• When they say agent, think “mission-driven automation with guardrails.“

AI won’t replace judgment, but it will punish vague instructions, messy data, and unclear ownership. Cheat code? Use workflows when the path is clear and you need consistency at scale. Send agents when the mission is complex and the path can’t be fully mapped in advance. And always demand receipts when the answer matters.

The post 11 Terms You Need to Know Before Incorporating AI appeared first on ShiftMag.