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 Damala 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.

Last week, a Python library called chardet became the most contested piece of open source software on the internet. And not because it does anything glamorous – it detects character encodings and figures out whether your file is UTF-8 or Shift-JIS.

It’s plumbing. The kind of thing that used to sit inside requests (and still does if you have it installed) which means it’s probably somewhere in your dependency tree whether you know it or not.

Here’s what happened:

The maintainer who kept this plumbing running for twelve years used Claude to rewrite it from scratch, then published the result under MIT instead of LGPL. The original author, who disappeared from public life in 2011, came back from the dead to object. Two hundred and forty-four comments followed. Most of them were unhelpful.

What makes this interesting isn’t the law, it’s that every single participant in this fight chose a position that protects their ego over one that would have actually fixed anything.

Three licenses walk into a bar…

If you don’t live in licensing land, here’s the short version – three licenses matter for this story: MIT, GPL, and LGPL. They all let you use, modify, and distribute the code. The difference is what they demand in return.

MIT says: do whatever you want. Use it in your startup, your side project, your proprietary product. Keep the copyright notice, and we’re done. No further obligations. This is why companies love it – their lawyers read it once, nod, and move on.

GPL (General Public License) says: you can use and modify this code, but if you distribute the result, you have to release your entire program’s source code under the same license. That’s the “copyleft” mechanism, keeping free software free. The trade-off: it’s viral – if GPL code touches your code, your code inherits the obligation. Most companies treat GPL like radioactive material; legal teams won’t approve it for anything shipped to customers.

LGPL (Lesser GPL) is the compromise. It says: you can use this library inside proprietary software without the copyleft spreading to your code (that’s the “Lesser” part). But if you modify the library itself, those modifications must stay under LGPL. You must include the license, provide the library’s source, and let users swap in their own modified version. That last part matters: it’s meant for libraries like chardet – shared plumbing usable everywhere, but with improvements flowing back to the community. The practical consequence: MIT code can go anywhere.

GPL code can only go into other GPL projects. LGPL sits in between: any project can use it, but nobody can take improvements private.

The Python standard library requires permissive licensing (MIT, BSD, or similar) because anything in stdlib ships with every Python installation on earth, including inside proprietary products. LGPL’s requirements (source disclosure, relinkability, copyleft on modifications) make that impossible. That one restriction is what set this entire fight in motion.

The maintainer should have forked

Dan Blanchard has been primary maintainer of chardet since 2013, contributing nearly seven hundred commits versus forty-eight from the next person. He aimed to relicense the library for Python standard library inclusion – a goal on record since 2014. It’s reasonable: LGPL prevents stdlib inclusion, and chardet is one of Python’s most widely used packages.

So, he used Claude Code to write a clean reimplementation. Ran JPlag plagiarism detection. Got 0.04% average similarity to the old codebase. Published the design documents. Published the implementation plans. Released it as version 7.0.0 under MIT.

And he did all of this under the same package name, in the same repository, on the same PyPI listing.

That’s the mistake – not the rewrite, not the AI. Not even the license change in isolation. The mistake is claiming your code is “an independent work, not a derivative” while simultaneously shipping it as the next version of the thing you say it’s independent from.

You don’t get to have it both ways: If 7.0.0 is an independent work, it’s not chardet, call it chardet-ng.Call it chardetect. Call it encoding-detector. Ship it as a new package. Let people migrate on their own terms. The Python standard library doesn’t care what the package is called on PyPI, it cares about the license and the code quality.

There’s a real question buried here that most people skipped over: who actually controls the PyPI listing? Dan has been the sole active maintainer for over a decade. Could he even publish a fresh package under the chardet name without owning the existing listing? PyPI doesn’t have a “fork the namespace” button. The infrastructure assumes continuity.

That’s a genuine constraint, not just a convenience play. But it doesn’t change the outcome – if the code is independent, it deserves an independent identity, even if the migration is harder.

But Dan didn’t do that, because the value isn’t in the code – the value is in the name. In the twelve years of trust built by that name. In the fact that thousands of requirements.txt files already have chardet in them.

He knows this. He said as much in the issue: “It’s not like this was a thing I just popped into last week.” Right. That’s the point. The name carries weight that the code, by itself, does not. And the name isn’t his to relicense.

The mob should have shown up years ago

242 comments. People comparing Dan to a sex offender. People offering to fund lawsuits. People from a group called “Monadic Sheep” volunteering to take over the project. The FSF was invoked. DMCA was invoked incorrectly. Someone brought up trademark law. Someone posted a Rust rewrite just to prove a point.

Where were all these people for the last twelve years?

Dan maintained this library alone. No funding. No co-maintainers. No help. The other two people on the chardet team haven’t committed since 2017 at the latest – one of them not since 2012. The original author deleted his entire internet presence in 2011. This is one of the most depended-upon packages in the Python ecosystem, and it was held together by a single person on their own time.

Now that person does something people don’t like, and suddenly everyone has opinions about governance and stewardship and the spirit of free software.

Mike Hoye nailed it in the thread:

If the end state of open source projects is that devs are left to work alone for years on the keystone projects of this jenga tower we’re calling modern infrastructure, and then we collectively jump all over them when they turn to the kind of help that, however reprehensible it might be, actually shows up to help, then this entire FOSS project is just a popularity contest where the losers join a slow, lonely suicide pact.

That’s not comfortable to read. It’s accurate.

The people most outraged by this license change are people who benefited from Dan’s work for a decade without lifting a finger. Consumed the output of a copyleft license without contributing back. Relied on a single maintainer without offering support. And now they’re furious he made a unilateral decision without consulting them.

If you want a voice in how a project is governed, you have to be present when the project needs governing. Not just when it does something you don’t like.

The AI optimists should stop celebrating

Armin Ronacher wrote a blog post about this called “AI And The Ship of Theseus.” He’s excited. He sees AI rewrites as a way to finally escape the GPL, which he views as a restriction on sharing:

If you throw away all code and start from scratch, even if the end result behaves the same, it’s a new ship.

With respect to Armin, whose work I deeply admire, this framing is dangerous.

What he’s describing is license laundering. Take copyleft code. Feed it to a model that was trained on that code. Ask the model to produce something functionally equivalent. Point at the output and say “look, no similarity.” The fact that a plagiarism detector can’t find matching tokens doesn’t mean the work is independent. It means the laundering was effective.

If this technique is legitimate, every copyleft project in existence is one Claude session away from becoming MIT. Or proprietary. The same trick works in both directions.

Someone in the GitHub thread made the sharpest observation of the entire debate: take a leaked Windows source code dump, run it through an LLM, and release the output as open source. Is that acceptable? If not, explain why chardet is different. The mechanism is identical. The only variable is whether you sympathize with the copyright holder.

Ronacher also points out that:

Vercel happily reimplemented bash but got visibly upset when someone reimplemented Next.js in the same way.

He means this as a critique of hypocrisy. It’s actually a critique of his own position. Everyone is fine with license laundering when it benefits them. Nobody is fine with it when it’s their code being laundered. That’s not a principled stance. That’s convenience.

The celebration of AI-assisted relicensing as “exciting” or “progress” only works if you assume that copyleft licenses are a mistake that needs a technological workaround. If you think authors should have the right to choose how their work is used, this should terrify you. Not because the law is clear, but because it isn’t. And the people with the resources to push the boundaries are the ones who benefit from copyleft disappearing.

The man who defined open source says you already lost

Bruce Perens showed up in a separate chardet issue. If you don’t know the name: he co-founded the Open Source Initiative and wrote the Open Source Definition. He’s the person who decided what “open source” means.

His position should make everyone uncomfortable.

To the copyleft defenders, he said:

The courts have not sided with plaintiffs in finding AI work to be infringing so far, because the law as it stands today is built primarily around the concept of literal copying, cut and paste of the actual text.

The AI doesn’t do that. It produces statistically probable output from a blended model of everything it’s been trained on. The result is “unrecognizable as derived from any one source.”

Then he added this:

I was hoping the courts would go a different way than they have so far. My present conclusion is that the wrong side may have won, but they won.

Read that again. The man who defined open source licensing thinks the wrong side won. And he’s telling you to act accordingly.

To the AI enthusiasts celebrating, he offered no comfort either:

I am not evangelizing this. This might not be the world I would have liked to have, but it’s the one we got.

And to the companies wondering what to do, he was blunt:

I do not recommend rejecting an AI-mediated Open Source program with verified low-similarity to other works on the basis of legal risk at this time.

Not because it’s right. Because the law, as it currently works, doesn’t have the tools to stop it. “So, yes, it’s copying, but it’s not the kind of copying the court is going to prosecute as a copyright violation.” (He expanded on this in an interview with The Register.)

Perens is describing a world where copyright law was built for photocopiers and the technology outran it. The copyleft purists are right on principle. The AI laundering crowd is right on current law. And the gap between those two things is where every open source project now lives.

Nobody in the chardet thread wants to sit with this. The purists want to believe the law will catch up. The optimists want to believe the law was always wrong. Perens is telling both sides that the law is what it is, it’s probably not going to change fast enough to matter, and you should plan accordingly.

That’s a f*****g eulogy, not a victory speech.

The copyleft purists should stop pretending they’re owed

On the other side of the thread, people are arguing that Dan owes the LGPL, the FSF, and the original author something that goes beyond what the license actually says.

The LGPL says derivative works must be released under the same license. The core legal question is whether 7.0.0 is a derivative work. That’s a question for a judge, not for a GitHub comment thread. And it’s genuinely unclear. The JPlag numbers suggest structural independence. The fact that Claude was trained on the original code suggests something murkier.

Some commenters went further than the legal point: Dan should step down, never be trusted, his work is a supply chain risk, and twelve years of maintenance entitle him to nothing.

That’s not a principled defense of copyleft. That’s resentment wearing a license as a mask.

A license is a legal instrument. It grants and restricts specific rights. It does not create a moral hierarchy where the original author has permanent authority over a project they abandoned fifteen years ago, simply because they chose the license. The LGPL doesn’t say “the maintainer must defer to the original author in perpetuity.” It says derivative works must carry the same license.

If the code is truly independent, the LGPL doesn’t apply. If it’s not, the LGPL requires the license to be reverted. Those are the only two outcomes the license contemplates. “The maintainer should resign in shame” is not one of them.

Dan’s mistake was strategic, not moral. He should have made a new project. He didn’t, and now he’s in a mess. But treating him like he committed a crime against the commons, when he’s the only person who actually showed up to maintain the commons for over a decade, is selective outrage at its worst.

The only person who did their job right

Mark Pilgrim opened the issue: 4 paragraphs, no insults, no legal threats, no grandstanding.

I respectfully insist that they revert the project to its original license.

Then he stopped talking.

He made his position clear, provided his reasoning, and let others respond. He didn’t engage with the two hundred comments that followed. Didn’t threaten lawsuits or moralize. He stated a fact as he understands it and left.

Mark Pilgrim was a hero of mine. I grew up on Dive Into Python. His blog was one of those places where you went to learn how to think about the web, not just how to build for it. When he deleted his entire internet presence in 2011, it hit a lot of us hard. People called it an “infosuicide.” Whatever his reasons were, the web lost something real that day. Seeing his name show up in a GitHub issue in 2026 was – I don’t know. Not closure. But something.

Jason Scott vouched for his identity. And then he did something remarkable: he stayed out of it. Jason Scott is the kind of person who could give a two-hour talk on this topic without repeating himself. He’s an archivist, a historian, and nobody’s fool. The fact that he showed up, confirmed Mark was Mark, and then chose not to add his voice to the pile, that’s restraint that most people in that thread couldn’t manage. Sometimes the most useful thing you can do is not talk.

The person with the most legitimate claim to outrage was the least outraged person in the thread. The person most qualified to add commentary chose silence. There’s a lesson in that, if anyone’s paying attention.

Meanwhile, in the real world…

While the GitHub thread debated philosophy, someone who works at NVIDIA opened a separate issue with a different framing entirely. No ideology. No license theory. Just a practical assessment from someone who has to get software approved by a legal team before it ships. (They explicitly noted their opinions don’t represent NVIDIA’s.)

The title: “v7.0.0 presents unacceptable legal risk to users due to copyright controversy.”

The conclusion:

chardet v7.0.0 is absolutely toxic. If my employer’s open source review legal people got wind of it, I seriously doubt that they’d approve v7.0.0 and up for any use under any circumstances whatsoever.

This is the part that should have stopped everyone cold.

Dan’s stated goal was to make chardet more widely adopted. Get it into the Python standard library. Remove the LGPL barrier that kept companies from contributing.

Instead, the rewrite made chardet less usable than it was before. Under LGPL, any company could use it freely – LGPL is specifically designed to be non-viral for library consumers. Under the disputed MIT, no company with a functioning legal team will touch it. Not because MIT is worse than LGPL, but because the provenance is radioactive. The license dispute itself is the contamination.

Dan’s own user is telling him:

I can’t use this anymore. The license isn’t the problem. The uncertainty is. And uncertainty is worse than the restriction ever was.

This is what happens when you optimize for a theoretical audience (stdlib committee, hypothetical future contributors) instead of the actual one (the thousands of projects that depend on your library right now). You trade a known constraint for an unknown risk. And in enterprise software, unknown risk is the one thing nobody can accept.

What this is actually about?

This fight isn’t about chardet, it’s about three things crashing into each other at once, and nobody wants to untangle them because each thread, pulled separately, leads somewhere uncomfortable.

Thread 1: who owns a project? Open source has no good answer for what happens when the original author leaves and a sole maintainer carries the project for a decade. The license governs the code. Nothing governs the name, the reputation, the PyPI listing, the trust. Dan accumulated something real over twelve years. It’s not copyright. It’s not a trademark. But it’s not nothing, and the current system has no framework for recognizing it or limiting it.

Thread 2: AI makes clean-room arguments meaningless. The entire concept of a clean-room implementation (where you build something from scratch without ever looking at the original code, so you can prove your version is independent) assumes that knowledge contamination is binary. Either you’ve seen the code or you haven’t. LLMs break this model completely. The model has “seen” the code during training. The developer has seen the code during years of maintenance. The output has near-zero structural similarity.

Is that independence, or is it effective laundering? Nobody knows. No court has ruled. The first ruling will set precedent for every copyleft project in every language.

Thread 3: copyleft has a sustainability problem. LGPL kept chardet from entering the Python standard library for over a decade. It kept a sole maintainer trapped in a licensing box that actively prevented the project from growing. The license did exactly what it was designed to do, and the result was a critical dependency maintained by one exhausted person. If your license’s primary effect is preventing adoption and discouraging contribution, you should at least acknowledge that outcome before invoking the license as sacred.

None of these threads have clean answers. But here’s what would have worked: Dan creates a new project called chardetect under MIT. He announces that chardet 6.x is the final LGPL release and will receive security fixes only. He points the community to the new project. Mark has no grounds to object because the new project doesn’t claim to be chardet. The Python stdlib gets its MIT implementation. Everyone who depends on chardet can migrate on their own schedule. Nobody’s trust gets violated.

That didn’t happen because it would have required Dan to give up the one thing that made the rewrite valuable: the name.

The uncomfortable question

Pull up your dependency tree. Find the packages maintained by a single person. Check when they last committed. Check who else has commit access.

That’s your chardet. It’s sitting there right now. And when the maintainer finally snaps, burns out, or makes a decision you don’t like, you’ll have opinions about governance too.

The question is whether you’ll have earned them.

Further reading: Simon Willison’s analysis of the chardet dispute, Armin Ronacher’s “AI And The Ship of Theseus”, Bruce Perens in The Register, the original GitHub issue, and the legal risk issue.

The original Mozilla research on universal character set detection that predates all of this. The US Copyright Office report on AI and copyrightability. Google v. Oracle on API copyrightability and fair use.

The post License Laundering and the Death of Clean Room appeared first on ShiftMag.