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.

For Mackenzie Jackson (Developer and Security Advocate, Aikido Security) modern security is a nonstop game of whack-a-mole, with alerts and vulnerabilities keeping teams busy putting out fires instead of preventing them.

But that chaos of cybersecurity is familiar territory for him: he investigates attacks and helps teams turn those findings into actionable steps.

But strip away the complexity, and his advice on security is surprisingly simple:

One of the biggest areas for smaller teams to focus on is simply stopping the bleeding.

You don’t need a flawless system, you need to regain control, and by implementing proactive measures companies neutralize threats before they ever touch production. It’s not a complete solution, but it’s a necessary foundation.

Cybersecurity rests on two pillars: people and access

From the outside, cybersecurity looks like a web of interconnected threats and technically, and it is. But when incidents are investigated, the story tends to collapse into something much more… human:

When you actually investigate a breach, what happened? Well, someone was probably phished, their credentials stolen, and that gave access to a system.

From there, attackers escalate, finding additional credentials, uncovering secrets, moving laterally through systems. Despite all the layers of technical complexity, most breaches still come down to two variables: people and access. This doesn’t make security easy, but it does make it clearer.

Brakes make race cars faster – and security works the same way

One of the oldest problems in cybersecurity is organizational: How do you convince leadership to invest in something that, ideally, prevents things from happening?

Fear is the usual tactic so you talk about reputational damage, financial loss, worst-case scenarios. It works, but only to a point and that is why Jackson suggests a different framing:

Brakes make race cars go faster.

It’s a counterintuitive analogy, but an effective one: without brakes, speed becomes dangerous. With them, drivers can push harder, take sharper turns, and move faster with confidence. Security, in this sense is an enabler:

If we build security now, we can innovate faster… establish your brakes so that you can go faster with confidence.

The alternative, adding security later, under pressure from compliance or customer demands almost always slows teams down.

Security tools are here to stay, but AI gives them context

The arrival of AI introduced a pattern: urgency first, understanding later.

After tools like GPT entered the mainstream, companies rushed to integrate AI into their security products. But much of that early adoption, Jackson suggests, was surface-level. The real value of AI lies elsewhere:

AI is a terrible scanner… but it’s great at understanding context.

Traditional security tools are deterministic and that is why they answer yes-or-no questions. Is there a vulnerability? Does this code contain a known issue? AI, by contrast, is non-deterministic. It doesn’t always give the same answer twice and that makes it unreliable for detection, but powerful for interpretation:

If you give it vulnerabilities and ask how severe this is, how exploitable it is that’s where AI becomes incredibly useful.

In other words, AI doesn’t replace security tools. It complements them, helping teams prioritize what actually matters.

AI doesn’t make attackers smarter, it makes attacks easier

So if AI isn’t fundamentally changing how attacks work, what is it changing? Scale.

AI has given script kiddies superpowers.

This phrase captures the shift precisely: AI doesn’t necessarily make attackers more skilled, it makes attacks easier to execute, faster to launch, and accessible to a much larger pool of people. But the core mechanics of attacks remain the same:

It’s not moving the bar up… it’s changing the scale.

And that, perhaps, is the most important takeaway. Because if the nature of attacks hasn’t fundamentally changed, neither has the foundation of defense. Good security hygiene. Strong access control. Protecting the software development lifecycle, Jackson points out.

The tools may evolve. The threats may accelerate. But the principles still hold.

The post AI Won’t Replace Security Tools – It’s Helping Them Prioritize Biggest Threats appeared first on ShiftMag.

I found out about accessibility in college, eight or nine years ago, and loved it so much it became my thesis. From then on, I was often the only person in the room excited enough to talk about it – I persisted, advocated, learned more, and fought to raise awareness.

Rarely did anyone listen, it wasn’t important. Until last year.

When the European Accessibility Act became law, suddenly everyone wanted to talk about accessibility. I was in meetings, resources were finally allocated, and the thing I’d been shouting about for nearly a decade was at last… important.

I should have been thrilled. Instead, I felt nothing.

Anyone, anywhere, should be able to use the web

Tim Berners-Lee said:

The power of the Web is in its universality.

I believed it in college, and I still believe it today: the web should be accessible to everyone. That’s the foundational principle behind the platform we build every day.

But for most of my career, that principle wasn’t even on the radar. I watched us build walls in a medium meant to have none and I kept speaking up anyway, because someone had to.

I‘d won the battle and lost the war

Then 2025 arrived – the European Accessibility Act. Accessibility wasn’t optional anymore, it was a legal requirement. And suddenly, people listened.

Finally, I was having real conversations about accessibility – the thing I’d wanted for eight years. But it wasn’t because most people truly cared, they were asking only because they had to.

For the most part, few conversations focused on the 15% of users who experience the web differently. Most discussions were about checkboxes, compliance audits, and legal exposure, rather than creating experiences that work for everyone.

I’d won the battle and lost the war: accessibility was happening, but the why (the empathy, the principle, the universality of the web) was missing.

Let’s fix something that isn’t broken

You know what’s funny? Everything was fine for a while.

Native HTML elements come with accessibility built in. A <select> is usable by default, and a <button> handles keyboard interaction automatically – HTML was designed with accessibility in mind. The challenge comes when we want to style them: for example, dropdowns are notoriously hard to customize, so they often end up looking like the browser’s default, which can feel “ugly” compared to the rest of our design.

So we built custom ones and this where we start to lose accessibility. We didn’t mean to, we just wanted things to look better. But in chasing the shiny new, we broke what worked.

I guess it got to the point where enough people with disabilities were heard, and finally someone started to care. And now here we are, trying to fix what we broke with our shiny new toys. I’m glad we’re here. If we can, we should take everyone into consideration. It’s also good for business or something—I don’t know, I’m just a developer

But here’s what I do know: ship fast, yes, but don’t skimp on quality. Every commit carries your name, and that matters.

Accessibility automated – no brain cells required

So here I am: building accessible components, creating tools to automate accessibility, and teaching AI to check WCAG compliance. The idea: make accessibility so easy developers don’t have to think about it. Use our Bepo components – get compliance for free, ship accessible products, no explanations required.

After eight years of trying to get people to care, I’m now building systems so they don’t have to. The irony isn’t lost on me.

We’ve built Navigation with a ton of keyboard interactions developers never had to write. Broadcast with ARIA patterns they never had to learn. Color contrast decisions made at the token level. Focus management handled automatically. Claude Code plugin that catches accessibility issues in code review.

It works. Users benefit. Rarely anyone understands why. And that haunted me.

And still, I couldn’t sleep at night

I wrestled with it for months. Had I traded education for efficiency? Made accessibility just a checklist, a tool, not a principle? Where was the empathy in automation?

We’re not just building components, we’re building experiences. Real experiences for real people: those who navigate with keyboards, rely on screen readers, need high contrast, struggle with complex interactions, or depend on assistive technologies.

How do you automate caring about those people?

I thought I understood select… until I actually built one

Until recently, I didn’t really understand the difference between Select and Combobox. I thought I did, I could cite the ARIA spec, but I didn’t. I’d accepted what authorities said without questioning it. In our design system, they were just one Select component… like in many UI libraries. So I never questioned it.

There’s really no difference in what a screen reader announces – Select and Combobox have the same role. I guess Select came first and ARIA later, so the role applies to both. So having just one component… almost the same, right?

Except if you care about the structure of these elements, what it means, and why you can’t fully follow the pattern with just one component. That’s the tricky part

I didn’t really know about the Combobox, until frustration made me curious.

I dove into building a “vanilla” Select from scratch – ARIA patterns, screen reader testing, understanding user expectations, the whole thing. And I realized: modern components don’t really follow patterns. Some tools are technically correct, but they feel… wrong. Clunky. Not what users expect.

Bridging UX gaps is about making interfaces seamless, accessible, and human-first

This is the UX gap. We want custom, modern, polished, and accessible but there’s a bridge missing between the spec and good UX.

I realized: we can have almost all of it if we build with the experience in mind. Combine patterns. Use micro knowledge (like tabbing to inputs or arrowing through options) to make the Select feel as clear as native. Screen reader and keyboard should just make sense.

Average users don’t know about triggers. They just want to open the Select and pick an option. Keep it simple.

As a frontend developer, I see myself as a bridge between users and what I build. It’s my responsibility to make interfaces the best they can be, and to care about them.

You know what I had the most fun with while building my Select? Focus and keyboard interactions. It’s seamless, it works beautifully, exactly as I expect.

I see it in chunks: arrows navigate options, tab moves to buttons, links, inputs. But here’s the twist: if a Select has a custom footer with action buttons, arrows should still navigate options. The footer isn’t part of the pattern; it’s our addition. That’s where we bridge the gap. Or, as the Brits say: mind the gap.

This is the space for custom solutions, where language standards and patterns meet usability, inclusivity, and the full interaction experience.

Building that Select taught me the difference between patterns, user expectations, and implementation flexibility. It was so much fun.

I’ve always loved HTML and CSS – the right semantic element, the right ARIA role, perfect keyboard navigation. It’s craftsmanship. Most users won’t notice, they’ll just use the Select. That’s the point: good infrastructure and accessibility are invisible. You only notice when it’s missing.

We need the knowledge, the understanding, the empathy. UX gaps can’t be automated. Someone has to know what they’re building and who they’re building it for. That’s deep work. And it matters.

The accessibility reconciliation that gave me peace

Then I realized something:

I don’t need everyone to care the way I care, I need everyone to build accessible products. Those aren’t the same thing. And pretending they are was making me miserable.

Here’s the mental model that gave me peace:

Tier 1: The Foundation

• Use accessible components correctly
• Trust the automation
• Get accessibility “for free”
• Ship accessible products without deep expertise

This is how we scale accessibility: give people the right tools and let them use them.

Tier 2: The Curious

• Understand the patterns and why they work 
• Can compose components accessibly
• Catch edge cases automation misses
• Teach others

This is where cultural change happens: people see when automation isn’t enough, ask why, learn deeper patterns, and build better products for their users.

Tier 3: The Champions

• Deep expertise
• Build the infrastructure
• Advance the field
• Fight the eight-year battles

This is where I live, building the tools that make Tier 1 possible.

For eight years, I tried to push everyone to Tier 3, make everyone care as much as I did. I failed. I was exhausted. And I’ve realized I can’t make everyone care, but I can build the infrastructure, play the long game, and ship accessible products anyway. Maybe some will get curious, maybe they won’t, but by making accessibility the default, we create space for learning and a future where it’s just how things work.

Automation doesn’t give up; it accepts that people engage differently.

The door is always open: use components (Tier 1), get curious (Tier 2), contribute patterns (Tier 3). Or stay at Tier 1. That’s fine. That’s success. That’s an accessible product shipped.

You don’t need everyone to care, but everyone can benefit from what you build

If you build accessibility infrastructure, your work matters, even when it’s invisible. Build the safety net, automate what you can, and leave the door open for those who want to see how it works.

If you’re a developer: Tier 1 is enough: use the accessible components, trust the tooling, ship accessible products. Tier 2 is there if you’re curious: learn the patterns, understand your users, make better products. Tier 3 is there if you’re passionate: join us. We’ve been out here a while; it’s lonely sometimes, and we’d love the company.

After eight years in the wilderness, I’m finally building the tools – tools that make accessibility easy, scale empathy, and create experiences for everyone. That’s the infrastructure that matters. And that’s enough.

The post You don’t need to care, just make your products accessible appeared first on ShiftMag.

How are CTOs feeling about AI?

According to Andy Skipper, founder of CTO Craft, they’re experiencing fear, uncertainty, and doubt.

And if the technical leaders of companies are feeling that way, what can the rest of us expect? Certainly, we dream of productivity boosts and an AI El Dorado – but that’s not the reality.

That’s why we sat down with Skipper to talk about how CTOs should manage expectations for AI, and how to navigate the hype versus reality.

Stakeholders and investors are watching CTOs closely, and the pressure is rising

Many CTOs, Skipper notes, are navigating intense pressure from non-technical stakeholders and investors alike, especially with the massive resources being invested in AI and LLM technologies.

He’s a bit careful about this:

AI is not going to reduce costs or increase productivity in the way some non-technical people think just yet. It’s getting there, but it’s not there yet.

At the same time, Skipper points out a surprising upside: AI is giving engineering leaders a chance to reconnect with the code and architecture without writing all the code themselves:

One of the things you have to accept as an engineering leader is that you are going to get further away from the code the more senior you become. AI gives people an opportunity to get back to architecture and development work, even if they aren’t coding themselves.

CTO role can be isolating

When Skipper became a CTO for the first time, he quickly realized just how isolating the role could be. There was nowhere for tech leaders to share challenges, get support, or navigate the non-technical side of the job.

That gap inspired him to start CTO Craft, now a community helping senior engineering leaders navigate team dynamics, strategy, and AI.

When I was a CTO for the first time, I didn’t have somebody who I could talk to about the issues I was seeing or compare notes with people who had similar challenges. That’s what CTO Craft is all about – helping people understand where the challenges come from and understand they’re not alone in having those challenges.

As a coach and mentor, Andy works closely with CTOs around the world, helping them deal with issues like burnout, communication with nontechnical stakeholders, and, lately, how to adapt in the AI era.

The most common CTO mistake? Always chasing the newest technologies

Many first-time CTOs struggle with burnout, overextending themselves to shield teams from stress, and balancing hands-on coding with high-level responsibilities. He explains:

A lot of the people that I work with directly are suffering from burnout. First time CTOs commonly miss out self-preservation. And usually that’s a combination of too much expectation of their own energy levels, their own abilities, backlogs…

And after overextending themselves, first-time CTOs often make another common mistake: chasing the newest technologies. While adopting the latest tools and frameworks can seem exciting, Skipper warns that it’s not always the best choice for fast-moving teams trying to scale.

“Using bleeding-edge tech can slow you down, make systems harder to maintain, and even complicate hiring because the talent pool for newer technologies might be limited,” he explains.

As a coach, Skipper says these are just some of the recurring challenges he sees among engineering leaders, alongside a range of other operational and people-related issues.

Engineering skills alone won’t make you a CTO

For aspiring engineering leaders, Skipper highlights that growing into a successful CTO requires more than technical excellence: commercial understanding, communication, coaching, and vision-setting are just as crucial:

The difference between a good engineering manager and a great CTO is understanding how technology drives business success, while still inspiring and guiding your teams.

But technical and business skills are only part of the picture. Motivation and team management are equally critical. Skipper stresses that not everyone is motivated by the same things, and leaders need to understand individual drivers:

Having a vision in the first place is very important. But when it comes to actually bringing individuals along on the journey, they all need to be worked with differently. You can’t just set it and expect everyone to be motivated.

He also warns against a common mistake among CTOs: trying to shield their teams from the challenges of a pivot or rapid change. While the instinct is understandable, it often backfires and drains the leader’s emotional energy. Instead, transparency and realistic communication are key:

Being transparent, being realistic, measuring your words, not being super negative about everything, but still being realistic, I think all these things are really important.

The need for a support network, not another tech stack

Skipper believes resilience and peer support are crucial for engineering leaders navigating the complexity of the CTO role. Sharing experiences and learning from others can help leaders realize they’re not alone when facing difficult decisions.

Looking ahead, however, he admits that the pace of technological change makes it hard to predict what the role will look like in the future.

Five years from now, I honestly have no idea what the role of a CTO will look like. The way we build software is already changing rapidly, especially with AI. But the fundamentals like setting a vision, communicating it clearly, and connecting technology with business outcomes, will always remain essential.

For Skipper, that uncertainty makes peer support crucial: it helps leaders adapt, learn, and navigate a fast-changing profession.

Ultimately, he believes the most important skill for CTOs is the ability to keep learning and tackle challenges without going it alone.

*Infobip, the global communications API leader that launched ShiftMag, was an Event Partner at CTO Craft 2026.

The post CTOs Face Pressure to Deliver AI Gains, but Productivity Isn’t There Yet appeared first on ShiftMag.

Uber engineers aren’t just using AI to write code; they’re rethinking how developers work with it. That shift matters because, despite 93% adoption, productivity gains remain flat.

At the Pragmatic Summit, I listened to Uber’s Director of Engineering, Anshu Chadha, and Principal Engineer, Ty Smith, discuss how one of the world’s largest technology companies is integrating generative AI into its engineering workflow.

Then, they shared:

At Uber, engineers are beginning to assign coding tasks to AI agents much like managers distribute work among their teams.

Say hello to my new colleague – AI

Uber has been using AI for years in systems like its matching platform, but bringing generative AI into the day-to-day work of engineers is a newer step.

According to Anshu, the goal isn’t to replace engineers – it’s to help them get more done.

We’re not pushing for AI to automate all humans in the company. Our goal is to let engineers focus on creative work rather than toil.

Practically speaking, repetitive tasks such as code migrations, upgrades, documentation, and bug fixes are now being handled by AI-powered agents. According to Anshu, it frees engineers to build features and enhance the user experience.

The end of hands-on programming as we know it?

One of the biggest shifts Uber has observed is the transition from traditional AI-assisted coding tools toward agent-based workflows.

Tools like GitHub Copilot made coding faster by helping developers in the moment, but now we’re entering a new era: AI agents that can work independently, tackling tasks without needing someone at the keyboard.

Back in 2022 and 2023, developer velocity saw a modest 10–15% increase. Today, the paradigm has shifted to what we call “peer programming,” where developers can delegate workloads to AI agents and intervene or redirect them as needed.

This approach essentially positions engineers as tech leads directing AI agents. Developers define the goal, while agents execute parts of the work in the background and return results for review.

Uber has built an internal platform that plugs AI agents right into its engineering workflow, mostly on Michelangelo, its machine learning platform. This gives access to models from OpenAI and Anthropic, as well as Uber’s own internal models.

On top of that, they’ve created agent-driven tools that tap into company data (source code, documentation, Jira tickets, Slack) so the AI agents have enough context to actually get work done.

AI tackles toil, but gaining trust is the real challenge

At the conference, a standout demo was Uber’s “Minions” system. Engineers submit a prompt via web, Slack, or command line, and it generates code changes and opens pull requests automatically. Ty says:

You give the agent a prompt and expect a pull request as the output. A few minutes later the system notifies you on Slack that the task is complete and the PR is ready to review.

The platform also helps engineers craft better prompts by suggesting improvements when instructions are unclear, increasing the likelihood that the agent will succeed.

When Uber first rolled out agentic workflows, they found about 70% of submitted tasks were “toil” – repetitive maintenance work developers usually avoid. These predictable tasks are ideal for AI, creating a feedback loop: the more AI handles, the more developers are willing to delegate.

Still, scaling AI isn’t just about technology. Supporting engineers as they adjust from traditional workflows and gain confidence in AI-generated code is an important focus.

Sharing success stories sparks faster AI adoption

Uber found that peer-driven adoption worked better than mandates. Anshu points out:

The most successful tactic has been sharing wins. When engineers see examples from their peers where AI helped them accomplish something impressive, adoption spreads quickly.

But measuring real impact remains tricky.

Uber tracks metrics like developer satisfaction, productivity, and code output, but connecting them to business outcomes is harder. “These are activity metrics, not business outcomes,” Anshu says.

To fix this, Uber is working to track the full development lifecycle (from design to production) to see how AI truly speeds up product delivery.

AI is powerful but EXPENSIVE

Cost is also becoming an issue. Running large language models at scale requires expensive compute resources, and AI infrastructure spending has grown dramatically, Anshu explains:

Since 2024, our costs have gone up at least six times. This technology is amazing, but the cost of AI is too high.

That’s why Uber is investing in AI infrastructure that picks the right model for each task, balancing performance and cost. With the AI landscape changing fast, the company continuously evaluates new tools and updates its stack:

What’s successful this month may be overtaken next month. So we constantly test new tools, gather feedback from developers, and adapt.

This is a fundamentally different approach from the standard coding-assistant model, one that addresses the real constraints. See the broader context: 42% of code is AI-assisted, yet 96% of developers don’t fully trust it.

Uber’s coding agent now writes 1.800 code changes per week

Just one day after we published this article, Praveen Neppalli Naga, Uber’s CTO, shared in a LinkedIn post that agentic software engineering adoption is accelerating rapidly at Uber:

• 1.800 code changes per week are now written entirely by Uber’s internal background coding agent.
• 95% of engineers use AI every month across tracked tools.

Over the past few months, Uber has leaned in heavily, and as Neppalli Naga notes, the results have been phenomenal:

84% of AI users are now working with agent-style workflows, not just tab completion. Usage of Claude Code nearly doubled in two months (32% → 63%), while traditional IDE-based tools have largely plateaued.

He also said that engineers are shifting from accepting suggestions to delegating tasks. Even within traditional IDEs, around 70% of committed code is now AI-generated.

All of this suggests a quiet but significant shift:

Background agents are increasingly writing code autonomously. Uber’s internal coding agent grew from contributing less than 1% of all code changes to 8% in just a few months, with zero human authoring. Engineers review and approve, but the code itself is written entirely by AI.

The post How Uber Engineers Use AI Agents appeared first on ShiftMag.