Petri Hänninen

We've all been there. Sitting in a meeting looking at a slide where everything seems to be in order, and even of very high quality. But the confusion is still there: What am I, or anybody, supposed to get out of this? What is that person trying to say with this? Why are there so many graphs and numbers on this slide, what should I focus on?

This is what happens when people are evaluated on, or more often they evaluate themselves based on how much output they can produce. AI tools are able to gather a bunch of data, create graphs, compile them to a hundred slides and make them pretty with a couple of prompts if that. If you think producing more equals, or even roughly correlates, with the value you bring to your team, it's obvious that you will start to create more stuff.

But this is where you miss the point; you don't see that your value is in the key insights you find, not the hundred data points you gather. It's way more impactful to find the most crucial, most impactful idea and focus on it. Look at it from different sides, evaluate possibilities for creating change you think is worthwhile. Communicate your reasoning and your vision of what the situation should be. Formulate a plan, evaluate what you need, gather the resources to get that done and execute.

This isn't solely an AI slop issue either. There always have been people who think the purpose of their job is to recite numbers from a dashboard, the og meat proxies. But AI has made this issue way worse in two ways. First, it removes the effort from producing stuff, so people will just produce more. Secondly, it'll make you feel like you know the material, both by making things look like they make sense as well as simply by glazing you until you're sure you've got it. You probably don't.

Next time you're about to present something, just ask yourself "If I was allowed only a single data point or a single sentence to explain this, what would it be?"

If we want to actually tackle the issues, raise awareness, reap the benefits or just have any sensible discussion related to AI and its effect on us and the society, we need to define what we are talking about. Here is a short list of distinct topics, that all need exploring, analysing and considering but that shouldn't be mixed.

AI's Impact on the Day-to-day of a Knowledge Worker

How do you use AI at work? Will you become more productive? If some things in your work become faster and are not the bottleneck anymore, where do the bottlenecks shift?

AI as a Feature in an Already Existing Product

Do you already provide a product or service, and have you / the company you work for been doing that for the past 5 or 50 years? What are the new features and/or improvements to your current features that help you provide even more value or capture even broader market? Where can you embed AI to make your customers' experience even better?

AI as the Core Product of your Service

Did you start a new business on an opportunity that is only possible because what you can achieve with LLMs and other AI tools? What are the things that the world has never had that nwo could become a reality?

AI Providers

Is your company actually providing LLMs or related tools to others? Do you work at Anthropic, OpenAI or such?

AI Takes Our Jobs

If some jobs become more efficient to do, some people will lose their jobs. What can they do instead, will Jevon's paradox come to the rescue? Will there be a new group of people struggling to apply their old-world skills to this post-AI world?

Copyright Issues

Have the LLMs used been trained in lawful and morally acceptable ways? Should the original creators be compensated?

Information Security and AI Hacks

How should we deal with the fact that AI is used to break the security in pretty much every software on the planet and probably in space as well. Should the frontier models be guardrailed to avoid this, and if, how?

Slop

Fuck that please stop

We are all pushing out more code than ever before. Finally you get to create all the features from your icebox. Fix all the minor, tiny and nano bugs that have been waiting for resolution for ages. Refactor the annoying functions and modules that have bothered you since the "Initial commit". Rewrite everything in Rust.

But how much do all those things bring value to your users?

A Life Engineered did an amazing interview with Demetri Spanos. In the interview, when asked about us now being able to have agents go through hundreds and thousands of Jira tickets from the backlog and having projects essentially with zero tech debt, Demetri asks "why were they in the backlog" and answers his own question by "because they didn't matter very much [as] you always had something more important to do".

From what I know of things that have been on the backlog for ages, I very much agree.

Calculating the Diminishing Impact

Going further, he points out that if you have a list of 30 items you want done but have resources for 10, you will try your best to choose the most impactful 10. Then, getting to 15 or 20 actually isn't double the impact on your users but way less.

I think this point warrants emphasizing, so let's calculate this out.

Let's estimate that ordered by impact, your list of 30 will have a decreasing impact of 1/n * 100. Then, the first item will get 100 points, second 50, third 33 and so on. 30th item will have a score of 3.

The total sum of all 30 items will then be (1/1 + 1/2 + 1/3 + ... + 1/30) * 100 = 399. Accomplishing the highest-impact item on the list gets you 25 % there. To have half of the available impact, you need to achieve just 4 items (52 %). First 10 items give you 73 % of the results, so nearly 3/4.

And I think here the impact calculation is quite generous. If we go with something like 1/fibonacci(n), you are at 99 % already on item number 9. Or 1/2^n gives you 99 % at item 7. No matter how you decide to calculate this, assuming there is any decay on the value you provide as you go down the list, I think it's pretty clear that getting to the item #18347 on the Jira board that was created when either of the Bushes was president will probably not make your business the next Unicorn.

Do Only the Valuable Stuff

You still really need to consider what are the few things that actually create the most value and focus your efforts on those. Your users aren't there for the long list of whatever features but the few things that work well.

The apps and SaaS I find myself replacing most eagerly aren't the small and simple things but the apps that try to pack in everything and the kitchen sink. If I want to check the weather, I do not want to check local news. If I want to log my macros, I don't want to learn 10 new ways to cook broccoli. If I want to call mom, I don't want to also check out guitar tabs. And NONE OF THESE APPS NEED A GOD DAMN BUILT-IN SOCIAL MEDIA PLATFORM. /rant

Focus on what matters and your users will thank you.

What are is the ideal software team like in 2026? Who will have a job, who will need to re-skill and what roles become obsolete?

The main point lies here: A single engineer is capable of producing enough code in a week to last a lifetime. Back in the day aka a year or two ago the main bottleneck was the actual implementation of new features. That was what held the whole system back. Now that that's not the case, what kind of teams would be best placed to reap the benefits? I'll explore this first role by role and then summarize with a view of the whole team

What Are the New Role Descriptions Like

Software Engineer

We are now able to produce infinite lines of code. The questions then become either a) what's worth producing and b) how do we deal with all that. Let's look at both of them and how they shape the role of a software engineer in the future

A. What's worth producing

Here, everything comes down to taste. You need to be able to understand the business and ask questions like what actually creates value, where does the revenue come from, what's interesting to our customers.

Which customer segments should we focus our efforts on? Who brings the most value now, where is the unutilized potential for the future?

B. How do we deal with all that

You then need to combine those answers with your expertise about the software itself. Evaluate what your current stack is like and where the current software should be heading. Do not just look at the lines of code but think of things like the limitations on the infrastructure, complexities in the architecture, risks for performance and issues in accessibility.

Think of all of those and more, and you can provide valuable insights that nobody else can.

Product Owner

Somebody, who owns the direction we're going towards is crucial. Additionally, you need to understand the business goals and requirements and ensure you're aligned on what's important. Every person in the team can and should bring their own opinion into the mix, but you need to be the benevolent dictator that makes the final call.

There hardest part with the collaboration between PO and the rest of the team has been getting your vision across - it's not anymore. You can launch agents to gather insights from your data lake, come up with 10 mock-ups to evaluate, produce PoCs for your shortlist and actually show the rest of the team what you mean when you say "this needs X". This is a superpower and shortcut to better communication you cannot not ignore.

Make no mistake, the PoCs aren't supposed to immediately become the features. Before that you need to combine the rest of the teams' expertise into a coherent, well working feature that will not blow up in your faces.

UI/UX Designer

You're responsible for the actual look and feel of the product you deliver and nobody else in the team has the overall vision regarding that, this has not changed since the stone age. Visual quality and UX are still the prime differentiators from pure AI slop, as the agents, at least at the time of writing, still produce generic garbage.

But how you can achieve this broadens. Now you can build your own components in code. You can create functional prototypes not just with your design tool of choice but as actually working feature within your coded-up design system. Back in the day, even if you had a vague understanding of frontend code, the practicalities of production-grade software and hurried deadlines often ended up with the code being quite incomprehensible without a significant time investment. But what AI tools are great at is figuring out where some change needs to take place, so this barrier has now been obliterated.

Service Designer

Your role has always been and still is to be the voice of the user. You need to research, investigate, test things etc as you always have.

What's new now is that you can run any test in production. You might need to work with the engineer to get your system ready for a/b testing, asking users questions etc, but once the necessary guardrails are in place, you should be able to make any changes and tests you like. You have the best idea of what you want to investigate, no need for anybody to gatekeep the production app anymore.

Project Manager

With small enough teams where you don't need to coordinate work between e.g. a handful of engineers, project management is deprecated as an individual role. You should see this as an opportunity for re-inventing yourself, there are interesting things to focus on under the other headlines on this page, or you can always open up a cafe.

Ideal Team

And ideal team probably has 3-4(5) people. Four would be optimal: a person responsible for the UI, a person responsible for understanding the client, a person responsible for technical excellence and a person who brings this all together into a product vision and business outcome.

If you need to squeeze down even further, especially service designer is well-placed to bring in the business insights as well, and a small, well-functioning team can combine their vision into one without an overseer and overlord making the final choices.

In some special cases an extra person with some special skills can be brought in. This could be anything from a security researcher to a domain specialist, a sales rep to data analyst, or whatever needs your team has in that specific situation. These resources can come from elsewhere in the organization or for example bought in as consultants as needed.

No matter if your team structure is what I outline above or far from it, the fact is that the capabilities of everybody have expanded tremendously. You and your team need to investigate, what it is that each of you are now able to do that was only a pipedream a year ago.

Also, everybody should invest time in actually figuring out what their vision for the service they're working on is. How do you create value, what are the main pain points, where are the biggest opportunities? If you can answer these questions, you are more valuable than any agent.

Probably most of us have wondered, if AI will take our jobs. If you do nothing but grab the Jira ticket that somebody wrote, copy-paste it to your agent and forward the results, it definitely will. Or if it won't, the company you work for will be outpaced by a competitor, and the result will be the same.

How do you avoid this fate then? By bringing something that an AI can't: your taste. Any unique experiences and expertise you have gathered can be combined to create your own vision you and your team should be taking. Then you're not just a meat proxy, but somebody who helps shape the future and thus provide an alternative PoV that any general LLM can't.

To gather the experience, you need to gain smoe battle scars. Build stuff, break stuff, figure out what went well and what did not. Learn new things, run experiments and gain perspective. Do not just restrict yourself to code stuff either. Solve issues in your day to day. Read a book on business, design or whatever domain you care about. Write about you experiences, record a video or have a chat with a friend over coffee or beer. Every single thing you do is a step forward.

Here's simply a list of my most-referenced XKCDs.

• Standards
• Workflow / Hyrum's Law
• Dependency / Thankless in Nebraska
• Nerd Sniping
• Compiling
• Pascal's Law
• Flow Chart
• Goodhart's Law
• Tasks / Estimate What's Hard or Easy