Ahead of the Infobip Shift Conference in Zadar this September (for which you get a special discount as a ShiftMag reader), we spoke with Amir, who will be one of the speakers. Reflecting on Doist’s longevity, he said, “We’ve always thought in decades, not quarters.”

While many Todoist competitors raised big funding rounds and grew too fast before being acquired or shutting down, Doist chose a slower, steadier path focused on product and users – and it paid off.

Remote work needs to be sustainable, not glamorous

Doist has also been remote-first from the start and is often cited as an early example of remote work at scale.

They have spoken often about job satisfaction, mental health and wellbeing, but he says Doist hasn’t “solved” mental health in remote work. Instead, the company is structured to make people less likely to feel isolated or overworked, or to struggle quietly.

Furthermore, Amir explained:

Remote work offers freedom, but it can also blur boundaries and create loneliness. So we focus on making it sustainable, not on making it glamorous. We’re remote-first, not nomad-first: people can work from anywhere, but we encourage them to build roots near friends, family, and community.

For Amir, people simply do their best work when they have good lives. Simple as it may be, it’s also something that goes completely over the heads of many companies, especially fast-growing startups in the “AI hustle” era.

Building software isn’t enough anymore

A quick Google or LinkedIn search tells you all you need to know about the state of productivity apps and software in 2026. The marketplaces are flooded with AI tools and wrapper apps, creating a greater need for quick success than just a few years before, and a “closing window” dynamic where developers must achieve massive scale in months or disappear.

Amir tells us that, despite this, many of the fundamentals still matter:

Are you solving a real customer pain point in a 10x way? Is your solution differentiated? Do you have strong marketing and a memorable brand?

Continuing, Amir says that the bar to create has dropped dramatically, but the quality bar has risen just as much. To succeed now, one needs to build something far better than what was required when Amir was starting out. Concluding, Amir says that you “need to be incredible at many things, such as design, marketing and sales, not just software.”

Engineering still matters in 2026

Doist emphasizes deliberate decision-making, and that same approach shapes its engineering culture. For Amir, “engineering culture at Doist” means:

Making clear technical choices and trade-offs that help us serve users, move faster with confidence, and build durable foundations. It’s about thoughtful preparation, strong ownership, high-quality systems, and focusing on the technical work that matters most (not chasing everything at once).

Speaking of engineering, Amir’s talk at Infobip Shift will be watched by engineers and leaders in the space, many of whom are building products themselves. To them, he says that the engineering mindset is still incredibly useful for building and scaling companies, and that engineering still matters a lot in 2026.

Make sure to reserve your ticket with a special discount for ShiftMag readers!

The post Doist CEO: ‘The bar to create has dropped, but the quality bar has risen’ appeared first on ShiftMag.

At CTO Craft Con, Dr. Catherine Hicks (founder of Catharsis Consulting and researcher on open-science work involving 15,000+ developers) argued that most engineering measurement failures aren’t really data problems.

No matter how much dashboards you vibe-code (we all do that nowadays, don’t we?), the problem is theoretical: understanding what causal model your metrics are actually testing.

Are you building spite lines?

Hicks opened with a historical detour that turned out to be her sharpest part of the argument. Probably a bit brutal from today’s point of view, but early electricity measurement looked straightforward: count the deaths, count the lumens, measure the hours of labor saved.

Why the number of deaths? Those numbers made sense relative to what came before. Gas infrastructure occasionally caused sidewalks to explode. Zero to ten electrocution deaths in a neighborhood looked different once you remembered that twenty people you knew had died from the sidewalk going up.

Measurement always encodes a comparison, and if you do not make that comparison explicit, your metric will mislead you.

The more cutting example was the spite line. In early U.S. rural electrification, large power companies would create something called a spite line. It’s a single wire that ran through a region, sometimes connected to nothing more useful than a light in a shed, in order to legally claim the territory and block rural co-ops from building real infrastructure. The federal government that was measuring electrification by the presence of a line wasn’t measuring access but the exact opposite.

Hicks argued that engineering organizations are building spite lines right now, and mostly do not know it.

Measurement failures usually come back to theory failures.

The loudest thing (on Slack) might not be the most important

A change theory, in her framing, is a causal model: if I give engineers more ramp time on this language, they will engage differently with these processes, and that will produce a business outcome. Everyone operates inside such models, but most teams never make them explicit.

The result is that they default to measuring what is visible, what is fast to collect, or what is loudest on Slack. None of those is necessarily connected to the outcome they care about.

On AI specifically, she identified three recurring failure modes:

1. Treating developers as interchangeable units producing identical work, when they’re actually using AI in highly individual contexts.
2. Reading early spikes in code volume as a stable signal, when research on open-source repositories shows those spikes often normalize into different patterns within weeks.
3. Measuring only at the individual level while ignoring the interaction between the tool, the team, the task, the project goals, and organizational culture – a system Hicks said has too many interaction terms for any person to hold at once.

Her response to that complexity was deliberate: stop trying to measure everything.

Your job is not to measure everything that’s happening. What you really need to do is think about what in your organization are the key signals to measure if they give you two things.

Those two things are levers, predictors of large behavioral patterns, or blockers you can actually remove, and shared outcomes you can hold the organization accountable to over time.

Correlation between learning culture and team effectiveness

Hicks drew on her own research to illustrate what a well-theorized lever looks like.

In a 2024 study of over 3,000 working developers, her team tested whether learning culture could reduce the identity threat that developers report feeling from AI. Teams with strong learning cultures, defined as believing they have organizational support to learn, and rejecting fixed-mindset assumptions about what makes someone technically capable, cut their AI-related identity threat by 50% or more. She has since replicated the correlation between learning culture and team effectiveness across multiple engineering organizations, and found that reaching the highest effectiveness tier requires clearing a threshold of learning culture, not just improving incrementally.

The practical upshot for leaders: if you want to measure whether your AI investment is working, you probably should not start with token consumption or PR velocity. You should ask whether developers believe their organization treats learning as legitimate work.

What if your metrics are broken?

On the question of what to actually do when you realize your metrics are broken, Hicks was direct. Describe how you got there. Find the argument you lost, or the organizational story that made a bad measure feel safe to commit to. Then build a change theory first, and derive the measures from that, not the other way around.

She closed with a framing that captured her broader position: you are not trying to map every variable in a complex system. You are trying to create enough shared understanding that people will tell you what is actually happening.

You will become the person who can hear what is really happening. You will be the person who will start to hear: I think we’re measuring spite lines over here.

That, she argued, is more useful than any dashboard.

The post Tokens and PR velocity won’t tell you if your AI investment is paying off appeared first on ShiftMag.

From my experience as a people manager (and an even longer stint as a developer), I’ve noticed that many engineers don’t see much value in goals.

If this is how you feel when your manager asks you to set yearly goals (or hands you new ones) you’re not alone.

In my perspective, they often feel like extra homework, tacked on after the “real work” of coding, only to resurface at the end of the year when someone asks about your progress. And from where I stand, you’re right: when treated this way, goals rarely deliver tangible benefits.

But it doesn’t have to be like this.

You’re missing out (on what exactly?)

Periodic goals, when used correctly, are a powerful long-term focus tool. In fast-paced teams, swamped with Jira tickets, code reviews, and spikes, you can be constantly busy yet rarely challenge the true priority or value of your next task.

That’s what goals are for:

• Company goals make sure you’re working on what matters.
• Personal development goals help you learn intentionally from your day-to-day work.

If your goals aren’t doing that, it’s probably because they’re not being used as intended.

How goals started making sense (and bringing value) to me

Once again: you must pick something that you truly feel strongly about. Realising this simple truth was the change in my case. It is better to have one goal that truly meets this requirement than four you only slightly care about.

My turning point came from my personal, not professional, life. I realised that my life wasn’t heading where I wanted, and if I didn’t change course, I wouldn’t be happy with how I’d spent it. This insight helped me see the importance of long-term planning (and I wouldn’t have seen it if I hadn’t read Stephen Covey’s classic book The 7 Habits of Highly Effective People).

From there, I began setting goals, actually tracking them, and finally seeing the value.

How to make goals work

For goals to work for you, you need three simple requirements:

1. Choose goals you genuinely believe are important and valuable.
2. Track progress regularly (if you’re not tracking, it’s usually a sign that requirement 1 isn’t really met).
3. Connect goals to your daily work, so progress happens as you ship, not as an afterthought.

Don’t isolate goals from your workflow

A common problem is that the goals are too detached from your daily work. You likely spend most of your time in the codebase, making changes based on your issue‑tracking system. Now consider a goal like:

By the end of the year, I will have finished a Kotlin fundamentals training.

That’s planning to fail. Will you truly make room for this while putting tickets on hold? If yes, great. But for most of us, day-to-day tasks feel more urgent. December arrives, and you realise you’ve made no progress. Cue the last-minute scramble.

Define a different goal instead: 

When I see a Kotlin feature in the codebase that I don’t understand, I’ll read the documentation and make a note of it (at least once a week).

Why this works: you don’t need much extra time, it won’t derail the task at hand, it’s easy to track, and it builds a habit of continuous learning rather than a one-off course completion.

Focus on the “how,” not just “what”

Another tip is defining goals that focus you on how you’d like to accomplish something. Probably the task from the issue tracking system already tells you what you need to do. A goal can help you define additional criteria or focus on the quality.

Let’s say you introduced a few bugs into the system recently and want to avoid this in the future. You could define a goal:

For every applicable pull request, I will leave a comment documenting measured test coverage before and after the change and ensure it increases.

This keeps the goal anchored in your daily work while adding a perspective often missing from the ticket.

Keep the goals visible

This relates to Requirement 2: if you do not see the goal often, you’re likely to forget to track it. Keep them in sight: as a sticky note on your monitor or pinned at the top of your to-do list.

Use OKRs (or something similarly effective)

There’s a reason OKRs have stuck around: they’re simple and effective. A practical check I like is to define the Objective and then ask:

Will it really happen once these KRs are met?

If the answer is “not quite,” adjust your Key Results until they make the objective inevitable.

Final thought

If you’ve made it this far, I hope it’s a bit clearer how goals can help. Pick goals that matter, track them regularly, and tie them to your daily work. You’ll feel the difference.

Happy goal‑setting!

The post Developer Goals Don’t Have to Be Corporate Theatre appeared first on ShiftMag.

You get an idea and a moment later, the code’s already in your head. And before you know it – bam! – it’s on GitHub.

But hey, it was your side project, not your day job. Because once you step into a “real job,” things get complicated by the minute.

At first, you might think, Oh, we refine the task, put it in the next sprint, implement it, do a PR, testing… and it’ll be done in about two weeks. No bam! this time, but it’s still fast… comparatively.

That speed reminds you of working alone (or with a small, familiar team) where ideas move almost as quickly as they appear. Code follows a thought, and suddenly it’s in the repo.

But once an idea crosses teams or touches parts you don’t own, time stretches. Days turn into weeks, weeks into months – not because the code is harder, but because communication is: unfamiliar code, processes, priorities, even languages.

Who you work with is EVERYTHING

Now I’m going to challenge you even more: how long would it take to implement a system‑wide feature? I’m not talking about some fancy, super‑complex, revolutionary refactor, just something that stretches across many components that aren’t yours. You don’t know them. You don’t even know the maintainers.

And let’s be honest, you don’t want to talk – you’re a programmer, after all, right? You think, Well, a couple of sprints… maybe a few months… if you’re feeling optimistic.

When you’re working alone, the only communication is between your neurons, and that’s pretty fast, isn’t it?

The same goes when you collaborate with teammates you know well. You understand each other, don’t need to repeat much, and many things are already covered by your working agreements (whether written down or just implicit) so you barely have to mention them.

But step into a new or larger team, and suddenly communication is full of obstacles. You don’t know the people, you don’t know how they work, they might speak another language – or worse, code in another language! Cooperation suddenly feels almost impossible.

It will take months, because you need to talk to the others, discuss multiple opinions, understand different perspectives and reach number of compromises. Implementation is easy-peasy. 

The less we know about the project, the more we try to handle it ourselves

Recently we’ve been implementing a very custom solution for a big client. We generally don’t provide custom solutions, but sometimes customers, especially big ones, manage to convince us somehow. 

For most of our integrations, we rely on two key components:

1. Component A handles queuing, throttling, and light request processing. 
2. Component B handles more substantial model transformations and aligns our data with the external provider’s protocol.

In this case, no major model manipulation was required. However, we couldn’t simply send data from A to the provider. We were aware of the configuration possibilities in Component A.

So the question arose: Should we stick to our usual A+B setup, following the well‑worn path? Or should we step outside our comfort zone, reconfigure Component A, and see if we can eliminate the need for Component B altogether?

If both were ours, the answer would be easy. But we didn’t know much about A – we didn’t even know the maintainers.

The temptation to stick with the usual path grew. Then someone had the clever idea to explore Component A using Claude Code. Now we know it, we’re AI-powered! We can do anything, even talk to strangers! Bring them on! we thought. This time, we did it the right way.

Jokes aside, Components A and B (and their ownership by different teams) are a classic example of Conway’s Law: the tendency to copy organizational structure into system design. The harder it is for two people or teams to collaborate, the more likely they are to build separate, siloed parts of the system (have you heard about silos?).

Still doubt that poor communication shapes architecture? Reread the first paragraph – you probably didn’t even notice it the first time. Or check out the insightful presentation The Only Unbreakable Law.

Still unconvinced? Here’s a knockout argument: think back to the last time you tried to sort something out at a government office. How many doors did you have to knock on? How many forms did you have to fill out? How many organizational units did you have to visit? And all for just one issue…

In a well-designed company, this doesn’t always need to be an issue. Why would a corporate lawyer need to talk to a DevOps engineer? Or an accountant to a UI tester?

But when it comes to software, the boundaries aren’t always so clear. In our example, the less we know about the people maintaining a given component, the more likely we are to misuse it and try to solve the problem on our own. That often leads first to overcomplicated architecture, and then to technical and organizational silos.

This is how my team fought the Conway’s Law

You’re probably thinking there must be a way around this, and you’re right. There’s an approach called the Inverse Conway Maneuver: if the organization shapes the architecture, why not design teams to build the system we want?

Sounds clever, but it’s not easy, especially in established companies.

Management must be tech-savvy and understand the right architecture, and engineers need to grasp the target design and reasoning, since changes often involve reorganizing the codebase.

Organizational changes don’t have to impact the whole company and they can be applied on a smaller scale. Here’s a simple example from my experience.

We used to work on a product end-to-end and our area was defined by the product, not the architecture. Sounds nice, right?

However, we were backend developers, and since the product included front-end applications, we also had to develop and maintain the user-facing parts. We were never front-end experts, so we struggled a lot. We knew the product and its business specifics, but our tech gaps were a constant drag.

Eventually, we decided to hand it over to front-end experts. What a relief! Product Managers got what they wanted on time, backend developers could focus on our strengths, and frontend developers had fun fixing our mistakes.

We thought everything was sorted, until later, when we all got together in one room, despite being geographically distributed, to talk about the product. During that session, we uncovered a few weird issues we hadn’t noticed before.

The key was sharing knowledge about how each part worked and how they worked together, which revealed bugs invisible when working in isolation. It was eye-opening, and I can’t overlook another benefit: building team spirit through shared activities and discoveries, which greatly improved our future collaboration.

Sit down and listen to other teams

So here’s the thing: Conway’s Law isn’t going away. No matter how hard you try, no matter how many architecture diagrams you draw, your system will always reflect how your teams communicate… or don’t.

But before you panic, remember the government office analogy: you’re knocking on doors because that’s how the organization is structured, not because doors are inherently evil. The same applies here. Yes, your architecture will mirror organizational boundaries, but it’s on you whether you knock or find a workaround.

Every time you sit in a room with people from another team and actually listen, every time you take the time to understand how the system really works, you’re actively shaping the architecture – whether you realize it or not.

The post Code Isn’t Slowing Your Project Down, Communication Is appeared first on ShiftMag.

At the Web Summit conference, Andrew Filev, CEO of Zencoder – a company that achieved a $2.25B exit – debunked that myth. He called it blind hustle, a mindset that destroys long-term innovation and sustainable growth.

For engineers and founders navigating fierce competition, Filev argues that success depends not on the number of hours worked but on the quality, focus, and sustainability of effort. He calls this approach the smart grind.

The toxic cult of 996

Filev highlights how overwork has become normalized, especially through the infamous “996” schedule, 9 AM to 9 PM, 6 days a week, a routine common in hyper-competitive tech markets.

This panic-driven culture often disguises itself as passion but ultimately stunts professional growth.

Creative output peaks only within a certain range; beyond that, productivity nosedives. Those extra hours often add little value and instead drain the energy needed for rest, reflection, and strategic thinking.

Many skilled engineers fall into what Filev calls the “over-engineer’s trap,” where they chase hours instead of impact. In doing so, they trade clear, strategic thinking for the illusion of productivity, creating overly complex solutions when simpler ones would suffice.

Even stepping away can feel difficult. Filev recalls taking vacations yet constantly feeling pulled back into work, a cycle that slowly erodes creativity. Innovation, he argues, depends on perspective – and perspective only comes when you truly disconnect.

The “smart grind” mindset

Instead of chasing blind hustle, Filev promotes the smart grind, which drives lasting, industry-defining success.

The myth of the “overnight success” fuels burnout. Filev explains that every transformative company, including his own, grew from years of consistent, intentional work. Real progress demands a sustainable pace, not a desperate sprint.

I’d rather work in a way that increases the law of probability that success finds me.

True success isn’t a lottery. It’s the outcome of steady, high-quality decisions that compound over time.

Think clearly and direct AI effectively!

Shift your focus from how long you work to what you work on and how you approach it.

Start by recognizing patterns, study market trends, and your team’s performance to make smarter, more informed choices.

Then, guide your direction by ensuring every hour of effort supports your long-term strategy instead of reacting to short-term, low-impact tasks.

Filev warns that AI could amplify the blind hustle mindset. As automation handles more tasks, the real advantage belongs to people who can think clearly and direct AI effectively. Burnout dulls that ability, leaving even talented teams ineffective as AI “bosses.”

The edge no longer comes from working longer, but from maintaining the mental clarity to make high-impact, strategic decisions. Filev’s message is simple:

The $2.25B exit didn’t come from sleepless nights at the office. It came from years of disciplined, well-rested, high-quality decisions. True innovation and lasting success come from sustainability, not sacrifice.

The post Zencoder CEO: Hustle Hype Didn’t Drive Our $2B Exit – Sustainable Work Did appeared first on ShiftMag.

Enter the Paladin – a brave soul with a new set of duties each sprint.

This role helps teams stay focused, move faster, and still tackle the things that usually fall through the cracks. Curious how it works? Let me share what we’ve learned in my team.

Meet the Paladin – defender of focus, slayer of tech debt

The Paladin is a dedicated team member with unique responsibilities each sprint – a hybrid between a sprint host and a support guardian.

This role runs alongside the sprint, not within its planned capacity, serving as the shield that protects the team from distractions, context switching, and chaos.

Duties of the Paladin:

1. Monitor team support and monitoring channels.
2. Provide immediate support and troubleshooting for reported problems.
3. Host all sprint-related ceremonies, such as daily standups, sprint reviews, and sprint planning.
4. Resolve tech debt and improvement tasks during support downtime.

The Paladin helps the team stay laser-focused on sprint goals while reducing distracting context switches. It speeds up response times for support, monitoring, and incident handling – all without impacting sprint or company objectives.

And a happy side effect? It frees up time to tackle tech debt and improvement tickets that would otherwise languish in the backlog.

What it looks like in action?

Our team has a dedicated Kanban board for tech debt and improvement tasks (including tasks with special labels and bugs). This allows us to prioritize items that the Paladin can tackle without affecting the team’s availability or deliverability.

Some examples of tasks the Paladin has successfully handled include migrating microservices to a new framework (.NET 6 to .NET 8), improving CI/CD pipelines, ensuring compliance with various ADRs, enhancing logging, and moving background logic to dedicated jobs.

Beyond task management, the Paladin also participates in PR reviews. This serves two purposes:

• Ensuring there are enough team members for quality reviews.
• Keeping the Paladin up to date with ongoing sprint tasks.

Additionally, having the Paladin facilitate sprint-related ceremonies indirectly strengthens soft skills while helping push sprint goals forward. Another indirect benefit is that the Paladin frees up time for tasks that often get sidelined in the normal team flow, such as improving documentation, support, and monitoring.

Do you need a Paladin?

The biggest value of the Paladin role is that it allows teams to focus their sprint time on delivering sprint and company goals without losing too much time to mundane tasks like support, monitoring, tech debt, and sprint ceremonies.

By having a dedicated team member each sprint to handle these responsibilities, we indirectly increase the value of the whole team and improve our ability to support future features. Of course, every team is different, and the challenges they face are unique, so this role can be used as a template to tailor the best experience for your own team.

The post Need Someone to Handle Support, Tech Debt, and Team Focus? Meet the Paladin 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.

The survey shows GPT models dominate, with 82% of developers using them last year. Claude Sonnet is gaining ground too – especially among pros (45%) over beginners (30%). While many try “vibe coding,” 77% say it’s not part of their real workflow.

This gap between use and trust drove us to explore where LLMs truly help and where they can make a mess. To break it down, we put together a list of the top 5 good ways to use these AI tools, along with 5 situations where you should absolutely steer clear.

LLMs as superstars for these tasks

LLMs excel at practical, time-saving tasks – particularly those that are repetitive or well-structured. From generating boilerplate code and debugging to drafting docs or translating languages, they act as tireless productivity boosters. They’re also handy learning companions, offering explanations and exercises on demand.

Next, we’ll highlight where LLMs truly add value in everyday development.

1. Boilerplate and setup

We all know that LLMs solve repetitive tasks excellently. That happens because they can automatically generate a project template, initialization code, config files, or standard classes and functions in just one second.

For example, ChatGPT needs only one second to hit the usual patterns and syntax on the first attempt. They are most effective for generating base code, which the developer then reviews, shapes, and adapts.

2. Debugging assistance

LLMs always step in as reliable assistants when you need “another pair of eyes” to find a bug. They analyse code surprisingly well because they can spot logical gaps, propose fixes, and even explain why a function fails specific tests.

For example, you only need to insert an error message and ask, “What is wrong here?” – the model will suggest where the issue hides. Of course, always check suggestions through tests.

3. Documentation and comments

Writing documentation and comments often feels boring, but LLMs do it quickly and efficiently. They can generate docstrings, README sections, or comments based on code.

As one Reddit user says: “for simple tasks – like adding documentation or looking up syntax – I can get a near-instant solution.” So, in this case, LLMs are excellent for filling documentation gaps or creating explanations for colleagues who need help.

4. Code conversion

Porting code between languages or frameworks often feels exhausting. ChatGPT can help translate a Python function into Java or C# code. It works best with popular languages and standard patterns.

Naturally, you always need to validate the translated code and adapt idioms or APIs, but as a first step, it can significantly speed up the process.

5. Learning aid

Naturally, the thing we all use LLMs for: quick learning! They can serve as an educator available 24/7. They can explain concepts, clarify syntax, or offer exercises.

For example, you can ask ChatGPT: “What does this error mean?” or “Give me a recursion exercise for beginners.” The model will generate explanations and examples that align with your knowledge level.

Again, this proves very useful for self-study, with the note that you must verify every claim.

Where LLMs consistently fail

LLMs aren’t perfect. They can speed up development, but real-world tasks reveal their limits – from subtle bugs and insecure code to flawed designs and privacy risks. Over-reliance can even weaken core developer skills.

Next, we highlight where LLMs often fall short and the risks teams should watch for.

1. Risks in production code

Do not assume that AI code works for production. Even when it looks correct, it can contain hidden bugs or incomplete logic.

Experienced developers warn: always “double-check your code, run the appropriate tests, and use your best logical judgement.” Also, keep in mind that models act non-deterministically—the same prompt can yield different results.

2. Security vulnerabilities

AI often suggests insecure patterns. Research shows that about 40% of Copilot suggestions contained exploitable vulnerabilities.

ChatGPT can generate similar problems (e.g., SQL injection, weak encryption). Best practice dictates treating every AI-generated code as insecure until you check it with static analysis and a code review process.

3. Limitations in system design

LLMs do not suit the creation of architecture or complex systems. They can assemble a diagram or deployment script, but lack an understanding of context and trade-off decisions.

They can also suggest outdated libraries or naive choices. Use them only for smaller parts of the design you control and verify.

4. Data privacy issues

Stay careful with what you send to LLM services. Prompts often get logged and stored. That means your code may end up in a future training set.

Experts warn that uploading source code into a public model can “inadvertently disclose vital trade secrets.” Never input confidential data (passwords, internal comments, user information) into public models.

5. Skill degradation

Excessive reliance on LLMs can cause developers to neglect fundamental skills. Junior developers skip learning basics, while seniors lose the habit of diving deep into problems.

As analyses warn, “skills atrophy” is a real risk. Over time, teams may code quickly but stay underprepared for unexpected issues. Best practice suggests using LLMs as assistants and tutors, not as crutches.

LLMs serve as helpful assistants but never as infallible ones. Treat them best “like Stack Overflow snippets: useful, but unreliable.”

Take advantage of the “yay” areas to accelerate routine tasks, but always keep the “nay” risks in mind. With careful use and human oversight, LLMs can help you increase productivity without breaking your codebase.

The post 5 Times LLMs Help You Code… and 5 Times They Fail appeared first on ShiftMag.

We all agree: saying no is important – it can be liberating, support work-life balance, and is a crucial life skill.

What’s discussed far less is the cost of refusing, especially the psychological cost. That’s what I’d like to explore: the emotional toll of refusing – on ourselves and on those we ask for something, even when we reassure them, “It’s totally fine if you can’t.”

It’s hard to refuse – and all too easy to agree

Overall, saying no often carries negative connotations, which is why we tend to avoid it. We dislike being in situations where our words or actions might be perceived as negative. It becomes even more difficult to decline in person – especially when we know the person well or feel emotionally connected to them or the topic.

People are generally more dismissive online or in anonymous settings, where the perceived consequences are minimal. It’s much easier to ignore or mock a request to “like” a post on social media than to say no to your mum when she asks for help picking apples.

In a professional setting, declining becomes even more complicated.

We’ve created a work culture where declining requests too often can feel like a career risk, especially for women and members of minority groups. Declining isn’t only disappointing for the person who asked; it might also mean missing out on a promotion or an exciting opportunity. Holy carp!

Conversely, accepting is effortless.

It feels nice and positive. You’re pleasing the other person, maybe even securing a future reward for yourself. What could be better? Since humans are wired to chase immediate rewards and often overlook future pain, we tend to say yes just to see that happy twinkle in someone’s eye – consequences be damned!

If you Google “how to say no”, you’ll get a lot of results, mostly focused on the actual skill of rejecting something. If you Google “how to say yes”, you mostly get results about how to say words and phrases in different languages. Declining is a tricky soft skill; accepting is often just about language.

Turning something down is… stressful.

So, where are we with no?

• We’re not that great at saying it.
• It’s not a pleasant thing to do.
• It can have negative consequences.

As a result, it’s often stressful to refuse a request.

We tend to worry about it before, during, and after the fact. This stress can be even worse if we’re already dealing with things like burnout, impostor syndrome, or anxiety. Saying no in those situations can feel like adding fuel to the fire. If I already don’t believe I’m doing a stellar job, turning something down might only reinforce the fear that others see me as a failure.

Our tendency toward herd mentality doesn’t help either. When most of the team says yes and we’re the only ones who want to say no, we often end up going along with the group, even if we feel conflicted inside.

Many of us have experienced this in sprint planning and sprint reviews – the team takes on more work than necessary during planning to avoid refusing requests, and then feels deflated and disappointed when they can’t deliver everything by the end. Over time, this can hurt team morale and spirit, lower motivation, and even create a toxic dynamic between teams and their stakeholders.

All of this leads to a simple point: refusing comes with its own burden. Telling someone to “just say no” can be disingenuous – placing the emotional and social cost of rejection on them, while pretending it’s easy.

Expecting a simple refusal hurts the ones who care most

The people who are most invested in a project, those who care deeply about the quality of their work and their team’s delivery, often your “best performers”, are usually the ones who find it hardest to say no. As a result, they often take the initiative to pick up tasks that others might reject.

If you keep asking, they may continue to agree, depending on their situation, until they eventually hit a wall and burn out.

Be kind. Don’t act like no is just a simple word

We should be mindful of our colleagues’ workloads and, whenever possible, avoid asking them for additional tasks if we know they might already have a full plate.

It’s important to recognize that they may feel unable or reluctant to refuse, even when they want to. And even when they do refuse, it can still come at a cost to their emotional well-being or personal life.

We should also recognize that refusal comes in many forms. It can mean:

• Literally saying no.
• Taking only 5 tasks out of 10 that were offered.
• Choosing not to volunteer when most others do.
• Not attending a meeting or participating in a Slack discussion.

All of the above can be difficult to do and may lead to negative consequences down the road, for both the individual and the team.

What’s the solution?

• Talk openly with your colleagues. Be aware of the challenges they face and the workloads they carry. Don’t expect them to simply reject additional work – understand their situation through honest conversations.
• Keep expectations realistic. Avoid presenting people or teams with overwhelming wish lists they can’t reasonably deliver. Don’t assume others will just say no to unreasonable demands.
• Diversify your requests for help. Instead of always turning to the same people who tend to say yes, reach out to others and distribute the load more evenly.
• Avoid herd mentality pressure. Give individuals space and time to make decisions independently, and encourage sharing outcomes in a safe environment. This is why practices like writing retrospective points individually or revealing estimations simultaneously in planning poker are important.
• Lead by example. Show that saying no when it’s appropriate is acceptable. Recognize that you might also struggle with this and discuss it openly with your team.
• Establish fair systems and processes. Ensure workloads are distributed transparently and fairly, rather than relying on informal methods that often favor those who find it easier to say no – which can unfairly burden those who care most about the project’s success.
• Don’t reward or idolize overwork. Encourage a culture that values balance and sustainable effort over relentless hustle.

The post Saying NO is not a free action in the world of software engineering appeared first on ShiftMag.

Procrastination – the act of delaying or postponing something – has been studied in academic settings, but never in the context of software engineers. What do developers procrastinate? How does it affect their work?

Researchers from the University of Southern California, Department of Computer Science, conducted an interview study with developers across different industries and levels of seniority to understand the process of procrastination.

They’ve found that procrastination has positive and negative effects, as well as factors that trigger it, as perceived by participants.

Getting That Deadline High

Among the 14 negative effects are rushed coding, accumulation of technical debt, poor code quality, and last-minute stress, which can lead to reduced team trust when tasks consistently run late. All of the participants also cited emotional distress as a negative effect of procrastination.

Yet, 80% of developers reported at least one positive effect, such as improved mood, creativity, or near-deadline efficiency. Racing against a deadline also boosts focus and productivity.

Why do Engineers Procrastinate

The study distills procrastination triggers into three buckets:

1. Task-related factors such as vague expectations, unpredictable scope, or excessive cognitive load.
2. Personal factors, including low energy, stress, impostor syndrome, or low intrinsic motivation.
3. External factors like shifting priorities, unclear ownership, dependency on others, or organizational friction.

The study highlights 19 practical techniques for mitigating procrastination. These include building awareness of patterns, structured planning, micro‑tasking, pairing or peer support, and task framing to raise engagement.

Struggling with procrastination? Read some first-hand advice from a fellow engineer:

The post Why Do Software Engineers Procrastinate? appeared first on ShiftMag.