Ask anyone outside the industry why people go into software engineering and they’ll say: good money, remote work. Talk to the developers themselves and you get a different story.

For most of the 20 of our Infobip colleagues we interviewed, it started with genuine curiosity – a need to understand how things work, then build their own. Some caught the bug in childhood, others through gaming. But the thread running through nearly every story is the same: they fell in love with the craft long before they ever thought about the salary.

Josip Antoliš, Senior Principal Engineer, captures this sentiment:

It felt like playing with Lego, just for older kids. It was really about building and experimenting.

If money is the only reason you want to become a developer, you won’t make it

Money is part of the equation, and some developers are honest about it – job security and solid pay were what first pointed them toward the field. There’s nothing wrong with that. But most will tell you it only gets you so far.

Engineering is demanding, constantly evolving, and unforgiving to those who are just going through the motions. The developers we spoke to largely agreed: without a genuine curiosity for the craft, the motivation eventually runs dry, no matter what’s in your bank account.

Olga Koroleva, Staff Software Engineer, explains:

For me, it was not money driven. I just naturally like learning new things.

Not everyone had a master plan. For some of the developers we spoke to, the path into software was less a calling and more a series of small, accidental steps like following friends into a computer science program, or stumbling onto coding in their twenties and realizing they had a knack for logical thinking and breaking problems apart.

What matters less, it turns out, is how you got in. What keeps people thriving is the willingness to keep learning and adapting in a field that never really stands still.

Among younger developers in particular, gaming played a surprisingly direct role – less a hobby, more an early window into how software actually works.

Edvin Teskeredžić, Senior AI Software Engineer, remembers his Counter-Strike days:

We used to play a lot of Counter-Strike, and to play together we had to set up servers. Later we started modifying the game, and only later realized we were actually programming.

In the end, whatever brought them to the field, most engineers find a way to grow into it. As Denis Kranjčec, Staff Engineer, puts it:

I started programming 40 years ago, and money was fine, but it was not the only thing.

The best things about being a developer

When asked what they love most about the job, the answers kept circling back to the same themes.

• Cracking a hard problem in a clean, elegant way
• Shipping something that actually makes life easier for people – knowing your code is quietly doing its job out in the world
• Those rarer moments when a tangle of complex systems finally clicks into place, and what was chaos becomes something that just works

Creativity and problem-solving remain central themes. As Teskeredžić puts it:

I like solving practical problems and applying creative solutions.

Beyond the work itself, the setup matters too – remote work, autonomy, and long uninterrupted stretches to actually think. But as Olga Koroleva puts it, what really keeps people around is simpler than any perk:

The best part is staying curious.

The not-so-good part of a developer’s career

Ask about the downsides and the answers get a lot shorter. One word came up more than any other: meetings. Pointless ones, mostly. The kind that could’ve been an email.

Beyond that, developers highlighted several systemic frustrations that disrupt deep focus:

• Constant context-switching takes a significant mental toll.
  
• Bureaucracy and tedious reporting often fracture the time dedicated to core engineering tasks.
  
• Navigating undocumented legacy code and parsing ambiguous logs slows development velocity.

There’s also the relentless pace of change. Kristina Valjak, Engineering Lead, puts it plainly:

The speed of change means you constantly have to learn. You have to sacrifice things. It is not a job you leave at the door.

And then there’s the physical reality: long hours at a screen, tight deadlines, pressure that doesn’t let up. Even in teams doing interesting work, that combination can wear you down.

Would they choose this career again? Absolutely.

When asked if they’d do it all over again, there was barely a pause. Absolutely. 100 percent.

More pros than cons. Almost without exception, these developers would make the same choice and most believe tech still offers something few other industries can match: genuine stability and room to keep growing.

Ivona Škorjanc, Software Engineer, remains highly optimistic:

I would still choose it. It is exciting and I see myself growing in it.

A few said they’d have invested more in the fundamentals early on – the theory, the computer science basics that tend to get skipped in the rush to learn frameworks and ship code. But that’s a minor footnote to a bigger conclusion: this field is hard, and most of them wouldn’t trade it for anything.

Teskeredžić offers a final, inspiring perspective on the profession:

To me, engineers are like real-world wizards. Advanced technology is like magic, and if you can be a wizard for a career, why not.

Even the ones who occasionally miss working with their hands come back to the same answer: they’d choose this path again.

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

The post We Asked 20 Developers Why They Really Got Into Tech. It Wasn’t the Money. appeared first on ShiftMag.

Top experts from global tech leaders will share how they build and scale some of the world’s most complex systems, with real-world lessons from production environments.

Across multiple stages, the program features panels, workshops, and talks focused on deep technical insight and practical experience. Speakers include Katie Gamanji (Apple), Igor Dmochowski (NVIDIA), Sven Peters, Bette Lyon Delsordo, and many others.

You don’t need silicon valley for world-class tech

Igor Dmochowski, Head of Developer Relations for Central and Eastern Europe at NVIDIA, said that Infobip Shift is already internationally recognized, and added that he is especially excited to meet local developers whose potential is increasingly visible on the global stage:

Croatia has exceptional technological talent and a strong AI community, and I’m glad to be part of an event that puts this into a global context. True tech innovation comes from connecting people and ideas, and Shift has that energy.

On the other hand, Ivan Brezak Brkan, the Director of Developer Experience at Infobip, said that Infobip Shift is rightfully the largest tech conference in this part of Europe and one of the largest in the world.

You don’t have to, especially in today’s conditions, travel to the other side of the world to exchange experiences with people whose technological solutions power the world. If you want to advance your career not only through knowledge but also through connections, you need to be at Shift.

No professional speakers and marketing presentations

“Infobip Shift is built on two foundations: high-quality content and a relaxed atmosphere that encourages networking. We ensure strong content by carefully selecting speakers who share real-world experience from people actively working in the industry,” said Stipe Cigic, Director of the Infobip Shift, adding:

We avoid professional speakers, marketing-driven presentations, and topics overloaded with buzzwords and hype. That has become especially challenging today, when roughly every second submitted topic is somehow related to AI. Our speakers are real developers – people whose knowledge our audience truly values.

He also said the second foundation of Shift is its relaxed, laid-back atmosphere – a vibe the team aims to create each year. It can’t be forced, but they work to make the event feel light, summery, and welcoming. That kind of atmosphere makes networking more natural and fun.

Meeting new people is the biggest opportunity for attendees. I know at least 2 projects that started from casual chats at last year’s Shift. High-quality content plus a summer vibe, that’s what makes it memorable.

Knowledge gets you started, networking takes you further

With increasing reports of layoffs and disruption in the global IT industry, networking is becoming even more important. Stipe says the goal is for developers to leave Shift not only with new knowledge, but also with greater confidence and reassurance in their skills, value, and future in the industry.

I believe that, when it comes to networking and professional connections, Shift has no real competition in this part of Europe within the developer industry. A junior developer can casually grab a coffee with a senior engineer from companies like Netflix. The exchange of knowledge and experience in conversations like that is something our community rarely finds at nearby conferences.

Stipe concluded that Shift is a long-term platform developers can rely on, not just to meet peers, but also potential employers, clients, and partners. It offers many opportunities, whether for networking or simply enjoying great talks, food, and drinks under the Mediterranean sun.

Interested in Infobip Shift? Explore what we have planned!

The post Infobip Shift 2026 Returns to Zadar, Bringing Apple and Nvidia to the Stage appeared first on ShiftMag.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

But there’s a price.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In 2025, Sonar surveyed over 1.100 developers worldwide to see how software engineering is evolving. The findings show AI is now central to development – but it hasn’t made the job easier, only reshaped it.

Developers now write code faster than ever. At the same time, they spend more time questioning, reviewing, and validating what gets shipped. Productivity has increased. Confidence has not kept pace. This tension defines the current “State of Code” research.

AI is no longer experimental, it’s operational!

• 72% of developers who use AI coding tools rely on them daily
• Developers estimate that 42% of the code they commit is AI-assisted
• They expect that number to rise to 65% by 2027

AI-assisted coding has shifted from novelty to routine. Among developers who have tried AI tools, most now use them daily. Many estimate that more than 40% of the code they commit includes AI assistance. They expect that percentage to grow significantly in the next two years.

Developers use AI across the full spectrum of work: prototypes, internal tools, customer-facing products, and even business-critical systems. AI no longer supports side experiments. It participates directly in production workflows.

Instead of fighting the tool, rethink how you use it. How Uber engineers shifted from writing code with AI to assigning it work: a different approach to the productivity problem.

This level of integration signals a structural shift in software engineering. Teams no longer ask whether to use AI. They focus on how to use it responsibly.

Do developers trust AI?

• 58% use it in business-critical services
• 88% use AI for prototypes and proof-of-concept work
• 83% use it for internal production systems
• 73% integrate it into customer-facing applications

Developers consistently report that AI makes them faster. Most say AI helps them solve problems more efficiently and reduces time spent on repetitive tasks. Many even report increased job satisfaction because they can offload boilerplate and mechanical work.

However, speed does not equal certainty. Nearly all developers (96%) express doubts about the reliability of AI-generated code. They acknowledge that AI often produces output that looks correct at first glance but contains subtle errors or hidden flaws. This creates a trust deficit.

Despite this skepticism, not all developers consistently verify AI output before committing it. The pressure to ship features quickly often outweighs the discipline of thorough review. As a result, teams face a new bottleneck: verification.

Reviewing AI-generated code frequently demands more effort than reviewing human-written code. Developers must reconstruct intent, validate assumptions, and check edge cases without knowing how the model arrived at its solution. AI compresses the time spent writing code but expands the time required to evaluate it.

In this environment, confidence – not velocity – becomes the true measure of engineering maturity.

AI doesn’t remove toil, it changes it!

75% believe AI reduces toil. However, time allocation data reveals a more complex picture:

• Developers still spend roughly 23–25% of their work week on low-value or repetitive tasks
• This percentage remains consistent regardless of AI usage frequency

One of the promises of AI tools involved reducing developer toil: repetitive, frustrating tasks such as writing documentation, generating tests, or navigating poorly structured codebases. Many developers believe AI reduces certain kinds of toil. They report improvements in documentation quality, test coverage, and refactoring efficiency.

However, the overall proportion of time developers spend on low-value work has not meaningfully decreased. Instead, AI shifts the nature of toil. Developers now spend less time writing boilerplate and more time validating AI suggestions. They spend less time drafting documentation and more time correcting generated code. Traditional frustrations have not disappeared; they have transformed.

This dynamic challenges simplistic narratives about AI productivity gains. AI does not eliminate friction. It redistributes it.

Teams that recognize this reality can adapt workflows accordingly. Teams that assume AI automatically saves time risk underestimating the verification cost.

Technical debt: reduction and acceleration at once

Positive impact:

• 93% report at least one improvement related to technical debt
• 57% see better documentation
• 53% report improved testing or debugging
• Nearly half report easier refactoring

Negative impact:

• 88% report at least one negative consequence
• 53% say AI generates code that appears correct but is unreliable
• 40% say it produces unnecessary or duplicative code

AI influences technical debt in both directions. On the positive side, developers use AI to modernize legacy code, generate missing tests, improve documentation, and refactor inefficient structures. These activities reduce long-standing debt and improve maintainability.

On the negative side, AI sometimes generates redundant, overly verbose, or structurally weak code. Developers frequently encounter code that appears correct but introduces subtle reliability problems. When teams integrate such code without rigorous review, they create new debt.

AI therefore acts as both a debt reducer and a debt accelerator. Managing this tension requires deliberate governance. Teams must treat AI contributions as first-class code changes subject to the same standards as human-written code. Automated testing, static analysis, and clear architectural principles become even more critical in this environment.

Technical debt already ranks among developers’ top frustrations. Uncontrolled AI usage can amplify that burden rather than alleviate it.

What is shadow AI?

Most used tools:

• GitHub Copilot (75%)
• ChatGPT (74%)
• Claude (48%)
• Google Codey/Duet (37%)
• Cursor (31%)

GitHub Copilot and ChatGPT dominate AI-assisted coding usage, but developers rely on a growing ecosystem of tools. Many teams use multiple AI platforms simultaneously, selecting each for specific strengths. This fragmentation creates flexibility but introduces complexity.

A critical risk signal:

• 35% of developers use AI tools through personal accounts
• 52% of ChatGPT users access it outside company-managed environments
• 57% worry about exposing sensitive data

Developers often access AI tools through personal accounts rather than company-approved environments. This behavior reflects demand for productivity but introduces governance risks. When developers paste proprietary code into unmanaged AI systems, organizations lose visibility and control.

Security concerns rank among the most significant worries associated with AI adoption. Developers themselves recognize the risk of exposing sensitive data.

Organizations must respond pragmatically. Banning AI rarely works. Developers adopt tools that help them work faster. Instead, companies should provide secure, sanctioned AI environments and define clear usage guidelines. Enablement, not prohibition, produces safer outcomes.

The experience divide

Less experienced developers:

• Use AI for understanding codebases
• Rely more heavily on AI for implementation
• Estimate a higher percentage of AI-assisted code

Senior developers:

• Use AI more selectively
• Focus on review, optimization, and refactoring
• Express higher skepticism

AI does not affect all developers equally. Less-experienced developers tend to adopt new AI tools more aggressively. They use AI to understand unfamiliar codebases, generate implementations, and explore new frameworks. For them, AI functions as both assistant and tutor.

More experienced developers integrate AI differently. They rely on it to review code, optimize performance, and assist with maintenance tasks. Their experience enables them to identify flaws more quickly and apply AI selectively.

Junior developers often trust AI more readily. Senior developers approach it more cautiously. This difference does not reflect competence; it reflects perspective.

High-performing teams combine both approaches. Junior engineers introduce experimentation and speed. Senior engineers provide oversight and architectural discipline. Together, they mitigate risk while capturing gains.

What this means for engineering teams?

The State of Code 2025 reveals a profession in transition. AI increases output but raises the bar for validation. It reduces certain manual burdens while introducing new forms of cognitive load. It offers opportunities to address legacy debt while risking new complexity.

The central lesson does not concern speed. It concerns confidence. Developers must treat AI as a powerful collaborator that requires supervision. Engineering leaders must invest in testing infrastructure, review practices, and secure tooling environments. Organizations must acknowledge that productivity improvements depend on disciplined integration, not blind adoption.

Developers no longer compete on how quickly they can type code. They compete on how effectively they can evaluate, refine, and ship trustworthy systems.

The tools have changed. The responsibility has not. Teams that focus on clarity, code quality, and secure AI integration will thrive in this new environment. Teams that chase velocity without verification will accumulate invisible risk.

The post 42% of Code Is Now AI-Assisted! appeared first on ShiftMag.

Picture a team arguing over whether to keep a global Redux store or roll out a context-only solution for a new React component. Minutes later, someone pushes a change that breaks the whole test suite.

A week later, another debate erupts about whether the REST API should be versioned or use a graph-based approach. And there’s always that one Git rebase that turns a quiet sprint into a full-blown firefight.

The line between brilliant innovation and productivity meltdown is thinner than you think – and ego is often the culprit lurking behind every heated Slack thread and passive-aggressive code comment.

What is egoless development?

Egoless development is not about surrendering conviction or becoming passive. It’s about letting the problem drive the solution, not the other way around. Gerald Weinberg, in his seminal work The Psychology of Computer Programming, wrote: “The most powerful learning occurs when someone produces a better solution than you had imagined.” If your ego can’t digest a “better” or “different” answer, you have no business leading a software team.

In practice, egoless engineering means:

• Staying open to new ideas – even if they come from a junior teammate or an external library.
• Focusing on the product’s value – not on proving your own architectural choices.
• Accepting feedback without defensiveness – because every line of code is a hypothesis, not a manifesto.
• Separating self-worth from code quality – your value isn’t measured by how rarely your code needs revision.

How ego shows up and undermines everything

Ego erodes trust, inflates the perception of individual contribution, and turns collaboration into a zero-sum game. The consequences ripple outward: missed deadlines, higher bug counts, knowledge silos, and ultimately, a loss of team morale that drives your best people toward the exit.

The psychology behind code ownership

When we write code, our brains treat it as an extension of ourselves. Neuroscience research shows that criticism of our work activates the same neural pathways as physical threats. This is why a simple “This could be refactored” comment can feel like a personal attack.

Understanding this psychological reality helps us build better defenses:

• Recognize the feeling – When defensiveness arises, pause and acknowledge it
• Reframe criticism as collaboration – Someone improving your code is helping you, not attacking you
• Build emotional distance – Use phrases like “the code” instead of “my code”
• Practice receiving feedback – Like any skill, gracefully accepting criticism improves with practice

Real examples of ego at work

Linus Torvalds, creator of Linux, became known for a harsh communication style on the Linux Kernel Mailing List, often going beyond technical feedback.

In 2015, during the “Brain Damage” incident, he dismissed a developer’s security proposal as “mindless security theater” and called it “brain damaged.” The developer stopped contributing, and the security concern became a real exploit two years later.

The fallout? Talented contributors left, community diversity dropped, and valid concerns were ignored based on who raised them.

After years of this, Torvalds took a break and issued a public apology in 2018, acknowledging that his ego had harmed the project and committing to a Code of Conduct.

Even brilliant technical leaders can cause real damage when ego outweighs empathy – but egoless engineering is a conscious choice.

Now let’s see egoless communication in action

This is my own example. It was 2:37 PM when my code hit production. By 3:00 PM, our monitoring  tool sent alerts all over and showed 50 errors. New users couldn’t sign up. Existing users couldn’t complete their profiles.

This is where most teams spiral. Blame gets assigned. Confidence gets crushed. Someone becomes the cautionary tale.

Not this team.

The team lead’s first message: “Okay, let’s work the problem. Ivan, walk us through what happened – no judgment, just facts. Everyone else, what do we need to stabilize right now?”

My response: “I skipped the integration test because I thought it was just an isolated signup flow change. Clearly, I was wrong. I can roll back immediately, then we need to figure out why our CI didn’t catch this.”

Ten minutes later, production was stable. The retrospective didn’t focus on my mistake – it focused on the process gap. Why weren’t integration tests enforced for all changes? How could CI catch this automatically?

System got fixed and the whole team started advocating for comprehensive testing.

Lead with purpose, not ego

The antidote to ego-driven culture is a purpose-driven mindset. Put the team first: “Ship better products. Learn together. Celebrate collective wins.”

Adopt core values such as:

• Open collaboration – Everyone’s input matters, regardless of tenure or title.
• Continuous improvement – No single person owns the ship; we all keep it afloat.
• Shared ownership – Success is a team metric, not a résumé headline.
• Blameless culture – Focus on systems and processes, not individual fault.
• Intellectual humility – “I don’t know” is a strength, not a weakness.

These values create a safety net that lets people experiment, fail fast, and iterate without fear of ego-related retribution.

How to cultivate egoless teams?

1. Morning coffee feedback sessions

Schedule a quick, informal chat with each teammate once a month.

Purpose: Surface concerns early, show genuine interest, reinforce the “we” narrative.

Pro tip: Keep it casual – grab actual coffee, go for a walk, or just sit outside the usual meeting room environment.

2. Code review as conversation

Treat every PR as a dialogue, not a verdict.

Instead of: “Why did you do that?”
Try: “I’m curious about your approach to X – what tradeoffs did you consider?”

Key practices:

• Assume good intent always
• Ask questions before making statements
• Provide context for your suggestions
• Praise the good before noting improvements

3. Process-focused retrospectives

Avoid blame, focus on improving the workflow.

Outcome: The team learns to iterate on their own practices, identifying systemic issues rather than scapegoating individuals.

Framework to try: Use “What went well? What could be better? What will we try next?” instead of “Who caused the production incident?”

4. Celebrate team wins

Highlight milestones that benefited the whole product, not individual heroics.

Effect: Reinforces that value comes from collaboration. Consider a “Team Win Thursday” where you spotlight collaborative achievements in your all-hands.

5. Rotate responsibilities

Give everyone a chance to lead a sprint, own a component, or make architectural decisions.

Result: Empowers diverse viewpoints and reduces power-centered thinking. It also prevents knowledge silos and builds empathy for different roles.

6. Create a “learning debt” board

Just like technical debt, track what the team needs to learn.

How it works: Anyone can add skills or knowledge gaps. The team prioritizes learning together through lunch-and-learns, workshops, or dedicated study time. This normalizes not knowing everything.

Purpose-driven teams really excel

The data backs up the philosophy:

• Faster problem solving – Collective knowledge surfaces solutions faster.
• Higher-quality products – Diverse eyes catch more bugs; studies show pair programming can reduce bugs by 15-50%.
• Happier teams – People feel valued beyond ego metrics.
• Lower turnover – People stay when they feel part of something bigger; psychological safety is the #1 predictor of team success (Google’s Project Aristotle).
• Innovation acceleration – When failure isn’t punished, experimentation flourishes.

In our own team, we’ve seen the difference. The “Misfit Days” workshops we introduced – short, daily stand-ups where anyone can bring a friction point- have slashed bug-backlog time by 35% and doubled the rate of new feature delivery. More importantly, our employee satisfaction scores jumped 28 points in six months.

Warning signs your team has an ego problem

Watch for these red flags:

1. Pull requests sit for days because no one wants to critique the senior dev.
2. “I told you so” moments are celebrated instead of collective problem-solving.
3. Knowledge hoarding where individuals protect “their” domains.
4. Defensive Slack threads that spiral into 47-message arguments over syntax.
5. Silent meetings where juniors don’t speak up for fear of looking stupid.
6. Resume-driven development where tech choices prioritize personal branding.
7. Hero culture where all-nighters and firefighting are glorified over prevention.

If you recognize three or more of these in your team, it’s time to intervene.

What should I do?

Ego is a silent saboteur that thrives in the quiet corners of code reviews and pull-request comments. It whispers that your solution is the only solution, that criticism is an attack, that admitting uncertainty is weakness. But the best engineering teams know differently.

By embracing egoless engineering – focusing on shared purpose, valuing every voice, and making collaboration the default – we turn potential productivity meltdowns into engines of innovation. The code improves, the products ship faster, and most importantly, people actually enjoy coming to work.

Remember: The best code you’ll ever write is the code you wrote with others. The best solution you’ll ever implement is the one that made someone else’s idea better. And the best career move you’ll ever make is building a reputation as someone who makes everyone around them better.

Starting tomorrow:

• Implement a monthly open-feedback routine – Put it on the calendar now.
• Audit your code review comments – Are you asking questions or issuing verdicts?
• Celebrate a team win – Find one this week and make noise about it.
• Try one new strategy – Pick from the list above and experiment for a sprint.

Every idea is respected. Constructive feedback is not just welcome; it’s required. Success is measured by shared achievements, not individual credit.

The post Developers, your EGO is the real bug in the system appeared first on ShiftMag.

By the end of 2025, I had read a lot about people building entire apps with AI, going from an idea to a product in just weeks or even days. That made me ask myself: how are they doing this?

I have more than ten years of experience in enterprise backend development. Seeing these fast, AI-built apps sparked my curiosity. I use AI in my day-to-day work, but only for small tasks, nothing close to building a full product.

So I thought, why not try it myself and see if it’s really possible?

I started thinking about what I actually wanted to build, and it quickly became clear that it had to be something I’d use myself. I’m a runner and I work in enterprise, so the idea came pretty naturally: a running app, but with a twist – tracking fitness while mapping it onto a corporate-style career journey.

That’s how RunCorp came to life.

AI as a fast MVP builder and UI scaffold

My main stack is Java and Python, but I deliberately avoided what I know best. I wanted something familiar, yet still a bit uncomfortable. For the backend, I chose Laravel, since I’ve done some freelance work with it. For mobile, I picked Flutter, even though I had never built a mobile app before.

I bought a Claude Code subscription and started building. I quickly learned that you can’t just tell it to do something and expect a good result. That realization led me to throw away the very first thing it generated.

What really works is using plan mode. You let the AI analyze the problem, ask you questions, and create a plan. Only after you feel happy with the plan do you let it generate code. It feels more like collaborating with a teammate than typing commands at a tool.

The downside is that this approach burns through tokens. If you don’t want to pay for extra usage, you have to wait a few hours for the limit to reset. Even so, I managed to build a basic MVP in six days.

I started with just the UI and mocked data. By the end of the first day, I had an app with all the MVP screens in place. You could actually “use” the app – move from screen to screen and see something -even though real functionality didn’t exist yet. Everything ran on mocked data. For this kind of work, AI proved very effective at generating basic Flutter layouts like this:

class HomeScreen extends StatelessWidget { 
@override
Widget build(BuildContext context) {
return Scaffold(
 appBar: AppBar(title: Text('RunCorp')),
  body: ListView(
   padding: EdgeInsets.all(16), 
    children: [
     Text(
      'Welcome back',
     style: Theme.of(context).textTheme.headlineSmall,
    ),
    SizedBox(height: 16),
    Card(
     child: ListTile(
      title: Text('Current Level'), 
      subtitle: Text('Senior Runner'),
      ),
     ),
    ],
   ),
  );
 }
}

Nothing complex, but very fast. This is where AI clearly shines: it scaffolds the UI, wires screens together, and handles repetitive setup.

Outdated libraries and testing challenges

After that, I worked screen by screen, building front-end and back-end functionality together. I followed the same workflow every time: create a plan, answer AI questions, refine the plan, answer again, and generate code only after I felt satisfied with the plan.

Here’s the first big problem for someone without much experience: when you use plan mode, the AI asks questions you might not know how to answer. It asks things like: do you want to use OAuth? How do you want to encrypt passwords? Do you want a separate table for user profiles, or do you want everything in one table? You have to make these decisions early. Otherwise, the AI generates something that either doesn’t work or becomes hard to change later.

One concrete backend issue came up during the Strava integration. When I asked the AI for help with Strava authentication, it suggested an existing Laravel package.

At first glance, the suggestion looked reasonable. But after I checked it more closely, I realized the package hadn’t received updates for several years and didn’t support the current Laravel version. It relied on outdated dependencies and failed in a modern Laravel setup.

This example shows where AI falls short. It suggests known libraries, but it doesn’t judge whether teams still maintain them or whether they fit today’s ecosystem.

Instead of forcing the package into the project, I implemented the Strava OAuth flow directly using Laravel’s HTTP client. The core token exchange looked like this:

$response = Http::asForm()->post('https://www.strava.com/oauth/token', [.                                  
    'client_id'	=> config('services.strava.client_id'), 
    'client_secret' => config('services.strava.client_secret'),
    'code'	=> $request->get('code'),
    'grant_type'	=> 'authorization_code',
]);

$data = $response->json();

A similar issue appeared on the frontend. The AI generated Flutter UI that looked great on a large simulator. Once I tested it on smaller phones, problems started to show up. Text became barely readable, layouts overflowed, and some screens turned difficult to use. A typical example looked like this:

Text(
'Weekly Distance',
style: TextStyle(fontSize: 24),
);

Hardcoded font sizes worked fine on larger screens but failed badly on smaller ones. Fixing this required a shift toward responsive design. I improved the layout by switching to theme-based typography:

Text(
'Weekly Distance',
style: Theme.of(context).textTheme.titleMedium,
);
 
LayoutBuilder(
 builder: (context, constraints) { 
  return Text(
   'Weekly Distance', 
  style: TextStyle(
   fontSize: constraints.maxWidth < 360 ? 16 : 20,
   ),
  );
 },
);

The UI technically worked before – it just didn’t work well everywhere. Issues like this only show up when you test on real devices.

When AI-generated code meets real users

After six days, I had an app with enough functionality to be tested by someone. I asked people from my running club if they wanted to try it, and they said yes. I sent them a beta build, and 25 of them started using it. That’s when the real problems began to appear.

After just two days, people reported that the home screen took a long time to load and that the stats screen kept crashing. That was the moment I realized this was the end of just talking with AI. I had to do what I’ve been doing for years: actually debug and review all the code.

The AI-generated backend code looked clean. It passed basic tests and worked perfectly with small datasets, so I shipped it. But once real users arrived, reality hit hard. Requests were timing out, the stats and home pages barely loaded on mobile, database CPU spiked, and every request ran over 20 queries. Classic red flags.

These were problems that wouldn’t have made it to production if I had written the code myself from the start. Experience teaches you where bottlenecks usually hide. AI didn’t optimize anything; it just made things work.

Here’s what the AI-generated backend code got wrong all at once:

• No eager loading, causing N+1 queries
• Queries running inside loops
• Loading entire models into memory just to calculate aggregates
• No caching at all
• Missing database indexes
• Recalculating values that were already stored
• Doing heavy computation in PHP instead of letting the database handle it

None of these were bugs – they were experience problems.

At that point, I had to step in and do what I’ve been doing for years: rewrite the entire statistics pipeline. Some of the key fixes were:

Eager Loading Instead of N+1

$user = $request->user()->load('profile');

Aggressive Response Caching

return Cache::remember("user_stats:{$user->id}", now()->endOfDay(), 
function () {
    // heavy calculations

});

Query Consolidation (7 Queries → 1)

$stats = DB::table('activities')

    ->where('user_id', $userId)

    ->selectRaw("

         SUM(distance_meters) as total_distance, 
         COUNT(DISTINCT DATE(start_at)) as active_days,
 
         SUM(CASE WHEN start_at >= ? THEN distance_meters ELSE 0 END) as weekly_distance
", [$weekStart])

->first();

GROUP BY Instead of Query Loops

->groupBy('week_num')

Using Stored Values Instead of Recomputing

$longestStreak = $user->profile->highest_streak ?? 0;

Strategic Indexes

$table->index(['user_id', 'start_at', 'distance_meters']);

The results were immediate

After these changes, the app finally felt usable in real conditions. The home screen loaded instantly, the stats screen didn’t crash, and the database handled multiple users at the same time. Experience made the difference.

I shipped a working app quickly, but I still had to do a lot of work myself. Coding the basics – the tasks any junior developer can handle – is easy, and that’s exactly where AI excels. It can speed up development, but you need to know when to step in, what to change, what to ask, and how to plan everything properly.

Coding isn’t even the hardest part, at least for mobile apps. You can build the app fast, but you must deploy the backend, set up servers, configure domains, and prepare everything for the app stores.

Then comes the part no one talks about: Google Play beta testing, Apple App Store review, waiting for developer accounts and licenses to get approved, fixing small issues reviewers reject, and updating screenshots, descriptions, and privacy policies. None of this is hard, but all of it takes time.

From the moment I started building to the moment the app went public, the process took just over a month, still very fast.

I realized that today AI becomes incredibly powerful in the hands of someone who knows what they’re doing. For experienced engineers, it can provide a huge speed boost, almost like a superpower. AI acts like a team of juniors handling repetitive work while you focus on high-level decisions.

Someone with solid experience can now build projects that used to require a small team. Can a non-technical person build an app with AI? Yes, to some extent. They can create something that looks decent and runs, but most of the time it will start falling apart quickly.

The main takeaway: the basics still matter. Understanding how things work under the hood makes all the difference. AI doesn’t replace experience, but it amplifies it, and that’s where it delivers real value.

The post How I Built a Full-Stack App in 6 Days with the Help of AI appeared first on ShiftMag.

Using pip is like assembling IKEA furniture without instructions. Add a single package, and suddenly you’re battling dependency conflicts, version chaos, and cryptic errors – decoding them feels like reading an ancient language.

I can’t even run a simple script without either polluting my global environment or creating a virtual environment for a one-off script I’ll never run again.

It’s ridiculous how something that should simplify our lives makes it more complicated, especially compared to other ecosystems. Having previously worked with Ruby and its beautiful and mature gem system, I felt like switching to Python downgraded my experience.

Simplifying Python projects with uv

As engineers, we desire simple, robust, and predictable solutions. Yet here I was, praying that my environment wouldn’t implode every time I made a tiny change or – God forbid – updated a package version.

After some search (and reading the excellent book Hypermodern Python Tooling), I’ve found an alternative that solved most of my issues in one swoop: uv – a fast, modern, and reliable Python dependency management tool.

It streamlined the internal process of developing Python services within our team and made us more productive. Our builds are faster, and it eliminated all the complexity we had from using many different tools.

In this article, I’ll convince you to leave your comfort zone and switch to using uv as your go-to tool for everything and anything Python.

The hellscape that is Python tooling

In terms of tooling, entering the Python ecosystem while previously working with Ruby (and privately with Go) felt like I replaced a reliable Toyota with a carriage drawn by a malnourished horse.

Virtual environments, pip, and dependency management wasted many engineering hours that we could have spent writing code (and producing actual value!).

Spinning up a new microservice tested your patience, as the tooling tried to ruin your day with a broken package, an unreadable error message, or sluggish build times because the cache didn’t update somewhere.

Let’s talk about real-world examples

Dependency management with pip behaves unpredictably. It can’t build anything beyond the simplest dependency graph. When you work on legacy code (and you absolutely will), updating it often breaks your functionalities. You can only debug by endlessly examining the output of pip freeze until that command engraves itself in your brain like an ancient chant.

The core problems come from the fact that pip doesn’t guarantee that two runs of installing dependencies will also install the same sub-dependencies. If you want to know more, there’s a great article about this.

Virtual environments devour disk space. The concept sounds great: if project A uses one version of dependency X, and project B uses another, you isolate them in virtual environments so every project keeps its source of truth. But in practice, you quickly drain your memory when running many Python services, each with its own project.

The problem worsens with AI-based projects: in the AI space, we often use PyTorch and that single dependency consumes at least 936MB for the CPU version and 1.8GB for the GPU version (numbers taken from the PyTorch forums, here and here).

Imagine running multiple AI projects – if we keep this up, our disk space disappears.

Say Hi to uv!

Now that we’ve established how badly Python needs better tooling, let’s look at uv.

What exactly is uv? According to their website, uv is a high-speed Python package and project manager written in Rust. Integrating uv into your workflow eliminates most of the tools you currently rely on – it directly replaces pip, pip - tools, poetry, and many more.

The core design philosophy focuses on giving you one Python development tool while also delivering extreme speed (we’ll test this later).

“Alright,” you might ask, “what can this magical tool do?” Great question! Let’s look at some of uv’s most compelling features.

Project dependency management

Managing your Python project with uv is extremely simple because uv provides first-class project support built around declarative manifests and universal lockfiles (similar to those in the JS ecosystem and Poetry).

This setup ensures reproducible installs and fast syncs. You initialize projects with uv init, add and declare dependencies (e.g., numpy and lang chain), and generate fully pinned lockfiles with uv lock.

After that, subsequent environment creations or updates (“syncs”) use that lockfile to reproduce identical sub-dependency graphs every time. In practice, this stops the endless back-and-forth of “works on my machine” messages via Slack.

Unlike plain pip install, which can produce different sub-dependency graphs on repeated runs (creating inconsistent project environments), uv lock locks everything down – you won’t encounter surprises halfway through a deployment pipeline.

Running standalone scripts

Whipping up a quick Python script to try something out is amazing – until you need packages without standard Python. Then the experience quickly turns into venv juggling and ad-hoc pip installs.

With uv, we can run standalone scripts without creating new environments: just run uv run --with [your packages] script.py to auto-install any dependencies to the cache and run your script. These commands install packages on the fly, and you can later lock them with uv lock if needed.

You can even embed metadata into your scripts to declare dependencies and required Python versions, like so:

# /// script
# requires-python = ">=3.13"
# dependencies = [
#     "langchain",
#     "typer==0.12.3",
# ]
# ///

import os
import langchain
# ... rest of your script ...

You can save this script and run it efficiently with uv run script.py. Thanks to uv’s speedy resolver and global cache, the script runs repeatably and in milliseconds. You can finally spend less time fighting your environment and more time doing what you actually want: writing code.

Disk-Space Efficiency

Uv maintains a global cache of all downloaded packages. Once you fetch any version of a package (even a sub-dependency!), you never need to re-download or duplicate it across projects. By comparison, pip re-downloads wheels into each virtual environment, and Poetry duplicates caches in projects – these approaches waste massive amounts of disk space, which matters especially for AI-based projects and workflows.

To get a bit technical, uv keeps a single copy of each exact release in a global cache directory. Any project that needs the same version can access it via a symlink, rather than copying the entire package into the project. Beyond this cache, uv writes project-specific artifacts (e.g., compiled wheels) into a per-project store. Since both stores use content hashes to identify files, uv instantly detects duplicates.

This means that if two projects depend on langchain-0.3.24, uv stores that version only once.
The real-world impact is visible in multi-project AI workflows. As AI engineers, we often maintain and juggle multiple PyTorch-based services.

We drastically reduce total disk usage by sharing the PyTorch wheel (approximately 1.8 GB) across various projects. As the memory footprint from dependencies shrinks, scaling up microservice-based architectures becomes more manageable.

This improvement is crucial for CI pipelines and developer workstations, which can run multiple microservices simultaneously.

Speed!

One of the main drawbacks of working in the AI space is the sheer size of all the packages and tools that a modern AI service uses. Installing all those dependencies takes time, slows down our CI/CD pipeline, and hampers our developer experience.

Naturally, install speed becomes crucial in such scenarios. The makers of uv provide speed comparison benchmarks, testing their tool against pip and Poetry.

Across all scenarios (warm/cold installs and warm/cold resolution), uv outperforms pip and Poetry by orders of magnitude.

These results come directly from uv’s official benchmarks. These benchmarks install Trio’s official dependencies. Let’s see how uv’s benefits impact our developer workflow.

Comparing uv to other tools when building an AI microservice

To compare uv with other tools (in this case, pip and poetry), we’ll walk through the common steps of building a Python application and see how much easier it is to use uv. The typical steps for creating a Python app include:

• Initializing a project
• Adding dependencies
• Locking/freezing your dependencies
• Installing/syncing packages
• Running scripts and notebooks (handy for AI/ML engineers)

To provide an at-a-glance comparison, we’ve summarized these steps in a table:

Testing Install Speed on a “real” AI microservice

To compare the experience of using uv with other tools like pip and poetry, let’s build a basic AI microservice. We’ll start with these dependencies:

fastapi==0.110.2
uvicorn[standard]==0.29.0

# AI/GenAI/LLM related
transformers==4.40.1
torch==2.2.2
scipy==1.13.0
scikit-learn==1.5.0
numpy==1.26.4
sentence-transformers==2.7.0
langchain==0.1.16

# Pydantic for data validation
pydantic==2.7.1

# Async tools
httpx==0.27.0

# Background tasks and scheduling
celery==5.4.0
redis==5.0.4

# Observability (logging, tracing, monitoring)
opentelemetry-api==1.25.0
opentelemetry-sdk==1.25.0

# Environment variables
python-dotenv==1.0.1

# ORM
sqlalchemy==2.0.30

This setup doesn’t mimic a real AI microservice; it just represents what you’d commonly find in one. We’ll create this as a Python project using three different build tools: pip, Poetry, and uv. Then, we’ll benchmark how fast these tools install the dependencies.

We’ll use Python 3.12 for our virtual environment, which should not affect the results. In addition, we run this test on Ubuntu 22.04.5 LTS. For all tests, we perform a cold installation (no cache), followed by a warm installation (with cache).

Keep in mind that cold install times depend heavily on your network speed and bandwidth, and your ISP can throttle TCP, affecting the results.

Why uv wins?

Swapping between multiple CLIs introduces cognitive overload – uv ends that. With pip and venv, you constantly toggle between Python’s venv module, manual requirements files, and pip installs. Poetry tries to put everything under its own umbrella, but still makes you chain together poetry install , poetry lock , and poetry run.

By contrast, uv gives you a single tool for all your needs and covers every workflow step. It just works. Under the hood, uv’s dependency resolver and global cache guarantee repeatable installs without spinning wheels or bloated environments.

Every project shares the same content-address store, which prevents duplicate downloads and wasted disk space.

Since uv builds from the ground up with modern workflows in mind, it provides first-class support for Python version management (Poetry requires a separate tool, pyenv, for this), workspaces (missing from Poetry), script metadata that turns Python files into portable executables (not supported by Poetry), and even built-in publishing capabilities.

In short, uv gives you a simple, lean, and fast pipeline while simultaneously replacing the old ways of dependency management in Python.

Uv in production – benefits and lessons learned

After careful consideration, we slowly started adopting uv as our go-to tool for writing new Python microservices, especially in AI. By switching to uv, we consolidated our workflow under one tool and leveraged its many benefits. The results speak for themselves: consistent, millisecond-scale installs, smaller container layers, and zero “it worked on my machine” issues across all environments.

The benefits are measurable, too. Our average CI/CD pipeline build time dropped by half for services we migrated to uv. Running multiple services locally became easier because uv provides a global cache and symlinks to dependencies, greatly reducing disk usage.

In addition, uv.lock ensures every branch and pipeline uses the same dependency graph, eliminating surprise version bumps or broken sub-dependencies.

Finally, our cognitive workload as developers decreased significantly as we removed multiple tools from our toolchain, dramatically reducing maintenance overhead.

After using uv for some time, we also discovered a few valuable tricks:

• Cache Management – Periodically running uv cache prune keeps the cache directory clean by removing all unused entries.
• Accelerator Configuration – Following uv’s PyTorch integration guide lets us pin CPU vs. CUDA builds per service declaratively, avoiding manual URL overrides. This approach allows us to install CUDA-enabled PyTorch on Linux, CPU-only builds on MacOS, and even include custom flags to enable or disable GPU builds when needed.

You should give uv a chance

As we’ve seen, traditional Python tooling too often slows us down, wastes space, and forces us to hope for reproducible builds. Uv cuts through that noise with a single, fast binary that handles every step of your workflow – from project initialization to publishing.

Uv runs much faster than its competitors, and its universal lockfile guarantees deterministic builds that work everywhere, every time.

Whether you build heavy AI pipelines, ship microservices, or maintain a monorepo filled with standalone scripts and notebooks, uv brings consistency, performance, and simplicity to your workflow.

Stop wrestling with half-baked tools and give uv a spin today – I promise it will turn your dependency hellscape into a clean, reliable experience!

The post Tame Python Chaos With uv – The Superpower Every AI Engineer Needs appeared first on ShiftMag.

He drew a clear line through past transformations — User Experience (UX) reshaped digital products in the 1990s, and Developer Experience (DX) redefined platforms in the 2010s. Matt argues that AX drives the critical design frontier in the era of AI-driven development.

“Good DX doesn’t always mean good AX,” Matt said. Tools that feel intuitive for humans often frustrate AI agents. He urged builders to design platforms that deliver seamless human usability and strong agentic experience, allowing AI systems to interact, adapt, and create value without friction.

Redefining the Developer Population

Matt opened by challenging how we define a “developer.” He reminded the audience that the industry once dismissed frontend developers as “pseudo-developers,” only later to acknowledge them as essential builders of the modern web.

Similarly, he argued that today’s AI agents sit at the edge of legitimacy. With the right platforms and tooling, they could redefine development and bring billions more people into the fold.

Matt envisioned a future not limited to millions of professional software engineers but open to as many as three billion people — anyone with technical acumen and an internet connection — who could step into development through agents.

The opportunity is not just to grow the developer market, but to redefine what development means for the “next 100 million people coming online”.

Access, Context, and Tools: The Three Pillars of AX

Matt framed AX around three core challenges: access, context, and tools.

Access focuses on how easily agents can interact with a product. Traditional authentication models, like OAuth scopes, often block agents that need open-ended flexibility. Matt highlighted “anonymous flows” and sandboxed environments, which let agents experiment before locking in permissions.

Netlify, Neon, and Clerk provided clear examples of this pattern, granting limited access first and formalizing accounts only when necessary. Context ensures agents understand a product’s existence and how to use it effectively.

Matt spotlighted “context engineering,” where structured documentation — Markdown files, MCP servers, or custom .md rules — feeds LLMs the information they need to generate reliable output. He also suggested that search engine optimization could evolve into Generative AI Optimization, helping models surface and apply product knowledge more accurately.

Tools form the final pillar, shaping how agents act on information. Matt stressed that platforms must offer intuitive APIs, predictable interfaces, and robust debugging options so agents can perform reliably at scale.

For Matt, AX is not a feature or protocol but a discipline, much like UX. It requires constant observation, iteration, and empathy.

On the other hand, tools are the interfaces through which agents interact with products. Even well-designed CLIs and APIs can fail when faced with non-human users.

Matt showed how Netlify’s CLI, long celebrated for its developer experience, repeatedly tripped up an AI coding agent during deployment. He transformed the tool into an AX-ready platform by adding a single non-interactive command — useless for most humans but ideal for agents.

Standards and Ecosystem Shifts

A recurring theme in Matt’s lecture was the lack of standards around agentic experience (AX). He highlighted early frameworks like the Model Context Protocol (MCP) and lightweight conventions such as llms.txt as signals of the industry’s direction.

Matt warned against naively exposing entire APIs to agents. He urged developers to treat MCP like a user interface for LLMs, carefully designing the minimal tools and context agents need to succeed.

He contrasted Salesforce’s closed approach, which pushes proprietary agents while restricting integration, with HubSpot’s open strategy, which embraces MCP to give agents seamless access. The latter, Matt argued, shows how embracing AX can differentiate products in a fast-evolving ecosystem.

For Matt, AX isn’t just a feature or protocol — it’s a discipline, like UX. It demands constant observation, iteration, and empathy, not just for human end-users but also for the agents acting on their behalf. He suggested this shift could unlock enormous economic potential by serving existing professionals and bringing entirely new demographics into web development.

At Netlify, early investments in AX have already delivered results. Since launching these efforts a year ago, the company has seen a fivefold increase in daily signups and a sevenfold jump in paid conversions. Even more importantly, AX has empowered millions of new users with little or no coding background to become active builders on the platform.

A Call to Developers

As AI agents take on more tasks — writing, debugging, and deploying code — the barriers to entry for development are collapsing. Skills like algorithm design and CLI expertise may lose weight, while qualities such as product sense, empathy, and domain knowledge gain importance.

“This is an opportunity to invite so many more people into the room,” Matt said, highlighting use cases from HR teams designing surveys to marketers prototyping campaigns with AI agents.

The next generation of developers are coming, and it’s up to us to ensure the web is ready for them.

For developers, Matt delivered a clear message: just as UX and DX once drove competitive advantage, mastering agentic experience (AX) may soon decide which tools — and which companies — define the future of software.

Want to know what else was discussed at Infobip Shift at Zadar in 2025? Find out here!

The post Your Platform Might Already Be Incompatible With the Future appeared first on ShiftMag.

Tech debt is no longer the main source of wasted time and friction for developers.

It’s also not testing or code reviews – it’s finding information, as per Atlassian’s State of Developer Experience 2025 report, based on surveys of 3,500 developers and managers worldwide.

Paradoxically, 68% of developers reported that they save over 10 hours per week thanks to generative AI tools – up sharply from 46% the prior year. Yet, half of developers say they still lose more than 10 hours weekly due to organizational inefficiencies, and 90% lose at least six hours to issues like poor cross-team coordination, unclear project direction, and difficulty retrieving information.

Coding is Just 16% of Developers’ Jobs

Atlassian’s report noted that this is where the question of whether AI tools are truly helping developers enters the equation.

These tools primarily support developers with coding tasks, which only make up around 16% of their working week. The remainder of their time is spent on administrative work, tool-switching, documentation, and context-switching.

Another source of developer frustration where AI tools are not much help (yet) is context and clarity on what they’re building. They report wasting time getting clarifications from other teams and understanding institutional knowledge.

Leadership Does Not Understand Developers

There is also a growing disconnect between software engineers and leadership. 63% of developers report that leadership doesn’t truly understand their day-to-day pain points, up 19 percentage points from last year. The study argues that engineers experience friction firsthand, and leaders are more likely to see productivity gains on a dashboard and accept them as a sign of progress.

Without alignment on what the pain points really are and what investments in developer experience actually make developers’ lives easier, investments in AI tools risk becoming superficial solutions that fail to ease real friction.

The post The Number One Productivity Killer for Devs? Finding Information! appeared first on ShiftMag.

Developers are not happy at work, and they keep letting us know. According to the Stack Overflow 2025 Developer Survey, only 24% of developers reported that they were happy at work – a four percent increase from the year before.

In the same survey, developers ranked autonomy and trust as the most important factors contributing to their satisfaction, followed by competitive pay and benefits, and solving real-world problems.

A group of Swedish researchers conducted an interactive study with 15 engineers to understand what influences the well-being of software engineers. They asked them what in their environment, on a personal as well as a team level, contributes to or takes away from their well-being.

Stress is everywhere

The biggest sources of stress for software engineers are personal life issues (62%), high workload (53%), and tight deadlines (46%). But that’s not the full story. Poor tooling, social isolation, and chaotic or unstructured environments also play a role. When expectations shift constantly and communication is messy, even strong developers can get overwhelmed fast.

Developers are doing their part

Most engineers aren’t sitting around waiting for someone to fix this. In the survey, 71% reported maintaining physical health routines, and over half said they actively manage their mental health. Exercise, hobbies, and sleep are go-to coping strategies. But they can only go so far when team dynamics and org structures keep adding pressure.

Social connection and recognition matter

What really stands out is how much people rely on other people. Developers consistently pointed to social interactions – whether with teammates, friends, or family – as the backbone of their well-being. Feeling seen, supported, and appreciated isn’t a “nice to have.” It directly affects motivation and long-term engagement.

The recognition gap is real: while 91% of developers said they felt respected in general, only 64% felt like they were being supported in their professional growth. That gap creates friction. Lack of recognition was one of the most common reasons people thought about quitting.

What teams can do

Investing in developer well-being doesn’t mean adding ping-pong tables or wellness webinars. It means making space for honest conversations, checking in before things hit a breaking point, and treating social connections like an asset.

Teams that build trust, celebrate wins (big or small), and offer flexibility in how people get work done tend to perform better over time. This is not because they “optimize” for productivity but because they understand that happy developers equal productive developers.
 

The post What Makes Developers Happy? appeared first on ShiftMag.